Database Corruption ->> Fix Database In Suspect State

昨天在工作中遇到一个情况,就是Development环境中的某台服务器上的某个数据库进入了Suspect状态。以前看书倒是知道说这个状态,不过实际工作当中从来没有遇到过。那么一些背景情况是这样的。

环境:Development

数据库产品:SQL Server 2008 R2

数据库业务类型:DataWare House

数据库恢复模式:Simple

备份情况:每天就一个备份

 

在Google上查询了相关资料加上自己对于这种情况已有的储备知识,首先我第一部先到SQL Server Log里面查找最近关于这个数据库的一些报错信息,定位到到底是为什么还有何时发生的?

从SQL Server Log我找到了这样一些日志记录。 原因是在6月13号这台服务器的SQL Server重启时在CHECKDB命令检查这个数据库时发现了Error。很可能就是这台服务器意外重启而导致了这个很可能是一致性检查不通过的问题。更糟糕的在后面。

这里有几个链接来自Microsoft的BOL。里面讲了上图提示的两个Error的cause和fix/resolution

https://support.microsoft.com/en-us/kb/2015753

https://technet.microsoft.com/zh-cn/library/ff713991(v=sql.105).aspx

https://support.microsoft.com/en-us/kb/2015741

 

这个时候应该是尽可能对该数据库运行DBCC CHECKDB来确定遇到一致性问题的页面数量(范围)。这个时候我需要先把数据库切换到EMERGENCY模式才可能访问数据库。

ALTER DATABASE [YourDatabase] SET EMERGENCY

然后我运行了DBCC checkdb来定位问题页面
DBCC checkdb([YourDatabase])

命令输出了下面的信息:

Msg 7987, Level 16, State 1, Line 1
System table pre-checks: Object ID 5 has chain linkage mismatch. (1:29885)->next = (1:28340), but (1:28340)->prev = (1:28339). Check statement terminated due to unrepairable error.
DBCC results for 'XXXX'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'XXXX'.

 

很明显可以看到某个数据库表对象两个页面的前后指向出了问题,没办法match上。感兴趣的你可以用DBCC PAGE打开上提到的几个页面去看下里面页头的内容。不过我觉得糟糕的是这个Object_ID = 5的信息。这意味着这个对象很可能是张系统表。我觉得它糟糕的原因是因为即便这时我做最坏的打算用DBCC CheckDB ([YourDatabase], REPAIR_ALLOW_DATA_LOSS)来解决这个问题,也还是不成,因为DBCC CHECKDB存在很多限制,并不是说所有的表都可以repair的,其中就包括system table。DBCC CHECKDB的作者在他的一篇博文中讲到了这点。因为系统表本身就是SQL Server用来存储用户表元数据的地方,一旦某张系统表出现问题而强制repair这种系统表不就是意味着要把有问题的页面删掉,而页面中涉及到的用户表也需要被删掉来保证一致性呢。这样的结果显然完全无法接受。不过即便如此,这样的答案还是令人沮丧的。因为这就是意味着除非恢复备份,否则这张系统表将无法得救。幸运的是,如果坏的是某些页面像GAM,SCAM,PFS这样的页面,那将是顶级灾难。必须完全恢复整个数据库。而至少现在我有个想法,就是利用SQL Server的PAGE RESTORE,只恢复特定的页面。这点我不晓得行不行得通,毕竟页面是某张系统表的。以后找个时间试下。

http://www.sqlskills.com/blogs/paul/checkdb-from-every-angle-can-checkdb-repair-everything/

 

这里还有作者讲的另外一篇关于corruption的文章:http://www.sqlskills.com/blogs/paul/corruption-demo-databases-and-scripts/

 

上面说了那么多,为了验证确实没办法repair一张系统表的页面,我也试了一下,确实不行。
ALTER DATABASE [YourDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([YourDatabase], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [YourDatabase] SET MULTI_USER

 

下面是输出信息:

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.
Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.
Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.
Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.
Msg 7987, Level 16, State 1, Line 3
System table pre-checks: Object ID 5 has chain linkage mismatch. (1:29885)->next = (1:28340), but (1:28340)->prev = (1:28339). Check statement terminated due to unrepairable error.
DBCC results for 'XXXX'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'XXXX'.

 

万一说备份都没有,或者备份实在是太旧了,而且上面我提到的那个PAGE RESTORE的办法又行不通,那就没办法了,只剩一个办法:

因为这个时候数据库已经进入正常模式,可以被访问。我们只有尽可能去挽救数据。把可以访问的数据表里面的数据都导出到另外一个库。

至于这里,因为是开发环境,我直接restore了整个库。

 

 
  

RESTORE FILELISTONLY
FROM DISK = '\\XXXXXX\MyDB\MyDB_NB_FULL_20150624000352.BAK'


RESTORE
DATABASE MyDB FROM DISK = '\\XXXXXX\MyDB\MyDB_NB_FULL_20150624000352.BAK' WITH MOVE 'MyDBPrimary' TO 'D:\MSSQL\Data\MyDBPrimary.mdf', MOVE 'MyDBLog01' TO 'O:\MSSQL\Log\MyDBLog01.ldf', MOVE 'MyDBData24' TO 'O:\Data3\MSSQL\Data\MyDBData24.ndf', MOVE 'MyDBData23' TO 'O:\Data2\MSSQL\Data\MyDBData23.ndf', MOVE 'MyDBData22' TO 'O:\Data1\MSSQL\Data\MyDBData22.ndf', MOVE 'MyDBData21' TO 'O:\MSSQL\Data\MyDBData21.ndf', MOVE 'MyDBData20' TO 'H:\Data3\MSSQL\Data\MyDBData20.ndf', MOVE 'MyDBData19' TO 'H:\Data2\MSSQL\Data\MyDBData19.ndf', MOVE 'MyDBData18' TO 'H:\Data1\MSSQL\Data\MyDBData18.ndf', MOVE 'MyDBData17' TO 'H:\MSSQL\Data\MyDBData17.ndf', MOVE 'MyDBData16' TO 'D:\Data3\MSSQL\Data\MyDBData16.ndf', MOVE 'MyDBData15' TO 'D:\Data2\MSSQL\Data\MyDBData15.ndf', MOVE 'MyDBData14' TO 'D:\Data1\MSSQL\Data\MyDBData14.ndf', MOVE 'MyDBData13' TO 'D:\MSSQL\Data\MyDBData13.ndf', MOVE 'MyDBData12' TO 'O:\Data3\MSSQL\Data\MyDBData12.ndf', MOVE 'MyDBData11' TO 'O:\Data2\MSSQL\Data\MyDBData11.ndf', MOVE 'MyDBData10' TO 'O:\Data1\MSSQL\Data\MyDBData10.ndf', MOVE 'MyDBData09' TO 'O:\MSSQL\Data\MyDBData09.ndf', MOVE 'MyDBData08' TO 'H:\Data3\MSSQL\Data\MyDBData08.ndf', MOVE 'MyDBData07' TO 'H:\Data2\MSSQL\Data\MyDBData07.ndf', MOVE 'MyDBData06' TO 'H:\Data1\MSSQL\Data\MyDBData06.ndf', MOVE 'MyDBData05' TO 'H:\MSSQL\Data\MyDBData05.ndf', MOVE 'MyDBData04' TO 'D:\Data3\MSSQL\Data\MyDBData04.ndf', MOVE 'MyDBData03' TO 'D:\Data2\MSSQL\Data\MyDBData03.ndf', MOVE 'MyDBData02' TO 'D:\Data1\MSSQL\Data\MyDBData02.ndf', MOVE 'MyDBData01' TO 'D:\MSSQL\Data\MyDBData01.ndf', REPLACE, STATS = 10;

Restore完记得DBCC CHECKDB(MyDB)


 

转载于:https://www.cnblogs.com/jenrrychen/p/4584261.html

dm-verity corruption是指Android系统中的数据完整性校验功能被破坏或损坏的情况。红米手机可能会出现这种问题,导致系统无法正确地验证数据完整性。 当手机出现dm-verity corruption问题时,可能会导致一些严重的后果。首先,手机可能无法正确地启动。用户可能会遇到无法进入系统的情况,只看到红米的标志或无法通过开机画面。其次,一些应用程序无法正常运行。因为系统无法正确验证数据的完整性,可能会导致某些应用程序无法正确加载或运行。最后,手机可能会变得不稳定,出现频繁的崩溃和重启问题。 为了解决dm-verity corruption问题,我们可以尝试以下方法。首先,可以尝试重启手机。有时候,这个问题只是一个临时的错误,重启可以解决。其次,可以尝试进行系统恢复。可以通过进入恢复模式来进行系统恢复,这可能会修复损坏的数据完整性校验功能。如果这些方法都无效,可能需要考虑刷机或重装系统来修复dm-verity corruption问题。 总的来说,dm-verity corruption是一个可能出现在红米手机和其他Android设备上的问题。它会导致系统无法正确验证数据的完整性,可能导致手机无法启动或应用程序无法正常运行。通过尝试重启或进行系统恢复,我们可以尝试解决这个问题。如果问题依然存在,可能需要采取更深入的修复措施。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值