古いオールフラッシュアレイから新しいオールフラッシュアレイ（異なるが、確立されたベンダー）に移行すると、チェックポイント中にSQL Sentryで待機が増えることがわかりました。
バージョン：SQL Server 2012 Sp4
私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2,500で約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。歩哨は私たちをPAGEIOLATCHワティスにもっと向けます。独自の分析を行うと、PAGEIOLATCH and PAGELATCH待機の組み合わせのようです。Perfmonを使用すると、一般に、チェックポイントを行うページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです（主に挿入/更新）。
ストレージベンダーは、ファイバーチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、HBAキューの問題であるとは考えていません。また、ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1 TBに変更せずに増やしました。チェックポイントプロセス中に、2〜4個のコア（16個のうち）が100％に急上昇しますが、全体的なCPUは約20％です。BIOSも高パフォーマンスに設定されています。興味深いことに、CPUがC2スリープ状態になっているのは無効にしたにもかかわらず、通常はC2スリープ状態であるため、スリープ状態がC1を超えた理由を調査しています。
ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部の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
「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。SIOSデータキーパーを無効にする（これが古いストレージで行われている場合でも）。異なるHBAブランド。
exec sp_Blitz @outputtype = 'markdown'優先度5：信頼性：-危険なサードパーティモジュール-Sophos Limited-ソフォスのバッファーオーバーラン保護-SOPHOS〜2.DLL-危険と思われるサードパーティモジュールがインストールされています。
優先度200：情報：-クラスターノード-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117がグローバルに有効になります。-トレースフラグ1118がグローバルに有効になります。-トレースフラグ3226がグローバルに有効になります。
優先度200：ライセンス：-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 SP1より前のバージョンでは復元が失敗します。* xxxxx-[xxxxxx]データベースはパーティショニングを使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 SP1より前のバージョンでは復元が失敗します。
優先度240：待機統計：-重大な待機は検出されませんでした-このサーバーはアイドル状態にあるか、誰かが最近待機統計をクリアした可能性があります。
優先度250：サーバー情報：-ハードウェア-論理プロセッサー：16.物理メモリー：512GB。-ハードウェア-NUMA構成-ノード：0状態：オンラインオンラインスケジューラ：8オフラインスケジューラ：0プロセッサグループ：0メモリノード：0メモリVAS予約済みGB：1177-ノード：1状態：オンラインオンラインスケジューラ：8オフラインスケジューラ：0プロセッサグループ：0メモリノード：1メモリVAS予約済みGB：0-電源プラン-サーバーに3.50 GHz CPUがあり、高性能電源モードです-サーバーの最終再起動-2018年7月4日4:56 AM-SQLサーバーの最終再起動-7月5日2018 5:11 AM-SQL Serverサービス-バージョン：11.0.7462.6。パッチレベル：SP4。エディション：Enterprise Edition（64ビット）。可用性グループの有効化：1.可用性グループマネージャーのステータス：1-仮想サーバー-タイプ：（HYPERVISOR）-Windowsバージョン-Windowsのかなり新しいバージョンを実行しています：サーバー2012R2時代、バージョン6.3
優先度200：デフォルト以外のサーバー構成：-エージェントXP-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。-バックアップ圧縮のデフォルト-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-ブロックされたプロセスのしきい値（複数可）-このsp_configureオプションが変更されました。デフォルト値は0で、20に設定されています。-並列処理のコストしきい値-このsp_configureオプションが変更されました。デフォルト値は5で、30に設定されています。-データベースメールXP-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-最大並列度-このsp_configureオプションが変更されました。デフォルト値は0で、8に設定されています。-最大サーバーメモリ（MB）-このsp_configureオプションが変更されました。デフォルト値は2147483647で、496640に設定されています。-最小サーバーメモリ（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オプションが変更されました。