DBCC CHECKDB returned errors

  • Hi,

    DBCC CHECKDB returned errors for database Mydb as below:

    Please advise:crying:

    Msg 8928, Level 16, State 1, Line 1

    Object ID 1445580188, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594048151552 (type LOB data): Page (1:10725) could not be processed. See other errors for details.

    Msg 8939, Level 16, State 98, Line 1

    Table error: Object ID 1445580188, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594048151552 (type LOB data), page (1:10725). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.

    Msg 8965, Level 16, State 1, Line 1

    Table error: Object ID 1445580188, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594048151552 (type LOB data). The off-row data node at page (1:10725), slot 0, text ID 1844314112 is referenced by page (1:10715), slot 0, but was not seen in the scan.

    Msg 8929, Level 16, State 1, Line 1

    Object ID 1445580188, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594054574080 (type In-row data): Errors found in off-row data with ID 1844314112 owned by data record identified by RID = (1:13865:31)

    CHECKDB found 0 allocation errors and 4 consistency errors in table 'fw_testcase_detail_tcd' (object ID 1445580188).

    CHECKDB found 0 allocation errors and 4 consistency errors in database 'Mydb'.

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

  • Do you have backups you can restore from?

    Have you checked for I/O issues to your data files?

    Those two steps are where you should start.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • a DBCC UPDATEUSAGE (Mydb) will probably fix those 4 errors.

  • Geoff A (4/23/2012)


    a DBCC UPDATEUSAGE (Mydb) will probably fix those 4 errors.

    UpdateUsage will not fix those errors. The errors are not related to page space tracking.

    Errors that can be fixed with UPDATEUSAGE look like this:

    Msg 2508, Level 16, State 3, Line 1

    The In-row data RSVD page count for object "Broken1", index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.

    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
  • You've got one LOB page (large Object) in the table fw_testcase_detail_tcd that's damaged and unreadable.

    When did the corruption occur and do you have a clean backup from before that time?

    Also, what recovery model is the database in and do you have an unbroken chain of log backups since the clean 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
  • There are NO IO errors.

    There are 50 databases on the same instance and the corruption is on only one database Mydb.

    It is a QA database and in simple recovery model. I can restore it from the good backup.

    But I would like to know the root cause of the error.

    Does it might be due to wrong data entry? Please advise.

    Thanks

  • gmamata7 (4/23/2012)


    There are NO IO errors.

    Yes there are, somewhere.

    It is a QA database and in simple recovery model. I can restore it from the good backup.

    That's good at least

    But I would like to know the root cause of the error.

    Does it might be due to wrong data entry? Please advise.

    No, data entry of any form cannot cause corruption. Corruption is an IO subsystem problem, something in the IO stack wrote random garbage over an 8kb page.

    You need to do some diagnostics, check logs, ensure firmware and drivers are up to date.

    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 checked the below logs but did not find any IO errors:

    1. SQL Server errorlog

    2. Application Event viewer logs

    3. System Event viewer logs

    Is there any other logs I can look for IO errors?

    and this database was restored 3 days ago from a backup file (provided by 3rd party)and after one day, the weekly scheduled integrity job failed and reported the corruption errors

    Is there any chance that backup itself corrupted?

    If the backup was corrupted, then we should get errors while restoring it right? But I did not get any errors while restoring?

    Thanks

  • gmamata7 (4/23/2012)


    Is there any other logs I can look for IO errors?

    RAID array or SAN

    and this database was restored 3 days ago from a backup file (provided by 3rd party)and after one day, the weekly scheduled integrity job failed and reported the corruption errors

    Is there any chance that backup itself corrupted?

    Absolutely yes it's possible. If the DB never passed an integrity check after being restored there's a good chance that the backup contained corruption and the DB that was the source of that backup is corrupt.

    Might want to suggest to that 3rd party that they check their DB.

    If the backup was corrupted, then we should get errors while restoring it right? But I did not get any errors while restoring?

    You'd only get errors if the backup was taken WITH CHECKSUM. It's not the default and way too many people don't realise they should be specifying it on their backups.

    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 9 posts - 1 through 8 (of 8 total)

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