(4.4)dbcc checkdb 数据页修复
转自: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:\mssql\corrupt.bak'withnorecovery backup log corrupttodisk='d:\mssql\corrupt.trn' restore log corruptfromdisk='d:\mssql\corrupt.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:\mssql\corrupt.bak'withnorecovery
backup log corrupttodisk='d:\mssql\corrupt.trn'
restore log corruptfromdisk='d:\mssql\corrupt.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 之前备份数据库。 |