January 15, 2013 at 12:33 am
I have some sql server database for which recovery model is set to full.Now for some databases the ldf size has become large.I tried taking log backup regularly,but i didn’t find decrease in physical size of ldf. I followed what stan20 has told in this link http://social.msdn.microsoft.com/Forums/en-US/databasedesign/thread/704bcfbc-9251-4f4e-9a80-04bc7fe9ae78 But it only reduced logical file size. So how i can mange size of ldf file?
January 15, 2013 at 1:17 am
Please read through this - Managing Transaction Logs[/url]
If the log file has grown too large, a once off shrink to bring it back to normal size is fine. Log backups don't shrink the log, just allow the space inside to be reused.
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
January 15, 2013 at 5:59 am
So log backup only reuse the space. But shrinking the log file will increase fragmentation ryt? So is it good habit to shrink the log file?
January 15, 2013 at 6:10 am
winmansoft (1/15/2013)
But shrinking the log file will increase fragmentation ryt?
No.
So is it good habit to shrink the log file?
Not regularly, no.
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
January 15, 2013 at 6:33 am
winmansoft (1/15/2013)
So log backup only reuse the space. But shrinking the log file will increase fragmentation ryt? So is it good habit to shrink the log file?
LOL.. got to love Gail's short answers, I guess the hint is to go and read the article. But here let me try and help with hopefully, a simple example:
Consider the following scenario:
1) You create a database and assign 100MB for data file and 100MB for log file.
2) You perform a large data import and some complex data manipulation on the database.
3) When you check the size of your files you find that the data file has grown to 1GB and the log file 2GB!
4) A week later you do another big job on the database which requires 3GB worth of transaction log information to be recorded. Suddenly your log file is 5GB in total size
You can see where this is going... as more stuff happens in your database, the log file will just keep growing and growing (assuming auto growth is enabled). Either way, you would soon find out about it when your machine runs out of disk space or SQL can't write to the log file!
So how to solve this?! Shrink or backup log file you say?
a) Log backup will basically allow SQL Server to re-use the space that was occupied by the backed up transactions. The actual size of the file will remain the same (until you perform another massive work load which might increase the size of the log from 5GB to say 7GB
b) Shrinking the file will give back the space the OS but if you know you're going to perform more large data manipulation then it's just going to grow again anyway.
Hope this helps.
---------------------------------------------------------
It takes a minimal capacity for rational thought to see that the corporate 'free press' is a structurally irrational and biased, and extremely violent, system of elite propaganda.
David Edwards - Media lens[/url]
Society has varying and conflicting interests; what is called objectivity is the disguise of one of these interests - that of neutrality. But neutrality is a fiction in an unneutral world. There are victims, there are executioners, and there are bystanders... and the 'objectivity' of the bystander calls for inaction while other heads fall.
Howard Zinn
January 15, 2013 at 6:55 am
Abu Dina (1/15/2013)
3) When you check the size of your files you find that the data file has grown to 1GB and the log file 2GB!4) A week later you do another big job on the database which requires 3GB worth of transaction log information to be recorded. Suddenly your log file is 5GB in total size
Won't be 5 GB. If it's in simple recovery or full recovery with log backups it'd be around 3GB or less. If full recovery and no log backups, probably a lot larger than 5GB because it'll contain every single data modification during the week, along with the 5GB of data loads.
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
January 16, 2013 at 6:43 am
So shrinking only log file will not increase the fragmentation?
January 16, 2013 at 7:26 am
No. Repeatedly shrinking and letting it grow might lead to file-system fragmentation.
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
January 16, 2013 at 7:34 am
winmansoft (1/16/2013)
So shrinking only log file will not increase the fragmentation?
Are you talking about index fragmentation??
If yes it happens only if you shrink data file or the whole DB
January 16, 2013 at 7:38 am
winmansoft (1/16/2013)
So shrinking only log file will not increase the fragmentation?
Shrinking the data file will cause fragmentation within the database, and as Gail has stated, regular shrinking in general (both Log and Data) will lead to fragmentation at the filesystem level. And if you're using RAIDed storage, defragmenting such storage devices will take a considerable amount of time (which your SQL Server will be unavailable).
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
January 16, 2013 at 9:57 am
Best practice of shrinking the transaction log is to shrink it all the way down to smallest size possible (close to 0) and then alter the log to grow it back to the desired size.
If the desired size is greater than 4gb, then alter the size in 4gb chunks. Per Kimberly Tripp (if I remember correctly), when you create the tran log greater than 4gb or alter it by more than 4gb, the vlf sizes are greater than what is optimal.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply