只有MDF的文件下的sql server數據庫恢復

對於sql 數據庫丟失日誌文件（ldf）只有數據文件（mdf）的時候使用此方法修復。

咱們執行了下面的步驟:

1. 在SQL Server Management Studio中刪除狀態爲Recovery Pending的(即丟失了LDF的)問題數據庫.

2. 重命名老的MDF文件.

3. 重建一個新的數據庫, 名字跟剛剛刪除的數據庫徹底同樣. 注意, 新的MDF的位置跟咱們老的MDF的文件的位置相同. 這裏的LDF文件的位置選在你想要存放的最終位置上(這個就是你所要的被恢復的LDF文件了).

4. 停掉SQL Server服務, 將新的MDF重命名掉, 老的MDF命名回原來的名字.

5. 啓動SQL Server服務, 這時這個數據庫的狀態會變爲Recovery Pending. 咱們開始執行下面的腳本.

alter database contentdb1 set emergency
alter database contentdb1 set single_user with rollback immediate
alter database contentdb1 rebuild log on (name=ContentDB1_log,filename='E:\CDBLOG\contentdb1log.ldf')
ALTER DATABASE contentdb1 SET MULTI_USER with rollback immediate

這時數據庫的狀態就應該恢復正常了.

6.運行： 

use Survey go
ALTER DATABASE Survey SET SINGLE_USER DBCC CHECKDB (Survey, repair_allow_data_loss) with NO_INFOMSGS go
ALTER DATABASE Survey SET MULTI_USER go

進行完整性檢查，否則程序查詢時會報錯。 檢測到基於一致性的邏輯 I/O 錯誤 pageid 不正確(應爲 1:126647，但實際爲 0:0)。在文件 'D:\DataBase\Survey.mdf' 中、偏移量爲 0x0000003dd6e000 的位置對數據庫 ID 7 中的頁 (1:126647) 執行 讀取 期間，發生了該錯誤。SQL Server 錯誤日誌或系統事件日誌中的其餘消息可能提供了更詳細信息。這是一個威脅數據庫完整性的嚴重錯誤條件，必須當即糾正。請執行完整的數據庫一致性檢查(DBCC CHECKDB)。此錯誤能夠由許多因素致使；有關詳細信息，問題解決.（此過程時間有點長，本次修復一個170多M的MDF文件，大概耗時2個半小時左右）.

筆者在運行上面的腳本的時候, 遇到了一個報錯. 在運行了命令alter database contentdb1 set single_user with rollback immediate以後, 運行alter database contentdb1 rebuild log on 的時候說數據庫在single user mode, 個人當前用戶沒法執行命令.

我使用了命令exec sp_who2, 發現個人contentdb1上有個suspend的session, 執行命令kill XY 殺掉這個死掉的session以後, 問題解決.