reconfigure with override
go
checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得用repair_allow_data_loss，完成所有修复。
chekcdb并不能完成所有的修复，我们需要更进一步的修复，用dbcc checktable对每一个表做检查吧。
表的列表可以用sysobjects里面得到，把objectproperty是istable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。
这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。dbcc dbreindex也许可以帮你一些忙。
数据库日志文件丢失时的恢复步骤，描述我误删除了数据库的事务日志文件(.ldf)之后，如何经过各种尝试恢复数据库的。
但是不少网友在处理“数据库置疑”的实践过程中，又产生了许多新的疑问。
我还是总结一下出现的几种情况，以供参考。
2.Zach的灵验脚本
Zach说他每次遇到这种数据库置疑情况，就运行下面这个脚本，屡试不爽：
======================================================
–before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
–Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = 'Database_Name'
–Run the following script
exec SP_resetstatus Database_Name
–stop and start the MSDTC at this stage
–After the procedure is created, immediately disable
updates to the system tables:
exec sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
=====================================
从上面可以看出，处理置疑的基本步骤还是我那篇文章中说的(注意我使用的字体颜色)：
执行 sp_configure 以允许对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置；
数据库重置紧急模式；
执行sp_resetstatus关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项（只有系统管理员才能执行）。执行该过程后，立即重启 SQL Server服务；
执行 sp_configure 以禁止对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。
status ^ 256的意思就是：
Constant Value Description
SQLDMODBStat_Suspect 256 Database integrity is suspect for the referenced database.
不同的是，有时候丢失了数据库日志文件，额外需要以下步骤：
把应用数据库设置为Single User模式；
