none
DBCC CHECKDB error message

    Question

  • When i try the DBCC CHECKDB on my UserDataBaseLD the bellow error message is came.

    Msg 7985, Level 16, State 2, Line 1
    System table pre-checks: Object ID 5. Could not read and latch page (1:43844) with latch type SH. Check statement terminated due to unrepairable error.
    DBCC results for 'UserDataBaseLD'.
    Msg 5233, Level 16, State 98, Line 1
    Table error: alloc unit ID 327680, page (1:43844). The test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. The values are 29493513 and -1.
    CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single object.
    CHECKDB found 0 allocation errors and 1 consistency errors in database 'UserDataBaseLD'.

    Please help on this issue.
    Wednesday, June 24, 2009 6:44 AM

Answers

  • It seems you have some serious case of corruption in an important system table. My guess is that your only option is restore from a healthy backup. You can of course open a case with MS Support, but I wouldn't have too much hope for that.


    Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi
    Wednesday, June 24, 2009 7:03 AM
    Moderator
  • Yep, you could try to do a taillog backup in order to restore the data if this is corruption type which might not be reflected if restored again. But I think you might have to go to a previous log backup.

    See the blog post from Paul for this:

    http://www.sqlskills.com/blogs/paul/post/CHECKDB-From-Every-Angle-Can-CHECKDB-repair-everything.aspx

    -Jens
    Jens K. Suessmeyer http://blogs.msdn.com/Jenss
    Wednesday, June 24, 2009 11:13 AM
    Moderator
  • As the 7985 message says, CHECKDB can't progress past corruption at the leaf-level of clustered indexes in critical system tables. You'll need to restore from your backups. You might be able to extract some info from the database, depending on what position the broken page is in the sys.sysrowsets table.

    Not much point opening a case with MS, they're not going to be able to do anything. This is an I/O subsystem corruption. Do you have page checksums enabled?
    Managing Director, SQLskills.com (http://www.sqlskills.com/blogs/paul), SQL MVP, Microsoft Regional Director, Contributing Editor of TechNet Magazine, Author of 2005 DBCC CHECKDB/repair, Course author/instructor of Microsoft Certified Master - Database.
    Wednesday, June 24, 2009 3:52 PM
    Moderator

All replies

  • It seems you have some serious case of corruption in an important system table. My guess is that your only option is restore from a healthy backup. You can of course open a case with MS Support, but I wouldn't have too much hope for that.


    Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi
    Wednesday, June 24, 2009 7:03 AM
    Moderator
  • Yep, you could try to do a taillog backup in order to restore the data if this is corruption type which might not be reflected if restored again. But I think you might have to go to a previous log backup.

    See the blog post from Paul for this:

    http://www.sqlskills.com/blogs/paul/post/CHECKDB-From-Every-Angle-Can-CHECKDB-repair-everything.aspx

    -Jens
    Jens K. Suessmeyer http://blogs.msdn.com/Jenss
    Wednesday, June 24, 2009 11:13 AM
    Moderator
  • As the 7985 message says, CHECKDB can't progress past corruption at the leaf-level of clustered indexes in critical system tables. You'll need to restore from your backups. You might be able to extract some info from the database, depending on what position the broken page is in the sys.sysrowsets table.

    Not much point opening a case with MS, they're not going to be able to do anything. This is an I/O subsystem corruption. Do you have page checksums enabled?
    Managing Director, SQLskills.com (http://www.sqlskills.com/blogs/paul), SQL MVP, Microsoft Regional Director, Contributing Editor of TechNet Magazine, Author of 2005 DBCC CHECKDB/repair, Course author/instructor of Microsoft Certified Master - Database.
    Wednesday, June 24, 2009 3:52 PM
    Moderator