3G大的数据库也叫大,楼主搞笑了.建议完整备份一次,也可以把备份恢复成其他名字的数据库检查其完整性.

引用 1 楼 tcmakebest 的回复:

3G大的数据库也叫大,楼主搞笑了.建议完整备份一次,也可以把备份恢复成其他名字的数据库检查其完整性.

3G大不大，不是重点。这不移动都上4G了嘛

每周日凌晨都有一个全备。想知道：在这样的情况下，全备的内容可靠吗？

引用 2 楼 davidyu720 的回复:

Quote: 引用 1 楼 tcmakebest 的回复:

3G大的数据库也叫大,楼主搞笑了.建议完整备份一次,也可以把备份恢复成其他名字的数据库检查其完整性.

3G大不大，不是重点。这不移动都上4G了嘛

每周日凌晨都有一个全备。想知道：在这样的情况下，全备的内容可靠吗？

可靠不可靠,一试就知道,
如果备份没报错估计是没问题的,但楼主还是谨慎些吧

还原之后用dbcc检查一下

我问：“成功全备是否可靠”的原因是：

应用程序日志中记录了数据库错误
事件 ID: 832
日期:  2014-6-16 3:46:30
本应保持不变的页已更改(预期校验和: c3733b7c，实际校验和: 13733b7e，数据库 5，页 (1:121591))。

prod数据库中只有一个表test不断增长，其它表数据基本恒定。
因此，用dbcc page检查日志中报错的页 (1:121591)的前后各一页，能看到表名test和主键值范围
dbcc page(5,1,121590,3) with tableresults
dbcc page(5,1,121592,3) with tableresults
根据主键值范围推算：表test的主键值为KT00002465531的记录在页 (1:121591)中。

用select * from test whre pk='KT00002465531' 查询这条记录，报错：
消息 5242，级别 22，状态 1，第 1 行
在数据库 'prod'(ID:5)中对页 (1:121591) 执行内部操作期间检测到不一致性。请与技术支持联系。参考号为 4。

数据库都已经这样了，所以我怀疑：全备虽然没有报错，但也会有问题。

哪位能从数据库全备的机制方面来点分析和建议？

全备的恢复要等几天才能做。
趁着这个空档，想请大家多指点，搞清楚全备的机制。

备份过程中如果选择了：，基本上没有什么你可以额外做的了，如果还报错，那就只能进行修复。

据LZ的描述看,这个全备应该是不可靠的.

建议dbcc checkdb()看详细的错误信息,尝试基于数据页的恢复.

若再不行,则新建空库,把数据导入到新库中.

引用 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 个一致性错误。

上面拷贝粘贴错了，无权限修改。只能重发改正：

找了另外一台服务器做恢复测试：
 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。
 再用2014-06-08 全备恢复完毕，运行一次 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 在报告中没有看到：无法修复的错误。重复运行一次DBCC ，结果：发现 0 个分配错误和 0 个一致性错误。 

请教大家一个新问题：从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 刚才做了个差异备份。

引用 10 楼 davidyu720 的回复:

找了另外一台服务器做恢复测试：
 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。 

请LZ把 DBCC CHECKDB具体的错误信息贴一下才好分析喔.

引用 12 楼 ap0405140 的回复:

Quote: 引用 10 楼 davidyu720 的回复:

找了另外一台服务器做恢复测试：
 首先用2014-06-15 全备恢复完毕，但运行 DBCC CHECKDB('prod', REPAIR_ALLOW_DATA_LOSS) 报告说：有无法修复的错误。估计没戏，放弃。 

请LZ把 DBCC CHECKDB具体的错误信息贴一下才好分析喔.

版主好兴致啊！等我再抽时间重做一遍。

重新恢复 0601 0608 0615 三个全备，在测试机上都可以恢复成功，使用 DBCC CHECKDB (xxx, repair_allow_data_loss) 处理后，都能正常使用。
但是仔细检查里面包含的数据量，发现事情变复杂了，没有想的那么简单 :(
在从0608全备和0615全备恢复得到的两个库中，6月1～7号增加的数据条数不一样！

推测原因：使用了repair_allow_data_loss，所以存在数据丢失！

比较了一下，0601库中包括的历史数据最多，而且修复从0601全备恢复得到的库时，错误最少。
DBCC CHECKDB (prod0518, repair_allow_data_loss) found 43 errors and repaired 43 errors. Elapsed time: 0 hours 1 minutes 58 seconds.
DBCC CHECKDB (prod0601, repair_allow_data_loss) found 12 errors and repaired 12 errors. Elapsed time: 0 hours 2 minutes 4 seconds.
DBCC CHECKDB (prod0608, repair_allow_data_loss) found 55 errors and repaired 55 errors. Elapsed time: 0 hours 2 minutes 0 seconds.
DBCC CHECKDB (prod0615, repair_allow_data_loss) found 25 errors and repaired 25 errors. Elapsed time: 0 hours 1 minutes 43 seconds.

所以，下一步尽快用0601的全备作为基础进行恢复。虽然生产库还在运行，但我觉得潜藏着风险：已丢失的数据就丢失了，但每天的新增数据也可能会丢失，必须尽快将数据库恢复到正常状态。

但此全备之后，有差异备份，也有其它的全备。
请问大家：能通过这些差异备份文件（和其它什么文件）恢复到当前点吗？

如果不能，是不是就只能这样：从生产库中提取0601全备后产生的全部数据，插入到测试机的恢复库中，得到一个正常的数据库？

没必要动不动就：repair_allow_data_loss吧

引用 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。

dbcc可以重复执行多几次，索引损坏可以试一下重建聚集索引

引用 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) 有问题。
下一步可以如何处理呢？

聚集索引是要重建,不是简单删除,重建可以重新分配.

USE prod 

GO 

ALTER DATABASE prod SET SINGLE_USER

DBCC CHECKDB (RUM, repair_allow_data_loss) WITH  NO_INFOMSGS

楼主在发现报错之前是否对数据库进行分离然后附加等操作？

引用 楼主 davidyu720 的回复:

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

因为数据库比较大 3GB，没有动手用全备来恢复，想到这里把问题弄明白再动手。
请问：在这样的情况下，全备的内容可靠吗？可以用来恢复数据库吗？全备是对数据库的一个简单拷贝吗？全备时会对数据块进行校验吗？

楼主执行上面语句的时候不要放在proc库执行，可以在master或者temp中执行试试

引用 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 是最低的修复级别。

repair_allow_data_loss 是最后选择，没办法的时候只能不停地做这个，最好在紧急模式下做。

引用 20 楼 galenkeny 的回复:

USE prod 

GO 

ALTER DATABASE prod SET SINGLE_USER

DBCC CHECKDB (RUM, repair_allow_data_loss) WITH  NO_INFOMSGS

楼主在发现报错之前是否对数据库进行分离然后附加等操作？

你是要关注 发现数据库异常报错，还是执行DBCC的报错？
不过不管是关注哪方面，一直都没有做过分离然后附加的操作。

引用 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中执行试试

不太理解啊，是指执行那条语句？

引用 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软件不正常了。最后临时用测试机顶上去。

1、用：dbcc checkdb(xxx) with physical_only 做日常检查
2、如果你觉得有风险，要计划开始转移数据库了，比如先建一个新库，然后把所有对象（存储过程、表、视图、函数、用户等等）产生脚本并在新库部署。然后找一个空闲时间，用导入导出工具把所有数据导过去。然后对新库做检查，没问题的话就计划切换到新库。旧库就不要了。

小小总结一下：
在数据库有问题的状态下，全备不一定全失败。但全备成功不一定表明全备是可靠的。（全备是否可靠，是否只能用 恢复加DBCC来验证？）

补充一下：这台生产机曾经掉电过、蓝屏过。这可能是操作系统软件或者SQL2005软件出问题的原因。

引用 27 楼 DBA_Huangzj 的回复:

1、用：dbcc checkdb(xxx) with physical_only 做日常检查
2、如果你觉得有风险，要计划开始转移数据库了，比如先建一个新库，然后把所有对象（存储过程、表、视图、函数、用户等等）产生脚本并在新库部署。然后找一个空闲时间，用导入导出工具把所有数据导过去。然后对新库做检查，没问题的话就计划切换到新库。旧库就不要了。

假设有很多小系统，每个系统都有个不大的SQL2005数据库。即使不是关键系统，但现在看来，小系统也要每天巡检。如果安排人工每天去查看数据库的状态、是否有异常日志，工作量会比较大。
请问版主：有没有较好的针对较多库的监控方案建议啥的？

1、最简单的是用第三方软件，不过要钱，但是一般不会非常贵。
2、做脚本，借用windows、SQL JOB、SQL Server的notification、database mail等功能做daily check，哪天你收不到邮件就证明可能服务器出问题了