SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Database で読み取り可能なセカンダリレプリカに対してのクエリストアが使用できるようになっていました

leave a comment

先日気づいたのですが、SQL Database で 読み取り可能なセカンダリレプリカに対してのクエリストア が使用できるようになっていました。

アップデートのアナウンスは見当たらなかったのですが、本機能についての情報を整理しておきたいと思います。

機能の実装が行われたタイミング

前述のとおり、本機能に対してのアナウンスが見当たらなかったのですが、私の環境では、2025-10-03 辺りからクエリストアの情報の取得が行われていそうでした。

ドキュメントでは次のタイミングで更新が行われています。

ドキュメントとしては、2025-10-03 のタイミングで次のサービスレベルで利用することができるようになった記載が追加されたようです。

  • 汎用目的の Active Geo レプリケーション
  • Premium
  • Business Critical
  • Hyperscale のレプリカ

2025-11-07 のドキュメントの更新のタイミングで SQL Database のサービスレベルについての記載は削除されており、現在はすべてのサービスレベルで使用できているように思えます。

私が使用している環境は Standard + Active Geo レプリケーションの環境なのですが、この環境でもセカンダリレプリカのクエリストアを使用することができています。

明示的に設定を変更していない状態で使用できていますので、SQL Database の場合は、何らかの設定変更を実施しなくても利用することができるようになっているようでした。

 

セカンダリのクエリストアへのアクセス

クエリを直接実行してセカンダリのクエリストアにアクセスする方法は従来から提供されていました。

SSMS の GUI を使用してセカンダリレプリカのクエリストアにアクセスする方法は SSMS 21 から実装された機能 となります。

image

現在 SSMS 22 がリリースされていますので、GUI を使用する場合は SSMS 22 を使用するのが良いかと。

SSMS 21 以降で SQL Database の読み取り可能なセカンダリレプリカに対して接続をすると、クエリストアの状態が「READ_CAPTURE」になっていることが確認できます。

image

sys.database_query_store_options に READ_CAPTURE の説明が記載されていますが、このステータスになっている場合は、セカンダリのクエリストアが有効な状態となっています。

以前までは「READ_ONLY」となっていたのですが、いまは「READ_CAPTURE」となっており、セカンダリのクエリストアが有効にあっていることが表示内容からも確認することができます。

セカンダリのクエリストアのアクセスですが、機能をサポートしている SSMS を使用すると「レプリカ」という項目が表示され、接続されているインスタンスで使用可能なレプリカがプルダウンで表示されます。

前述のとおり私が使用している環境は Active Geo Replication の環境となりますので、「Geo Secondary」が表示されています。(この項目に表示される可能性のある内容は sys.query_store_replicas から確認ができます)

image

このレプリカで指定されているレプリカ向けのクエリストアの情報が表示されるようになります。

セカンダリのクエリストアですが、最終的にはプライマリに情報が連携され永続化が行われるものとなりますので、各レプリカのクエリストアの情報はすべてレプリカが保持していることになります。

 

セカンダリのクエリストアが実装されたことによる従来からの改善点

セカンダリのクエリストアが無い場合に、レプリカで実行されたクエリを過去にさかのぼって確認するのが難しかったです。

  • 実行中のクエリ
  • キャッシュに保持されている最後の実行情報

これらの情報は従来から確認することはできたのですが、しかし、過去にさかのぼって情報を確認することができなかったため「クエリの実行効率が低下した場合に、以前はどのように実行されていたのかを比較して分析を行う」ということが困難でした。

セカンダリのクエリストアがじっそされたことで、次のような対応を行うことが可能となりました。

  1. セカンダリで実行されたクエリを過去にさかのぼって時系列で確認
  2. セカンダリで実行されているクエリのプランの強制

「1.」についてはプライマリと同等の手法で、セカンダリのクエリの分析を行うことができるものとなります。

「2.」は、セカンダリ レプリカの自動プラン修正を有効にする の機能の活用となります。

セカンダリで実行されているクエリについては、従来まではプランの強制を使用することができず、実行プランが期待したものでない場合、クエリヒントで明示的に補正をする必要がありました。

今回の機能改善で、セカンダリレプリカで実行されているクエリに対してのプラン強制ができるようになり、セカンダリで実行される査証系のクエリで複数の実行プランが生成された場合の補正の容易性が向上しています。

 

セカンダリのクエリストアの無効化

私の環境では、セカンダリのクエリストアは自動で有効化されていました。

セカンダリ レプリカのクエリ ストアを無効にする の方法を使用することで無効化することもできました。

無効化することで「READ_CAPTURE」から「READ_ONLY」に状態が変わります。

基本的にセカンダリのクエリストアは有効化した状態が望ましいと思いますが、前述のとおりこの機能を有効にすると「セカンダリで実行されたクエリが永続化される」挙動となるため、永続化のためのディスク領域が必要となります。

そのため、大量のアドホッククエリをセカンダリで実行している場合などは、「クエリストアのサイズの肥大化」につながる可能性があるのではないでしょうか。

このようなケースではセカンダリのクエリストアの無効化を検討する必要が出てくるかもしれません。

クエリストアのサイズは sys.database_query_store_options の「current_storage_size_mb」で確認ができますので、セカンダリレプリカで頻繁にクエリを実行している環境ではこの値の変化は意識しておくとよいかもしれません。

Share

Written by Masayuki.Ozawa

11月 16th, 2025 at 7:11 pm

Posted in SQL Database

Tagged with

Leave a Reply