Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Best Practice Advice on Trans Logs, how to automate Expand / Collapse
Author
Message
Posted Monday, November 16, 2009 8:50 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 8:36 AM
Points: 264, Visits: 236
All -
Looking for best practice or way to keep transaction logs cleaned up. Working with (5) test region databases , all set to Simple Recovery. I have saw where Best Practices wants you to stay away from Shrinking the database regularly but wondered if there is some code to run regularly that would keep transaction logs trimmed down to acceptable levels. I thought of doing a Check Point then maybe a ShrinkFile on the log file but looking for opinons on that.

Example:

Use myDatabase1;
checkpoint
dbcc shrinkfile (myDatabase1_log, 15)

Any and all help appreciated, thanks !
Post #819433
Posted Monday, November 16, 2009 8:56 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 2:23 PM
Points: 40,656, Visits: 37,116
Please read through this - Managing Transaction Logs


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #819443
Posted Monday, November 16, 2009 9:25 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 8:36 AM
Points: 264, Visits: 236
I have read thru the Managing Transact Logs document but was kind of wanting some practical information. Like is the accepted practice to monitor transaction log files regularly and if they get to big, run a checkpoint and shrinkfile on the log file. (simple recovery)

Thanks
Post #819467
Posted Monday, November 16, 2009 9:31 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 2:23 PM
Points: 40,656, Visits: 37,116
The accepted practice is to size them for the workload (regardless of recovery model) and leave them alone.

Shrinking a log is a bad idea unless it's after an unusual operation and you know absolutely 100% that the log does not need to be that size. Repeated shrink/grow leaves you with lots of little VLFs in the log (slows down database recovery) and file-level fragmentation. Neither of which is something you want.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #819471
Posted Monday, November 16, 2009 9:35 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 8:36 AM
Points: 264, Visits: 236
Thanks I really appreciate the information.
Post #819477
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse