On one of our MS SQL Server 2005 boxes, we have a small problem each morning when the Maintenance Plan runs. For just a few seconds, the server's C:-drive gets filled up, leaving less than 1GB free, where normally it has more than 7GB free. It is interfering with the replication program on the system, which halts when the free space dips too low but doesn't automagically start itself when its free again.

(To give you an idea of how fast it goes, here are this morning's times: At 05:08:43 Free disk space <1GB, then at 05:08:51 Free disk space >7GB. In less than 10 seconds 6gb of data was created and destroyed.)

The Maintenance Plan does the following: check databases, shrink databases, reorganize indexes, and cleanup its old log files.

Note that SQL Server is installed on the C:-drive, but all the databases and the tempdb have been moved to another larger drive. Is there some other temp directory or such that SQL Server might be using during these tasks that I need to re-point to a different drive?

  • What recovery model(s) do your databases use? Are you using a separate log file, if so, where is it being stored? You should also check your auto-growth settings. – Eric H Sep 21 '09 at 17:03
  • Why are you shrinking your databases? – GilaMonster Sep 21 '09 at 17:11
  • Simple recovery, t-logs are in the same directory and are truncated when daily backups are made... which is about 6 hours before the maintenance jobs are run. There should be nothing else happening to the databases themselves at that hour, although the application servers keep the connection open. – ewall Sep 21 '09 at 21:08

Are you sure that it's SQL taking up the space? From what you describe, everything should be happening on the other volume. First thing I'd try is running a SQL Profiler trace during that time to see if you can see it. If that doesn't shed any light I would try running Process Monitor and see if you can track down what's going on.


Indeed, as squillman suggsted it was not SQL Server causing the problem. Or, well, I it was indirectly...

It appears that the replication program (the one that was getting the error) was also maybe attempting to replicate tempdb, and it keeps its cache files on the C:-drive. So when tempdb temporarily expanded for the checkdb and such, the replication program was copying all the changes to C:.

Last night I changed the replication program to ignore the tempdb files as well as keep its cache on the D:-drive, and the problem did not recur this morning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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