即使有日誌備份，日誌也會增長並佔用整個日誌驅動器

我有一個僅用於日誌的捲和另一個僅用於日誌備份的捲。

即使每 1 分鐘進行一次日誌備份，日誌量也會不斷增長，直到空間不足。

備份不是應該釋放日誌文件中的空間以再次寫入嗎？

這似乎沒有發生。

在您的伺服器上執行此查詢

SELECT [NAME], 
      RECOVERY_MODEL_DESC,
      LOG_REUSE_WAIT_DESC,
      IS_PUBLISHED,
      IS_MERGE_PUBLISHED,
      is_subscribed
FROM SYS.DATABASES

如果您在 LOG_REUSE_WAIT_DESC 中有與 NOTHING 不同的內容，那麼我將開始調查。

SQL Server 無法截斷事務日誌時可能會報告的八個原因

這可能是阻止日誌中的空間被重新使用的原因。

對於ACTIVE_TRANSACTION

我喜歡使用名為sp_whoisactive的儲存過程，它會告訴您伺服器上目前正在執行什麼。

或者更簡單，只是看看是否有未結交易：

DBCC opentran WITH NO_INFOMSGS

對於LOG_BACKUP

為什麼 log_reuse_wait_desc 在做日誌備份後說 LOG_BACKUP？

LOG_BACKUP 真正的意思是“要麼你需要進行日誌備份，要麼備份的日誌記錄都在目前的 VLF 中，因此無法清除。”

SQL Server 無法截斷事務日誌時可能會報告的八個原因

如果您的數據庫恢復模型是“完整的”，則 SQL Server 無法重用虛擬日誌文件，除非所有包含的事務日誌記錄都已使用日誌備份進行備份。如果日誌備份未完成，則日誌必須增長以適應新的數據更改。在此期間，您將看到 LOG_BACKUP 的 log_reuse_wait_desc。完整備份或差異備份不會備份所有事務日誌記錄，因此您需要執行實際日誌備份以允許虛擬日誌文件重用。

在這種情況下，我認為每分鐘備份一次事務日誌太高了。

在事務日誌中查找 VLF 的數量。

我遇到了這種情況：MY_DB (232 Gb) = 500,000 VLF

這就是我所做的（保持每個 VLF = 8GB）：

dbcc sqlperf(logspace)
go
use my_db
Go
select size/128,* from sys.sysfiles
dbcc loginfo('my_db')

-- updated my_db autogrowth to 4096Mb (chunk of 4 Gb)
DBCC SHRINKFILE(my_db_log, 1)
select size/128,* from sys.sysfiles


ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 8GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 16GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 24GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 32GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 40GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 48GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 56GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 64GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 72GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 80GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 96GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 104GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 112GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 120GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 128GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 136GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 144GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 152GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 160GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 168GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 176GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 184GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 192GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 200GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 208GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 216GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 224GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 232GB )
ALTER DATABASE [MY_DB] MODIFY FILE ( NAME = N'my_db_log', SIZE = 240GB ) 

事務日誌 VLC - 每個都是 4GB 的倍數

因此，我快速瀏覽了備份作業，當實際情況並非如此時，它們是成功的。查看日誌沒有生成新的日誌。事實證明，在不應該佔用儲存日誌的捲上的空間的情況下，保留了額外的備份。

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