September 16, 2014 at 5:28 am
Then we (well you) have a problem...
You can choose to repair and lose those ~50 rows
You can choose to restore to the last known good backup (one before the corruption occurred) which means reverting the entire DB to an earlier point in time
Or
You can repair, lose those 50 or so rows, then restore the last backup alongside the production DB and try to sync the missing data across. A tool like SQLDataCompare could help here. It does mean that any changes to those rows since that backup are lose
There is, however, no way you're going to recover this without data loss.
If you'd had log backups as well as those daily full backups, then it would have been possible to recover from this without any data loss. Since you don't, that's not possible.
To be honest, there's no good reason for a DB with critical data to not have log backups being taken.
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
September 16, 2014 at 5:40 am
thank you for following up and your help deare GilaMonster:-)
September 16, 2014 at 9:14 pm
This was removed by the editor as SPAM
September 17, 2014 at 4:25 am
thank you:-)
September 17, 2014 at 4:46 am
Bear in mind that in your case the pages were zeroed out (overwritten with zeroes), so unless a tool is capable of undoing that (which last I heard required a scanning electron microscope), it's not going to get your data back.
Also, you need to go and check your IO subsystem for errors, out of date drivers, etc.
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
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply