0

So, I got a corrupted database. This is the DBCC:

Msg 8944, Level 16, State 13, Line 4
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038845440, alloc unit ID 72057594039762944 (type In-row data), page (1:158), row 3. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 3139 and 288.

Msg 8944, Level 16, State 13, Line 4
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038845440, alloc unit ID 72057594039762944 (type In-row data), page (1:158), row 3. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 3139 and 288.

Msg 8928, Level 16, State 1, Line 4
Object ID 2105058535, index ID 1, partition ID 72057594038845440, alloc unit ID 72057594039762944 (type In-row data): Page (1:158) could not be processed.  See other errors for details.

Msg 8976, Level 16, State 1, Line 4
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038845440, alloc unit ID 72057594039762944 (type In-row data). Page (1:158) was not seen in the scan although its parent (1:159) and previous (1:156) refer to it. Check any previous errors.

Great. now if I query Suspect_Pages, I don't see any signal of issues:

enter image description here

I read here that DBCC captures it and put it into the table, but I'm not sure why i don't see it there.

https://www.stellarinfo.com/blog/monitor-sql-database-suspect-pages/

2 Answers 2

3

At the end of the day - you have a corrupted database. The Suspect_Pages table notwithstanding, you have corruption. And many types of corruption will not log an entry there - and even then they are only logged there in certain circumstances.

Whether there are entries there or not - the corruption must be dealt with. And that must happen fast while you have backups available.

If you are running checkdb frequently, and maintain your databases in full recovery model with ample log backup history and know when your DB was good - restore is the best bet. But don't use the lack of a row in suspect_pages for anything in decision making processes.

2

The suspect_pages documentation mentions only 823 and 824 errors are captured:

Contains one row per page that failed with a minor 823 error or an 824 error. Pages are listed in this table because they are suspected of being bad, but they might actually be fine. When a suspect page is repaired, its status is updated in the event_type column.

I suggest you start with the doc as the authoritative SQL Server reference.

2
  • Doesn't that view also depend on checksum/torn page detection being enabled for the database/the pages in question being checked? Mar 4, 2022 at 16:34
  • I don't below, @ErikDarling. Any IO error can cause 823. Error 824 may be due to checksum or torn page but may be due to other causes too.
    – Dan Guzman
    Mar 4, 2022 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.