Check All Your MSDB Cleanup Jobs With One Query

Are all of your servers set up to clean out their backup history periodically?

Are you sure?

If you looked back at the monitor with “WTF?” written all over your face, I’ll bring you up to speed.  Here’s the problem: SQL Server stores information about completed backups in the MSDB database.  In older versions of SQL Server, that database isn’t indexed very well, and it can become a performance bottleneck during backups and restores.  I’ve written about one particular case where I cut the company’s backup times by 2/3 just by cleaning out their backup history.

To make sure your servers are keeping their MSDB clean, you can use SQL Server Management Studio 2008’s new multi-server-query-execute feature to quickly query all of your servers.  Go read my article on how to query multiple servers at once in SSMS, and then run this query against your SQL Servers:

The query runs almost instantaneously since it’s sorted by the primary key of the table.  The results of the query are shown here:

Consolidated MSDB Backup History
Consolidated MSDB Backup History

In that screenshot, I can see right away that three of the servers in my lab have problems.  They don’t have cleanup tasks properly configured.

If you see results like this in your own environment, drop what you’re doing and go add MSDB cleanup tasks to your maintenance plans or add sp_delete_backuphistory to your T-SQL maintenance scripts.  The first time it runs, you may run into some horribly long runtimes and locks, unfortunately.

Previous Post
Managing People Sucks, But You Should Try It Anyway
Next Post
Laptop Virtualization Best Practices – And a Contest!

21 Comments. Leave new

  • Forgive me for being slow, but how can you tell those 3 have problems and not the others with dates preceeding 8/21?

  • Check the year.

  • Ah, oops. However, this gives me a good idea for a blog entry. 🙂

  • Fantastic! I saw this when you posted it originally but didn’t have the time to check then. Glad you did a recap of it as I now had the time. Records going back years is right! I had some going back to January of 2001! I had over 200k records in one of my backupset tables. It’s a good thing we only use simple and daily full backups at this point. I set a limit on how far back we want to save, created a job to run the sp_delete_backuphistory. I also added a step to reindex the tables it touched as well. You might not need the backupfilegroup table, as it doesn’t exist on all my servers I’m nto sure why. Probably only if you have ever performed a filegroup backup I’m not sure. These could always be werapped in an exists statement too.

    dbcc dbreindex (‘backupfilegroup’, ”) ;
    dbcc dbreindex (‘backupfile’, ”) ;
    dbcc dbreindex (‘backupmediafamily’, ”);
    dbcc dbreindex (‘backupmediaset’, ”);
    dbcc dbreindex (‘backupset’, ”);
    dbcc dbreindex (‘restorefile’, ”);
    dbcc dbreindex (‘restorefilegroup’, ”);
    dbcc dbreindex (‘restorehistory’, ”);

    Thanks Brent!

  • See for a script to more efficiently clear out the backup history.

  • Thanks Brent, David and Mufasa.
    Does anyone who uses SQL Agent Jobs should run similar task for cleaning jobs log regularly? I’ve found sp_delete_jobsteplog, and BOL says it’s purpose is “Removes all SQL Server Agent job step logs that are specified with the arguments. Use this stored procedure to maintain the sysjobstepslogs table in the msdb database.”
    Unfortunately, sp_delete_jobsteplog is not available on SQL Server 2000. Yeah, we still use it, but going to migrate. Fortunately, there is sp_purge_jobhistory “Removes the history records for a job.” which removes all log entrines for job/step specified.
    But there are even more space-cloggers in msdb – tables prefixed with DTA_. Right now msdbdata.mdf size is 1644Mb and there are 2,912,825 rows in DTA_reports_querycolumn_index table! These are because of DB Engine Tuning Advisor.
    Should I just drop rows from it’s tables because we don’t need it?

    • IL – good question. I haven’t worked with those tables, so I’m hesitant to say. I would probably truncate ’em though.

      • Brent, I’ve cleaned DTA* tables by
        truncate table DTA_reports_querycolumn
        truncate table DTA_reports_indexcolumn
        truncate table DTA_reports_queryindex
        truncate table DTA_reports_querytable
        truncate table DTA_reports_querydatabase
        truncate table DTA_reports_tableview
        truncate table DTA_reports_partitionscheme
        truncate table DTA_tuninglog
        truncate table DTA_output
        truncate table DTA_progress
        delete DTA_input
        delete DTA_reports_column
        delete DTA_reports_index
        delete DTA_reports_query
        delete DTA_reports_table
        delete DTA_reports_database
        delete DTA_reports_partitionfunction
        and msdb returned to 14Mb size after shrinking. Thanks again for good advice to clean msdb regularly.

  • oh look, i just #sqlhelped this!

    i heart this here blog entry. i remember and reference it, a whole year later.

  • Brent,

    How about the sysjobstepslogs table? It occupies 95% space on my msdb database.

    sp_delete_jobsteplog would delete records on this table.

  • Thanks for this, I was trying to figure out how to do this for like 2 months and of course the answer was under my nose.

  • Clean and simple.
    Very nice usage of multi-server-query-execute feature.
    I like it.


  • I have uncheck “Limit size of job history log”
    and make a maintenance plan to delete agent job history older than 2 months.
    however, I still find the job doesn’t help me to keep 2 months, ( i think it only keep 25-30 days only, depends on different job……..)


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.