（最初發佈在 DBA.StackExchange.com 上，但已關閉，希望在這裡更相關。）
亞歷山大和可怕的、可怕的、不好的、非常壞的…備份。
設定:
我有一個本地部署SQL Server 2016標準版實例運行在虛擬機來自VMWare。
@@版本：
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（內部的標準版本1433）版（64 位元）： )（管理程式）
伺服器本身目前已分配8 個虛擬處理器， 有32 GB 內存，以及所有的磁碟是 NVMe哪些繞過1 GB/秒的 I/O。資料庫本身位於 G: 磁碟機上，備份會單獨儲存在 P: 磁碟機上。所有資料庫的總大小約為 500 GB（在壓縮到備份檔案本身之前）。
維護計畫每晚（晚上 10:30 左右）運行一次，對伺服器上的每個資料庫進行完整備份。伺服器上沒有運行任何其他異常情況，也沒有任何其他特定時間正在運行。伺服器的電源計劃設定為「平衡」（並且「之後關閉硬碟」設定為 0 分鐘，即永不關閉）。
發生了什麼事：
在過去一年左右的時間裡，維護計畫作業的總運作時間約為 15分分鐘總共要完成。自上週以來，它所花費的時間激增至約 40 倍，約 15小時去完成。
在維護計劃放慢的同一天，我唯一知道的變化是在維護計劃運行之前在電腦上安裝了以下 Windows 更新：
我們也在另一台虛擬機器上配置了另一個類似的 SQL Server 實例，該實例經歷了相同的 Windows 更新，隨後也經歷了較慢的備份。我們認為 Windows 更新是直接原因，因此將其完全回滾，而且備份維護計劃仍然運行得非常慢。奇怪的是，恢復給定資料庫的備份速度非常快，並且幾乎使用了 NVMe 上的全部 1 GB/秒 I/O。
我嘗試過的事情：
當使用 Adam Mechanic 的 sp_whoisactive 時，我發現備份進程的最後等待類型始終表明存在磁碟效能問題。我總是看到BACKUPBUFFER並BACKUPIO等待類型，除了ASYNC_IO_COMPLETION：
在備份期間查看伺服器本身的資源監視器時，磁碟 I/O 部分顯示正在使用的總 I/O 僅約為 14 MB/秒（自此問題發生以來我見過的最高值是30 MB/秒） ：
偶然發現有幫助之後Brent Ozar 關於使用 DiskSpd 的文章，我嘗試自己在類似的參數下運行它（僅將線程數降低到 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 有很大差異，而且似乎還不足以成為我的問題的根本原因。進一步交叉檢查，我在伺服器本身上運行了一些 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。我撓頭了…
答案1
在這種情況下，我們確實遇到了磁碟問題，對於這個特定的虛擬機器來說，這不是 SQL Server 內部的問題。實際上，這最終是我們在使用 Veeam 和 VMWare 時遇到的一個錯誤案例。
總結一下我對發生的情況的理解，顯然 VMWare 並未承認我們的 Veeam 備份已完成。因此，當每天需要備份伺服器時，VMWare 都會指示 Veeam 重新備份前一天，這在兩週內變成了這個累積成長的問題。 （我確信我否定了這個解釋，但這幾乎就是我所知道的範圍。）
Veeam / VMWare 必須刪除每個快照文件，每天的文件都比前一天的文件大，因此他們的 3 級支援需要大約 26 小時才能完成。之後，虛擬機器又恢復正常運作了。根據他們的技術支持，顯然這並不是一個罕見的問題。
抱歉，這是一個非常具體的問題，可能不會對其他許多人有幫助，但希望能有所幫助。