怎么自动判数据库损坏【质疑，不能使用等】，并且把损坏的数据库备份，在通过以前备份的数据在还原

Question

损坏，质疑

Answer 1

一般情况下是用DBCC CHECKDB去看看有没有损坏的，不过时间相对较长，关注，有没有效率更高的办法

Answer 2

DBCC CheckDB是我目前见到的最合理，最准确的办法。

Answer 3

就算是第三方工具，估计也是调用这些，DBCC CHECKDB 有with physical_only选项，可以用，但是即使是徐海蔚的书，也没有其他方案

Answer 4

这个dbcc checkdb是好办法。我觉得从方法来看，也就是dbcc checkdb，关键的问题是提高dbcc checkdb的速度，你可以用下面的命令，来加快速度，不过副作用是会加表锁：DBCC CHECKDB(你的数据库) with TABLOCK

Answer 5

通过加上表锁，也就是tablock，dbcc CHECKDB的速度一般能提高4-5倍

Answer 6

我们用dbcc CHECKDB这个是被动的模式，有没有只要数据库一损坏，我们就能捕获到，在还原数据？什么方法来解决？

Answer 7

你写个定时任务呗，运行下面的代码，返回数据库的状态：
select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases

Answer 8

你写个定时任务呗，运行下面的代码，返回数据库的状态：
select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases

上面返回的 state_desc   --状态,可能是online,offline,suspect等
不是很懂，我也查看了MSDN，关于他的解释，但是我对一个数据库用DBCC CHECKDB 是错误，但是，这个数据库的 state_desc   --状态  一直都是online，为什么不是suspect？一直都搞不懂？麻烦可以说说DBCC CHECKDB 报错的数据库，他的状态怎么还是online？

Answer 9

你写个定时任务呗，运行下面的代码，返回数据库的状态：
select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases

上面返回的 state_desc   --状态,可能是online,offline,suspect等
不是很懂，我也查看了MSDN，关于他的解释，但是我对一个数据库用DBCC CHECKDB 是错误，但是，这个数据库的 state_desc   --状态  一直都是online，为什么不是suspect？一直都搞不懂？麻烦可以说说DBCC CHECKDB 报错的数据库，他的状态怎么还是online？你说的对，这个还真不确定。比如有个，或者有一些数据页，也就是page损坏了，那么整个数据库还是online。
这个可以在如下的语句中查询到，里面是有问题的数据页：select *
from msdb.dbo.suspect_pages
如果是数据库有重大的损坏，那么就会处于suspect状态，或者是其他的比如restoring状态，那么这个应该能查询到：select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases
而如果某个文件有问题，你可以查询这个视图看看：select DB_NAME(database_id) as database_name,
       name as file_logical_name,
       physical_name,
       state_desc
from sys.master_files

Answer 10

你写个定时任务呗，运行下面的代码，返回数据库的状态：
select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases

上面返回的 state_desc   --状态,可能是online,offline,suspect等
不是很懂，我也查看了MSDN，关于他的解释，但是我对一个数据库用DBCC CHECKDB 是错误，但是，这个数据库的 state_desc   --状态  一直都是online，为什么不是suspect？一直都搞不懂？麻烦可以说说DBCC CHECKDB 报错的数据库，他的状态怎么还是online？你说的对，这个还真不确定。比如有个，或者有一些数据页，也就是page损坏了，那么整个数据库还是online。
这个可以在如下的语句中查询到，里面是有问题的数据页：select *
from msdb.dbo.suspect_pages
如果是数据库有重大的损坏，那么就会处于suspect状态，或者是其他的比如restoring状态，那么这个应该能查询到：select name,
       state_desc   --状态,可能是online,offline,suspect等
from sys.databases
而如果某个文件有问题，你可以查询这个视图看看：select DB_NAME(database_id) as database_name,
       name as file_logical_name,
       physical_name,
       state_desc
from sys.master_files
楼上说的很完整了，查数据库的状态，MSDB的suspect_pages，还有一个就是查询SQL Server Error Log 比如823，824类似的错误。

Answer 11

查看数据库状态. select databasepropertyex('[数据库名]','Status')

Answer 12

请问LZ的系统出现什么问题,为什么经常需要dbcc checkdb()和判断数据库状态.

Answer 13

请问LZ的系统出现什么问题,为什么经常需要dbcc checkdb()和判断数据库状态.不是经常dbcc checkdb()，因为我们软件有时暴力关机或其他的情况使数据丢失或者数据库损坏，为了尽量使风险降到最低，最理想的方案就是当数据库损坏的时候，能够及时知道，马上还原。谢谢你的回答。

Answer 14

可以在前端程序中加入try..chach..捕获异常,如访问数据时出错,自动做数据库还原后再次访问.

Answer 15

可以在前端程序中加入try..chach..捕获异常,如访问数据时出错,自动做数据库还原后再次访问.不好意思，我想问下，怎么样的异常才是数据库损坏？我也想了这样的情况，但是不知道是怎么样的异常。

Answer 16

按错误代码或错误信息中的关键词判断,
SQL Server中数据库损坏的代码是824,其内容:
SQL Server 检测到基于一致性的逻辑 I/O 错误 %1!。在文件 '%6!' 中、偏移量为 %5! 的位置对数据库 ID %4! 中的页 %3! 执行 %2! 期间，发生了该错误。SQL Server 错误日志或系统事件日志中的其他消息可能提供了更详细信息。这是一个威胁数据库完整性的严重错误条件，必须立即纠正。请执行完整的数据库一致性检查(DBCC CHECKDB)。此错误可以由许多因素导致；有关详细信息，请参阅 SQL Server 联机丛书。