SqlServer 异常报逻辑 I/O 错误和无法NOLOCK方式扫描

为什么80%的码农都做不了架构师？>>>   

今天有同事报MSSQL数据库发生异常，看了下错误信息有两个:

1.SQL Server 检测到基于一致性的逻辑 I/O 错误 pageid 不正确(应为 1:94511，但实际为 2:-268434432)。在文件 'F:\justyle.mdf' 中、偏移量为 0x0000002e25e000 的位置对数据库 ID 8 中的页 (1:94511) 执行 读取 期间，发生了该错误。SQL Server 错误日志或系统事件日志中的其他消息可能提供了更详细信息。这是一个威胁数据库完整性的严重错误条件，必须立即纠正。请执行完整的数据库一致性检查(DBCC CHECKDB)。此错误可以由许多因素导致；有关详细信息，请参阅 SQL Server 联机丛书。

2.错误   601
严重级别   12
消息正文
由于数据移动，未能继续以   NOLOCK   方式扫描。

做数据库检查时发现有很多的错误信息
检查语句：
dbcc checkdb(eol_tcclub)

消息 8928，级别 16，状态 1，第 1 行
对象 ID 1893021925，索引 ID 1，分区 ID 72057594100776960，分配单元 ID 72057594116243456 (类型为 LOB data): 无法处理页 (1:3672)。有关详细信息，请参阅其他错误消息。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 1893021925，索引 ID 1，分区 ID 72057594100776960，分配单元 ID 72057594116243456 (类型为 LOB data)，页 (1:3672)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 12716041 和 -4。
消息 8928，级别 16，状态 1，第 1 行
对象 ID 1893021925，索引 ID 1，分区 ID 72057594100776960，分配单元 ID 72057594116243456 (类型为 LOB data): 无法处理页 (1:3673)。有关详细信息，请参阅其他错误消息。

消息 2575，级别 16，状态 1，第 1 行
索引分配映射(IAM)页 (0:0) (位于对象 ID 1782349464，索引 ID 0，分区 ID 72057594071941120，分配单元 ID 72057594081574912 (类型为 In-row data))的下一个指针指向了 IAM 页 (1:6238)，但扫描过程中检测不到它。
消息 7965，级别 16，状态 2，第 1 行
表错误: 由于无效的分配(IAM)页，无法检查对象 ID 1782349464，索引 ID 0，分区 ID 72057594071941120，分配单元 ID 72057594081574912 (类型为 In-row data)。
消息 8906，级别 16，状态 1，第 1 行
数据库 ID 11 中的页 (1:6238) 在 SGAM (1:3) 和 PFS (1:1) 中进行了分配，但未在任何 IAM 中分配。PFS 标志 'IAM_PG MIXED_EXT ALLOCATED   0_PCT_FULL'。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 1782349464，索引 ID 0，分区 ID 72057594071941120，分配单元 ID 72057594081574912 (类型为 In-row data)，页 (1:6238)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 29493257 和 -4。
消息 8939，级别 16，状态 98，第 1 行

消息 8964，级别 16，状态 1，第 1 行
表错误: 对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094288896 (类型为 LOB data)。位于页 (1:3773)，槽 0，文本 ID 9478209536 的行外数据节点未被引用。
消息 8964，级别 16，状态 1，第 1 行
表错误: 对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094288896 (类型为 LOB data)。位于页 (1:3774)，槽 0，文本 ID 9478209536 的行外数据节点未被引用。
消息 8964，级别 16，状态 1，第 1 行
表错误: 对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094288896 (类型为 LOB data)。位于页 (1:3775)，槽 0，文本 ID 9478209536 的行外数据节点未被引用。
消息 8964，级别 16，状态 1，第 1 行
表错误: 对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094288896 (类型为 LOB data)。位于页 (1:3781)，槽 0，文本 ID 9480241152 的行外数据节点未被引用。
消息 8929，级别 16，状态 1，第 1 行
对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094354432 (类型为 In-row data): 在 ID 为 9478209536 的行外数据中发现错误，该数据由 RID = (1:3540:0) 标识的 data 记录所有
消息 8929，级别 16，状态 1，第 1 行
对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094354432 (类型为 In-row data): 在 ID 为 9480241152 的行外数据中发现错误，该数据由 RID = (1:6867:7) 标识的 data 记录所有
消息 8929，级别 16，状态 1，第 1 行
对象 ID 160107711，索引 ID 1，分区 ID 72057594083409920，分配单元 ID 72057594094354432 (类型为 In-row data): 在 ID 为 9473818624 的行外数据中发现错误，该数据由 RID = (1:6867:10) 标识的 data 记录所有

TOL_TICKETREFUNDLOG的DBCC 结果。
对象'TOL_TICKETREFUNDLOG' 的0 页中有0 行。
CHECKDB 在数据库'EOL_TCGROUP' 中发现13 个分配错误和28 个一致性错误。
DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。

根据对象ID号，可以找出对象，select * from sys.sysobjects a where a.id = '160107711',点击该对象查看属性时也能发现上述错误信息。或者用命令方式 DBCC CHECKTABLE('TBillTemplateXml')查看错误信息

设置单用户模式：

USE master; 
ALTER DATABASE eol_tcgroup SET MULTI_USER;

    --修复的时候设置单用户还可以用alter database ** set single_user来，但再修复时老是提示有其他连接，修复失败，此时再用立即回滚的方式即可

GO

修复语句：

DBCC CHECKDB ('eol_tcgroup',repair_allow_data_loss)   --会丢失数据  
 --DBCC CHECKDB ('eol_tcgroup',repair_rebuild)             --不会丢失数据

知道异常表的情况下也可以单独对该表进行修复 DBCC CHECKTABLE('TBillTemplateXml',REPAIR_REBUILD )

最后要切换回多用户模式

USE master;
ALTER DATABASE eol_tcgroup SET MULTI_USER;

修复时修复语句可以执行多次，极有可能会在下一次修复成功。万一还是修不好，那只能用备份还原了。

转载于:https://my.oschina.net/Kenyon/blog/54824