Database repair series Part3: repair

Run DBCCCHECKDBwithNO_INFOMSGS and find the following errors: Tableerror: ObjectID7, indexID2, partitionID562949953880064, struct (typeIn-rowdata), page (). Test (bytes) |

Run dbcc checkdb with NO_INFOMSGS and find the following error: Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064 (type In-row data ), page (:54 ). test (m_type = DATA_PAGE m_type = UNDOFILE_HEADER_PAGE) |

Run dbcc checkdb withNO_INFOMSGS and find the following error:

Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064 (type In-row data), page ). test (m_type> = DATA_PAGE & m_type <= UNDOFILE_HEADER_PAGE) | (m_type = UNKNOWN_PAGE & level = BASIC_HEADER) failed. values are 0 and 0.

Msg 8939, Level 16, State 5, Line 4

Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064 (type In-row data), page ). test (m_headerVersion = HEADER_7_0) failed. values are 0 and 1.

Msg 8939, Level 16, State 6, Line 4

Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064 (type In-row data), page ). test (m_type> = DATA_PAGE & m_type <= UNDOFILE_HEADER_PAGE) | (m_type = UNKNOWN_PAGE & level = BASIC_HEADER) failed. values are 0 and 0.

Repair_allow_data_loss is the minimum repairlevel for the errors found by dbcc checkdb (corrupt2008demofatalpolicuption ).

The minimum repair level is repair_allow_data_loss.

If we do not have database backup, can not use page restore, then we need to use repair_allow_data_loss to repair (there will be data loss, and not all are can be restored reference: http://blog.csdn.net/smithliu328/article/details/7827147

)

Next we will use dbcc checkdh repair_allow_data_loss to repair the damaged database.

--- Change the database status to emergency mode

Alter database Corrupt2008DemoFatalCorruption SETEMERGENCY

GO

-- Change the database to single-user access

Alter database Corrupt2008DemoFatalCorruptionSETSINGLE_USER

GO

-- Run repair_allow_data_loss to fix

Dbcc checkdb (Corrupt2008DemoFatalCorruption, repair_allow_data_loss)

Go

--- After the fix is completed, run dbcc checkdb to confirm there is no problem

Dbcc checkdb withNO_INFOMSGS

Go

-- Change the database to multi-user access

Alter database Corrupt2008DemoFatalCorruptionSETMULTI_USER

If the recommended repair level is REPAIR_REBUILD, You can execute it without any data loss. This includes fast repairs (such as fixing missing rows in non-clustered indexes) and time-consuming repairs (such as re-indexing ).

Note:

Only use the REPAIR option as the final method. To fix the error, we recommend that you restore it through backup. The repair operation does not consider any constraints that may exist between tables. If the specified table is related to one or more constraints, we recommend that you run dbcc checkconstraints after the repair operation. If you must use REPAIR, run dbcc checkdb without the REPAIR Option to find the REPAIR level to be used. If you use REPAIR_ALLOW_DATA_LOSS, we recommend that you back up the database before running dbcc checkdb with this option.

Two steps are used to compare data loss:

1. Create a copy of the specified upt database before running repair so you can compare the prerepair and postrepair data and see what is missing. This may be tricky to do if
Database is badly used upt-you may need to use the WITH CONTINUE_AFTER_ERROR options of BACKUP and RESTORE to do this.
2. start an explicit transaction before running repair. it is not very well known that you can run repair inside a transaction. after repair completes, you can examine the database to see what repair did, and if you want to undo the repairs, you can simply roll back the explicit transaction.