December 26, 2008 at 8:28 am
The thing you need to determine is why your log files are getting so big? Perhaps they need to be big, perhaps you do not have a proper schedule for log backups.
Shrinking should be a rare occurrence, not regular maintenance. If it is regular, you are not managing SQL Server well.
December 26, 2008 at 10:24 am
1. Everything Steve said.
2. why not use shrink (shrink file rather than shrink db) to shrink the log files? what are the downsides?
The downsides to shrinking in general are file fragmentation and resource usage. Shrinking is not free and can put a strain on your production systems.
3. Backup log file with truncate_only option and shrink database log file.
If you choose this option and are using the full recovery model, you just broke your recovery chain. Do a full backup immediately.
December 27, 2008 at 1:52 am
Gents,
many thanks for the comments. I am a developer rather than DBA so the whole transaction log file thing is out of my area of knowledge. Are there any good articles that explain abbout log files and possibly best practice.
They are growing at quite a rate as there is no backup. (except when I do one manually. This is something I am very kean to change as I have noticed that this does cause severe issues where I am currently working. There seems to have been no DBA for some time and thus it has fallen upon me to try and sort out a few big issues.
Many Thanks.
Ells
December 27, 2008 at 3:01 am
I posted a link to a doc about tran log management earlier in the thread.
GilaMonster (12/22/2008)
Take a read through this - http://www.sqlservercentral.com/articles/64582/
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply