SQL Server 記錄檔的問題與解決方案 - 心得分享
幾天前，oncall DBA 接到請求支援的電話，狀況是這樣的…
有一個 SQL Server 的儲存空間已經快要用完了 (99% full)，Server Admin 檢查過後，判斷可以增加儲存空間，不過，先決條件是必須要 reboot 重新開機後，才可以使用新增加的儲存空間。經過討論後，因為有重要的資料庫程序正在進行中，所以不希望在短時間內重新開機，因此想要看看 DBA 有沒有什麼辦法來處理這個問題。
仔細看了一下，發現其中一個資料庫的 LDF (log file 記錄檔) 已經快要超過 500 GB 了，心裡的如意算盤是只要簡單地壓縮並且釋放記錄檔的空間就可以了。但是很無奈的，這個資料庫的復原模式設定是 FULL (完整)。換句話說，SQL Server 會設法一直保護這個記錄檔，必須要等到交易紀錄備份完成以後，才可以允許做壓縮釋放記錄檔的動作。又趕緊的檢查了一下備份的歷史紀錄，得知這個資料庫的交易紀錄備份的程序，大概要30分鐘才能完成。
根據這個狀況，經過了第二波討論後。沒錯，我們被告知沒有辦法再等30分鐘，希望 DBA 能夠運用一些 magic 來解決這個問題。是的，這就是 Production DBA 的日常。以下來談談 oncall DBA 如何運用 magic 來處理這件事情。
1.將資料庫復原模式從 “完整” 更改為 “簡單”。如此，SQL Server 才允許資料庫的記錄檔壓縮。
2.壓縮記錄檔，並將可用的空間釋放取回。大約取回 490 GB 可用的磁碟儲存空間。
3.在這個時候，SQL server 資料庫已經是處於正常運作而且可管理的狀態了。
4.將資料庫復原模式從 “簡單” 更改回 “完整”。
5.立即進行 ”完整” 資料庫備份。這個動作必須馬上執行，確保資料庫的資料備份。
6.安排設定更頻繁的交易紀錄備份排程。
終於，好不容易，可以找空檔續杯咖啡，休息一下了。