SQL Server 交易記錄檔 VLF 碎片化：成因、影響與最佳實踐指南

SQL Server 將實體記錄檔內部分割為多個虛擬記錄檔（VLF），以便追蹤可重複使用的區段。然而，不當的自動成長設定會導致 VLF 數量暴增，形成「VLF 碎片」，嚴重拖垮資料庫效能。

VLF 數量如何決定？

每次記錄檔成長（自動或手動）時，依成長大小劃分 VLF：

例如：一次建立 8 GB 記錄檔 → 16 個 VLF（各 512 MB）；若後續以 4 GB 自動成長 → 新增 16 個 VLF（各 256 MB），總計 32 個 VLF。

VLF 過多的危害

• 延長崩潰復原、記錄備份、交易式複寫、資料庫還原等作業時間。
• 啟動資料庫、建立資料庫快照時因零初始化造成停頓。
• 經驗值：VLF 超過 1,000 即屬異常，極端案例曾達 154 萬（1 TB 記錄檔）。

查詢目前 VLF 數量

DBCC LOGINFO;  -- 輸出行數即為 VLF 數

降低 VLF 碎片的標準流程

1. 執行記錄備份以截斷記錄（BACKUP LOG）。
2. DBCC SHRINKFILE (logfile, target_size) 手動收縮至最小。
3. 重複 1~2 直到記錄檔縮至極小（忙碌系統可能需多次）。
4. 一次性手動成長至目標大小（如 8 GB），依公式產生適量大 VLF（單一 VLF ≤ 512 MB）。

關鍵最佳實踐

1. 固定自動成長增量，勿用百分比

預設 10% 會導致成長量越來越大，產生大量小 VLF。建議設定固定值（如 32 MB、64 MB、256 MB），並預先將記錄檔擴展至穩態大小。

2. 避免定期收縮記錄檔

若業務導致記錄檔反覆成長至 X 大小，直接將初始大小設為 X 並管理 VLF，免去反覆零初始化的效能代價。

3. 單一記錄檔即可，勿建立多個 .ldf

多檔案不提升效能（記錄寫入是循序的），反而增加還原時的零初始化時間，延長 RTO。

4. Tempdb 同樣需固定大小

服務重啟後 Tempdb 會縮回初始大小，若未預先調大，重啟後會因反覆成長而效能受損。

5. 資料庫快照還原後需手動調整記錄檔

從快照還原會重建兩個 0.25 MB 的微小 VLF，必須立即手動成長至最佳大小，否則後續自動成長又會產生碎片。

總結

健康的交易記錄檔 = 適當的初始大小 + 固定增量 + 受控的 VLF 數量（< 1,000）。搭配監控自動成長頻率與 I/O 延遲，即可維持穩定效能。