Logical Consistency Error

  • It seems that I have some corruption within a user database. Running DBCC CHECKDB results in the following error:

    Msg 8921, Level 16, State 1, Line 1

    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

    I tried running DBCC CHECKALLOC and DBCC CHECKCATALOG. Both complete without an error. Next, I ran DBCC CHECKTABLE on each table. I found a single table that produced the same error as above from DBCC CHECKDB.

    When I try to query the table (for instance, SELECT COUNT(*) FROM dbo.Table), SSMS returns this error (which is identical to the corresponding errors in the SQL Server error log and the system event log):

    Msg 824, Level 24, State 2, Line 1

    SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:98530; actual 57553:769). It occurred during a read of page (1:98530) in database ID 26 at offset 0x000000301c4000 in file 'D:\Program Files\Microsoft SQL Server\MSSQL10.ATLCSETASQL\MSSQL\DATA\xt3_newbraunfels_01.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

    Next, I took the info from above and ran this:

    DBCC TRACEON (3604)

    DECLARE @DBId INT = DB_ID(DB_Name())

    DBCC PAGE( @DBId, 1, 98530 )

    I'm trying to interpret the output from DBCC PAGE (see attached). However, I'm not sure how to proceed.

  • The best way to recover from this is to restore from a good backup.

  • Dave Mason (5/29/2014)


    It seems that I have some corruption within a user database. Running DBCC CHECKDB results in the following error:

    Msg 8921, Level 16, State 1, Line 1

    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

    Restore from backup.

    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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Thanks Jack and Gail. On May 10th and May 17th, I took full backups. DBCC CHECKDB completed with no errors on the 10th. The logical consistency error showed up on May 17th. I'm thinking I could restore the May 10th backup to a temp db name, truncate (or drop) the offending table in the current db, and rebuild it with data from the backup. Do you think this strategy is worth trying? Or is it strictly an all-or-nothing problem?

  • Restore the database from a clean backup, before the corruption occurred. You have some corruption more sever than just that table or checkDB wouldn't have aborted with an error

    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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • I don't know enough about the database to know if your data would be in a consistent state if you restored to another database name and rebuilt the table from the almost 3 week old backup. If there is enough data that would have to be re-entered or lost it might be worth a shot. If there isn't a lot of work created by just doing a restore and starting over from that point I'd go with that.

    You should also be checking your storage to make sure it doesn't happen again. Usually there are hardware issues when a database gets corrupted.

  • I restored the May 10th backup. DBCC CHECKDB still fails. I double-checked the SQL Server Agent job history. The May 10th job that created the full backup and ran DBCC CHECKDB succeeded.

    I'm at a loss...

  • Did you ever test the backup after it was made?

    Restore it somewhere else and check as well.

    Also, make sure you restored the right backup in the right place. 🙂

    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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply