読み取り可能なセカンダリのクエリ ストア

適用対象: SQL Server 2025 (17.x) Azure SQL Database

読み取り可能なセカンダリのクエリ ストアでは、セカンダリ レプリカで実行されるワークロードに対するクエリ ストアの分析情報が有効になります。 有効にすると、セカンダリ レプリカはクエリ実行情報 (ランタイムや待機統計など) をプライマリ レプリカにストリーミングします。このレプリカでは、データはクエリ ストアに保持され、すべてのレプリカで表示されます。

プラットフォームのサポート

現在、読み取り可能なセカンダリ機能のクエリ ストアは、SQL Server 2025 (17.x) および Azure SQL Database の運用環境で使用でき、サポートされています。 SQL Server 2025 (17.x) 以降、および Azure SQL Database では、読み取り可能なセカンダリのクエリ ストアが既定で有効になっています。

SQL Server 2022 (16.x) では、読み取り可能なセカンダリのクエリ ストアはプレビューのままであるため、運用環境ではサポートされていないため、既定では無効になっています。 SQL Server 2022 (16.x) でのみ読み取り可能なセカンダリに対してクエリ ストアを有効にするには、プライマリ レプリカとすべての読み取り可能なセカンダリ レプリカに対してトレース フラグ 12606 を有効にする必要があります。 トレース フラグ 12606 は、SQL Server 2022 (16.x) に基づく運用環境の展開用ではありません。 詳細については、 SQL Server 2022 リリース ノートを参照してください。 SQL Server 2025 (17.x) の場合、読み取り可能なセカンダリ機能のクエリ ストアは既定で オン になっています。

Azure SQL Database では、すべてのデータベースが自動的に登録され、サポート されているサービス レベルと高可用性シナリオで、読み取り可能なセカンダリ機能のクエリ ストアをサポートするように有効になります。 現時点では、この機能は Azure SQL Database Hyperscale ではサポートされていません。

現時点では、この機能は、Azure SQL Managed Instance または Microsoft Fabric の SQL データベースではサポートされていません。

サポートされている高可用性シナリオ

• SQL Server 2025 (17.x) インスタンスで読み取り可能なセカンダリにクエリ ストアを使用する前 に、Always On 可用性グループ を構成する必要があります。

• Azure SQL Database の場合、読み取り可能なセカンダリのクエリ ストアでは、次のサービス レベルがサポートされています。

  • アクティブ geo レプリケーションを用いた一般的な用途 (組み込みの高可用性レプリカはなく、セカンダリサポートには geo レプリケーションの構成が必要です)
  • Premium (組み込みの高可用性レプリカが含まれます。アクティブ ジオレプリケーションにも対応しています)
  • ビジネス クリティカル (組み込みの高可用性レプリカが含まれます。アクティブ geo レプリケーションもサポートされています)

読み取り可能なセカンダリのクエリ ストアを有効にする

プライマリ レプリカでクエリ ストアがまだ有効になっておらず、READ_WRITE モードの場合、先に進む前に有効にする必要があります。 プライマリ レプリカ上の目的のデータベースごとに、次のスクリプトを実行します。

ALTER DATABASE [Database_Name]
    SET QUERY_STORE = ON(OPERATION_MODE = READ_WRITE);

読み取り可能なすべてのセカンダリでクエリ ストアを有効にするには、プライマリ レプリカに接続し、この機能を使用するために参加するデータベースごとに次のスクリプトを実行します。

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_WRITE);

セカンダリ レプリカの自動プラン修正を有効にする

適用対象: SQL Server 2022 (16.x) 以降のバージョン、Azure SQL Database。

セカンダリ レプリカに対してクエリ ストアを有効にした後、必要に応じて自動チューニングを有効にして、自動プラン修正機能でセカンダリ レプリカにプランを強制できるようにします。 これにより、クエリ オプティマイザーは、セカンダリ レプリカでの実行プランの回帰によって発生するクエリ パフォーマンスの問題を自動的に特定して修正できます。

セカンダリ レプリカの自動プラン修正を有効にするには、プライマリ レプリカに接続し、目的のデータベースごとに次のスクリプトを実行します。

ALTER DATABASE [Database_Name]
FOR SECONDARY
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

セカンダリ レプリカのクエリ ストアを無効にする

すべてのセカンダリ レプリカでセカンダリ レプリカのクエリ ストア機能を無効にするには、master レプリカのprimary データベースに接続し、目的のデータベースごとに次のスクリプトを実行します。

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_ONLY);

セカンダリ レプリカでクエリ ストアが有効になっていることを検証する

セカンダリ レプリカ上のデータベースに接続して、 secondary レプリカでクエリ ストアが有効になっていることを検証し、次の T-SQL ステートメントを実行できます。

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

sys.database_query_store_options カタログ ビューのクエリ結果は、クエリ ストアの実際の状態がREAD_CAPTURE_SECONDARYであり、readonly_reasonが8であることを示す必要があります。

desired_state_desc	actual_state_desc	readonly_reason
READ_CAPTURE_SECONDARY	READ_CAPTURE_SECONDARY	8

注釈

用語

レプリカ セットは、データベースの読み取り/書き込みレプリカ (プライマリ) と、論理ユニットとして扱われる 1 つ以上の読み取り専用レプリカ (セカンダリ) として定義されます。 このコンテキストの ロール は、特定のレプリカのロールを指します。 レプリカがプライマリ ロールで機能している場合、データ変更と読み取りアクティビティの両方を実行できる読み取り/書き込みレプリカです。 レプリカを読み取り専用アクティビティのみを実行するように構成すると、セカンダリの役割（セカンダリ、ジオセカンダリ、ジオHAセカンダリ）として機能します。 ロールは、計画されたフェールオーバー イベントまたは計画されていないフェールオーバー イベントによって変更される可能性があります。この場合、プライマリがセカンダリになる場合と、その逆になる可能性があります。

現在サポートされているロールは次のとおりです。

• プライマリ
• Secondary
• 地理的セカンダリ
• Geo HA セカンダリ
• 名前付きレプリカ

動作方法

クエリに関して格納されたデータは、ロールごとにワークロードとして分析できます。 読み取り可能なセカンダリのクエリ ストアを使用すると、セカンダリ レプリカに対して実行される可能性がある一意の読み取り専用ワークロードのパフォーマンスを監視できます。 データはロール レベルで集計されます。 たとえば、SQL Server の 分散型可用性グループ の構成は、次で構成される場合があります。

• 可用性グループ 1 (AG1) の一部である 1 つのプライマリ レプリカ

• 2つのローカル セカンダリ レプリカもAG1の一部です。

• 別の可用性グループ (AG2) の一部である別の場所にある 1 つのリモート プライマリ レプリカ。 SQL Server の用語では、グローバル フォワーダーとも呼ばれますが、読み取り可能なセカンダリ機能のクエリ ストアは、地理的に分散されたセカンダリ レプリカであると仮定して、それを認識し、 Geo secondary レプリカと呼びます。

AG1 と AG2 が AG1 のセカンダリ レプリカのいずれかに対して読み取り専用ワークロードを実行するときに読み取り専用接続を許可するように構成されている場合、クエリ ストアの実行統計は AG1 のプライマリ レプリカに送信され、集計され、 secondary ロールから生成されたデータとして保持されてから、そのデータが AG2 のグローバル フォワーダーを含むすべてのセカンダリ レプリカに返されます。 AG2 のプライマリであるグローバル フォワーダーに対して別のワークロードが実行されると、そのデータは AG1 のプライマリ レプリカに送り返され、 Geo secondary ロールから生成されたデータとして保持されます。

監視の観点から、 sys.query_store_runtime_stats システム カタログ ビューが拡張され、実行統計の発生元のロールを特定するのに役立ちます。 このビューと sys.query_store_replicas システム カタログ ビューの間には関係があり、ロールのわかりやすい名前を指定できます。 SQL Server では、 replica_name 列が NULL。 ただし、名前付きレプリカが存在し、読み取り専用ワークロードに使用されている場合は、Hyperscale サービス レベルの replica_name 列が設定されます。

過去 8 時間の上位 50 個のクエリの全体的な分析に使用できる T-SQL クエリの例を次に示します。これは、すべてのレプリカから CPU リソースを消費しました。

-- Top 50 queries by CPU across all replicas in the last 8 hours
DECLARE @hours AS INT = 8;

SELECT TOP 50 qsq.query_id,
              qsp.plan_id,
              CASE qrs.replica_group_id WHEN 1 THEN 'PRIMARY' WHEN 2 THEN 'SECONDARY' WHEN 3 THEN 'GEO SECONDARY' WHEN 4 THEN 'GEO HA SECONDARY' ELSE CONCAT('NAMED REPLICA_', qrs.replica_group_id) END AS replica_type,
              qsq.query_hash,
              qsp.query_plan_hash,
              SUM(qrs.count_executions) AS sum_executions,
              SUM(qrs.count_executions * qrs.avg_logical_io_reads) AS total_logical_reads,
              SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) AS total_cpu_ms,
              AVG(qrs.avg_logical_io_reads) AS avg_logical_io_reads,
              AVG(qrs.avg_cpu_time / 1000.0) AS avg_cpu_ms,
              ROUND(TRY_CAST (SUM(qrs.avg_duration * qrs.count_executions) AS FLOAT) / NULLIF (SUM(qrs.count_executions), 0) * 0.001, 2) AS avg_duration_ms,
              COUNT(DISTINCT qsp.plan_id) AS number_of_distinct_plans,
              qsqt.query_sql_text
FROM sys.query_store_runtime_stats_interval AS qsrsi
     INNER JOIN sys.query_store_runtime_stats AS qrs
         ON qrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id
     INNER JOIN sys.query_store_plan AS qsp
         ON qsp.plan_id = qrs.plan_id
     INNER JOIN sys.query_store_query AS qsq
         ON qsq.query_id = qsp.query_id
     INNER JOIN sys.query_store_query_text AS qsqt
         ON qsq.query_text_id = qsqt.query_text_id
WHERE qsrsi.start_time >= DATEADD(HOUR, -@hours, GETUTCDATE())
GROUP BY qsq.query_id, qsq.query_hash, qsp.query_plan_hash, qsp.plan_id, qrs.replica_group_id, qsqt.query_sql_text
ORDER BY SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) DESC, AVG(qrs.avg_cpu_time / 1000.0) DESC;

SQL Server Management Studio (SSMS) 21 以降のバージョンのクエリ ストア レポートにはレプリカ ドロップダウン リストが用意されており、さまざまなレプリカ セット/ロールにわたってクエリ ストア データを表示できます。 また、オブジェクト エクスプローラー ビュー内のクエリ ストア ノードは、読み取り可能なセカンダリ レプリカに接続されている場合、クエリ ストア (つまり、READ_CAPTURE_SECONDARY) の現在の状態を反映します。

Azure SQL Database の読み取り可能なセカンダリ テレメトリのクエリ ストア

適用対象: Azure SQL データベース

Azure 診断設定を使用してクエリ ストア のランタイム統計 をストリーミングする場合、テレメトリ データのレプリカ ソースを識別するのに役立つ次の 2 つの列が含まれます。

• is_primary_b: データの送信元がプライマリ レプリカ (true) かセカンダリ レプリカ (false) かを示すブール値です。
• replica_group_id: レプリカ ロールに対応する整数

これらの列は、レプリカ セット間でワークロードを分析する際に、メトリックとパフォーマンス データを明確に区別するために不可欠です。 Log Analytics、Event Hubs、または Azure Storage にクエリ ストアのランタイム統計をストリーミングするように診断設定を構成する場合は、クエリとダッシュボードがこれらの列を考慮してレプリカ ロールによってデータを適切にセグメント化するようにします。 診断設定と使用可能なメトリックの構成の詳細については、「 Azure Monitor の診断設定」を参照してください。

Important

現在、Query Performance Insight for Azure SQL Database (QPI)does notでは、replica_group_idの概念がサポートされています。 ダッシュボード内に表示されるデータは、すべてのレプリカのすべてのランタイムと待機統計データを集計します。

読み取り可能なセカンダリのクエリ ストアのパフォーマンスに関する考慮事項

セカンダリ レプリカがクエリ情報をプライマリ レプリカに送信するために使用するチャネルは、セカンダリ レプリカを最新の状態に保つために使用されるのと同じチャネルです。 channelとはどういう意味ですか?

可用性グループ (HADR) 構成では、レプリカは、プライマリ レプリカとセカンダリ レプリカの間にログ ブロック、受信確認、およびステータス メッセージを含む専用トランスポート層を使用して相互に同期します。 これにより、データの一貫性とフェールオーバーの準備が保証されます。

読み取り可能なセカンダリのクエリ ストアが有効になっている場合、別のネットワーク エンドポイントは作成されません。 代わりに、既存のトランスポート層を介して新しい論理通信パスを確立します。

• Azure SQL Database (ハイパースケール以外)、Azure SQL Managed Instance、SQL Server では、高可用性とディザスター リカバリー (HADR) Always On トランスポート層が使用されます。

• Azure SQL Database Hyperscale では、リモート BLOB I/O トランスポート層と呼ばれる別のトランスポート層が使用されます。 リモート BLOB I/O トランスポート層は、コンピューティング ノードとログ サービス/ページ サーバー間の通信チャネルです。 リモート BLOB I/O トランスポート層は、ログ レコードとデータ ページを移動するための信頼性の高い暗号化されたチャネルを提供します。

このパスは、同じ暗号化されたセッションを使用して、通常のログ レコード トラフィックと共にクエリ ストアの実行データ (クエリ テキスト、プラン、ランタイム/待機統計) を多重化します。 この機能には独自のキャプチャ キューと受信キューがあります。これは、任意のレプリカの観点から sys.database_query_store_internal_state ビューに対してクエリを実行することで表示できます。

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

セカンダリからのデータは、プライマリ上の同じクエリ ストア テーブルに保持されるため、ストレージ要件が増加する可能性があります。 負荷が高い場合、トランスポート チャネルで待機時間やバックプレッシャが発生する可能性があります。 プライマリのクエリ ストアに適用されるのと同じアドホック クエリ キャプチャの制限は、セカンダリにも適用されます。 クエリ ストアのサイズとキャプチャ ポリシーの管理に関する詳細とガイダンスについては、「 クエリ ストアで最も関連性の高いデータを保持する」を参照してください。

負のクエリ ID/プラン ID の表示

負の ID は、プライマリに永続化する前のセカンダリのクエリ/プランの一時的なメモリ内プレースホルダーを示します。

クエリ ストアのデータが読み取り可能なセカンダリ レプリカからプライマリに永続化される前に、クエリ ストアのローカルインメモリ表現 ( MEMORYCLERK_QUERYDISKSTORE_HASHMAP) 内でクエリとプランに一時的な識別子が割り当てられる場合があります。 クエリ ID とプラン ID は負の数として表示され、プライマリ レプリカが権限のある識別子を割り当てるまでプレースホルダーになります。これは、クエリ ストアが構成された キャプチャ モードの要件を満たしているとクエリが判断した後に発生します。 カスタム キャプチャ ポリシーが設定されている場合は、sys.database_query_store_options システム カタログ ビューに対してクエリを実行して、満たす必要がある要件を確認できます。

SELECT query_capture_mode_desc,
       capture_policy_execution_count,
       capture_policy_total_compile_cpu_time_ms,
       capture_policy_total_execution_cpu_time_ms
FROM sys.database_query_store_options;

クエリがキャプチャ済みとして指定されると、その実行時/待機統計とプランを保持でき、ローカルの一時 ID は正の ID に置き換えられます。 これにより、プランの強制またはヒント機能を使用することもできます。

関連コンテンツ

• ALTER DATABASE SET オプション (Transact-SQL)
• sys.query_store_replicas
• sys.query_store_plan_forcing_locations (クエリ ストア プラン強制ロケーション) (Transact-SQL)
• sys.sp_query_store_force_plan(Transact-SQL)
• クエリ ストアのヒント
• クエリ ストアの使用シナリオ
• sys.database_query_store_options(Transact-SQL)
• クエリ ストアを使用してワークロードを監視するためのベスト プラクティス
• クエリ ストアを管理するためのベスト プラクティス
• クエリ ストアを使用してパフォーマンスを調整する