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 ««12

simple recovery model Log truncation Expand / Collapse
Author
Message
Posted Monday, September 24, 2012 5:00 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 10:03 AM
Points: 1,312, Visits: 2,482
To understand it better I am pointing you to an excellent article written by Gail:

http://www.sqlservercentral.com/articles/Transaction+Logs/72488/



Sujeet Singh
Post #1363415
Posted Monday, September 24, 2012 5:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:11 AM
Points: 7,128, Visits: 6,291
hp_dba_uk (9/24/2012)
Some of these DBs have never been backed up but were in Full recovery model. So does this change anything?

or is it a simple matter of watining?


Oh, heavens. I think you just granted me my daily dose of database terror with that statement.

If "some of these" databases have never been backed up, the first thing you should do upon reading this message is a FULL backup on all your databases. Then test the backups on a sandbox server to make sure your backup processes are working and not corrupting anything.

The second thing you want to do is schedule regular backups (full, differential, file, etc.) based on your recovery strategy.

Then, and only then, worry about your transaction log. There's a good chance the transaction logs are larger than they need to be if they never got backed up. Your best bet, if you really really need the drive space (OS as Divine Flame commented), only shrink by small increments and let the log sit for a few days to see if it increases in size again. If not, shrink another small increment.

If you try to shrink too much of the log, you may see a performance hit as the sql engine auto-grows the log again to account for the needed space. Especially if it has to "thrash" for the growth. (Even though it isn't really disk thrashing when the engine grows the file, I do actually use the phrase "thrashing" to describe the back and forth performed by the engine when it encounters a file that's just too small and the AutoGrow setting is also too small for the current set of transactions.)

If, however, you don't need the disk space, I strongly advise leaving the log file alone.


Brandie Tarvin, MCITP Database Administrator

Webpage: http://www.BrandieTarvin.net
LiveJournal Blog: http://brandietarvin.livejournal.com/
On LinkedIn!, Google+, and Twitter.

Freelance Writer: Shadowrun
Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
Post #1363417
Posted Monday, September 24, 2012 2:15 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, November 3, 2012 8:04 PM
Points: 37, Visits: 123
Divine Flame (9/24/2012)
To understand it better I am pointing you to an excellent article written by Gail:

http://www.sqlservercentral.com/articles/Transaction+Logs/72488/


Thanks
Post #1363719
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse