Dave Mason walks through troubleshooting one database corruption scenario:
I’ve been lucky with database corruption during my career. I could probably count on one hand the number of times I’ve had to deal with it. A couple times, it was in a customer’s environment–they managed it themselves, but called me in to help. The other incidents were ones I inherited from a backup I had to restore into a production environment. The first time it happened to me, I didn’t realize it until days later when DBCC CHECKDB ran during a weekend maintenance window. After that, I added a new “rule” to my list: always run DBCC CHECKDB after restoring a database from someone else. That rule paid dividends today.
Here’s the output I saw:
Msg 8914, Level 16, State 1, Line 50 Incorrect PFS free space information for page (1:2564368) in object ID 457768688, index ID 1, partition ID 72057619124060160, alloc unit ID 72057594116767744 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL. CHECKDB found 0 allocation errors and 1 consistency errors in table 'tbl_Redacted' (object ID 457768688). CHECKDB found 0 allocation errors and 1 consistency errors in database 'db_redacted'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (db_redacted).
Read on to see how Dave solved this issue.