Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've a problem I'm investigating whereby my tempdb logfile grows out of all proportion to anything which would seem sensible. This morning it was over 10x the size of the data files. However, the database continues to function fine and the only limit on the size of the templog seems to be the size of the disk it's on.

My question then, would it be safe for me to limit the size of the templog, I have heard you shouldn't limit the size of tempdb as it is critical for work which needs to be done within sql server. But, the fact the log file grows just to the size allowed by disk suggests I could limit it without breaking anything. Is this the case? and If so, is there a lower bound (ie the combined size of the data files) I should not limit it below?

Btw, I realise that this is not a solution to the issue of the log growing, that is being investigated but may not be solved soon.

Cheers,

share|improve this question
    
just out of curiousity, how big (mb) are the tempdb data files, and how big is the log? –  BradC Sep 3 '09 at 13:33
    
the data files (2 of them ) were 4.5gb each, the log was 145gb. 145 was the limit of the space available on the disk. Previously it had stopped growing at 45gb which was the limit of the disk it was on then. –  Robin Sep 3 '09 at 14:09
    
yeah, that's pretty outrageously big, compared to the data files. –  BradC Sep 3 '09 at 22:45
add comment

2 Answers

up vote 2 down vote accepted

All you are going to do by limiting the size of the log is cause a failure when whatever is growing the log hits the limit. (Will error out and probably roll back the transaction).

Actually, might be a usable way to see what is growing the log so large! :) Although an even better way would be to use Perfmon to monitor the SQL:Database:Log Used (kb) counter to see when it is growing, and correlate that to other activity on the server.

share|improve this answer
add comment

We had a similar issue, after having raised PSS call with Microsoft and in-depth investigation of the issue we zoned into the following possible cause and resolution.

Cause:

The probable cause for the symptoms are due to disks/lun's on which user databases are placed having severe I/O response issues; this causes the automatic checkpoint on user databases to take very long to finish.

Now, checkpoint on tempdb occurs only when the tempdb log becomes 70% full and also it has a lower priority than user database checkpoints. So, effectively when automatic checkpoint on user database/s is issued and is trying to complete, due to heavy tempdb usage causes the tempdb log file to fill up quickly; at 70% log usage the tempdb checkpoint occurs but is queued behind the user database checkpoint.

In the time it takes for the user database checkpoint to finish the tempdb log file keeps getting filled up and if autogrow is set the log file grows when it requires more space. This is the reason the log file keeps growing.

In summary, the most possible root cause for the symptoms you describe are due to poor I/O response from the disks/lun's for your user and/or tempdb database/log files.

Solution:

We worked around the issue while we sorted out the I/O subsystem by setting up an alert which fired when the tempdb log file became 75% full and in response executed a job which forced a manual "CHECKPOINT"(which takes precedence over automatic system checkpoints), clearing out the tempdb log preventing it from auto-growing indefinitely. It is still a good idea to leave the log file on auto grow for any other eventuality.

Hope this helps.

share|improve this answer
    
Also, might be a good idea to shrink the log file to something more meaningful after you put the workaround in. –  Chirag Sep 3 '09 at 14:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.