............ Have a nice day............
USER MENU ID IS UNDEFINED IN FINACLE MIS SERVER   Date of Implementation of "VERY GOOD" Bench Mark for MACPs effect from 25.07.2016   Expected DA from Jan 2017 – 3% or 2% ?    One minute talk time for each Rupee in Airtel Payments Bank   AICPIN for October 2016 : Chances for 5% DA from January 2017   Central Government employees retiring from January 2017 to submit online application   Pre-Budget Views of Govt. Employees for inclusion in the Budget for the Year 2017-18: Confederation i.e. Scrap NPS, Minimum Wage Rs. 26,000 & Fitment Formula etc   On Salary Week, Banks Unlikely to Meet Demand for Extra 1 Lakh Cr   82 per cent ATMs dry because government used that money to pay its own employees   National Anthem Before Movie, Rules Supreme Court. Citizens 'Duty-Bound' To Show Respect    undefined

Monday, 13 May 2013

Is running repair on msdb safe?


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:
  1. 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.
  2. 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.

No comments:

Post a Comment