分析差異備份，看看為什麼這麼大

我們很快就有了非常大的差異文件。儘管該數據庫是一個高度事務性的數據庫，但也有大量的靜態數據。

進行完整備份後的 1 或 2 天，差異備份大於完整備份。（那裡有 2 天，因為一天完全備份失敗，所以我能夠見證第二天）。

目前的備份計劃是：每天full，每2小時diff備份，每分鐘log備份。所有備份都在單獨的文件中。

有沒有辦法分析導致差異備份的原因是什麼？

由於我們每分鐘都進行一次 tran 備份，因此如果我們每 2 小時進行一次 diff 備份，則不需要那麼多恢復。我們聽取了https://www.brentozar.com/archive/2014/02/back-transaction-logs-every-minute-yes-really/的建議

sys.dm_db_file_space_usage對,modified_extent_page_count列進行快照。這正是所說的。自上次完整備份以來修改了多少擴展區，以頁為單位。

本專欄於 2016 年推出。在此之前，您會破解 DIFF 地圖頁面。正如 Paul Randal在這裡所解釋和舉例說明的那樣，以及 @Mo64 在評論中所建議的那樣。

每 5 分鐘拍一張這樣的快照到一張桌子上，看看它什麼時候爆炸。可能這足以讓您確定是什麼原因造成的。我的猜測是一些批處理工作。

如果這還不夠，請繼續前進，這樣您就有了可靠的模式（“每週二下午 3 點到 3:15 之間”）。您現在可以在那時在您的系統上執行 XE 跟踪並擷取送出給您的 SQL Server 的 SQL。

使用此查詢，您可以從日誌備份中查看哪些表更新最多。用您的日誌備份文件替換 pathtologbackup

SELECT o.name, count(*)
FROM fn_dump_dblog (NULL, NULL, N'DISK', 1, N'pathtologbackup',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
left join sys.partitions p on p.partition_id=PartitionId
left join sys.objects o on o.object_id=p.object_id
group by o.name
order by count(*) desc

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