升級到更好的儲存後檢查點期間的等待時間增加
當我們從較舊的全快閃記憶體陣列遷移到較新的全快閃記憶體陣列（不同但成熟的供應商）時，我們開始看到 SQL Sentry 在檢查點期間的等待增加。
版本：SQL Server 2012 Sp4
在我們的舊儲存上，我們的等待時間約為 2k，在檢查點期間“峰值”到 2500，而新儲存的峰值通常為 10k，峰值接近 50k。Sentry 將我們更多地指向
PAGEIOLATCHwatis。做我們自己的分析，似乎是PAGEIOLATCH and PAGELATCH等待的組合。使用 Perfmon，我們通常可以說我們檢查點的頁面越多，我們得到的等待就越多，但在檢查點期間我們只刷新了 ~125 mb。我們的工作量主要是寫入（主要是插入/更新）。儲存供應商已向我們證明，光纖通道直連陣列在這些檢查點事件期間響應時間不到 1 毫秒。HBA 還確認陣列的編號。我們也不認為這是 HBA 排隊問題，因為隊列深度從未超過 8。我們還嘗試了更新的 HBA，更改 ZIO、執行限制和隊列深度設置無濟於事。我們還將伺服器的記憶體從 500 GB 增加到 1 TB，沒有任何變化。在檢查點過程中，我們確實看到 2 - 4 個單獨的核心（共 16 個）飆升至 100%，但總體 CPU 約為 20%。BIOS 也設置為高性能。有趣的是，我們確實看到 CPU 通常處於 C2 睡眠狀態，即使我們已禁用它，所以我們仍在研究為什麼睡眠狀態會超過 C1。
我們可以看到幾乎所有的等待都發生在數據頁面上，偶爾會出現 DCM 頁麵類型的 PFS。等待在使用者數據庫中，而不是在 tempdb 中。我們還看到等待是在多個數據頁上進行的，其中一些 SPID 在同一頁上等待。數據庫設計確實有幾個插入熱點，但舊儲存也採用了相同的設計。
執行這個查詢的循環 100 次，我們能夠捕捉到有多少 SPID 在磁碟和記憶體上等待
SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100
“好”的事情是我們可以在具有相同模型陣列和相似伺服器規格的 perf 環境中輕鬆重現該問題。我將不勝感激有關其他地方或如何縮小問題範圍的任何想法。目前我們的下一個測試包括：具有更新主機板和更多 CPU 的新伺服器；禁用 SIOS 數據管理器（即使舊儲存已使用此功能）；不同的HBA品牌。
exec sp_Blitz @outputtype = 'markdown'優先級 5：可靠性： - 危險的第三方模組 - Sophos Limited - Sophos 緩衝區溢出保護 - SOPHOS~2.DLL - 安裝了疑似危險的第三方模組。
優先級 200：資訊： - 集群節點 - 這是集群中的一個節點。- TraceFlag On - 全域啟用跟踪標誌 1117。- 全域啟用跟踪標誌 1118。- 全域啟用跟踪標誌 3226。
優先級 200：許可：- 企業版功能正在使用 * xxxxx -
$$ xxxxxx $$數據庫正在使用壓縮。如果將此數據庫還原到標準版伺服器上，則還原將在 2016 SP1 之前的版本上失敗。* xxxxxx - 的$$ xxxxxx $$數據庫正在使用分區。如果將此數據庫還原到標準版伺服器上，則還原將在 2016 SP1 之前的版本上失敗。 優先級 240：等待統計： - 未檢測到重大等待 - 此伺服器可能只是閒置，或者最近有人可能已清除等待統計。
優先級 250：伺服器資訊: - 硬體 - 邏輯處理器：16 個。物理記憶體：512GB。- 硬體 - NUMA 配置 - 節點：0 狀態：ONLINE 線上調度程序：8 離線調度程序：0 處理器組：0 記憶體節點：0 記憶體 VAS 保留 GB：1177 - 節點：1 狀態：ONLINE 線上調度程序：8 離線調度程序：0 處理器組：0 記憶體節點：1 記憶體 VAS 保留 GB：0 - 電源計劃 - 您的伺服器具有 3.50GHz CPU，並處於高性能電源模式 - 伺服器上次重新啟動 - 2018 年 7 月 4 日上午 4:56 - SQL Server 上次重新啟動 - 7 月 5 日2018 年上午 5:11 - SQL Server 服務 - 版本：11.0.7462.6。更新檔級別：SP4。版本：企業版（64 位）。啟用的可用性組：1. 可用性組管理器狀態：1 - 虛擬伺服器 - 類型：(HYPERVISOR) - Windows 版本 - 您正在執行一個非常現代的 Windows 版本：Server 2012R2 時代，版本 6.3
優先級 200：非預設伺服器配置: - Agent XPs - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - 備份壓縮預設值 - 此 sp_configure 選項已更改。其預設值為 0，已設置為 1。 - 阻塞程序門檻值 (s) - 此 sp_configure 選項已更改。其預設值為 0，已設置為 20。 - 並行成本門檻值 - 此 sp_configure 選項已更改。它的預設值為 5，已設置為 30。 - 數據庫郵件 XPs - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - max degree of parallelism - 此 sp_configure 選項已更改。它的預設值為 0，已設置為 8。 - 最大伺服器記憶體 (MB) - 此 sp_configure 選項已更改。它的預設值為 2147483647，並已設置為 496640。 - min server memory (MB) - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 8196。 - 針對臨時工作負載進行優化 - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - 遠端訪問 - 此 sp_configure 選項已更改。它的預設值為 1 並且已設置為 0。 - 遠端管理連接 - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - 掃描啟動過程 - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - 顯示高級選項 - 此 sp_configure 選項已更改。它的預設值為 0 並且已設置為 1。 - xp_cmdshell - 此 sp_configure 選項已更改。
唔。您顯示在檢查點期間等待的 spid，但沒有顯示平均/總體等待多長時間（老實說，這將是我所關心的）。進行差異等待統計分析以查看持續時間是否值得關注。另外，你圖表中的兩個等待到底是什麼？如果您在使用 1TB RAM 的情況下獲得大量記憶體授予等待，我們需要進行不同的討論。:-D
檢查點期間的 125MB 寫入速度：是只是檢查點寫入還是全部？無論哪種方式，全快閃記憶體儲存似乎都很低。您是否針對各種寫入模式對所述儲存進行了基準測試，如果是，您得到了什麼數字？
我們不確定為什麼我們的 SQL Server 的行為發生了變化（我們有證據表明它發生在儲存切換之前），但是為使用者 DB 啟用間接檢查點已經為我們解決了這個問題。