Just saw this on a forum – running REPAIR_ALLOW_DATA_LOSS on msdb to cope with corruption. Yes, this will work but it's certainly not safe and something I'd only recommend as a last resort.
Here's why: msdb stores your backup history and your Agent jobs. REPAIR_ALLOW_DATA_LOSS works by usually "delete what's broken and fix up all the links" (quoting myself). If you run repair on msdb, you need to pay close attention to what was deleted by repair, as it could lead to big problems later on. Some examples:
What if repair deletes a record which just happened to store the Agent job that runs the transaction log backups for your main production database? Suddenly your log isn't being backed up and you don't know about it. The log starts to grow and eventually runs out of space. The database stops and your application is down until you figure out what's wrong.
What if repair deletes a record which just happened to store the details of a log backup of the production database? Your have a disaster and run the script that looks through the backup history tables and auto-generates RESTORE statements to get you up and running again with up-to-the minute recovery. Because of the missing record, there's a missing RESTORE LOG statement in the middle of the restores of the log-backup-chain for the production database. So the restores fail, and you're down until you figure out what's wrong.
Bottom line, it's not safe to run repair on msdb – proceed with extreme caution. Not that repair won't work, or will cause corruption, but that it's far better to have backups of msdb that you can restore from.
3 thoughts on “Is running repair on msdb safe?”
I agree in general, Paul.
But to be honest, I sort of fail to see why we should treat msdb in any particular way. The types of problems you describe exists for just any database, right? All databases has dependencies and just ripping out whatever data might be corrupt will caus all types of havoc in your database. I know you know this, and have been an evangelist to not run REPAIR but as a very last resort – but I feel what you say here applies for all databases.
I agree with you, but my point is that if something gets deleted from msdb, it’s not *just* data – it can potentially affect the operations on other databases too – and that should be borne in mind when running repair.
As per your article…
(dbcc checkdb (dbname, repair_allow_data_loss) in emergency mode). Nope, msdb can’t be put into emergency mode.