运行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 之前备份数据库。 |
本文转自 lzf328 51CTO博客，原文链接:
