数据库修复系列Part3:repair_allow_data_loss

运行DBCC CHECKDB withNO_INFOMSGS发现下面的错误：

 

Table error: ObjectID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064(type In-row data), page (1:54). 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 (1:54). 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 (1:54). 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 (Corrupt2008DemoFatalCorruption).

 

最小的修复级别是repair_allow_data_loss

 

 

如果我们没有数据库备份，无法使用页面还原，那么我们就需要用repair_allow_data_loss来修复（会有数据损失，而且不一定所有的都是可以恢复的 参考：http://blog.csdn.net/smithliu328/article/details/7827147

）

 

下面我们就使用DBCC CHECKDH repair_allow_data_loss来修复损坏的数据库。

---将数据库状态改为紧急模式

ALTER DATABASE Corrupt2008DemoFatalCorruption SETEMERGENCY

GO

--将数据库改为单用户访问

ALTER DATABASE Corrupt2008DemoFatalCorruptionSETSINGLE_USER

GO

--运行repair_allow_data_loss修复

DBCC CHECKDB(Corrupt2008DemoFatalCorruption,repair_allow_data_loss)

Go

---修复完成后运行DBCC CHECKDB确定没有问题

DBCC CHECKDB withNO_INFOMSGS

Go

--将数据库更改为多用户访问

ALTER DATABASE Corrupt2008DemoFatalCorruptionSETMULTI_USER

 

如果建议的修复级别为REPAIR_REBUILD，您可以放心执行，不会有数据损失 。 这包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。

 

注意事项：
仅将 REPAIR 选项作为最后手段使用。 若要修复错误，建议您通过备份进行还原。 修复操作不会考虑表本身或表之间可能存在的任何约束。如果指定的表与一个或多个约束有关，建议您在修复操作后运行 DBCC CHECKCONSTRAINTS。如果必须使用 REPAIR，则运行不带有修复选项的 DBCC CHECKDB 来查找要使用的修复级别。如果使用 REPAIR_ALLOW_DATA_LOSS 级别，则建议您在运行带有此选项的 DBCC CHECKDB 之前备份数据库。

 

两个步骤用来对比数据丢失：

1.Create a copy of the corrupt 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 the
database is badly corrupt—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.