我有一個關於SQL日誌文件大小以及在日誌文件備份後應該設置什麼的問題。我知道這取決於很多因素，並且沒有正確或錯誤的數量（相對而言，因爲我不會在默認情況下在1 MB處開始記錄），但是應該有多少VLF應該存在如果我們做了大約200MB的事務（或者我們的.mdf文件增長了那麼多），那麼這個VLF有多大或者日誌文件有多大？我已經閱讀了Kimberly Tripp和Paul Randal的博客，但最好還是有霧。SQL 2005日誌文件初始大小
就像你說的那樣，這是一個'取決於'的答案。我可能會過分簡化一些事情，但通常我會像這樣描繪過程：
在將'stuff'寫入數據文件之前，每個事務都先寫入日誌。 日誌永遠不會被清除。當日志文件「翻轉」時，寫指針會移回文件的頂部，並繼續在舊文件上再次寫入。
所以日誌至少需要是最大的交易 日誌大小的尺寸。
接下來考慮的是併發用戶的數量。當您的 有10個用戶同時進行最大的交易時，您明白了。
另一個考慮因素是使用強度。檢查點發生之前累積多少數據。這是當日志數據以批處理方式寫入到mdf文件時。
最後要考慮的是您的恢復模式。在完全恢復 模式下，日誌文件尚未受到 事務日誌備份「保護」的部分無法翻轉，並且將繼續增長，直到進行事務日誌備份。
每個數據庫只需要一個物理日誌文件。 Sql服務器一次只能寫入一個文件。
您希望擁有儘可能少的虛擬日誌文件。爲日誌文件提供足夠的初始空間，以便儘可能減少自動增長。 VLF是通過自動增長過程創建的。
而且，當你自動增長時，確保它的體積正在增長。還要記住，每個vlf都需要先被清零。在可以使用之前，文件需要完全填充零。當你指定非常大的數據塊（比如說1 GB）時，這個數據庫上的每個查詢都將排隊，直到完成零輸出過程。
當我對日誌需求毫無頭緒時，我個人從500 MB大小開始，自動增長100 MB塊。從那裏開始，我監控汽車增長事件並根據需要進行調整。
當涉及到日誌文件時，是否有任何'最佳實踐'？ Msft是否有任何建議值？我只是在這裏問，因爲我讀過的書和Msft網站並不總是爲這些模糊的猜測類型的問題提供最好的。 – ctmcklowe96
歷史通常是未來規模的最佳預測指標。
它在備份之間的日誌通常會達到20 GB，然後您可以預計它會在備份之間達到20 GB。
如果你的尺寸爲20GB，那麼它不一定會增長。
如果日誌必須增長20倍甚至100倍，那麼不是那麼大的一筆交易。
如果日誌必須增長1000倍，那麼您肯定應該將其大小設置錯誤。
一個1 mb的日誌，一次只能增長1 MB，達到1000 MB是不好的。
一個100 mb增長100％只需增長4倍達到1600 mb。
還有最大尺寸。
恢復模式對日誌大小有巨大的影響。
還有很多要考慮的比初始大小。
另外看看把日誌放在一個單獨的驅動器來傳播IO。
看看把溫度放在一個單獨的驅動器來傳播IO。
備份前有多大？ – Paparazzi
我應該通過說我們的日誌的初始大小是20g，但是截斷是由備份軟件（Veeam）完成的。我不知道這種截斷是否是我們應該做的，因爲它可能會或可能不會正確處理VLF。也許Veeam和SQL Server（2005首選）用戶可以幫助回答這個問題。 – ctmcklowe96