The transaction log for database 'WSS_Content' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Question

Hi all,
Observing the below error in event logs once in every day at 3:30 AM on the on SQL Server Machine, it is being used for TFS 2010.
The transaction log for database 'WSS_Content' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
Kindly advice me here on what to do?
Thanks in advance

Answer 1

First thing to check is, what is happening at 3:30am to cause the log to fill up?  Is there any maintenance tasks being run against the DB, such as index re-organizations or rebuilds?  If so, take a look at what the job is doing, maybe it could
be tuned (ex:  A Maintenance Plan with a rebuild indexes task will rebuild *every* index whether it needs it or not.  Look at using something that checks how fragmented an index is, and then intelligently determines what, if anything, to do to that
index.)
Basically, the error is telling you that SQL is trying to do something in the DB, and has filled up the log (either because it's not getting backed up often enough, or the transaction in question is running *very* long, or your log is set to not auto-grow)
So, a couple possible solutions:
Increase the frequency of Transaction Log backups of WSS_Content (only works if the DB is in Full Recovery)
If you've got the disk space, turn on auto-growth for the TLog (or just manually grow it larger) {This will work for both Full and Simple Recovery}
It would be nice to know what's causing the space to not be re-used, but with this occuring at 3:30am, you'll either need to set up an Agent job to run around that time and record its results, or manually run something like "select log_reuse_wait_desc from
sys.databases where name = 'WSS_Content';"  Me, I prefer to be soundly sleeping at 3:30am and would set up an Agent job to run from say about 3:00am to 3:45am once per minute (maybe even more frequently.)
DON'T shrink the log, though.  SQL will idealy grow the log as large as it needs it (if autogrowth is enabled) and no more.  If you shrink the file, SQL will just have to re-grow it later again, which can affect performance.
Jason A.