关于修复数据库一致性问题，修复后过段时间又出现同样情况，请求帮助，谢谢！

[wzh1215]

近期数据库经常出现一致性错误，出现现只有重启服务器才能使用，重启后通过修复可以解决错误（通过DBCC CHECKDB修复），但使用一段时间（一天或几天）又出现同样的错误！请大家支招，谢谢！

[--小F--]

是不是数据库版本的问题 你用的什么版本的??

[--小F--]

其实出了问题不好解决的话 最好的办法就是换数据库 把你原先的数据备份出来

[wzh1215]

而且还有一个数据库（我们的系统采用多数据库结构），从服务器日志上可以看到有报一致性错误（让通过DBCC CHECKDB处理），且系统无法使用，重启服务器后，通过DBCC CHECKDB却查不到错误，但问题一直存在于该数据库中，我该怎么查出这个问题所在？
错误日志为：
错误: 7987，严重度: 22，状态: 2
在数据库 'Produce' 中检测到一个可能的数据库一致性问题。应该对数据库 'Produce' 运行 DBCC CHECKDB 和 DBCC CHECKCATALOG。

[wzh1215]

数据库版本：SQL SERVER 2000+SP4

[feixianxxx]

有没有错误提示？
就像楼上的说的 如果很严重 又不容易解决
推荐 拷贝出来 然后换数据库~~·

[ai_li7758521]

数据库置疑之后，你可以查看系统数据库maseter中的sysdatabase中的status列，如果该列值是256表示置疑       
  你可以手工恢复       
  必须以sa登陆       
  USE     master       
  GO       
  sp_configure     'allow     updates',     1       
  GO       
  RECONFIGURE     WITH     OVERRIDE       
  GO       
  sp_resetstatus           
  go       
      
  update     sysdatabase           
  set     status     =     status     -256       
  where     dbname="your     database     name     here"       
  and     status&256=     256(或者直接写256)       
  go       
  sp_configure     'allow     updates',     1       
  GO       
  RECONFIGURE     WITH     OVERRIDE       
  GO       
  sp_resetstatus           
  go       
  这样一般能恢复   
    
    
  ----------------------------------------------   
    
  DBCC   DBREINDEX                   重建指定数据库中表的一个或多个索引   
  DBCC   DBREPAIR                     除去损坏的数据库   
  DBCC   INDEXDEFRAG               整理指定的表或视图的聚集索引和辅助索引碎片   
  DBCC   SHRINKDATABASE         收缩指定数据库中的数据文件大小   
  DBCC   SHRINKFILE                 收缩相关数据库的指定数据文件或日志文件大小   
  DBCC   UPDATEUSAGE               报告和更正   sysindexes   表的不正确内容，   
                                                该内容可能会导致通过   sp_spaceused     
                                                系统存储过程产生不正确的空间使用报表  

[feixianxxx]

执行下DBCCCHECKDB(数据库名)，看看有没有错误信息

[rucypli]

http://msdn.microsoft.com/zh-cn/library/ms365223(sql.90).aspx

[feixianxxx]

错误: 7987，严重度: 22，状态: 2
在数据库 _中检测到一个可能的数据库一致性问题。应该对数据库 'hsabdb_local' 运行 DBCC CHECKDB 和 DBCC CHECKCATALOG。

[feixianxxx]

又或者是磁盘空间快满了 清除了些好些了

[ai_li7758521]

一般情况下，引起分配错误的原因是磁盘损坏或突然停电；一致性错误可能是数据库中的表或索引坏，一般都可修复。
1、查看红色报错文字，并把有错误的数据库表名记录下来，或把索引损坏的表名记录下来。
2、把数据库设置为单用户模式，直接在查询分析器中执行以下语句即可：
EXEC sp_dboption 'dbname', 'single user', 'TRUE'.
3、进入查询分析器执行如下语句：
   use  dbname
   dbcc checkdb（'dbname',repair_allow_data_loss）-------修复数据库
   dbcc checkdb ('dbname',REPAIR_REBUILD)----------------修复数据库索引
4、再执行：dbcc checkdb，检测数据库，出现结果为：
CHECKDB 发现了0个分配错误和 0个一致性错误（在数据库 'dbname' 中）。
数据库已经修复完毕。
5、取消单用户模式，即直接在查询分析器中执行以下语句即可：
EXEC sp_dboption 'dbname', 'single user','FALSE'

[ai_li7758521]

修复sql sever 数据库一致性错误，可以采用以下语句

ALTER DATABASE [dvbbs] SET SINGLE_USER 
GO 
DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK 
GO 
ALTER DATABASE [dvbbs] SET MULTI_USER 
GO 

--CHECKDB 有3个参数: 
--REPAIR_ALLOW_DATA_LOSS 
--执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。 
--REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。 
--REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。  



本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lujun10/archive/2006/10/22/1344932.aspx

[wzh1215]

出问题后，通过DBCC CHECKDB检查，几乎每次都是那几个表（难道通过DBCC CHECKDB修复问题只是表面工作嘛，为什么会再出现同样的问题！）。

[wzh1215]

修复问题时我都是用“ai_li7758521”的方法来做的，问题是修复后没多久又会出现同样的问题（问题又出现在修复的表上）！

[csdyyr]

硬盘有坏道?

[wzh1215]

硬盘不会有问题，因为服务器我都重装过几次了！

[等待戈多12]

迁移数据，似乎checkdb也不能检查也所有的数据库问题

[wzh1215]

怎么迁移数据？是新建数据库，导出旧数据库中所有数据到新数据库中吗？

[ChinaJiaBing]

数据库的迁移方法：包括DTS设计器导入导出、利用备份和恢复、直接拷贝数据文件、在应用程序中定制和SQL Server的复制功能

把数据库重装，然后再附加一下。。。