Post reply

sys.allocation_units corrupted

  • January 27, 2009 at 12:42 pm

    #383812

    This is our customer db. SQL 2005 SP2.

    When they did a checkdb, they got:

    DBCC results for 'xxxxxx'.

    Msg 2515, Level 16, State 1, Line 1

    The page (3:10), object ID 7, index ID 1, partition ID 458752, allocation unit ID 458752 (type In-row data) has been modified, but is not marked as modified in the differential backup bitmap.

    There are 18466 rows in 200 pages for object "sysallocunits".

    CHECKDB found 0 allocation errors and 1 consistency errors in table 'sysallocunits' (object ID 7).

    Msg 7995, Level 16, State 1, Line 1

    Database 'xxxxxx': consistency errors in system catalogs prevent further DBCC checkdb processing.

    CHECKDB found 0 allocation errors and 1 consistency errors in table 'ALLOCATION' (object ID 99).

    CHECKDB found 0 allocation errors and 2 consistency errors in database 'xxxxxx'.

    repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (xxxxxx).

    DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    Anybody knows what could be the possible reasons for this to happen? Also, is it possible that an application could have caused this (by doing SQL) or is it more likely a problem of the db server?

    Thanks a lot.

  • January 27, 2009 at 1:16 pm

    #933471

    James Zhang (1/27/2009)

    Anybody knows what could be the possible reasons for this to happen? Also, is it possible that an application could have caused this (by doing SQL) or is it more likely a problem of the db server?

    Most likely it's a problem with the IO subsystem. SQL won't corrupt its own databases. Maybe stale reads, dunno. Check the windows event log and any drive logs that you have, see if there's anything else

    Do you have a clean backup? Since checkDB can't finish checking (consistency errors in system catalogs prevent further DBCC checkdb processing), I highly doubt it's going to repair.

    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

  • January 27, 2009 at 2:54 pm

    #933512

    Thanks for the notes.

    I, too, do not think any SQL operations could have caused this kind of corruption. Will focus on IO, etc.

    thanks.

  • January 27, 2009 at 4:45 pm

    #933561

    Yup - CHECKDB can't get past this. If you don't have a backup, you'll need to extract out to a new database (plus do root cause analysis).

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

Viewing 4 posts - 1 through 3 (of 3 total)

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