我是否需要在我的數據庫日誌文件所在的磁碟上留出一些額外的空間，以便日誌備份操作成功進行？

如果我調整日誌文件的大小以平均分割它們所在的整個驅動器，不留下額外的可用空間，日誌備份是否仍然能夠成功進行？我有幾個數據庫，每個數據庫有一個日誌文件。

不要在驅動器上留下任何可用空間，即將其全部分配給日誌文件是一種好習慣嗎？（在這種情況下，驅動器專用於日誌文件，數據和作業系統位於它們自己的分區上。）

如果日誌文件所在的驅動器沒有可用空間，則SQL Server沒有技術問題，假設日誌本身沒有用完可用的、未使用的 VLF 條目。

如果日誌用完可用空間，您將無法送出任何事務，直到您解決問題。如果整個驅動器都被日誌文件佔用，您可以採取的唯一措施是將不同驅動器上的日誌文件添加到數據庫中。如果您主動管理您的日誌文件，並且永遠不會用完日誌空間，那麼就沒有技術禁止您做您正在考慮的事情。

話雖如此，我不建議您調整日誌文件的大小以消耗所有可用的驅動器空間：

1. Windows 會抱怨磁碟空間不足，這可能很煩人。
2. 如果您確實用完了日誌空間，並且幾乎可以肯定在某個時候會用完，那麼在您添加新的日誌文件之前，數據庫將無法訪問。
3. 磁碟空間的成本是多少？與 SQL Server 企業版許可的價格以及停機時間給企業帶來的潛在成本相比，幾乎沒有什麼價值。問問自己為什麼不在驅動器上留下一點空間。請不要認為這意味著我支持使用錯誤的數據類型，例如使用 abigint而不是 a int，甚至是 a smallint。未使用的磁碟空間很便宜，但由於@SolomonRutzky在此處簡潔概述的原因，應將數據庫內使用的空間視為溢價成本。

在評論中，您提到您發現日誌增長以填滿磁碟與磁碟已被大部分空日誌填滿，隨後又被填滿之間沒有區別。假設是正確的，這兩個事件都會導致伺服器返回以下錯誤：

消息 9002，級別 17，狀態 2，第 22 行

由於“LOG_BACKUP”，數據庫“<database_name>”的事務日誌已滿。

但是，如果您有 SAN，則可以精簡配置驅動器，最大容量為 10TB。使用估計的“正確”初始大小創建日誌文件，例如 1GB，增長設置為 1GB（或任何有意義的值）。這樣您就不會使用比您需要的更多的 SAN 磁碟空間，但是您將有空間來增加日誌文件，而無需 SAN 管理員參與。雙贏。

---

在我之前的回答版本中，我陳述了以下不正確的資訊：

當您已經用完日誌空間時添加日誌文件可能是不可能的，因為添加日誌文件這一事實會修改主數據文件，這需要寫入日誌。這是一種先有雞還是先有蛋的事情。

經過一些相當廣泛的測試後，我能夠在現有日誌文件空間不足後成功添加新的日誌文件。我在SQLServerScience.com上寫了一篇博文，展示了它是如何工作的。添加新日誌文件所需的操作包括：

1. 在磁碟上物理創建新文件
2. 將新的 VLF 結構寫入文件
3. 更新現有日誌文件 - 現有日誌文件中必須為此目的預先分配足夠的空間，不能用於其他任何事情。
4. 更新主 mdf 以反映新創建的日誌文件。

以上已在 SQL Server 2008 R2 和 SQL Server 2016 上得到驗證。

引用自：https://dba.stackexchange.com/questions/232048