Tip
Microsoft Fabric Data Warehouse は、将来のアーキテクチャ、組み込みの AI、および新機能を備えた、Data Lake 基盤上のエンタープライズ 規模のリレーショナル ウェアハウスです。 データ ウェアハウスを初めて使用する場合は、Fabric Data Warehouseから始めます。 既存の dedicated SQL プール ワークロードは、Fabric にアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。
- Fabric無料試用版を開始します。
- Fabric Data Warehouse 用マイグレーションアシスタント
この記事では、ワークロードが専用 SQL プールのアダプティブ キャッシュを最適に活用しているかどうかを判断して、低速なクエリ パフォーマンスを監視およびトラブルシューティングする方法について説明します。
専用 SQL プール ストレージ アーキテクチャでは、NVMe ベースの SSD に存在するキャッシュ内で、最も頻繁に照会される列ストア セグメントが自動的に階層化されます。 キャッシュに存在するセグメントをクエリが取得すると、パフォーマンスが向上します。
Azure Portal を使用したトラブルシューティング
Azure Monitor を使用してキャッシュ メトリックを表示し、クエリのパフォーマンスをトラブルシューティングできます。 まず Azure portal に移動し、[ 監視]、[ メトリック] の順にクリックし、 スコープを選択します。
![スクリーンショットは、Azure portal の [メトリック] から選択されたスコープを選択するを示しています。](media/sql-data-warehouse-how-to-monitor-cache/cache-0.png)
検索バーとドロップダウン バーを使用して、専用 SQL プールを見つけます。 次に、[適用] を選択します。
![スクリーンショットには、データ ウェアハウスを選択できる [スコープの選択] ウィンドウが示されています。](media/sql-data-warehouse-how-to-monitor-cache/cache-1.png)
キャッシュのトラブルシューティングの主要なメトリックは、 キャッシュ ヒット率 と キャッシュ使用率です。 [ キャッシュ ヒット率 ] を選択し、[ メトリックの追加 ] ボタンを使用して キャッシュの使用率を追加します。
キャッシュ ヒット率と使用率
次のマトリックスでは、キャッシュ メトリックの値に基づくシナリオについて説明します。
| キャッシュヒット率が高い | キャッシュヒット率が低い | |
|---|---|---|
| キャッシュ使用率が高い | シナリオ 1 | シナリオ 2 |
| キャッシュ使用率が低い | シナリオ 3 | シナリオ 4 |
シナリオ 1: キャッシュを最適に使用しています。 クエリの速度が低下する可能性があるその他の領域のトラブルシューティングを行います。
シナリオ 2: 現在の作業データ セットがキャッシュに収まらないため、物理読み取りによるキャッシュ ヒット率が低くなります。 パフォーマンス レベルをスケールアップし、ワークロードを再実行してキャッシュを埋めることを検討してください。
シナリオ 3: キャッシュに関係のない理由により、クエリの実行速度が低下している可能性があります。 クエリの速度が低下する可能性があるその他の領域のトラブルシューティングを行います。 コストを節約するために、 インスタンスをスケールダウン してキャッシュ サイズを減らすことも検討できます。
シナリオ 4: コールド キャッシュが存在していたため、クエリが遅かった原因である可能性があります。 作業データセットがキャッシュされるようになったので、クエリを再実行することを検討してください。
重要
ワークロードの再実行後にキャッシュ ヒット率またはキャッシュ使用率が更新されない場合は、ワーキング セットが既にメモリ内に存在している可能性があります。 クラスター化列ストア テーブルのみがキャッシュされます。
次のステップ
一般的なクエリ パフォーマンスチューニングの詳細については、「 クエリ実行の監視」を参照してください。