转自：http://blog.51cto.com/lzf328/955852 三篇
一、创建错误数据库
以前看Pual写过很多数据恢复的文章，他很多的测试都是自己创建的Corrupt数据库，其实我们自己也可以。
DBCC CHECKDB MSDN:https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-2017
ALTER DATABASE Corrupt2008DemoFatalCorruption SET EMERGENCY ---将数据库状态改为紧急模式
ALTER DATABASE Corrupt2008DemoFatalCorruption SET SINGLE_USER --将数据库改为单用户访问
DBCC CHECKDB(Corrupt2008DemoFatalCorruption,repair_allow_data_loss) ---运行repair_allow_data_loss修复
DBCC CHECKDB withNO_INFOMSGS ---修复完成后运行DBCC CHECKDB确定没有问题
ALTER DATABASE Corrupt2008DemoFatalCorruption SET MULTI_USER --将数据库更改为多用户访问
--通过备份文件还数据页
命令：---Corrupt.bak是在数据库损坏之前的备份 restore database corrupt page='1:78'fromdisk='d:mssqlcorrupt.bak'withnorecovery backup log corrupttodisk='d:mssqlcorrupt.trn' restore log corruptfromdisk='d:mssqlcorrupt.trn'withrecovery 页面还原用于修复隔离出来的损坏页。 还原和恢复少量页面的速度可能比还原一个文件更快，因此减少了还原操作中处于脱机状态的数据量。 还原页步骤： 1. 获取要还原的损坏页的页 ID。 2. 从包含页的完整数据库备份、文件备份或文件组备份开始进行页面还原。 在 RESTORE DATABASE 语句中，使用 PAGE 子句列出所有要还原的页的页 ID。 3. 应用最近的差异。 4. 应用后续日志备份。 5. 创建新的数据库日志备份，使其包含已还原页的最终 LSN，即最后还原的页脱机的时间点。 设置为顺序中首先还原的最终 LSN 是重做目标 LSN。包含该页的文件的联机前滚可以在重做目标 LSN 处停止。 6. 还原新的日志备份。 应用这个新的日志备份后，就完成了页面还原，可以开始使用页了。
SQL Server页级别的数据恢复
1. 创建数据库数据表插入数据：
use master
go
create databasecorrupt
use corrupt
go
create tabletest(IDint, namevarchar(10))
declare @int asint
set @int = 1
while @int <20
begin
insert intotestvalues(@int,'allentest')
set @int += 1
end
2. 使用DBCC IND查看Test表所在的PageID
dbcc ind(corrupt,test,1)
3. 用DBCC PAGE查看TEST表的内容：
dbcc traceon(3604,-1)
go
dbcc page(corrupt,1,55,1)
这里我们只修改Slot 1数据，偏移地址为78，转化为10进制为120.
所以当前Slot1的实际地址为：55*8192+120=450680
4. 停掉SQL Server用XVI32打开数据文件然后输入地址找到对应的数据（可以看到数据与Step3中看到的数据一致）。
5. 对数据进行修改保存关闭XVI32。
6. 重启SQL Server然后用DBCC PAGE看Page 55 Slot1内容（已经被更改）
7. DBCCCHECKDB检查数据库发现下面的错误：
dbcc checkdb withno_infomsgs
Msg8928, Level 16, State 1, Line 1
Object ID2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID72057594039828480 (type In-row data): Page (1:55) could not be processed. See other errors for details.
Msg8939, Level 16, State 98, Line 1
Table error: ObjectID 2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID72057594039828480 (type In-row data), page (1:55). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) failed. Values are 12716041 and -4.
这样我们就创建了一个Corrupt的数据库，稍后我会花时间测试恢复（page restore/ dbcc checkdbrepair_allow_data_loss/rebuildSQL Server log）,然后把测试步骤发出来.
如果你不想自己创建的话，也可以使用Paul提供的两个Corrupt数据库做测试。
二、页面还原
上文我们已经新建了Corrupt的数据库，今天我们就用页面还原修复损坏的页面。
首先我们允许DBCC CHECKDB查看损坏的页面ID：
DBCC CHECKDB withNO_INFOMSGS
Msg 8928, Level 16,State 1, Line 1
Object ID2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID72057594039828480 (type In-row data): Page (1:78) could not be processed. See other errors for details.
Msg 8939, Level 16,State 98, Line 1
Table error: ObjectID 2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID72057594039828480 (type In-row data), page (1:78). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) failed. Values are 12716041 and -4.
repair_allow_data_loss is the minimumrepair level for the errors found by DBCC CHECKDB (corrupt).
建议的修复 是repair_allow_data_loss，但是如果用repair_allow_data_loss修复的话就会有数据损失，而且可能会造成数据一致性问题。SQL Server 2005之后提供了Page Restore,使用Page Restore我们可以直接修复这个损坏的页面。
命令：---Corrupt.bak是在数据库损坏之前的备份
restore database corrupt page='1:78'fromdisk='d:mssqlcorrupt.bak'withnorecovery
backup log corrupttodisk='d:mssqlcorrupt.trn'
restore log corruptfromdisk='d:mssqlcorrupt.trn'withrecovery
页面还原用于修复隔离出来的损坏页。 还原和恢复少量页面的速度可能比还原一个文件更快，因此减少了还原操作中处于脱机状态的数据量。
还原页步骤：
1. 获取要还原的损坏页的页 ID。
2. 从包含页的完整数据库备份、文件备份或文件组备份开始进行页面还原。 在 RESTORE DATABASE 语句中，使用 PAGE 子句列出所有要还原的页的页 ID。
3. 应用最近的差异。
4. 应用后续日志备份。
5. 创建新的数据库日志备份，使其包含已还原页的最终 LSN，即最后还原的页脱机的时间点。 设置为顺序中首先还原的最终 LSN 是重做目标 LSN。包含该页的文件的联机前滚可以在重做目标 LSN 处停止。
6. 还原新的日志备份。 应用这个新的日志备份后，就完成了页面还原，可以开始使用页了。
更多页面还原信息请参考：http://msdn.microsoft.com/zh-cn/library/ms175168.aspx
三、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 之前备份数据库。 |