InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 03:24:52 GMT20http://www.sqlservercentral.com/Forums/Topic819433-357-1.aspxThanks I really appreciate the information.Mon, 16 Nov 2009 09:35:20 GMTmark_copleyhttp://www.sqlservercentral.com/Forums/Topic819433-357-1.aspxThe 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.Mon, 16 Nov 2009 09:31:07 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic819433-357-1.aspxI 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) ThanksMon, 16 Nov 2009 09:25:07 GMTmark_copleyhttp://www.sqlservercentral.com/Forums/Topic819433-357-1.aspxPlease read through this - [url=http://www.sqlservercentral.com/articles/64582/]Managing Transaction Logs[/url]Mon, 16 Nov 2009 08:56:43 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic819433-357-1.aspxAll -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 !Mon, 16 Nov 2009 08:50:35 GMTmark_copley