方法一
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 方法二
事情的起因
昨天，系統管理員告訴我，我們乙個內部應用資料庫所在的磁碟空間不足了。我注意到資料庫事件日誌檔案***_data.ldf檔案已經增長到了3gb，於是我決意縮小這個日誌檔案。經過收縮資料庫等操作未果後，我犯了乙個自進入行業以來的最大最愚蠢的錯誤：竟然誤刪除了這個日誌檔案！後來我看到所有論及資料庫恢復的文章上都說道：「無論如何都要保證資料庫日誌檔案存在，它至關重要」，甚至微軟甚至有一篇kb文章講如何只靠日誌檔案恢復資料庫的。我真是不知道我那時候是怎麼想的？！
這下子壞了！這個資料庫連不上了，企業管理器在它的旁邊寫著「(置疑)」。而且最要命的，這個資料庫從來沒有備份了。我唯一找得到的是遷移半年前的另外乙個資料庫伺服器，應用倒是能用了，但是少了許多記錄、表和儲存過程。真希望這只是一場噩夢！
沒有效果的恢復步驟
附加資料庫
_rambo講過被刪除日誌檔案中不存在活動日誌時，可以這麼做來恢復：
1，分離被置疑的資料庫，可以使用sp_detach_db
2，附加資料庫，可以使用sp_attach_single_file_db
但是，很遺憾，執行之後，sql server質疑資料檔案和日誌檔案不符，所以無法附加資料庫資料檔案。
dts資料匯出
不行，無法讀取***資料庫，dts wizard報告說「初始化上下文發生錯誤」。
緊急模式
怡紅公子講過沒有日誌用於恢復時，可以這麼做：
1，把資料庫設定為emergency mode
2，重新建立乙個log檔案
3，把sql server 重新啟動一下
4，把應用資料庫設定成單使用者模式
5，做dbcc checkdb
6，如果沒有什麼大問題就可以把資料庫狀態改回去了，記得別忘了把系統表的修改選項關掉
我實踐了一下，把應用資料庫的資料檔案移走，重新建立乙個同名的資料庫***，然後停掉sql服務，把原來的資料檔案再覆蓋回來。之後，按照怡紅公子的步驟走。
但是，也很遺憾，除了第2步之外，其他步驟執行非常成功。可惜，重啟sql server之後，這個應用資料庫仍然是置疑！
不過，讓我欣慰的是，這麼做之後，倒是能夠select資料了，讓我大出一口氣。只不過，元件使用資料庫時，報告說：「發生錯誤：-2147467259,未能在資料庫 '***' 中執行 begin transaction，因為該資料庫處於迴避恢復模式。」
最終成功恢復的全部步驟
設定資料庫為緊急模式
停掉sql server服務；
把應用資料庫的資料檔案***_data.mdf移走；
重新建立乙個同名的資料庫***；
停掉sql服務；
把原來的資料檔案再覆蓋回來；
執行以下語句，把該資料庫設定為緊急模式；
執行「use master
go sp_configure 'allow updates', 1
reconfigure with override
go」
執行結果：
已將配置選項 'allow updates' 從 0 改為 1。請執行 reconfigure 語句以安裝。
接著執行「update sysdatabases set status = 32768 where name = '***'」
執行結果：
（所影響的行數為 1 行）
重啟sql server服務；
執行以下語句，把應用資料庫設定為single user模式；
執行「sp_dboption '***', 'single user', 'true'」
執行結果：
命令已成功完成。
做dbcc checkdb；
執行「dbcc checkdb('***')」
執行結果：
'***' 的 dbcc 結果。
'sysobjects' 的 dbcc 結果。
物件 'sysobjects' 有 273 行，這些行位於 5 頁中。
'sysindexes' 的 dbcc 結果。
物件 'sysindexes' 有 202 行，這些行位於 7 頁中。
'syscolumns' 的 dbcc 結果。
執行以下語句把系統表的修改選項關掉；
執行「sp_resetstatus "***"
go sp_configure 'allow updates', 0
reconfigure with override
go」
執行結果：
在 sysdatabases 中更新資料庫 '***' 的條目之前，模式 = 0，狀態 = 28（狀態 suspect_bit = 0），
沒有更新 sysdatabases 中的任何行，因為已正確地重置了模式和狀態。沒有錯誤，未進行任何更改。
已將配置選項 'allow updates' 從 1 改為 0。請執行 reconfigure 語句以安裝。
重新建立另外乙個資料庫***.lost；
dts匯出嚮導
執行dts匯出嚮導；
複製源選擇emergencymode的資料庫***，匯入到***.lost；
選擇「在sql server資料庫之間複製物件和資料」，試了多次，好像不行，只是複製過來了所有表結構，但是沒有資料，也沒有檢視和儲存過程，而且dts嚮導最後報告複製失敗；
所以最後選擇「從源資料庫複製表和檢視」，但是後來發現，這樣總是只能複製一部分表記錄；
於是選擇「用一條查詢指定要傳輸的資料」，缺哪個表記錄，就導哪個；
檢視和儲存過程是執行sql語句新增的。
這樣，***.lost資料庫就可以替換原來的應用資料庫了。
無資料庫日誌檔案恢復資料庫方法
方法一 1.新建乙個同名的資料庫 2.再停掉sql server 注意不要分離資料庫 3.用原資料庫的資料檔案覆蓋掉這個新建的資料庫 4.再重啟sql server 5.此時開啟企業管理器時會出現置疑，先不管，執行下面的語句 注意修改其中的資料庫名 6.完成後一般就可以訪問資料庫中的資料了,這時,資...
無資料庫日誌檔案恢復資料庫方法兩則
方法一 1.新建乙個同名的資料庫 2.再停掉sql server 注意不要分離資料庫 3.用原資料庫的資料檔案覆蓋掉這個新建的資料庫 4.再重啟sql server 5.此時開啟企業管理器時會出現置疑，先不管，執行下面的語句 注意修改其中的資料庫名 6.完成後一般就可以訪問資料庫中的資料了,這時,資...
binlog日誌檔案 恢復資料庫
檢視資料庫是否開啟binlog日誌 show variables like log bin 如果 log bin off 則在my.ini檔案加入如下命令 路徑為自己mysql下位置所在 d wamp bin mariadb mariadb10.4.10 bin log 自己所建立檔案 mysql ...