黃昏的甘蔗

 MS-SQL 資料庫會有兩個檔案，分別資料檔（MDF）與記錄檔（LDF），每一筆交易(Transaction)完成後，會先記錄在記憶體(Memory)裡，等到檢查點(Checkpoint)時再寫入交易記錄檔，實際運作的情形並不會隨時的將資料都寫回到資料檔裡，所以妥善的保護交易記錄檔是相當重要的事。但所有的交易紀錄都被寫在LDF裡，會導致LDF膨脹的飛快，並且會比資料檔來得大上許多（好幾GB的LDF大有人在），上圖的例子中，資料其實才13MB，但交易記錄檔卻是24倍的大，該怎麼處理呢？

1. 卸離資料庫（Detach）
2. 刪除交易記錄檔（有人建議用更名的方式較安全）
3. 附加資料庫（attach）
4. 搞定收工～LDF直接縮小成 504KB

↓ 附加資料庫（attach）

↓ 小動作123

1. 按「加入」按鈕，並選要附加的資料庫的MDF檔案
2. 由於LDF已經被改名，所以會顯示找不到，這時點LDF列，然後按下方「刪除」鈕
3. 按「確定」～搞定

↓ 到檔案總管查看，果然新增了新的交易記錄檔，而且只有小小的504KB

結束了嗎？

還沒～～～這樣的動作會導致，此資料庫的復原模式（Recovery Mode）變成簡單（Simple），這可能會影響到你備份的動作（功能），因為在簡單模式下，你只能做 Full Backup 與 Differential Backup ，而無法執行 Transaction Log Backup ，所以也會無法還原到任一時間點上。

↓ 把復原模式改為完整吧

*********************************************************

雖然這個方法有效，且許多網友也提供這個方法，但隱隱的覺得不太保險，覺得在實務上風險相當大

所以測試了一下

再把原本的交易記錄檔名稱改回來，並試著重新附加資料庫（attach），結果因為前面的重建LOG，導致名稱已對應不上，附加也失敗了

出現了下面的錯誤訊息

我想～我在實務上應該不敢採用這個方法。

另外，RiCo 兄提供了當 LDF 意外損毀（因為磁區壞軌）的救援方式

1. 確認原本資料庫檔案路徑位置
2. 建立新的資料庫（名稱需與原資料庫名稱相同）
3. 停止SQL server （不能單純用 detach 的嗎？）
4. 將原本的MDF，覆蓋新資料庫的MDF檔案
5. 將舊的LDF檔刪除
6. 啟動 SQL Server
7. 查看資料庫狀態「select state_desc from sys.databases where name='DB_Name'」，因為LOG檔找不到，所以狀態為「Recovery_Pending」
8. 將資料庫設為「Emergency」狀態「ALTER DATABASE DB_Name SET SINGLE_USER; Go;」、「ALTER DATABASE DB_Name SET EMERGENCY; Go;」、「DBCC CHECKDB (DB_Name, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS; Go;」
9. 再確認資料庫狀態 「select state_desc from sys.databases where name='DB_Name'」
10. 檢查[DBCC checkdb('DB_Name')]
11. 到 Table 去查看資料正常與否