异常关机后，金蝶帐套突然无法访问，发现数据库置疑，使用此方案解决：

注意：在做任何修复操作之前，请务必备份.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 (‘’, REPAIR_ALLOW_DATA_LOSS) go

—此命令可能需要运行多次，才能完全修复。

三、

通过BCP，DTS，select into等方式将好的表，或者表中好的数据导出来。建议使用BCP的方法，这样可以最大限度的回复数据．BCP会停在出错的纪录上，但是前面的数据就能成功导出．使用DTS或Select into的话, 我们很难判断最大限度能导出的记录数．

优点：导出来的数据保证在应用程序逻辑这一层次的正确性

缺点：不会修复数据库中存在的错误，丢失的数据量会比较大，取决于第7步的运行结果。

二和三摘自：

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