Peter and I resolved this via email.
In case anyone else has a similar issue, this is how we resolved it:
To resolve the long running query, I had to cleanup the backup history tables in msdb. backupmediafamily was over 18 million records which is what was causing the slowdown.
Take away: Make sure you either enable the msdb history cleanup in SQL Backup, or run your own maintenance job to prevent the tables from growing too large.
In case anyone else has a similar issue, this is how we resolved it:
| Quote: | ||
We'll need to turn on a trace flag in SQL Backup then. To do this, you need to add a -sqbdebug option to the SQL Backup Agent service. Stop the SQL Backup Agent service. In the registry, look for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLBackupAgent_<your instace name> In the ImagePath value, add the -sqbdebug option e.g. C:\Program Files (x86)\Red Gate\SQL Backup 7\SQL2005\SQBCoreService.exe -i SQL2005 -sqbdebug Start the service. You should see a file named SQBCoreService_log.txt created in the folder where the SQL Backup Agent service executable is located e.g. C:\Program Files (x86)\Red Gate\SQL Backup 7\<your instance name> Let the job run once, preferably without the GUI running (as it'll add a lot of noise to the log). Investigated the debug log output and found this long running query:
|
To resolve the long running query, I had to cleanup the backup history tables in msdb. backupmediafamily was over 18 million records which is what was causing the slowdown.
Take away: Make sure you either enable the msdb history cleanup in SQL Backup, or run your own maintenance job to prevent the tables from growing too large.