how to correctly restore page ERROR (data-corruption)

  • hi All, i executed dbcc checkdb ('yout_Database') and

    result is as following:

    Msg 2533, Level 16, State 2, Line 1

    Table error: page (1:11760) allocated to object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594046578688 (type LOB data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.

    Msg 8965, Level 16, State 1, Line 1

    Table error: Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594046578688 (type LOB data). The off-row data node at page (1:11760), slot 1, text ID 5424095232000 is referenced by page (1:1374), slot 0, but was not seen in the scan.

    Msg 8965, Level 16, State 1, Line 1

    Table error: Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594046578688 (type LOB data). The off-row data node at page (1:11760), slot 3, text ID 5424095297536 is referenced by page (1:1374), slot 1, but was not seen in the scan.

    Msg 8965, Level 16, State 1, Line 1

    Table error: Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594046578688 (type LOB data). The off-row data node at page (1:11760), slot 4, text ID 5424095363072 is referenced by page (1:1374), slot 2, but was not seen in the scan.

    Msg 8929, Level 16, State 1, Line 1

    Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594052149248 (type In-row data): Errors found in off-row data with ID 5424095232000 owned by data record identified by RID = (1:1374:0)

    Msg 8929, Level 16, State 1, Line 1

    Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594052149248 (type In-row data): Errors found in off-row data with ID 5424095297536 owned by data record identified by RID = (1:1374:1)

    Msg 8929, Level 16, State 1, Line 1

    Object ID 1637580872, index ID 1, partition ID 72057594046054400, alloc unit ID 72057594052149248 (type In-row data): Errors found in off-row data with ID 5424095363072 owned by data record identified by RID = (1:1374:2)

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

    CHECKDB found 0 allocation errors and 7 consistency errors in database 'your_Database'.

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

    I decided to perform the dbcc checkdb becos i seen the below msg from the error logs:

    The Database ID 23, Page (1:11760), slot 1 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

    This error started off since last 14th Oct till now. Guess the subsequent backup from 14th Oct onwards cannot be use for the restoration ? Since only 1 page is affect can i use the backup of 13th Oct to restore the corrupted page? I am not too sure what impact or consistency problem if i were to use the last gd backup which is 13th Oct. The corrupted page seem to be reference by page (1:1374) which i think is up-to-date (26th Oct) . The doubt here is can i still use 13th Oct to just restore the corrupted page 1:11760 ?

  • flaskvacuum (10/26/2016)


    This error started off since last 14th Oct till now. Guess the subsequent backup from 14th Oct onwards cannot be use for the restoration ?

    Correct, they'll all have the corruption in them.

    Since only 1 page is affect can i use the backup of 13th Oct to restore the corrupted page?

    Yes, providing you have an unbroken chain of log backups from the 13th October up to present.

    You will need to restore the page from the full backup, then restore each log backup taken since that full backup, finally you'll need to take one more log backup and restore it, then the page will be accessible

    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 will need to restore the page from the full backup, then restore each log backup taken since that full backup, finally you'll need to take one more log backup and restore it, then the page will be accessible.."

    i have a question, when you perform the above steps to restore the Pages errors/ corruptions, the transaction logs being applied is restoring the problematic pages or database as a whole?

  • The pages you restored, which will have been marked 'restoring' by the first restore you did.

    Please practice this somewhere other than production if you've never done it before. If you have access to https://www.amazon.com/SQL-Server-MVP-Deep-Dives/dp/1617290475/, I wrote a chapter on how to do page restores.

    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
  • This was removed by the editor as SPAM

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

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