December 23, 2010 at 2:28 pm
This is loosely related to backups, so hopefully this is an appropriate place to ask.
Our production database is corrupted (see http://www.sqlservercentral.com/Forums/Topic926228-266-1.aspx for history). We've taken a backup and restored the backup on a test server and ran CheckDB with REPAIR_ALLOW_DATA_LOSS. That took a couple days to complete. We don't want to take that much down time in our production environment and are wondering if we could setup a new machine, take a backup and restore the backup to the new machine, run the CheckDB with REPAIR_ALLOW_DATA_LOSS on that machine, then start applying transaction logs from the production server to the other server to bring it up to date with any information that has changed since the time the CheckDB was running.
Is such a thing possible? Or is the answer, "It might work or it might not work."
Any other tips/ideas on how to repair a database with minimal downtime?
Thanks,
Kevin
December 23, 2010 at 3:34 pm
Unlikely, the lsns probably won't match. Try on your test server to be sure, restore backup with norecovery and see if it'll take a log backup. Very doubtful that it'll work (as in almost certain it won't).
As for other options - restore the repaired database alongside the prod, sync data (Redgate's SQLDatacompare comes to mind), then drop old and rename repaired DBs
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 23, 2010 at 5:38 pm
Thanks, Gail. You're always very helpful.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply