January 5, 2021 at 8:14 pm
Alright. Good news. Using the aforementioned approach, I was able to identify the problematic records. Unfortunately, I wasn't able to manually update or delete those records, but after running CHECKTABLE with REPAIR_ALLOW_DATA_LOSS, I was able to return the database to a working state, and using the previously identified records, was able to get the records deleted by CHECKTABLE and restore them from the production table (minus the binary data).
My plan is to now run the same CHECKTABLE against production, and then restore the deleted records from the backup above.
Thanks for the help Numpty and Jeffrey.
Also PS: I absolutely should have paid more attention to this when you brought it up two months ago in a previous post of mine, Jeffrey. I had kinda swept it under the rug at the time, since I had so many other things I was working on. Mea Culpa.
January 5, 2021 at 8:40 pm
Now that you got a path forward...make sure you setup daily backups and frequent transaction log backups - and verify those backups (as often as you can).
And...you really need to dig in and figure out what caused that corruption in the first place. If you don't fix that issue (generally hardware) it will just occur again.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply