【生产问题】-dbcc checkdb报错-数据页故障

更多操作参考：https://www.cnblogs.com/gered/p/9435282.html

 【生产问题】-dbcc checkdb报错-数据页故障

数据页故障，索引页故障

use db_tank
dbcc checkdb
--报错如下
由index ID 3可以得知，其为非聚集索引页出了问题
　　

Msg 8978, Level 16, State 1, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:2335514) is missing a reference from previous page (1:3628311). Possible chain linkage problem.
Msg 8978, Level 16, State 1, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:2839352) is missing a reference from previous page (1:3598023). Possible chain linkage problem.
Msg 8928, Level 16, State 1, Line 3
Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data): Page (1:3598023) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data), page (1:3598023). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 46270473 and -4.
Msg 8976, Level 16, State 1, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:3598023) was not seen in the scan although its parent (1:7723523) and previous (1:7723545) refer to it. Check any previous errors.
Msg 8928, Level 16, State 1, Line 3
Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data): Page (1:3628311) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data), page (1:3628311). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 348260361 and -4.
Msg 8976, Level 16, State 1, Line 3
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:3628311) was not seen in the scan although its parent (1:13500023) and previous (1:3075648) refer to it. Check any previous errors.

1、初步尝试--无损数据修复　　

--切换单用户模式

alter database db_tank
set single_user with rollback IMMEDIATE

dbcc checkdb('db_tank',repair_rebuild) --尝试无损修复
--结果如下

DBCC results for 'Sys_Users_Goods'.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:2335514) is missing a reference from previous page (1:3628311). Possible chain linkage problem.
        Repairing this error requires other errors to be corrected first.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:2839352) is missing a reference from previous page (1:3598023). Possible chain linkage problem.
        Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 1
Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data): Page (1:3598023) could not be processed.  See other errors for details.
        The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data), page (1:3598023). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 213911561 and -4.
        Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:3598023) was not seen in the scan although its parent (1:7723523) and previous (1:7723545) refer to it. Check any previous errors.
        Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 1
Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data): Page (1:3628311) could not be processed.  See other errors for details.
        Repairing this error requires other errors to be corrected first.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data), page (1:3628311). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
        Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 477960779, index ID 3, partition ID 72057594074890240, alloc unit ID 72057594081509376 (type In-row data). Page (1:3628311) was not seen in the scan although its parent (1:13500023) and previous (1:3075648) refer to it. Check any previous errors.

2.再次尝试，尝试运行丢失数据修复

select object_name(477960779) --根据object_id来找到故障对象
use db_tank
select count(1) from db_tank..Sys_Users_Goods where isexist=1 --61364953   --备份该库的有效数据，记录下该表的有效数据行
select count(1) from db_tank..Sys_Users_Goods --居然报错，那么肯定是isexist !=1的数据所在页有问题，那么即使丢失数据，也是isexist!=1的，也就是我不在乎的无效数据。那么直接跑

dbcc checktable('Sys_Users_Goods',repair_allow_data_loss)--尝试运行丢失数据修复
　　
--出现　　error has been repaired;

select count(1) from db_tank..Sys_Users_Goods where isexist=1 --61364953     --再次校验数据是否等于61364953，发现相等，证明只丢失了非有效数据
select count(1) from db_tank..Sys_Users_Goods　--再次查看，是否完成修复，一查，不报错了，那么就证明错误已经修复。

--恢复数据库模式为多用户模式
alter database db_tank
set multi_user with rollback IMMEDIATE

　DBCC CHECKDB 算是管理员们最常用的命令也是必须要知道的命令了。定期的检查及问题的修复都是比较重要的！！下面介绍一下 DBCC CHECKDB 的一些基本用法。

　　

　　DBCC CHECKDB 完成两项任务：

• 检查数据库里有没有损坏发生。
• 尽力修复数据库损坏，使数据库能够被重新正常访问。

　　

　　DBCC CHECK 做了些什么：

• 检查一些关键的系统表
• 对数据库运行DBCC CHECKALLOC
• 对数据库运行DBCC CHECKCATALOG
• 验证数据库中每个索引视图的内容
• 验证数据库中service broker数据

　　DBCC CHECKDB提供的修复方法

• Repair_allow_data_loss ：尝试修复所有错误（可能导致一些数据丢失，一般无发从备份恢复才使用）
• Repair_fast 未执行任何修复
• Repair_rebuild ：执行次要、快速修复（如：修复非聚集索引中的额外键）及耗时修复（如：重新生成索引），这些修复不会造成数据丢失。

　　注意：使用Repair_allow_data_loss参数导致的数据丢失也许是不能接受的，一般从备份还原的数据丢失可以做到心里有数，可以通过查询丢失前数据条数与修复后数据条数进行对比知道丢了多少数据。另外在早期备份中尝试找回。

　　如果使用repair_allow_data_loss级别都不能恢复：

• 按照预先备份恢复
• 如果损坏发生在默写用户对象（表、视图、存储过程等），可以把它们DROP掉
• 将数据库设置成紧急只读模式，用select into 将数据导入一个新建的空库。挽救尽可能多的数据，但是损坏严重程度不一样，丢失的数据多少也不一样。这样挽救回来的数据库各个数据表的状态将不一致，一般在逻辑上或有很大的问题。

　　虽然sqlserver 对dbcc checkdb 做了一些优化但是对于较大的数据库还是不小的负担所以分时间段进行不同的check检查以分散一次check的影响。还可以通过下面两个参数减轻一些消耗负担

• With noindex : 不对非聚集索引检查。
• With physical_only：只做物理结构完整性检查。