アダプティブ キャッシュを監視する方法

この記事では、ワークロードが専用 SQL プールのアダプティブ キャッシュを最適に活用しているかどうかを判断することで、パフォーマンスが遅いクエリを監視し、トラブルシューティングする方法について説明します。

専用 SQL プール ストレージ アーキテクチャでは、NVMe ベースの SSD に搭載されているキャッシュ内で、最も頻繁に照会される列ストア セグメントが自動的に階層化されます。 クエリでキャッシュに常駐しているセグメントを取得すると、パフォーマンスが向上します。

Azure Portal を使用したトラブルシューティング

Azure Monitor を使用すれば、キャッシュ メトリックを表示して、クエリのパフォーマンスをトラブルシューティングできます。 まず Azure portal に移動し、 [監視] 、 [メトリック] 、 [+ スコープの選択] の順にクリックします。

検索バーとドロップダウン バーを使用して、お使いの専用 SQL プールを見つけます。 次に、[適用] を選択します。

キャッシュをトラブルシューティングするための主要なメトリックは、 [キャッシュ ヒット率] と [キャッシュ使用率] です。 [キャッシュ ヒット率] を選択した後、 [メトリックの追加] ボタンをクリックして [キャッシュの使用率] を追加します。

キャッシュのヒット率と使用率

以下の表は、キャッシュ メトリックの値に基づくシナリオを示しています。

	高いキャッシュ ヒット率	低いキャッシュ ヒット率
高いキャッシュ使用率	シナリオ 1	シナリオ 2
低いキャッシュ使用率	シナリオ 3	シナリオ 4

シナリオ 1: キャッシュを最適に使用しています。 クエリを遅くしている可能性があるその他の領域をトラブルシューティングしてください。

シナリオ 2: 現在稼働中のデータ セットはキャッシュに収まりきらないため、物理的な読み取りのためにキャッシュ ヒット率が低くなります。 パフォーマンス レベルの拡張を検討し、ワークロードを再実行してキャッシュを設定してください。

シナリオ 3: キャッシュとは無関係な原因により、クエリが遅く実行されている可能性があります。 クエリを遅くしている可能性があるその他の領域をトラブルシューティングしてください。 また、インスタンスを縮小し、キャッシュ サイズを削減してコストを節約することも検討してください。

シナリオ 4: クエリが遅かったのは、コールド キャッシュが存在していたことが原因だった可能性があります。 現在稼働中のデータ セットがキャッシュされるように、クエリを再実行することを検討してください。

重要

キャッシュヒット率またはキャッシュ使用率がワークロードの再実行後にも更新されない場合、稼働中のセットは既にメモリに常駐している可能性があります。 クラスター化された列ストア テーブルのみがキャッシュされます。

次のステップ

一般的なクエリのパフォーマンス チューニングの詳細については、「クエリの実行の監視」を参照してください。