Does anyone restore a backup and run DBCC CHECKDB to check for errors before they restore the backup with no recovery to start Mirroring?
I'm guessing that you should just to be sure there are no errors in the file/restore process?
What happens if the mirror gets a corrupt sector? Would mirroring fail if normal processing touches that data?If the sector is dormant whilst mirrored I assume you get no warning until the mirror goes live and the data gets requested or a CHECKDB finds it?
asked Aug 22 '12 at 02:32 PM in Default
Problem is you have to then re-restore to get back to a mirroring state (i.e. restoring), essentially overwriting the database again, and that's now a different database to the one you've just DBCCd.
And yes you are right, you won't get any indication that the mirror is corrupted until something touches the corrupted page.Think the solution is to get mirroring up and running , then take a snapshot, and DBCC against that.
answered Aug 22 '12 at 06:05 PM
Kev Riley ♦♦
+1. Very nice. Until now we are not doing it as there is a process of DBCCing some databases randomly and some regularly (I am sure you would be running such kind of process in your environment as well). So a viable option may be to restore the already restored and DBCCd backup and then applying all the subsequent log backups? Which means you would not have the different database restored which is not DBCCd. As always, it all depends upon the environment and constraints.
But it absolutely makes sense to restore a fully verified DB to take full benefits of Automatic Page Repair. This same repair process may also answer some of the possible concerns raised by your questions.
answered Aug 23 '12 at 03:23 PM