May 28, 2018 at 5:57 pm
Weekly Maintenance Job checking DB integrity returns alertsabout corruption DB:
CHECKDB found 0allocation errors and 4 consistency errors in table 'myTable' (object ID 12345678).
CHECKDB found 0allocation errors and 8 consistency errors in database ‘MyDB’
Same info was confirmed:
SELECT * FROM [msdb].[dbo].[suspect_pages];
database_id file_id page_id event_type error_count
7 1 169223 4 4
7 1 169223 1 5
7 1 169222 2 5
As per CHECHDB: ” repair_allow_data_loss is theminimum repair level for the errors found by DBCC CHECKDB”
I know that most popular advice in that case is- find last good DBbackup, but I have no idea when it happened (another team monitor that server)- DB was restored from month oldbackup that already had corruption.
Question- if Repair Allow Data Loss won’t help what else option(besides to run 🙂) do we have?
Thanks,
May 31, 2018 at 4:11 pm
Yuri55 - Monday, May 28, 2018 5:57 PMWeekly Maintenance Job checking DB integrity returns alertsabout corruption DB:
CHECKDB found 0allocation errors and 4 consistency errors in table 'myTable' (object ID 12345678).
CHECKDB found 0allocation errors and 8 consistency errors in database ‘MyDB’
Same info was confirmed:
SELECT * FROM [msdb].[dbo].[suspect_pages];
database_id file_id page_id event_type error_count
7 1 169223 4 4
7 1 169223 1 5
7 1 169222 2 5
As per CHECHDB: †repair_allow_data_loss is theminimum repair level for the errors found by DBCC CHECKDBâ€
I know that most popular advice in that case is- find last good DBbackup, but I have no idea when it happened (another team monitor that server)- DB was restored from month oldbackup that already had corruption.
Question- if Repair Allow Data Loss won’t help what else option(besides to run 🙂) do we have?
Thanks,
It really depends. Sometimes if it's just a single table corrupted and you have it in another environment (dev, test,etc) that can help. You can try to dig through some older backups to find one that doesn't have the errors and you may be able to use the table from that backup. It really depends on what's corrupt. I've had occasions where I could get at most of the data in a corrupt table but not all. That's always worth checking. It may just be a table that really used, has no dependencies. You want to dig into those type of options. Otherwise maybe get some new running shoes.
I like doing refreshes to lower environments for things like this - run database consistency checks, you verify the backup with a restore, etc.
Sue
May 31, 2018 at 4:24 pm
Thanks Sue- Business agreed to repair with data loss after we did the test- restored same "corrupted" already backup and run repair- 1 row was recovered but 260 were deleted (around 01.% of total). Why it happened- maybe hardware issue, still not sure.
May 31, 2018 at 4:34 pm
Yuri55 - Thursday, May 31, 2018 4:24 PMThanks Sue- Business agreed to repair with data loss after we did the test- restored same "corrupted" already backup and run repair- 1 row was recovered but 260 were deleted (around 01.% of total). Why it happened- maybe hardware issue, still not sure.
Years ago when the database files weren't excluded in antivirus, that software would corrupt the files id/when they hit them. That's the only time I've seen it be something other than hardware. It's pretty rare to be something other than hardware these days. It can be something else but not likely.
Sue
June 14, 2018 at 11:30 pm
This was removed by the editor as SPAM
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply