SQL Server 检测到基于一致性的逻辑 I/O 错误 校验和不正确

今天调试测试数据库的时候突然发现数据库不能用了,但是不知道什么原因造成的。
执行代码语句如下:

SELECT count(1) FROM JXCmygps_ALiYun_2017_12_21.dbo.MYGPS_DEVICE_DATA_HISTORY where TIME_DATA > '2017-12-14 0:00:00'

显示消息结果如下:
这里写图片描述
上网查询了以后,发现下面的方法可以解决。
在有问题的数据库上执行下面的代码:

ALTER DATABASE JXCmygps_ALiYun_2017_12_21/*数据库名称*/ SET SINGLE_USER   --设置为单用户  
DBCC CHECKDB (JXCmygps_ALiYun_2017_12_21, repair_allow_data_loss) with NO_INFOMSGS   --允许丢失错误  
go  
ALTER DATABASE JXCmygps_ALiYun_2017_12_21 SET MULTI_USER   --设置为多用户  
go 

这个数据库大约有1G左右,修复时间花费了3小时38分18秒。
消息结果如下:

修复: 已为数据库 'JXCmygps_ALiYun_2017_12_21' 中的对象 'dbo.MYGPS_DEVICE_DATA_HISTORY' 成功地重新生成了 Clustered 索引。
修复: 页 (1:65135) 已从对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)释放。
修复: 页 (1:65177) 已从对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)释放。
消息 8945,级别 16,状态 1,第 2 行
表错误: 将重新生成对象 ID 471672728,索引 ID 1。
        该错误已修复。
消息 8928,级别 16,状态 1,第 2 行
对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data): 无法处理页 (1:65135)。有关详细信息,请参阅其他错误消息。
        该错误已修复。
消息 8939,级别 16,状态 98,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data),页 (1:65135)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 29362185 和 -4。
        该错误已修复。
消息 8976,级别 16,状态 1,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)。在扫描过程中未发现页 (1:65135),但该页的父级 (1:65563) 和上一页 (1:65134) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978,级别 16,状态 1,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)。页 (1:65144) 缺少上一页 (1:65135) 对它的引用。可能是因为链链接有问题。
        该错误已修复。
消息 8928,级别 16,状态 1,第 2 行
对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data): 无法处理页 (1:65177)。有关详细信息,请参阅其他错误消息。
        该错误已修复。
消息 8939,级别 16,状态 98,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data),页 (1:65177)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 29362185 和 -4。
        该错误已修复。
消息 8976,级别 16,状态 1,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)。在扫描过程中未发现页 (1:65177),但该页的父级 (1:65563) 和上一页 (1:65176) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978,级别 16,状态 1,第 2 行
表错误: 对象 ID 471672728,索引 ID 1,分区 ID 72057594048217088,分配单元 ID 72057594049658880 (类型为 In-row data)。页 (1:65178) 缺少上一页 (1:65177) 对它的引用。可能是因为链链接有问题。
        该错误已修复。
CHECKDB 在表 'MYGPS_DEVICE_DATA_HISTORY' (对象 ID 471672728)中发现 0 个分配错误和 8 个一致性错误。
CHECKDB 在表 'MYGPS_DEVICE_DATA_HISTORY' (对象 ID 471672728)中修复了 0 个分配错误和 8 个一致性错误。
CHECKDB 在数据库 'JXCmygps_ALiYun_2017_12_21' 中发现 0 个分配错误和 8 个一致性错误。
CHECKDB 在数据库 'JXCmygps_ALiYun_2017_12_21' 中修复了 0 个分配错误和 8 个一致性错误。

消息截图:
这里写图片描述

最后执行完成之后。数据库可以正常使用了。
这里写图片描述

*知识还是需要慢慢积累。
故不积跬步,无以至千里;不积小流,无以成江海。*

<think>我们正在处理一个关于SQLServer中“基于一致性逻辑I/O错误(页撕裂)”的问题。根据引用[1],我们知道在发生824错误(如页撕裂)时,数据库镜像伙伴会更新suspect_pages表。页撕裂通常是由于硬件故障(如内存或磁盘问题)或驱动程序问题导致的,它破坏了SQLServer页面的逻辑一致性。解决方案步骤:1.确认错误:检查SQLServer错误日志,确认错误号为824,并记录下发生错误数据库、文件、页号等信息。2.恢复数据:尝试从备份中恢复受影响的页或数据库。如果页撕裂只影响少量页面,可以使用DBCC CHECKDB的修复选项,但要注意修复可能导致数据丢失。3.检查硬件:由于页撕裂通常由硬件问题引起,应全面检查硬件(尤其是内存和磁盘),运行硬件诊断工具(如Windows的内存诊断工具、硬盘制造商的诊断工具)。4.替换/修复硬件:如果发现硬件故障,更换故障硬件。5.防止未来发生:确保系统有冗余(如RAID配置),定期进行备份和一致性检查(DBCCCHECKDB),并保持驱动程序和固件最新。另外,引用[3]中提到了组提交机制和LSN(日志序列号),虽然这与InnoDB相关,但在SQL Server中也有类似的机制。在SQL Server中,LSN用于跟踪事务日志记录,确保数据页的恢复点一致。如果页撕裂导致LSN一致,可能需要从日志备份中恢复。考虑到引用[4]中提到的磁盘发现信息,如果使用了特定的存储设备(如ASM),也要确保存储层的配置正确且没有损坏。因此,针对页撕裂问题,我们建议: -立即运行DBCC CHECKDB来检查数据库一致性,并修复错误(但修复前务必备份)。-检查并修复硬件问题。 -如果无法立即修复硬件,考虑将数据库移至健康的硬件上。注意:DBCC CHECKDB的修复选项(如REPAIR_ALLOW_DATA_LOSS)可能导致数据丢失,因此应优先从备份恢复。相关问题:1.如何运行DBCCCHECKDB并解释结果?2.如何配置SQL Server的备份策略以防止数据丢失?3.除了硬件问题,还有哪些原因可能导致页撕裂?4.如何监控SQL Server的页面完整性?</think>### SQL Server 一致性逻辑 I/O 错误(页撕裂)解决方案 页撕裂(Page Tearing)是 SQL Server 中由 824 错误代码标识的严重逻辑 I/O 错误,表示数据页在磁盘和内存间传输时发生逻辑损坏[^1]。以下是系统性的解决方案: --- ### **一、紧急处理步骤** 1. **检查错误日志** 定位错误详情: ```sql SELECT * FROM msdb.dbo.suspect_pages; -- 查看损坏页记录[^1] ``` - 记录受损的 `file_id`、`page_id` 和 `database_id` 2. **隔离损坏页** ```sql DBCC PAGE (<database_id>, <file_id>, <page_id>, 3); -- 查看页内容 ALTER DATABASE <db_name> SET PAGE_VERIFY CHECKSUM; -- 启用页校验[^3] ``` 3. **恢复数据** - 若损坏页较少: ```sql DBCC CHECKDB (<db_name>) WITH REPAIR_ALLOW_DATA_LOSS; -- 尝试修复(可能丢失数据) ``` - 若大面积损坏: ```restore RESTORE DATABASE <db_name> FROM BACKUP WITH RECOVERY; -- 从备份恢复 ``` --- ### **二、根本原因与长期修复** | **原因类型** | **解决方案** | |---------------------|-----------------------------------------------------------------------------| | **硬件故障** | - 运行 `CHKDSK /R` 检测磁盘坏道<br>- 更换故障内存条/磁盘<br>- 启用 RAID 冗余[^4] | | **驱动程序问题** | - 更新存储控制器/HBA 卡驱动<br>- 禁用非厂商认证的磁盘缓存驱动程序 | | **SQL Server 配置** | - 启用 `PAGE_VERIFY CHECKSUM`(强制所有页计算校验和)[^3]<br>- 定期执行 `DBCC CHECKDB` | | **电源/缓存问题** | - 配置 UPS 防止意外断电<br>- 禁用磁盘写缓存(需厂商支持安全写入) | --- ### **三、预防措施** 1. **启用页校验**(强制实施) ```sql ALTER DATABASE <db_name> SET PAGE_VERIFY CHECKSUM WITH NO_WAIT; ``` 2. **定期维护计划** - 每日:事务日志备份 - 每周:`DBCC CHECKDB` + 完整备份 3. **监控部署** ```sql -- 创建页损坏警报 EXEC msdb.dbo.sp_add_alert @name = N'824_Page_Corruption', @message_id = 824, @severity = 0; ``` > **关键提示**:页撕裂本质是硬件或 I/O 子系统故障的信号[^1][^4],修复后需持续监控硬件健康状态。对于关键业务系统,建议部署 AlwaysOn 可用性组实现页自动修复。 --- ### **相关问题** 1. 如何解读 `DBCC CHECKDB` 输出的错误类型? 2. `PAGE_VERIFY` 的 `CHECKSUM` 和 `TORN_PAGE_DETECTION` 模式有何区别? 3. 当备份可用时,如何最小化页撕裂导致的数据丢失? 4. AlwaysOn 可用性组如何自动修复损坏页? [^1]: 由操作系统 CRC 错误导致的 823 错误或 824 错误(如页撕裂)会触发 `suspect_pages` 表更新 [^3]: 日志序列号 (LSN) 机制确保数据页会被重复执行 redo log,但页撕裂会破坏 LSN 一致性 [^4]: 存储层配置错误(如兼容的 ASM 或磁盘缓存)可能导致 I/O 路径损坏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值