為什麼我的日誌文件如此龐大？22GB。我正在執行日誌備份

我似乎無法找出答案。我見過多個這樣的答案： 為什麼事務日誌不斷增長或空間不足？

每個人都在談論在您的日誌文件上執行備份以使其縮小。我正在這樣做，但它不會縮小任何東西！我也不相信我正在執行任何超長交易。

伺服器：SQL Server 2008

恢復模式：Full

我有一個維護計劃來儲存 5 天的備份。任務 1 使用 Backup Type 備份數據庫Full，任務 2 備份事務日誌。Verify backup integrity對這兩個任務進行檢查。

我的數據庫的正常.ldf文件是 22gb。當我執行上述任務時，.bak文件是435mb，但.trn.文件是22gb，與ldf相同。在成功執行之後，.ldf它根本不會縮小，儘管我讀過的所有內容都告訴我它應該？

這裡發生了什麼，為什麼日誌文件不會縮小？

如另一個答案中所述，我也嘗試過執行此命令：

select name, log_reuse_wait_desc from sys.databases

它說LOG_BACKUP的是帶有巨大日誌文件的數據庫。

根據下面的答案，我對已用空間的分配感到困惑。這些是我的統計數據：

由於我不知道為什麼，初始大小設置為 22gb …

您將分配的空間與已用空間混淆了。執行備份後，使用此查詢查看已分配空間和已用空間之間的差異。

select file_id
, type_desc
, name
, substring([physical_name],1,3) AS [Drive]
, physical_name
, state_desc
, size / 128 as 'AllocatedSizeMB'
, FILEPROPERTY([name],'SpaceUsed') /128 AS 'SpaceUsedMB'  --Addapted from https://sqlperformance.com/2014/12/io-subsystem/proactive-sql-server-health-checks-1
, (1- (FILEPROPERTY([name],'SpaceUsed') / CAST (size AS MONEY))) *100 AS 'PercentFree'
, growth / 128 as 'GrowthSettingMB'

from sys.database_files
order by type_desc Desc, name

您可以使用 GUI 通過更改“初始大小”來縮小日誌文件

如果您在縮小日誌時遇到問題，即使它看起來大部分都是空的，請參閱我的文章here

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