Post reply

DBCC CheckDB fails

  • January 29, 2013 at 12:14 pm

    #273529

    I get below error msg when I issue DBCC CHECKDB (DBNAME) WITH NO_INFOMSGS, ALL_ERRORMSGS:

    Msg 2576, Level 16, State 1, Line 1

    The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:204) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057594054901760 (type Unknown), but it was not detected in the scan.

    CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.

    CHECKDB found 1 allocation errors and 0 consistency errors in database 'ATTracker2'.

    repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB

    I backed up the DB, created a new DB, and restored from existing one but still got the error. I even tried DBCC with data loss, but that did not fix the problem. This database is using file stream, I am not sure if it was created correctly to begin with.

  • January 29, 2013 at 12:28 pm

    #1582308

    Hi,

    Was the database in single user mode when you ran the repair?

    Andrew

  • January 29, 2013 at 12:30 pm

    #1582310

    The repair will not be done if it is not set to a single mode! The answer is YES.

  • January 29, 2013 at 12:42 pm

    #1582316

    OK, just trying to help.

    As the first allocation error does not reference an object try creating a maintenance plan with a rebuild index task in it. Script out the index rebuilds and see if they relate to objects that still exist in the database.

  • January 29, 2013 at 12:45 pm

    #1582318

    There is a rebuild and reorganize jobs thar run on nightly basis, I do not think that is the cause.

  • January 29, 2013 at 12:48 pm

    #1582321

    What you're looking for is objects that no longer exist in the database but may be generating the allocation errors

  • January 29, 2013 at 12:56 pm

    #1582327

    That is not the case, just checked.

  • January 29, 2013 at 1:06 pm

    #1582334

    Backing up and restoring will never fix corruption, because the corruption is included with the backup and restored with it.

    Don't suppose there's a backup from before this started?

    Can you query sys.partitions, see what has a hobt_id of 72057594054901760 .

    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 29, 2013 at 1:13 pm

    #1582345

    Gail -

    1) There is not a good backup before that happened, it had the error when I took over the work.

    2) I do not get a record back when I select from sys.partitions where hobt_id = 72057594054901760

    Lava

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

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