DBCC CHECKDB Results: page ID contains an incorrect page ID in its page header

Question

DBCC CHECKDB results for 'tablename':

Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 1637580872, index ID 1, partition ID 72057596516040704, alloc unit ID 72057594048020480 (type LOB data), page ID (23:853329) contains an incorrect page ID in its page header. The PageId in the page header = (0:96).

Msg 8928, Level 16, State 1, Line 1
Object ID 1637580872, index ID 1, partition ID 72057596516040704, alloc unit ID 72057594048020480 (type LOB data): Page (23:853329) could not be processed. See other errors for details.

Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1637580872, index ID 1, partition ID 72057596516040704, alloc unit ID 72057594048020480 (type LOB data). The off-row data node at page (23:853329), slot 0, text ID 12904397012992 is referenced by page (16:840512), slot 0, but was not seen in the scan.

This is the only table I have a problem with.

As this issue occur when purge some old data so we don't have enough old backup to say clean. Restore option may not possible.

Now we are looking into repair. Is single table repair possible?

Can we rebuild index as problem is with clustered index?

Answer 1

Never use REPAIR_ALLOW_DATA_LOSS. I would do a database restore before that.

I suggest following this order:

1. REPAIR_FAST (works 1 of 10 times).
2. REPAIR_REBUILD (works up to 50% of the time).
3. Restore database.

Full syntax:

DBCC CHECKALLOC   
[  
    ( database_name | database_id | 0   
      [ , NOINDEX   
      | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]  
    )  
    [ WITH   
        {   
          [ ALL_ERRORMSGS ]  
          [ , NO_INFOMSGS ]   
          [ , TABLOCK ]   
          [ , ESTIMATEONLY ]   
        }  
    ]  
]  

Answer 2

See if you can select into another table: select * into newtable from oldtable

If that is not possible, and you do not have a good backup, and you have COMPLETELY RUN OUT OF ANY OTHER OPTIONS, then you can run DBCC CHECKTABLE (tablename, REPAIR_ALLOW_DATA_LOSS) http://technet.microsoft.com/en-us/library/ms174338(v=sql.110).aspx

WARNING!!!! If you run DBCC CHECKTABLE with the REPAIR_ALLOW_DATA_LOSS, there is a very high probability that you WILL LOSE DATA. Also, there is no guarantee that DBCC CHECKTABLE (tablename, REPAIR_ALLOW_DATA_LOSS) will be able to repair the corruption.

BEFORE attempting ANY repair, shut down SQL Server and copy the .mdf and .ldf files off to a safe place, so you can always get back to your starting point.