方法一

1.新建一個同名的數(shù)據(jù)庫

2.再停掉sql server(注意不要分離數(shù)據(jù)庫)

3.用原數(shù)據(jù)庫的數(shù)據(jù)文件覆蓋掉這個新建的數(shù)據(jù)庫

4.再重啟sql server

5.此時打開企業(yè)管理器時會出現(xiàn)置疑，先不管，執(zhí)行下面的語句（注意修改其中的數(shù)據(jù)庫名)

6.完成后一般就可以訪問數(shù)據(jù)庫中的數(shù)據(jù)了,這時,數(shù)據(jù)庫本身一般還要問題,解決辦法是,利用

數(shù)據(jù)庫的腳本創(chuàng)建一個新的數(shù)據(jù)庫,并將數(shù)據(jù)導(dǎo)進(jìn)去就行了.

use master
go
sp_configure allow updates,1 reconfigure with override
go
update sysdatabases set status =32768 where name=置疑的數(shù)據(jù)庫名
go
sp_dboption 置疑的數(shù)據(jù)庫名, single user, true
go
dbcc checkdb(置疑的數(shù)據(jù)庫名)
go
update sysdatabases set status =28 where name=置疑的數(shù)據(jù)庫名
go
sp_configure allow updates, 0 reconfigure with override
go
sp_dboption 置疑的數(shù)據(jù)庫名, single user, false
go


方法二

事情的起因

昨天，系統(tǒng)管理員告訴我，我們一個內(nèi)部應(yīng)用數(shù)據(jù)庫所在的磁盤空間不足了。我注意到數(shù)據(jù)庫事件日志文件xxx_data.ldf文件已經(jīng)增長到了3gb，于是我決意縮小這個日志文件。經(jīng)過收縮數(shù)據(jù)庫等操作未果后，我犯了一個自進(jìn)入行業(yè)以來的最大最愚蠢的錯誤：竟然誤刪除了這個日志文件！后來我看到所有論及數(shù)據(jù)庫恢復(fù)的文章上都說道：“無論如何都要保證數(shù)據(jù)庫日志文件存在，它至關(guān)重要”，甚至微軟甚至有一篇kb文章講如何只靠日志文件恢復(fù)數(shù)據(jù)庫的。我真是不知道我那時候是怎么想的？！

這下子壞了！這個數(shù)據(jù)庫連不上了，企業(yè)管理器在它的旁邊寫著“(置疑)”。而且最要命的，這個數(shù)據(jù)庫從來沒有備份了。我唯一找得到的是遷移半年前的另外一個數(shù)據(jù)庫服務(wù)器，應(yīng)用倒是能用了，但是少了許多記錄、表和存儲過程。真希望這只是一場噩夢！

沒有效果的恢復(fù)步驟

附加數(shù)據(jù)庫

_rambo講過被刪除日志文件中不存在活動日志時，可以這么做來恢復(fù)：

1，分離被置疑的數(shù)據(jù)庫，可以使用sp_detach_db

2，附加數(shù)據(jù)庫，可以使用sp_attach_single_file_db

但是，很遺憾，執(zhí)行之后，sql server質(zhì)疑數(shù)據(jù)文件和日志文件不符，所以無法附加數(shù)據(jù)庫數(shù)據(jù)文件。

dts數(shù)據(jù)導(dǎo)出

不行，無法讀取xxx數(shù)據(jù)庫，dts wizard報告說“初始化上下文發(fā)生錯誤”。

緊急模式

沒有日志用于恢復(fù)時，可以這么做：

1，把數(shù)據(jù)庫設(shè)置為emergency mode

2，重新建立一個log文件

3，把sql server 重新啟動一下

4，把應(yīng)用數(shù)據(jù)庫設(shè)置成單用戶模式

5，做dbcc checkdb

6，如果沒有什么大問題就可以把數(shù)據(jù)庫狀態(tài)改回去了，記得別忘了把系統(tǒng)表的修改選項關(guān)掉

我實踐了一下，把應(yīng)用數(shù)據(jù)庫的數(shù)據(jù)文件移走，重新建立一個同名的數(shù)據(jù)庫xxx，然后停掉sql服務(wù)，把原來的數(shù)據(jù)文件再覆蓋回來。之后，按照怡紅公子的步驟走。

但是，也很遺憾，除了第2步之外，其他步驟執(zhí)行非常成功。可惜，重啟sql server之后，這個應(yīng)用數(shù)據(jù)庫仍然是置疑！