臃腫的事務日誌和 .bak 備份大小混淆
我最近繼承了一個管理不善的 SQL 伺服器。
其中一個數據庫處於粗糙狀態。以下是詳細資訊：
- .mdf 文件大小適中，為 369MB。
- .ldf 文件是一個臃腫的 29.7GB。
- 恢復模式設置為 FULL。
- 數據文件每晚備份一次，沒有問題，大小為 365MB。
- 從未備份過事務日誌。
我已將每晚的備份恢復到同一個 SQL 伺服器，並在其中四處查看以確保數據看起來完好無損。當我恢復該夜間 .bak 備份文件時，它會分別以 369MB 和 29.7GB 重新創建 .mdf 和 .ldf 文件。
在 SQL 方面表現不錯，但無論如何我都稱不上專家，我對這種情況有一些後續問題，希望得到回饋：
- 369MB .bak 文件如何同時恢復 369MB .mdf 文件和 29.7GB .ldf 文件？
- 關於如何處理恢復模型和臃腫的 .ldf 文件的任何建議？我們只關心每晚做一次備份——我們現在不需要做差異備份——但我稍後會解決這個問題。
365 .bak 文件如何同時恢復 369MB .mdf 文件和 29.7GB .ldf 文件？
它不是從日誌文件中恢復數據，也不是備份它，它只是以與備份時相同的大小創建它。檢查可用空間，它應該是 99% 的可用空間。
關於如何處理恢復模型和臃腫的 .ldf 文件的任何建議？我們只關心每晚做一次備份——我們現在不需要做差異備份——但我稍後會解決這個問題。
如果您只擔心每晚進行一次備份，請將恢復模式更改為簡單。如果您完全保留它，您還需要執行日誌備份。切換恢復模式或開始執行日誌備份後，您可以進行一次收縮以收回空間。
備份是 365 MB，而事務日誌幾乎是 30 GB，並且數據庫處於完全恢復狀態，但從未有事務日誌備份的事實有點令人困惑。除了備份之外，可能還有其他允許事務日誌重用的事情。
如果您想仔細檢查日誌備份是否正在發生，您可以從 Management Studio 執行此操作。右鍵點擊數據庫，然後轉到報告、標準報告、備份和還原事件。展開“成功的備份操作”並查看是否正在發生任何日誌備份。
如果不是，則檢查數據庫是否定期從 FULL 恢復更改為 SIMPLE 並再次更改回 FULL。這將在 SQL Server 錯誤日誌中顯示為類似
Setting database option RECOVERY to SIMPLE for database 'Scratch'..這樣一來，您就可以將事務日誌縮小到更合理的程度——可能是數據庫大小的 25-50% 左右——使用
DBCC SHRINKFILE. 您需要先進行事務日誌備份，以確保將活動日誌空間標記為可重複使用。接下來，執行EXEC sp_helpfile以獲取事務日誌文件的名稱（name列中的邏輯名稱，而不是物理文件名），然後將其縮小到適當的大小，例如DBCC SHRINKFILE('Scratch_log', 128)（大小以 MB 為單位）。請注意，它可能不會完全縮小到目標大小，具體取決於正在使用的日誌文件的哪個部分。如果是這種情況，您需要執行
CHECKPOINT，然後執行另一個日誌備份，然後再執行DBCC SHRINKFILE一次。然後為了持續維護，我建議讓數據庫處於完全恢復狀態，並在完全備份之前添加一個每晚的事務日誌備份。這樣，您至少可以在數據文件所在的任何捲髮生故障的情況下恢復數據庫（假設事務日誌文件仍然安全），並且還可以保留執行指向的能力-時間恢復。