如何調試我的數據庫備份維護計劃突然執行極其緩慢的原因？
（最初發佈在 DBA.StackExchange.com 但已關閉，希望在這裡更相關。）
亞歷山大和可怕的，可怕的，不好的，非常糟糕的……備份。
設置：
我有一個在VMWare的虛擬機上執行的本地****SQL Server 2016 標準版實例。
@@版本：
Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) - 13.0.5888.11 (X64) 2021 年 3 月 19 日 19:41:38 版權所有 (c) Windows Server 2016 Datacenter 10.0（內部版本 14393）上的 Microsoft Corporation 標準版（64 位）： )（管理程序）
伺服器本身目前分配有8 個虛擬處理器，具有32 GB 記憶體，所有磁碟都是 NVMes ，其****I/O 速度約為1 GB/秒。數據庫本身位於 G: 驅動器上，備份單獨儲存在 P: 驅動器上。所有數據庫的總大小約為 500 GB（在壓縮到備份文件本身之前）。
維護計劃每晚執行一次（大約晚上 10:30），以對伺服器上的每個數據庫進行完整備份。伺服器上沒有執行其他任何異常，特別是在那個時候也沒有執行其他任何東西。關閉伺服器的電源計劃設置為“平衡”（並且“之後關閉硬碟”設置為 0 分鐘，即永不關閉）。
發生了什麼：
在過去一年左右的時間裡，維護計劃作業的總執行時間總共需要大約 15分鐘才能完成。自上週以來，它已飆升至大約 40 倍的時間，大約需要 15小時才能完成。
在維護計劃放緩的同一天，我唯一知道的更改是在維護計劃執行之前在電腦上安裝了以下 Windows 更新：
我們還在另一個 VM 上擁有另一個類似配置的 SQL Server 實例，該實例經歷了相同的 Windows 更新，隨後也經歷了較慢的備份。考慮到 Windows 更新是直接原因，我們將它們完全回滾，並且備份維護計劃仍然執行得非常緩慢。奇怪的是，為給定數據庫恢復備份的速度非常快，並且幾乎使用了 NVMes 上 1 GB/秒的全部 I/O。
我嘗試過的事情：
在使用 Adam Mechanic 的 sp_whoisactive 時，我發現備份過程的最後等待類型始終表明存在磁碟性能問題。我總是看到
BACKUPBUFFER並BACKUPIO等待類型，除了ASYNC_IO_COMPLETION：
查看伺服器本身的資源監視器時，在備份期間，磁碟 I/O 部分顯示正在使用的總 I/O 僅為大約 14 MB/秒（自此問題發生以來我見過的最多的是30 MB/秒）：
在偶然發現這篇關於使用 DiskSpd 的有用Brent Ozar 文章後，我嘗試在類似的參數下自己執行它（僅將執行緒數降低到 8，因為我在伺服器上有 8 個虛擬處理器並將寫入設置為 50%）。這是確切的命令
diskspd.exe -b2M -d60 -o32 -h -L -t8 -W -w50 "C:\Users\...\Desktop\Microsoft DiskSpd\Test\LargeFile.txt"。我使用了一個手動生成的文本文件，它不到 1 GB 大。我相信它測量的 I/O 看起來還不錯，但是磁碟延遲顯示了一些可笑的數字：
DiskSpd 結果看起來簡直令人難以置信。在進一步閱讀之後，我偶然發現了 Paul Randall 的一個查詢，該查詢返回每個數據庫的磁碟延遲指標。結果如下：
最差的寫入延遲為 63 毫秒，最差的讀取延遲為 6 毫秒，因此這似乎與 DiskSpd 有很大差異，而且似乎還不足以成為我問題的根本原因。進一步交叉檢查，根據這篇 Microsoft 文章，我在伺服器本身上執行了幾個 PerfMon 計數器，結果如下：
這裡沒什麼特別的，我測量的所有計數器的最大值是 0.007（我相信是毫秒？）。最後，我讓我的基礎架構團隊檢查了 VMWare 在備份作業期間記錄的磁碟延遲指標，結果如下：
似乎在最壞的情況下，午夜時分出現大約 200 毫秒的延遲峰值，最高 I/O 為 600 KB/秒（我不太明白，因為資源監視器顯示備份至少正在使用大約 14 MB/秒的 I/O）。
我嘗試過的其他事情：
我剛剛嘗試恢復一個較大的數據庫（大約 250 GB），總共只需要大約 8 分鐘即可恢復。然後我嘗試
DBCC CHECKDB在它上面執行，總共執行了 16 分鐘（不確定這是否正常），但資源監視器顯示了類似的 I/O 問題（它使用的最多 I/O 是 100 MB/s），沒有其他執行：
這是我第一次執行時的 sp_whoisactive 結果
DBCC CHECKDB，然後在完成 5% 後，請注意，即使已經完成 5%，估計剩餘時間也增加了大約 5 分鐘。開始：
5% 完成：
我猜這是正常的，它只是一個估計值，對於 250 GB 的數據庫來說，16 分鐘似乎並不算太糟糕（雖然我不確定這是否正常），但 I/O 再次達到最大值大約 10% 的驅動器功能，在伺服器或 SQL 實例上沒有執行其他任何東西。
這些是 的結果，
DBCC CHECKDB沒有報告錯誤。我也遇到了奇怪的
SHRINK命令緩慢問題。我剛剛嘗試SHRINK了釋放 5% 空間（大約 14 GB）的數據庫。它只用了大約 1 分鐘就完成了 90% 的SHRINK：
大約 5 分鐘後，它仍然停留在相同的完成百分比，並且我的事務日誌備份（通常在 1-2 秒內完成）已經爭用了大約 30 秒：
15 分鐘後
SHRINK剛剛完成，而事務日誌備份現在仍在爭用大約 6 分鐘，僅完成 50%。我相信他們在完成後立即SHRINK完成。資源監視器一直顯示 I/O 仍然很糟糕：
SHRINK然後，當它完成時，我收到了命令錯誤：
我
SHRINK再次重試，結果與上述完全相同。然後我嘗試手動將 T-SQL 備份腳本編寫到 P: 驅動器上的文件中，並且執行速度很慢，就像維護計劃備份作業一樣：
大約 3 分鐘後我最終取消了它，它立即回滾。
概括：
巧合的是，在安裝 Windows 更新後，備份維護計劃作業每晚都會慢 40 倍（從 15 分鐘到 15 小時）。回滾這些 Windows 更新並不能解決問題。SQL Server 等待類型、資源監視器和 Microsoft DiskSpd 表明存在磁碟問題（特別是 I/O），但來自 Paul Randall 查詢、PerfMon 和 VMWare 日誌的所有其他測量結果均未報告磁碟的任何問題。恢復特定數據庫的備份很快，並且幾乎使用了完整的 1 GB/秒 I/O。我在撓頭……
在這種情況下，我們確實遇到了磁碟問題，而且對於這個特定的 VM，這不是 SQL Server 內部的問題。它實際上最終成為了我們在 Veeam 和 VMWare 中遇到的錯誤案例。
總結一下我對所發生情況的理解，顯然我們的 Veeam 備份並未被 VMWare 確認為已完成。因此，每天需要備份伺服器時，VMWare 都會指示 Veeam 在前一天重新備份，這在兩週內變成了這個不斷增長的問題。（我確信我扼殺了那個解釋，但這幾乎是我所知道的範圍。）
Veeam / VMWare 必須刪除每個快照文件，每天的文件都比前一個大，因此他們的 3 級支持大約需要 26 小時才能完成。之後，VM 再次執行良好。顯然，根據他們的技術支持，這不是一個不常見的問題。
抱歉，這是一個非常具體的問題，可能不會幫助其他許多人，但希望它可以。