异常关机后，金蝶帐套突然无法访问，发现数据库置疑，使用此方案解决：
注意：在做任何修复操作之前，请务必备份.mdf/.ndf以及.ldf文件。
一般情况下这样可以解决：
1、将数据库设置为应急状态
ALTER DATABASE AIS20150723104254 SET emergency
2、将数据库设置为单用户模式
ALTER DATABASE AIS20150723104254 SET SINGLE_USER
3、对数据库进行检查修复
DBCC CheckDB (AIS20150723104254, REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS代表，若此错误不能修复时，系统将直接删除相关数据。
DBCC checkdb (AIS20150723104254, REPAIR_REBUILD)
尝试直接修复数据库错误
使用上面两个语句进行数据库检查修复，如果返回结果中没有了红色的提示文字，说明修复成功
此数据库执行CHECKDB的过程中发现一些表的索引被破坏，于是针对具体的表进行重建索引的操作：
DBCC DBREINDEX（表名）
完成后可以运行dbcc checkdb(db_name)检查数据库的完整性.
4、最后，取消单用户模式即可。
exec sp_dboption AIS20150723104254, N'single', N'false'
ALTER DATABASE AIS20151130094910 SET MULTI_USER
日志文件损坏或丢失时，可以尝试此方法：
方法一：
先停止数据库服务，备份数据文件(MDF/LDF)：
A． 我们使用默认方式建立一个供恢复使用的数据库(如AIS20131106110002)。可以在SSQL Server Management Studio里面建立。
B． 停掉数据库服务器。
C． 将刚才生成的数据库的日志文件AIS20131106110002_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件AIS20131106110002_data.mdf。
D． 启动数据库服务器。此时会看到数据库AIS20131106110002的状态为“置疑”。这时候不能对此数据库进行任何操作。
E． 设置数据库允许直接操作系统表。此操作可以在SQL Server Management Studio里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如
下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F． 设置AIS20131106110002为紧急修复模式
alter database AIS20131106110002 set emergency
此时可以在SQL Server Management Studio里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G． 下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log( 'AIS20131106110002 ', 'D:\MSSQL2008\Data\AIS20131106110002_log.ldf ')
SQL 2012版本以后版本时：
alter database AIS20131106110002 Rebuild Log on (name=AIS20131106110002_log,filename='D:\MSSQL2008\AIS20131106110002_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
打开单用户模式即可
ALTER DATABASE AIS20131106110002 SET SINGLE_USER
或
alter database AIS20131106110002 set SINGLE_USER with ROLLBACK IMMEDIATE
警告: 数据库 'AIS20131106110002 ' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时可以访问数据库里面的用户表了。
H． 验证数据库一致性（可省略）
dbcc checkdb( 'AIS20131106110002 ')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'AIS20131106110002 ' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
如果发现出问题，可使用下面方法尝试修复：
一、
dbcc checkdb(AIS20131106110002,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(AIS20131106110002,REPAIR_REBUILD)
二、
使用Repair_Allow_Data_Loss选项修复数据库。
优点： 可能可以恢复尽量多的数据
缺点：
a) 不一定能够将全部错误修复，还有可能越修越多。同时，需要大量时间，需要经过多次执行修复命令．十几次，甚至数十次．修复时间不能预估．
b) 就算我们将所有错误修复，我们也不能保证数据在应用程序逻辑这一层次上的数据正确性，您需要找您的应用程序提供商来检查数据在程序逻辑层次是否正确。
dbcc checkdb (‘
—此命令可能需要运行多次，才能完全修复。
三、
通过BCP，DTS，select into等方式将好的表，或者表中好的数据导出来。建议使用BCP的方法，这样可以最大限度的回复数据．BCP会停在出错的纪录上，但是前面的数据就能成功导出．使用DTS或Select into的话, 我们很难判断最大限度能导出的记录数．
优点：导出来的数据保证在应用程序逻辑这一层次的正确性
缺点：不会修复数据库中存在的错误，丢失的数据量会比较大，取决于第7步的运行结果。
二和三摘自：
https://blogs.msdn.microsoft.com/apgcdsd/2013/06/26/for-sql-server-2000200520082008r2/
I． 设置数据库为正常状态
exec sp_dboption AIS20131106110002, N'single', N'false'
ALTER DATABASE AIS20131106110002 SET MULTI_USER
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J． 最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Management Studio里面恢复，也可以使用如下语句完
成
use master
go
sp_configure 'allow updates',0
go
reconfigure with override
go
注意，SQL2012后，系统无sp_dboption这个存储过程，可以用附件文本的方式，在MASTER中创建此存储过程即可。
方法二：
1、把问题数据库文件备份到其它目录
停掉SQLSERVER服务,把服务器上出问题的数据库, 假设名称为 ErrorDB的数据库文件及日志文件备份复制到其他目录,然后直接将其删除,把其数据库文件及日志文件也删除
2、新建同名数据库
启动SQLSERVER服务,新建同名数据库ErrorDB,文件目录和文件名和原来一致
3、用备份的数据库文件替换新的数据库文件
停掉SQLSERVER服务,把备份的数据库文件替换新的数据库文件（只替换数据库文件，不替换日志文件）
启动SQLSERVER服务,打开数据库，这时数据库应该是不能访问的
-------------------设置应急模式、单用户模式、检查修复数据，取消单用户模式----------------------
4、将数据库设置为应急状态
alter database ErrorDB set emergency
执行后，为了保险起见，重新停止、开启的SQLSERVER服务
再打开数据库，已经可以看到里面的内容了，如表，视图，存储过程等
数据库名称后有紧急标志，能看到数据库结构，但无法进行备份等操作
5、将数据库设置为单用户模式
ALTER DATABASE ErrorDB SET SINGLE_USER
6、对数据库进行检查修复
dbcc checkdb(ErrorDB,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(ErrorDB,REPAIR_REBUILD)
操作后，仍然停止启动SQLSERVER服务（不确定是否需要，我只是为了想无干扰查看执行后的数据库状况）
7、取消单用户模式即可
exec sp_dboption ErrorDB, N'single', N'false'
ALTER DATABASE ErrorDB SET MULTI_USER