In SQL server, how do you reduce the log files size without (DBCC) shrinking it. I know shrinking the log file will free up some space, but will also cause fragmentation. Doing a checkpoint in simple mode or backing up the transaction log in full mode should do the trick, but it is not working in one of my scenarios. Any advice/links will help in preventing log file fragmentation.
|
|
Once the log claims disk space the only way to get it back is to shrink. Checkpoints and truncation will free up space within the log file (now available for future use by the log) but the actual footprint of the file on disk stays the same. Read these articles for good information not only about how this works but the pro's and con's of messing with it. Most DBA's would agree that shrinking is not a good idea in most normal cases (as you eluded to in your question). http://msdn.microsoft.com/en-us/library/ms365418.aspx pros and cons |
|||||||||||
|
|
The only way you can change the physical size of the log files is using DBCC SHRINK. CHECKPOINT will do only log truncation but that never changes the physical log file size.\ http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx |
|||
|
|
|
I'm not sure the OP is referring to the physical footprint. He indicates a CHECKPOINT nor a log backup freed up space. This make me think he's referring to how much of the log is "active". My suggestion would be checking for open transactions which would prevent the active part of the log from clearing - DBCC OPENTRAN. |
|||
|
|