In the past few weeks I've written a few articles about Maintenance Plans:
SQL
Maintenance Plans
Maintenance
Plans - Behind the Scenes
SQL
Maintenance Plans - Under the Covers!
Those covered quite a bit and really
I had intended to stop there, but I ran across another little quirk that I
needed to investigate - so I decided to document as I went and share! Basically
what happened is I had a maintenance plan set to backup all databases once per
day and to delete backups older than 2 days. First two days ran fine, the third
day failed. Can you guess? Yes, insufficient disk space.
Now you'd think...really...that it would make sense to delete the files
first, then do the backup? Here is a screen shot of the maintenance plan
history:
That seems to support my theory about the backup running first (look at the
7:31:38 pair). But just to be sure, I turned to another tool I use on occasion
for tracking down stuff like this, FileMon. You can download a freeware version
of it at www.sysinternals.com. It has
the ability to track ALL file access! I started it up and applied a filter:
I started FileMon running and captured the following which shows sqlmaint.exe
trying to open the backup file that it's about to create. This is the first
activity from sqlmaint.
Further down I captured this:
You don't see this line in the maintenance plan history. What happened is
before I ran the job the last time I set the existing .bak file to read only.
You can see that it tries to delete the earlier file and fails. So FileMon
supports my initial conclusion plus the results from the plan history that the
backup runs BEFORE the file deletes.
It's one of those things I hadn't run into before because I try to keep a
decent amount of free space on my servers. In this case I needed about 15g for a
nightly backup and only had 10g or so free after the second days backup. I
really like having two backups on disk, so I'll probably add a separate job that
runs a couple minutes prior to the backup to remove the older set of files.
Although I could shortcut the issue for now by using a tool like SQLZip,
I'd rather put a fix in place that will cause the behavior I prefer (and
expected!).
