ALTER 導致“等待緩衝區鎖存器類型 2 時發生超時”
以下語句失敗，在等待頁面 (1:4365112) 的緩衝區閂鎖類型 2 時發生超時，數據庫 ID 12。：
alter table [T] add Id bigint identity(1, 1)有問題的表 T 有 500 萬行，每行都有一些大文本列，總共 60GB。它的設計很糟糕，所以我們試圖用一個簡單的整數自動增量 ID 和非聚集索引替換它目前的標識列，一個設置為聚集索引的 GUID 字元串列。該表只被附加到 - 它是一個審計日誌。它的數據很少被查看，但由於聚集索引和表非常大，因此佔用了大量 RAM。
ALTER 語句適用於小副本，但在較大的表上因給定錯誤而失敗，我們可能需要它在行數為 10 倍的表上工作。大約 1 小時後出現上述消息。
如果我們將數據庫置於單使用者模式，我們會在大約 45 分鐘內得到類似的錯誤，但速度稍快：在等待頁面 (1:4495724) 的緩衝區閂鎖類型 4 時發生超時，數據庫 ID 為 12。
我們可以用不同的方式完成相同的任務，例如，定義一個新表，然後編寫一些 T-SQL 以逐步插入行並建立新索引，然後刪除原始表。但是如果有辦法讓 ALTER 工作，那會更簡單，所以任何建議都會受到讚賞。
SQL 2019，在幾乎沒有負載的測試伺服器上。物理伺服器、大量磁碟和 RAM、SSD 驅動器。
該問題似乎是由於磁碟訪問速度慢和其他程序造成的。
我們查看了 SQL 錯誤日誌、Windows 事件查看器和 SQL 活動監視器。事件查看器中發布了硬體 I/O 錯誤，我們發現 Acronis 備份（使用 VSS）持續執行。我們進一步發現，由於它的大小，這個特定的數據庫被安裝在一個單獨的 SATA 驅動器上，而不是安裝在該伺服器上安裝其他數據庫的主 SSD 驅動器上。（因此我原來的文章關於 SSD 是錯誤的）。
因此，總而言之，我們發現數據庫在較慢的驅動器上，並且備份子系統正在不斷地使用它。這使 SATA 磁碟緊張到無法完成操作並在事件查看器中引發錯誤的程度。
我們將數據庫移至 SSD/RAID 驅動器集並降低備份頻率，然後此操作在 30 分鐘內完成。我沒有嘗試關閉和備份 SATA 驅動器，但我想這會慢得多。