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

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

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

引用:

Quote: 引用:

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

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

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

可靠不可靠,一试就知道,
如果备份没报错估计是没问题的,但楼主还是谨慎些吧
------解决方案--------------------
还原之后用dbcc检查一下

------解决方案--------------------
据LZ的描述看,这个全备应该是不可靠的.

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

若再不行,则新建空库,把数据导入到新库中.
------解决方案--------------------
dbcc可以重复执行多几次，索引损坏可以试一下重建聚集索引
------解决方案--------------------
聚集索引是要重建,不是简单删除,重建可以重新分配.
------解决方案--------------------
repair_allow_data_loss 是最后选择，没办法的时候只能不停地做这个，最好在紧急模式下做。
------解决方案--------------------
1、用：dbcc checkdb(xxx) with physical_only 做日常检查
2、如果你觉得有风险，要计划开始转移数据库了，比如先建一个新库，然后把所有对象（存储过程、表、视图、函数、用户等等）产生脚本并在新库部署。然后找一个空闲时间，用导入导出工具把所有数据导过去。然后对新库做检查，没问题的话就计划切换到新库。旧库就不要了。