減少高 VLF 計數
我一直在使用Brent Ozar 的 sp_blitz 腳本來查看我們的數據庫設置，發現自從更改為完全恢復模式後，主數據庫上的 VLF 計數很高（13562！）。
我在周末執行了一個完整的索引重建，在此期間，日誌文件在 46GB 數據文件上膨脹到大約 32GB，並且 10MB 日誌自動增長，我想這導致了高 VLF 計數。
據我了解，我應該提高自動增長，但這不是典型的活動。通常每隔幾個小時備份一次的 .trn 文件是 100-200MB，所以 10MB 似乎並不荒謬。
所以，我認為我需要縮小日誌文件並讓它在盡可能少的增長中再次增長，就像這裡腳本在幾個小時內一樣。在這種特殊情況下，這聽起來合理嗎？
此外，日誌文件的初始大小現在是 33896MB，我應該在縮小後將其減少到更合理的值（200MB）嗎？
10MB太荒謬了，恕我直言。您的 I/O 子系統是否在需要將增長限制在如此小的增量時變慢？理想情況下，您根本不應該觀察 AutoGrow，只要將日誌的大小調整到足以處理您最大的事務即可。並且僅使用 AutoGrow 作為拐杖來保護您免受異常事件的影響，例如這個，在這種情況下它應該相當大。
不，我不會將您的日誌文件減少到 200MB，而且我不確定這如何“更明智”。增長事件代價高昂，尤其是日誌文件，因為文件的擴展部分必須清零。您希望以能夠避免任何可預測的增長事件的方式調整日誌文件的大小。如果您將來要執行另一個類似的索引重建，我不明白同時將日誌文件縮小到 200MB 會獲得什麼。您是否要將釋放的空間出租給其他人，然後在您的日誌再次需要空間時將其踢出？我會說將日誌保留為 32GB（將其縮小並擴展一個事件，正如您指出的腳本所建議的那樣) 並監視 AutoGrow 事件（這些事件在預設跟踪中擷取，因此您無需進行任何設置，只需偶爾查看一下即可）。（在更現代的版本上，應該考慮使用擴展事件來跟踪增長事件。）這將告訴您是否需要考慮使其更大。
最小的日誌文件沒有獎勵——您希望它足夠大以容納所有正常（和異常）的日誌活動，而不必增長。