有逻辑I/O错误的数据库，其全备成功了。全备的内容可靠吗？

davidyu720 2014-06-16 11:50:02
数据库是 SQL2005 SP3
上周二有一条报错：SQL Server 检测到基于一致性的逻辑 I/O 错误 校验和不正确(应为: 0x97f2b731，但实际为: 0xf7f2b732)。
没有处理，一直正常运行。
周六晚 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) N多次，每次都报告：找到了不一样的错误，修复了xx个错误。实在做不下去了。
周日凌晨的对prod的全备没有报错。

因为数据库比较大 3GB，没有动手用全备来恢复，想到这里把问题弄明白再动手。
请问：在这样的情况下，全备的内容可靠吗？可以用来恢复数据库吗？全备是对数据库的一个简单拷贝吗？全备时会对数据块进行校验吗？
...全文
338 30 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
30 条回复
切换为时间正序
请发表友善的回复…
发表回复
以学习为目的 2014-06-20
  • 打赏
  • 举报
 回复
引用 楼主 davidyu720 的回复:
数据库是 SQL2005 SP3 上周二有一条报错：SQL Server 检测到基于一致性的逻辑 I/O 错误 校验和不正确(应为: 0x97f2b731，但实际为: 0xf7f2b732)。 没有处理，一直正常运行。 周六晚 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) N多次，每次都报告：找到了不一样的错误，修复了xx个错误。实在做不下去了。 周日凌晨的对prod的全备没有报错。 因为数据库比较大 3GB，没有动手用全备来恢复，想到这里把问题弄明白再动手。 请问：在这样的情况下，全备的内容可靠吗？可以用来恢复数据库吗？全备是对数据库的一个简单拷贝吗？全备时会对数据块进行校验吗？
楼主执行上面语句的时候不要放在proc库执行，可以在master或者temp中执行试试
以学习为目的 2014-06-20
  • 打赏
  • 举报
 回复 
USE prod 
GO 
ALTER DATABASE prod SET SINGLE_USER
DBCC CHECKDB (RUM, repair_allow_data_loss) WITH  NO_INFOMSGS
楼主在发现报错之前是否对数据库进行分离然后附加等操作？
發糞塗牆 2014-06-20
  • 打赏
  • 举报
 回复
聚集索引是要重建,不是简单删除,重建可以重新分配.
發糞塗牆 2014-06-20
  • 打赏
  • 举报
 回复
1、最简单的是用第三方软件，不过要钱，但是一般不会非常贵。 2、做脚本，借用windows、SQL JOB、SQL Server的notification、database mail等功能做daily check，哪天你收不到邮件就证明可能服务器出问题了
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
引用 27 楼 DBA_Huangzj 的回复:
1、用：dbcc checkdb(xxx) with physical_only 做日常检查 2、如果你觉得有风险，要计划开始转移数据库了，比如先建一个新库，然后把所有对象（存储过程、表、视图、函数、用户等等）产生脚本并在新库部署。然后找一个空闲时间，用导入导出工具把所有数据导过去。然后对新库做检查，没问题的话就计划切换到新库。旧库就不要了。
假设有很多小系统，每个系统都有个不大的SQL2005数据库。即使不是关键系统，但现在看来，小系统也要每天巡检。如果安排人工每天去查看数据库的状态、是否有异常日志，工作量会比较大。 请问版主：有没有较好的针对较多库的监控方案建议啥的？
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
小小总结一下： 在数据库有问题的状态下，全备不一定全失败。但全备成功不一定表明全备是可靠的。（全备是否可靠，是否只能用 恢复加DBCC来验证？） 补充一下：这台生产机曾经掉电过、蓝屏过。这可能是操作系统软件或者SQL2005软件出问题的原因。
發糞塗牆 2014-06-20
  • 打赏
  • 举报
 回复
1、用：dbcc checkdb(xxx) with physical_only 做日常检查 2、如果你觉得有风险，要计划开始转移数据库了，比如先建一个新库，然后把所有对象（存储过程、表、视图、函数、用户等等）产生脚本并在新库部署。然后找一个空闲时间，用导入导出工具把所有数据导过去。然后对新库做检查，没问题的话就计划切换到新库。旧库就不要了。
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
引用 23 楼 DBA_Huangzj 的回复:
repair_allow_data_loss 是最后选择，没办法的时候只能不停地做这个，最好在紧急模式下做。
生产库虽在运行，但总觉得潜藏着风险。 所以昨晚在生产机 将生产库离线后，恢复0601全备，然后用REPAIR_REBUILD和REPAIR_ALLOW_DATA_LOSS进行修复。奇怪的是，在测试机上一次REPAIR_ALLOW_DATA_LOSS就能修复到完全正常；但在生产机上修复后，还报“对页 (1:xxxxxx) 检测到不一致性” 将生产机从SQL2005 SP3升级到SP4（测试机是SP4）（在升级的最后，提示有一个组件（好像是客户端组件）升级失败）； 重复恢复0601全备和修复的步骤，还是不正常。 再后来，在生产机上多次出现：服务 SQL Server (MSSQLSERVER) 意外停止；最后数据库服务（连同prod生产库）都无法启动！ 个人感觉生产机的操作系统软件或者SQL2005软件不正常了。最后临时用测试机顶上去。
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
引用 21 楼 galenkeny 的回复:
[quote=引用 楼主 davidyu720 的回复:] 数据库是 SQL2005 SP3 上周二有一条报错：SQL Server 检测到基于一致性的逻辑 I/O 错误 校验和不正确(应为: 0x97f2b731，但实际为: 0xf7f2b732)。 没有处理，一直正常运行。 周六晚 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) N多次，每次都报告：找到了不一样的错误，修复了xx个错误。实在做不下去了。 周日凌晨的对prod的全备没有报错。 因为数据库比较大 3GB，没有动手用全备来恢复，想到这里把问题弄明白再动手。 请问：在这样的情况下，全备的内容可靠吗？可以用来恢复数据库吗？全备是对数据库的一个简单拷贝吗？全备时会对数据块进行校验吗？
楼主执行上面语句的时候不要放在proc库执行，可以在master或者temp中执行试试[/quote] 不太理解啊，是指执行那条语句？
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
引用 20 楼 galenkeny 的回复:
USE prod 
GO 
ALTER DATABASE prod SET SINGLE_USER
DBCC CHECKDB (RUM, repair_allow_data_loss) WITH  NO_INFOMSGS
楼主在发现报错之前是否对数据库进行分离然后附加等操作？
你是要关注 发现数据库异常报错，还是执行DBCC的报错？ 不过不管是关注哪方面，一直都没有做过分离然后附加的操作。
發糞塗牆 2014-06-20
  • 打赏
  • 举报
 回复
repair_allow_data_loss 是最后选择，没办法的时候只能不停地做这个，最好在紧急模式下做。
davidyu720 2014-06-20
  • 打赏
  • 举报
 回复
引用 19 楼 DBA_Huangzj 的回复:
聚集索引是要重建,不是简单删除,重建可以重新分配.
引用 19 楼 DBA_Huangzj 的回复:
聚集索引是要重建,不是简单删除,重建可以重新分配.
重建是用ALTER INDEX ALL ON test REBUILD 吧。 试过了，在我的这个实例中，只用repair_rebuild的话，做不到完全修复。 首先 删除rec_files上其它索引，保留pk索引； 然后 ALTER INDEX ALL ON test REBUILD不成功 ------------------------- 语句已终止。 消息 682，级别 22，状态 146，第 1 行 内部错误。提供用于读取列值的缓冲区太小。请运行 DBCC CHECKDB 查看是否有损坏情况。 然后 DBCC CHECKDB(prod0615, repair_rebuild) 不能完全修复 ------------------------- CHECKDB 在数据库 'prod0615' 中发现 0 个分配错误和 9 个一致性错误。 对于由 DBCC CHECKDB ('prod0615' , repair_rebuild)发现的错误，repair_allow_data_loss 是最低的修复级别。
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
引用 12 楼 ap0405140 的回复:
[quote=引用 10 楼 davidyu720 的回复:] 找了另外一台服务器做恢复测试： 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。
请LZ把 DBCC CHECKDB具体的错误信息贴一下才好分析喔.[/quote] 版主好兴致啊！等我再抽时间重做一遍。
唐诗三百首 2014-06-19
  • 打赏
  • 举报
 回复
引用 10 楼 davidyu720 的回复:
找了另外一台服务器做恢复测试： 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。
请LZ把 DBCC CHECKDB具体的错误信息贴一下才好分析喔.
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
请教大家一个新问题：从2014-06-08的全备中恢复后，如何能够进一步恢复到最新状态？ 备份情况如下： 2014-06-08 可靠全备 9/10/11/12/13/14 每天一个差异备份（是否可靠未知）BACKUP DATABASE WITH DIFFERENTIAL 2014-06-15 不可靠全备 16/17/18 这几天没有备份 2014-06-19 刚才做了个差异备份。
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
上面拷贝粘贴错了，无权限修改。只能重发改正： 找了另外一台服务器做恢复测试： 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。 再用2014-06-08 全备恢复完毕，运行一次 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 在报告中没有看到：无法修复的错误。重复运行一次DBCC ，结果：发现 0 个分配错误和 0 个一致性错误。
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
引用 8 楼 ap0405140 的回复:
据LZ的描述看,这个全备应该是不可靠的. 建议dbcc checkdb()看详细的错误信息,尝试基于数据页的恢复. 若再不行,则新建空库,把数据导入到新库中.
版主说的对：这个备份不可靠。 2014-06-08 全备成功 2014-06-10 开始报错 error 824: SQL Server 检测到基于一致性的逻辑 I/O 错误 2014-06-14 试图用DBCC修复，多次执行，最终不成功。 删除test表上索引，重建成功。 删除test表上pk，重建pk失败。重建成非唯一索引成功。 2014-06-15 全备成功 找了另外一台服务器做恢复测试： 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。 再用2014-06-15 全备恢复完毕，运行一次 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 在报告中没有看到：无法修复的错误。重复运行一次DBCC ，结果：发现 0 个分配错误和 0 个一致性错误。
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
引用 17 楼 DBA_Huangzj 的回复:
dbcc可以重复执行多几次，索引损坏可以试一下重建聚集索引
多次DBCC CHECKDB(lyxt0615, REPAIR_REBUILD)执行结果（删除了所有索引，删除了pk主键，均未重建）： ... ... REC_FILES的 DBCC 结果。 消息 8928，级别 16，状态 1，第 1 行 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data): 无法处理页 (1:238333)。有关详细信息，请参阅其他错误消息。 DBCC 语句的修复级别导致避开了此修复。 消息 8944，级别 16，状态 26，第 1 行 表错误: 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data)，页 (1:238333)，行 31。测试(((DataRecHdr*) m_pRec)->r_tagB == 0)失败。值为 16 和 0。 修复此错误要求首先修正其他错误。 消息 8944，级别 16，状态 26，第 1 行 表错误: 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data)，页 (1:238333)，行 31。测试(((DataRecHdr*) m_pRec)->r_tagB == 0)失败。值为 16 和 0。 修复此错误要求首先修正其他错误。 消息 8928，级别 16，状态 1，第 1 行 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data): 无法处理页 (1:238334)。有关详细信息，请参阅其他错误消息。 修复此错误要求首先修正其他错误。 消息 8944，级别 16，状态 17，第 1 行 表错误: 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data)，页 (1:238334)，行 32。测试(columnOffsets->offTbl [varColumnNumber] <= (nextRec - pRec))失败。值为 599 和 102。 修复此错误要求首先修正其他错误。 消息 8944，级别 16，状态 17，第 1 行 表错误: 对象 ID 341576255，索引 ID 0，分区 ID 72057594051952640，分配单元 ID 72057594057719808 (类型为 In-row data)，页 (1:238334)，行 32。测试(columnOffsets->offTbl [varColumnNumber] <= (nextRec - pRec))失败。值为 599 和 102。 修复此错误要求首先修正其他错误。 对象 'REC_FILES' 的 67075 页中有 3939302 行。 CHECKDB 在表 'REC_FILES' (对象 ID 341576255)中发现 0 个分配错误和 6 个一致性错误。 ... ... CHECKDB 在数据库 'prod0615' 中发现 0 个分配错误和 6 个一致性错误。 对于由 DBCC CHECKDB (prod0615, repair_rebuild)发现的错误，repair_allow_data_loss 是最低的修复级别。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 总是提示 页 (1:238333)和 页 (1:238334) 有问题。 下一步可以如何处理呢？
發糞塗牆 2014-06-19
  • 打赏
  • 举报
 回复
dbcc可以重复执行多几次，索引损坏可以试一下重建聚集索引
davidyu720 2014-06-19
  • 打赏
  • 举报
 回复
引用 15 楼 DBA_Huangzj 的回复:
没必要动不动就：repair_allow_data_loss吧
用repair_rebuild的执行结果如下，错误没有得到完全修复。那下一步该怎么做呢？ CHECKDB 在数据库 'prod0615' 中发现 0 个分配错误和 25 个一致性错误。 CHECKDB 在数据库 'prod0615' 中修复了 0 个分配错误和 7 个一致性错误。 对于由 DBCC CHECKDB (prod0615, repair_rebuild)发现的错误，repair_allow_data_loss 是最低的修复级别。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 消息 5242，级别 22，状态 1，第 1 行 在数据库 'prod0615'(ID:16)中对页 (1:238333) 执行内部操作期间检测到不一致性。请与技术支持联系。参考号为 7。 消息 5242，级别 22，状态 1，第 1 行 在数据库 'prod0615'(ID:16)中对页 (1:238334) 执行内部操作期间检测到不一致性。请与技术支持联系。参考号为 7。 消息 9100，级别 23，状态 2，第 1 行 检测到索引可能已损坏。请运行 DBCC CHECKDB。
加载更多回复（10）
Oracle数据库DBA专题技术精粹2
Oracle数据库DBA专题技术精粹
四级数据库工程师
国家计算机等级考试，四级数据库工程师，考试资料下载。
数据库开发指南V1.0_数据库开发规范_
针对数据库开发设计的规范条款，应用于数据库开发的标准化流程
Oracle数据库进阶 高可用性、性能优化和备份恢复
高可用性、性能优化和备份恢复-- Oracle数据库进阶
移动通信领域超大型ORACLE数据库的设计
移动通信领域超大型ORACLE数据库的设计经验分享和总结。
疑难问题

22,301

社区成员

121,734

社区内容

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章