--參考
据库置疑的处理办法 
在MS SQLSERVER中一直有这样的问题,SQLSERVER的状态"置疑",我们先来分析一下SQLSERVER数据库"置疑"的原因: 
1.错误的删除日志; 
2.硬件(HD)损坏,造成日志和数据文件写错误; 
3.硬盘的空间不够,比如日志文件过大; 
解决办法: 
这是最简单的办法是有数据库的全备份,然后恢复即可. 
步骤: 
1. 删除原始的数据库: 
USE MASTER 
GO 
DROP DATABASE DB_SUEPECT 
2.建立同名的数据库: 
USE master 
GO 
CREATE DATABASE DB_SUSPECT 
ON 
( NAME = DBNAME_DAT, 
FILENAME = 'C:', 
SIZE = 10, 
FILEGROWTH = 5 ) 
LOG ON 
( NAME = 'DBNAME_LOG', 
FILENAME = 'g:', 
SIZE = 5MB, 
FILEGROWTH = 5MB ) 
GO 
3.恢复数据库: 
RESTORE DATABASE DB_SUSPECT 
FROM DBNAME_BACKUP.DAT 
4.数据库完整性检测: 
DBCC CHECKDB('DB_SUSPECT') 
5.重新启动MSSQLSERVER服务. 
如果没有全备份,那就要用一些特殊的方法: 
1.设置数据库为紧急模式 
Use Master 
GO 
sp_configure 'allow updates', 1 
reconfigure with override 
GO 
UPDATE sysdatabases SET status = 32768 where name = 'DB_SUSPECT' 
GO 
2.停掉SQL Server服务: 
NET STOP MSSQLSERVER 
3.把原始数据库的数据文件DBNAME_DAT.MDF,DBNAME_LOG.LDF移走: 
4.启动SQL Server服务: 
NET START MSSQLSERVER 
5.重新建立一个同名的数据库DB_SUSPECT； 
USE master 
GO 
CREATE DATABASE DB_SUSPECT 
ON 
( NAME = DBNAME_DAT, 
FILENAME = 'C:', 
SIZE = 10, 
FILEGROWTH = 5 ) 
LOG ON 
( NAME = 'DBNAME_LOG', 
FILENAME = 'g:', 
SIZE = 5MB, 
FILEGROWTH = 5MB ) 
GO 
6.设置数据库运行在单用户的模式: 
USE MASTER 
GO 
ALTER DATABASE DB_SUSPECT SET SINGLE_USER 
GO 
7.停掉SQL服务: 
NET STOP MSSQLSERVER 
8.把原来的数据文件再覆盖回来: 
9.启动SQL Server服务: 
NET START MSSQLSERVER 
10.重新设置SQLSERVER的状态: 
USE MASTER 
GO 
EXEC sp_resetstatus "DB_SUSPECT" 
11.数据库完整性检测: 
DBCC CHECKDB('DB_SUSPECT') 
12.恢复数据库为多用户模式: 
USE MASTER 
GO 
ALTER DATABASE DB_SUSPECT SET MULTI_USER 
GO 
13.恢复SQLSERVER原始的配置: 
USE MATER 
GO 
UPDATE sysdatabases SET status = 4194320 where name = 'DB_SUSPECT' 
GO 
14.配置SQLSERVER不允许更新系统表: 
USE MASTER 
GO 
sp_configure 'allow updates', 0 
reconfigure with override 
GO 
15.重新启动MSSQLSERVER服务: 
最好重新启动操作系统 
16.备份数据库: 
可以通过SQLSERVER企业管理器或T-SQL.需要备份MASTER和DB_SUSPECT 
补充一点，如果用DOMAIN\USER时,要注意对.MDF.LDF的所在目录的权限

------解决方案--------------------

无数据库日志文件恢复数据库方法两则

方法一

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

方法二

事情的起因：昨天，系统管理员告诉我，我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB，于是我决意缩小这个日志文件。经过收缩数据库等操作未果后，我犯了一个自进入行业以来的最大最愚蠢的错误：竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道：“无论如何都要保证数据库日志文件存在，它至关重要”，甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的？！

这下子坏了！这个数据库连不上了，企业管理器在它的旁边写着“(置疑)”。而且最要命的，这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器，应用倒是能用了，但是少了许多记录、表和存储过程。最终成功恢复的全部步骤如下：

设置数据库为紧急模式
停掉SQL Server服务；

把应用数据库的数据文件XXX_Data.mdf移走；

重新建立一个同名的数据库XXX；

停掉SQL服务；

把原来的数据文件再覆盖回来；

运行以下语句，把该数据库设置为紧急模式；

运行“Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go”