在數據庫備份之前和之後縮小事務日誌文件的原因可能是什麼？

我是一個偶然的 DBA。我是一家公司中唯一一個對 SQL Server 有一定經驗的人，我必須處理從另一家公司繼承的系統在被收購後。最初設置的人不再可用。

伺服器版本：Microsoft SQL Server 2016 (SP1-CU15-GDR) (KB4505221) - 13.0.4604.0 (X64) Jun 15 2019 07:56:34 版權所有 (c) Microsoft Corporation Enterprise Edition：基於核心的許可（64 位）在 Windows Server 2016 Datacenter 10.0（內部版本 14393：）（管理程序）上

當我查看伺服器時，首先引起我注意的事情之一是一個 SQL Server 代理作業，它對主數據庫進行備份。數據庫處於簡單恢復模式。這項工作分為三個步驟：

-- step 1
DBCC SHRINKFILE (N'DWH_Main_log' , 0)

-- step 2
declare @disk varchar(100) = replace(N'G:\DB_Backup\DWH_Main_&d&.bak','&d&', convert(varchar, getdate(), 112))
--print @disk
;
BACKUP DATABASE [DWH_Main] 
   TO  DISK = @disk
   WITH  RETAINDAYS = 2
       , NOFORMAT
       , NOINIT
       ,  NAME = N'DWH_Main-Full Database Backup'
       , SKIP
       , NOREWIND
       , NOUNLOAD
       , COMPRESSION
       ,  STATS = 10
GO

-- step 3
WAITFOR DELAY '00:05'
;
DBCC SHRINKFILE (N'DWH_Main_log' , 0)

數據文件大小約為 400GB，目前的日誌文件大小約為 50GB。

CREATE DATABASE [DWH_Main]
CONTAINMENT = NONE
ON  PRIMARY 
( NAME = N'DWH_Main', FILENAME = N'E:\Data\DWH_Main.mdf' , SIZE = 411114496KB , 
 MAXSIZE = UNLIMITED, FILEGROWTH = 65536KB )
LOG ON 
( NAME = N'DWH_Main_log', FILENAME = N'F:\Log\DWH_Main_log.ldf' , SIZE = 53941184KB , 
 MAXSIZE = 2048GB , FILEGROWTH = 65536KB )

我可以看到很多日誌文件自動增長事件，這並不奇怪。DBCC LOGINFO返回 858 行，即 858 個片段，幾乎每個片段 64MB。

對於這種情況，我應該對我的老闆說些什麼？我不明白為什麼有人會希望在完整備份後每天都縮小事務日誌文件，尤其是對於處於簡單恢復模式的數據庫。

我的第一反應是簡單地DBCC SHRINKFILE從腳本中刪除命令，然後重新配置事務日誌文件的初始大小。以 8GB 塊手動將其增長到 ~64GB 以減少碎片，但也許我遺漏了什麼？

很可能設置該配置的人對 SQL Server 不是很有經驗。

或者，磁碟空間非常寶貴，即使您只在它（很快）再次增長之前回收一些磁碟空間，執行收縮的成本和缺點被認為比磁碟空間成本優先級低。不太可能，但理論上的可能性。

為什麼在完整備份之前和之後都進行收縮？打敗我。完整備份會執行一個檢查點，這將清空日誌（處於簡單恢復中），因此在完整備份之後進行收縮是合理的做法。當我們談論正常日誌收縮時，如果可以使用“合理”這個詞。

我會刪除收縮並添加一些監控。即，每 5 分鐘輪詢一次日誌的大小，看看它是否/何時增長。

當然，正如您所說，將其擴大到合理的大小。如果您有可用的資訊，那可能應該是您的高水印文件大小。可能是第一次縮小之前的大小 - 數據庫中的異常事件不計算在內……

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