Have you ever had problem with your backup jobs taking more time than usual overlapping your maintenance window? It is the disk IO throughput fast enough? or it is your SQL Server not performing well? what could be affecting the performance to avoid your backup job to completely in timely fashion?
The answer to all these questions is not that difficult to find, in most of the cases there is a common point of failure for backup jobs taking more time with the past of the time. Your databases are bigger and your backup and restore history has been retained forever (since the SQL instance was created).
Most of the DBAs in the wild doesn’t know about this very important performance tuning aspect, they completely forgot about paying attention to the MSDB database. Probably because this is a system database there is an assumption that does not requires maintenance as any other regular database.
According to Microsoft docs you simply have run the
sp_delete_backuphistory stored procedure in MSDB database, providing a date parameter to be used by this process as your oldest date to retain data to …. but guess what it does not work well and is not that simply.
Before you go for it, you must consider the following aspects:
- Purging this backup and restore history leads to blocking into MSDB
- Running the in
sp_delete_backuphistorystored procedure causes odd problems to your ongoing or scheduled SQL Agent jobs
sp_delete_backuphistoryit’s not optimal and takes a long time to run
So what are your options?
- Understand what the
sp_delete_backuphistorystored procedure is doing and write your own
Probably not the best option, because it will require you to invest time doing research, analysis, design and testing
- Look for missing indexes in all the MSDB tables purged by the
sp_delete_backuphistorystored procedure (Best option due the amount of time you have to invest creating a new process)
- Schedule a job to purge the backup history during short periods of time after all your daily jobs are completed
This is a good option, because we have identified those indexes beforehand for you and also there is no development effort to re-create a process that already exists. Also you probably can schedule a job to run every weekend to purge 2 weeks of data at the time so the MSDB is not compromised by the purging effort.
Based on our experience adding the missing indexes to all the tables involved in the purge process, we noticed an improvement of 60% of the
sp_delete_backuphistory stored procedure. So go ahead and try it and let us know how everything works for you 🙂
Happy purging, stay tuned for more DBA mastery tips.
- This indexes works starting from SQL Server 2008 R2 SP3
- You can find the MSDB Missing indexes script here
I’m a Microsoft Data Platform MVP also a very experienced multi platform DBA (MySQL, Oracle, SQL Server, SQL Azure) with over 10 years of experience in the database field.
I work in database support as primary consultant and DBA manager for larger US based companies in the healthcare, insurance, retail, food and energy industries.
I have a few certifications under my belt MCSE, MCSA, MCP, MCTS, ITIL v3, Docker, Kubernetes and RedHat openshift.
International speaker, blogger, Guatemala SQL community group leader, mentor.
Love everything related to technology, sci-fi and video games.