数据库出错，现已置疑

[shaken]

DBCC CHECKDB 发生错误。解决有酬谢
使用DBCC CHECKDB 发生错误。
各位兄弟救急.谢谢

使用DBCC CHECKDB 发生错误。

服务器: 消息 8966，级别 16，状态 1，行 1
未能读取并闩锁页 (1:44234)（用闩锁类型 SH）。sysindexes 失败。

[wgsasd311]

先分离，再附加试试。

[rivery]

不知道这个能否有用：
sp_resetstatus
重置置疑数据库的状态。

语法
sp_resetstatus [ @DBName = ] 'database'

参数
[@DBName =] 'database'

是要重置的数据库名。database 的数据类型为 sysname，无默认值。

返回代码值
0（成功）或 1（失败）

注释
sp_resetstatus 关闭数据库上的置疑标记。此过程更新 sysdatabases 中的命名数据库的模式和状态列。在运行此过程之前，应参考 SQL Server 错误日志并解决所有问题。执行 sp_resetstatus 后停止并重新启动 SQL Server。

由于某些原因，数据库可能成为置疑状态。可能的原因包括操作系统拒绝对数据库资源的访问，以及一个或多个数据库文件不可用性或已损坏。

权限
只有 sysadmin 固定服务器角色成员才能执行 sp_resetstatus。

示例
下例重置 PUBS 数据库的状态。

EXEC sp_resetstatus 'PUBS'

[szzdbf]

如果你曾经完全备份数据库，那么先备份当前日志，再还原原始备份，最后还原日志。若没备份，可没办法。

[vivianfdlpw]

数据文件损坏了。。。。。应该有公司专门修这个

[饮水需思源]

试试这个：

备份数据文件,然后按下面的步骤处理:

1.新建一个同名的数据库(数据文件与原来的要一致)

2.再停掉sql server(注意不要分离数据库)

3.用原数据库的数据文件覆盖掉这个新建的数据库

4.再重启sql server

5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.



USE MASTER
GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go

sp_dboption '置疑的数据库名', 'single user', 'true'
Go

DBCC CHECKDB('置疑的数据库名')
Go

update sysdatabases set status =28 where name='置疑的数据库名'
Go

sp_configure 'allow updates', 0 reconfigure with override
Go

sp_dboption '置疑的数据库名', 'single user', 'false'
Go

[iwl]

在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。
　　但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，恭喜你！你可以还原到崩溃前的状态。
　　一般的单位都是没有专职的DBA的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。
　　不幸的很的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。
那么就只好试一下这些方案了。当然，是要求至少你的数据文件是存在的，要是数据文件、日志文件和备份都没有了的话，别找我，你可以到楼顶上去唱“神啊，救救我吧”。
　　首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。
　　如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气馁，还是有别的方案的。
　　我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。
　　不过系统表是不能随便改的，设置一下先
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
然后
update sysdatabases set status = 32768 where name = '<db_name>'
现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。
　　虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。
　　先把SQL Server 重新启动一下，然后检查你的数据库吧。
先设置成单用户模式，然后做dbcc
sp_dboption '<db_name>', 'single user', 'true'
DBCC CHECKDB('<db_name>')
如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。
update sysdatabases set status = 28 where name = '<db_name>' --当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用sp_resetstatus
go
sp_configure 'allow updates', 0
reconfigure with override
Go
　　checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得用REPAIR_ALLOW_DATA_LOSS，完成所有修复。
chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。
这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。

[天地客人]

帮你UP了，没有做过，关注中！

[yangxiao_bo]

数据库修复在我的个人论坛里收集了一些资料希望对你有所帮助！
http://www.cqydkj.com/bbs