如何最好地維護 SQL 日誌文件大小

我有點像一個新的 DBA，我正在管理一個有大量活動的 SQL Server 2012 實例。我在完全恢復模式下執行，因為我們需要時間點恢復。

現在，我每天早上 5 點對數據庫和日誌進行完整備份。一些日誌文件已經膨脹到 300gb，即使在進行備份後，它們的大小也不會減小。我可以通過執行類似於以下內容來減小它們的大小：

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

當我檢查備份文件的 LSN 時，我看到如下內容：

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

我不相信我會通過縮小日誌文件來破壞我的日誌鏈。閱讀此內容後，我確實相信我正在損害我的表現，因為那些縮小的日誌文件必須重新增長自己。

問題：

1. 為什麼備份後日誌文件沒有縮小？是因為有未送出的交易嗎？
2. 起初我想我應該在每 5:00 AM 備份後縮小日誌文件。在閱讀了這對性能有何不利影響後，我現在認為我需要在一天中每隔幾個小時定期進行一次日誌備份。那是對的嗎？
3. 我每天早上 5:00 對數據庫/日誌進行正常的完整備份，有時需要 3 個小時。如果我將日誌備份安排為每小時發生一次，那麼當日誌備份與 5:00 AM 備份衝突時會發生什麼？

1. 為什麼備份後日誌文件沒有縮小？是因為有未送出的交易嗎？

實際的 NTFS 日誌文件不會從事務日誌備份中“縮小”，但事務日誌中的 VLF（虛擬日誌文件）被標記為可重用（因為它們現在已備份並保存在媒體上），從而允許環繞事務日誌使用發生。如果您沒有備份事務日誌，或者不夠頻繁，那麼將沒有可用的 VLF，這將導致事務日誌增長（假設設置了自動增長）以容納額外的事務日誌條目。

2.起初我想我應該在每 5:00 AM 備份後縮小日誌文件。在閱讀了這對性能有何不利影響後，我現在認為我需要在一天中每隔幾個小時定期進行一次日誌備份。那是對的嗎？

例行和計劃的文件收縮不是一個好主意。只有當您需要回收急需的空間時，您才應該考慮使用DBCC SHINKFILE. 此外，當您不斷增加事務日誌時，您可能會阻礙其他事情，例如數據庫的恢復。由於事務日誌中的 VLF 太多（事務日誌僅以很小的儲存增量增長時的常見問題），恢復數據庫的時間可能比預期的要長。

3.我每天早上 5:00 對數據庫/日誌進行正常的完整備份，有時需要 3 個小時。如果我將日誌備份安排為每小時發生一次，那麼當日誌備份與 5:00 AM 備份衝突時會發生什麼？

什麼都不會發生，這是完全合法的操作。請參閱MSDN的下圖。有黑點的地方，這兩個操作不能同時發生。如您所見，允許同時進行數據庫備份和事務日誌。

這裡的要點是您應該更頻繁地備份您的事務日誌。如果不更頻繁地備份事務日誌，NTFS 文件增長並不是唯一可能遇到的問題。如果您遇到儲存故障並且您的事務日誌失去，那麼您只能恢復到上次事務日誌備份的時間點。如果事務日誌失去，您將無法備份日誌尾部並恢復到故障的時間點。在您的情況下，您可能會失去 24 小時的數據。但是，如果您每隔 30 分鐘備份一次事務日誌，那麼您的最大數據失去時間將是 30 分鐘。在這種情況下，如果您的事務日誌消失了，並且您擁有完整備份和完整的日誌鏈，您可以恢復到最後一個日誌備份。

關於事務日誌截斷的 TechNet 文件

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