クエリ ストアを使用する際のベスト プラクティスBest practices with Query Store

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics

この記事では、ワークロードで SQL Server クエリ ストアを使用するためのベスト プラクティスについて説明します。This article outlines the best practices for using SQL Server Query Store with your workload.

最新の SQL Server Management StudioSQL Server Management Studio を使用するUse the latest SQL Server Management StudioSQL Server Management Studio

SQL Server Management StudioSQL Server Management Studio には、クエリ ストアを構成し、ワークロードに関する収集データを使用するための一連のユーザー インターフェイスが用意されています。has a set of user interfaces designed for configuring Query Store and for consuming collected data about your workload. 最新バージョンの Management StudioManagement Studioここからダウンロードしてください。Download the latest version of Management StudioManagement Studio here.

トラブルシューティング シナリオでクエリ ストアを使用する方法の簡単な説明については、@Azure ブログのクエリ ストアに関する記事を参照してください。For a quick description on how to use Query Store in troubleshooting scenarios, see Query Store Azure blogs.

UseAzure SQL Database で Query Performance Insight を使用するUse Query Performance Insight in Azure SQL Database

Azure SQL データベースAzure SQL Database でクエリ ストアを実行する場合、Query Performance Insight を使用して、経時的にリソース消費量を分析できます。If you run Query Store in Azure SQL データベースAzure SQL Database, you can use Query Performance Insight to analyze resource consumption over time. Management StudioManagement StudioAzure Data Studio を使用して、CPU、メモリ、I/O など、すべてのクエリの詳細なリソース消費量を取得することができますが、Query Performance Insight を使用すると、データベースの DTU 全体の消費量に対する影響を簡単かつ効率的に確認できます。While you can use Management StudioManagement Studio and Azure Data Studio to get detailed resource consumption for all your queries, such as CPU, memory, and I/O, Query Performance Insight gives you a quick and efficient way to determine their impact on overall DTU consumption for your database. 詳細については、「 Azure SQL Database Query Performance Insight」を参照してください。For more information, see Azure SQL Database Query Performance Insight.

このセクションでは、クエリ ストアおよび依存機能を確実に操作できるように設計された最適な構成の既定値について説明します。This section describes optimal configuration defaults that are designed to ensure reliable operation of the Query Store and dependent features. 既定の構成は、データ収集が継続的に実施される (OFF/READ_ONLY 状態の時間が最小限になる) ように最適化されています。Default configuration is optimized for continuous data collection, that is minimal time spent in OFF/READ_ONLY states. 使用可能なすべてのクエリ ストア オプションの詳細については、「ALTER DATABASE の SET オプション (Transact-SQL)」を参照してください。For more information about all available Query Store options, see ALTER DATABASE SET options (Transact-SQL).

構成Configuration 説明Description DefaultDefault 解説Comment
MAX_STORAGE_SIZE_MBMAX_STORAGE_SIZE_MB クエリ ストアがユーザーのデータベース内で使用するデータ領域の制限を指定します。Specifies the limit for the data space that Query Store can take inside the customer database 100100 新しいデータベースに適用Enforced for new databases
INTERVAL_LENGTH_MINUTESINTERVAL_LENGTH_MINUTES クエリ プランで収集されたランタイム統計が集計されて保存される間隔を定義します。Defines size of time window during which collected runtime statistics for query plans are aggregated and persisted. すべてのアクティブなクエリ プランには、この構成で定義された期間の行が最大で 1 行含まれます。Every active query plan has at most one row for a period of time defined with this configuration 6060 新しいデータベースに適用Enforced for new databases
STALE_QUERY_THRESHOLD_DAYSSTALE_QUERY_THRESHOLD_DAYS 保存されたランタイム統計と非アクティブなクエリのリテンション期間を制御する、時間に基づくクリーンアップ ポリシーTime-based cleanup policy that controls the retention period of persisted runtime statistics and inactive queries 3030 新しいデータベースと前の既定値 (367) を持つデータベースに適用Enforced for new databases and databases with previous default (367)
SIZE_BASED_CLEANUP_MODESIZE_BASED_CLEANUP_MODE クエリ ストアのデータ サイズが制限値に近づいたときに、データの自動クリーンアップが発生するかどうかを指定しますSpecifies whether automatic data cleanup takes place when Query Store data size approaches the limit AUTOAUTO すべてのデータベースに適用Enforced for all databases
QUERY_CAPTURE_MODEQUERY_CAPTURE_MODE すべてのクエリを追跡するか、クエリのサブセットのみを追跡するかを指定しますSpecifies whether all queries or only a subset of queries are tracked AUTOAUTO すべてのデータベースに適用Enforced for all databases
FLUSH_INTERVAL_SECONDSFLUSH_INTERVAL_SECONDS キャプチャされたランタイム統計がディスクにフラッシュされる前に、メモリ内に保持される最大期間を指定しますSpecifies maximum period during which captured runtime statistics are kept in memory, before flushing to disk 900900 新しいデータベースに適用Enforced for new databases

重要

上記の既定値は、すべての Azure SQL データベースAzure SQL Databaseのアクティブ化の最終段階で自動的に適用されます。These defaults are automatically applied in the final stage of Query Store activation in all Azure SQL データベースAzure SQL Database. 有効にされた後、ユーザーによって設定される構成値は、主要なワークロードまたはクエリ ストアの信頼できる動作に悪影響を与えない限り、Azure SQL データベースAzure SQL Database によって変更されることはありません。After it's enabled, Azure SQL データベースAzure SQL Database won't change configuration values that are set by customers, unless they negatively impact primary workload or reliable operations of the Query Store.

注意

Azure SQL データベースAzure SQL Database 単一データベースとエラスティック プールでは、クエリ ストアを無効にすることはできません。Query Store cannot be disabled in Azure SQL データベースAzure SQL Database single database and Elastic Pool. ALTER DATABASE [database] SET QUERY_STORE = OFF を実行すると、警告 'QUERY_STORE=OFF' is not supported in this version of SQL Server. が返されます。Executing ALTER DATABASE [database] SET QUERY_STORE = OFF will return the warning 'QUERY_STORE=OFF' is not supported in this version of SQL Server..

カスタム設定を維持する場合は、 ALTER DATABASE とクエリ ストア オプション を使用して、構成を前の状態に戻します。If you want to stay with your custom settings, use ALTER DATABASE with Query Store options to revert configuration to the previous state. クエリ ストアを使用する際の推奨事項」で、最適構成のパラメーターを選ぶ方法確認してください。Check out Best Practices with the Query Store in order to learn how to choose optimal configuration parameters.

エラスティック プール データベースでクエリ ストアを使用するUse Query Store with Elastic Pool databases

クエリ ストアは、すべてのデータベースで (高密度でパックされたプールであっても) 問題なく使用できます。You can use Query Store in all databases without concerns, in even densely packed pools. エラスティック プール内の多数のデータベースに対してクエリ ストアを有効にすると発生する可能性があった、リソースの過剰使用に関連するすべての問題は解決されました。All issues related to excessive resource usage that might have occurred when Query Store was enabled for the large number of databases in the elastic pools have been resolved.

ワークロードに合わせてクエリ ストアを調整するKeep Query Store adjusted to your workload

ワークロードとパフォーマンスのトラブルシューティングの要件に基づいて、クエリ ストアを構成します。Configure Query Store based on your workload and performance troubleshooting requirements. 始めは既定のパラメーターで十分ですが、時間の経過と共にクエリ ストアがどのように動作するかを監視し、それに応じて構成を調整する必要があります。The default parameters are good enough to start, but you should monitor how Query Store behaves over time and adjust its configuration accordingly.

クエリ ストアのプロパティQuery Store properties

次に、パラメーター値を設定する際のガイドラインを示します。Here are guidelines to follow for setting parameter values:

最大サイズ (MB) :クエリ ストアで使用されるデータベース内のデータ領域の制限を指定します。Max Size (MB): Specifies the limit for the data space that Query Store takes inside your database. これは、クエリ ストアの操作モードに直接影響する最も重要な設定です。This is the most important setting that directly affects the operation mode of Query Store.

クエリ ストアでクエリ、実行プラン、および統計情報が収集されている間は、この制限に達するまでデータベース内のサイズが増え続けます。While Query Store collects queries, execution plans, and statistics, its size in the database grows until this limit is reached. サイズが制限に達すると、クエリ ストアの操作モードが自動的に読み取り専用に切り替わり、新しいデータの収集が停止します。以降、パフォーマンス分析は正確ではなくなります。When that happens, Query Store automatically changes the operation mode to read-only and stops collecting new data, which means that your performance analysis is no longer accurate.

SQL Server 2016 (13.x)SQL Server 2016 (13.x) および SQL Server 2017 (14.x)SQL Server 2017 (14.x) の既定値は 100 MB です。The default value in SQL Server 2016 (13.x)SQL Server 2016 (13.x) and SQL Server 2017 (14.x)SQL Server 2017 (14.x) is 100 MB. ワークロードで多数の異なるクエリとプランが生成される場合や、クエリ履歴を長期間保持する必要がある場合、このサイズでは十分でない可能性があります。This size might not be sufficient if your workload generates a large number of different queries and plans or if you want to keep query history for a longer period of time. SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降では、既定値は 1 GB です。Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), the default value is 1 GB. クエリ ストアが読み取り専用モードに移行しないように、現在の使用領域を追跡して [最大サイズ (MB)] の値を増やしてください。Keep track of current space usage and increase the Max Size (MB) value to prevent Query Store from transitioning to read-only mode.

重要

[最大サイズ (MB)] の制限は、厳密には適用されません。The Max Size (MB) limit isn't strictly enforced. ストレージ サイズは、クエリ ストアでディスクにデータが書き込まれる場合にのみ確認されます。Storage size is checked only when Query Store writes data to disk. この間隔は、 [データのフラッシュ間隔 (分)] オプションによって設定されます。This interval is set by the Data Flush Interval (Minutes) option. クエリ ストアでストレージ サイズの確認の合間に最大サイズの制限を超えた場合は、読み取り専用モードに移行します。If Query Store has breached the maximum size limit between storage size checks, it transitions to read-only mode. [サイズ ベースのクリーン アップモード] が有効になっている場合は、最大サイズの制限を適用するクリーンアップ メカニズムもトリガーされます。If Size Based Cleanup Mode is enabled, the cleanup mechanism to enforce the maximum size limit is also triggered.

クエリ ストアのサイズに関する最新の情報を取得するには、 Management StudioManagement Studio を使用するか、次のスクリプトを実行します。Use Management StudioManagement Studio or execute the following script to get the latest information about Query Store size:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
 max_storage_size_mb, readonly_reason
FROM sys.database_query_store_options;

次のスクリプトでは、 [最大サイズ (MB)] の新しい値を設定します。The following script sets a new value for Max Size (MB):

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (MAX_STORAGE_SIZE_MB = 1024);

データのフラッシュ間隔 (分) :収集された実行時統計情報をディスクに保存する間隔を定義します。Data Flush Interval (Minutes): It defines the frequency to persist collected runtime statistics to disk. グラフィカル ユーザー インターフェイス (GUI) では分単位で表されますが、Transact-SQLTransact-SQL では秒単位で表されます。It's expressed in minutes in the graphical user interface (GUI), but in Transact-SQLTransact-SQL it's expressed in seconds. 既定値は 900 秒です。これは、グラフィカル ユーザー インターフェイスでは 15 分です。The default is 900 seconds, which is 15 minutes in the graphical user interface. ワークロードで生成される異なるクエリとプランの数が多くない場合、またはデータベースをシャットダウンする前にデータを長時間保持できる場合は、大きい値を使用することを検討してください。Consider using a higher value if your workload doesn't generate a large number of different queries and plans, or if you can withstand longer time to persist data before a database shutdown.

注意

トレース フラグ 7745 を使用すると、フェールオーバーまたはシャットダウン コマンドが発生した場合に、クエリ ストアのデータはディスクに書き込まれません。Using trace flag 7745 prevents Query Store data from being written to disk in case of a failover or shutdown command. 詳細については、「ミッション クリティカルなサーバーでトレース フラグを使用する」セクションを参照してください。For more information, see the Use trace flags on mission-critical servers section.

[データ フラッシュ間隔] に別の値を設定するには、SQL Server Management StudioSQL Server Management Studio または Transact-SQLTransact-SQL を使用します。Use SQL Server Management StudioSQL Server Management Studio or Transact-SQLTransact-SQL to set a different value for Data Flush Interval:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (DATA_FLUSH_INTERVAL_SECONDS = 900);

統計情報の収集間隔:収集された実行時統計情報に対する粒度のレベルを定義します (分単位)。Statistics Collection Interval: Defines the level of granularity for the collected runtime statistic, expressed in minutes. 既定値は 60 分です。The default is 60 minutes. より細かい粒度が必要な場合、または問題を検出して軽減するための時間を短くする場合は、小さい値を使用することを検討してください。Consider using a lower value if you require finer granularity or less time to detect and mitigate issues. 値はクエリ ストア データのサイズに直接影響することに注意してください。Keep in mind that the value directly affects the size of Query Store data. [統計情報の収集間隔] に別の値を設定するには、SQL Server Management StudioSQL Server Management Studio または Transact-SQLTransact-SQL を使用します。Use SQL Server Management StudioSQL Server Management Studio or Transact-SQLTransact-SQL to set a different value for Statistics Collection Interval:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (INTERVAL_LENGTH_MINUTES = 60);

古いクエリのしきい値 (日) :保存する実行時統計と非アクティブ クエリの保有期間を制御する、時間ベースのクリーンアップ ポリシーです (日単位)。Stale Query Threshold (Days): Time-based cleanup policy that controls the retention period of persisted runtime statistics and inactive queries, expressed in days. 既定では、クエリ ストアはデータを 30 日間保持するよう構成されていますが、シナリオによっては必要以上に長い場合があります。By default, Query Store is configured to keep the data for 30 days, which might be unnecessarily long for your scenario.

使用予定のない履歴データは保持しないようにしてください。Avoid keeping historical data that you don't plan to use. これにより、読み取り専用状態への移行を減らすことができます。This practice reduces changes to read-only status. クエリ ストアのデータのサイズと、問題を検出して軽減するまでの時間を予測しやすくなります。The size of Query Store data and the time to detect and mitigate the issue will be more predictable. 時間ベースのクリーンアップ ポリシーを構成するには、 Management StudioManagement Studio または次のスクリプトを使用します。Use Management StudioManagement Studio or the following script to configure time-based cleanup policy:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 90));

サイズ ベースのクリーンアップ モード:クエリ ストアのデータ サイズが制限に達したときに、データの自動クリーンアップを行うかどうかを指定します。Size Based Cleanup Mode: Specifies whether automatic data cleanup takes place when Query Store data size approaches the limit. クエリ ストアが常に読み取り/書き込みモードで実行され、最新データが収集されるようにするには、サイズ ベースのクリーンアップを有効にします。Activate size-based cleanup to make sure that Query Store always runs in read-write mode and collects the latest data.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (SIZE_BASED_CLEANUP_MODE = AUTO);

クエリ ストアのキャプチャ モード:クエリ ストアのクエリ キャプチャ ポリシーを指定します。Query Store Capture Mode: Specifies the query capture policy for Query Store.

  • [すべて] : すべてのクエリをキャプチャします。All: Captures all queries. これは SQL Server 2016 (13.x)SQL Server 2016 (13.x) および SQL Server 2017 (14.x)SQL Server 2017 (14.x) の既定のオプションです。This option is the default in SQL Server 2016 (13.x)SQL Server 2016 (13.x) and SQL Server 2017 (14.x)SQL Server 2017 (14.x).
  • Auto:頻度の低いクエリと、コンパイルと実行時間の短いクエリは無視されます。Auto: Infrequent queries and queries with insignificant compile and execution duration are ignored. 実行回数、コンパイル、実行時間のしきい値は内部的に決定されます。Thresholds for execution count, compile, and runtime duration are internally determined. SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降では、これは既定のオプションです。Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this is the default option.
  • None:クエリ ストアで新しいクエリのキャプチャが停止されます。None: Query Store stops capturing new queries.
  • Custom:追加の制御と機能を使用して、データ収集ポリシーを微調整できます。Custom: Allows additional control and the capability to fine-tune the data collection policy. 新しいカスタム設定では、内部キャプチャ ポリシーの時間のしきい値内で何が行われるかが定義されます。The new custom settings define what happens during the internal capture policy time threshold. これは、構成可能な条件が評価される時刻の境界であり、いずれかが true の場合、クエリがクエリ ストアによるキャプチャの対象となります。This is a time boundary during which the configurable conditions are evaluated and, if any are true, the query is eligible to be captured by Query Store.

重要

クエリ ストア キャプチャ モードが AllAuto、または Custom に設定されている場合、カーソル、ストアド プロシージャ内のクエリ、ネイティブ コンパイル済みのクエリは常にキャプチャされます。Cursors, queries inside stored procedures, and natively compiled queries are always captured when Query Store Capture Mode is set to All, Auto, or Custom. ネイティブ コンパイル済みのクエリをキャプチャするには、sys.sp_xtp_control_query_exec_stats を使用して、クエリごとの統計情報の収集を有効にします。To capture natively compiled queries, enable collection of per-query statistics by using sys.sp_xtp_control_query_exec_stats.

次のスクリプトでは、QUERY_CAPTURE_MODE を AUTO に設定します。The following script sets QUERY_CAPTURE_MODE to AUTO:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (QUERY_CAPTURE_MODE = AUTO);

Examples

次の例では、QUERY_CAPTURE_MODE を AUTO に設定し、SQL Server 2016 (13.x)SQL Server 2016 (13.x) のその他の推奨オプションを設定します。The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2016 (13.x)SQL Server 2016 (13.x):

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      QUERY_CAPTURE_MODE = AUTO,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60
    );

次の例では、QUERY_CAPTURE_MODE を AUTO に設定し、待機統計を含めるように SQL Server 2017 (14.x)SQL Server 2017 (14.x) のその他の推奨オプションを設定します。The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2017 (14.x)SQL Server 2017 (14.x) to include wait statistics:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      QUERY_CAPTURE_MODE = AUTO,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60,
      SIZE_BASED_CLEANUP_MODE = AUTO,
      MAX_PLANS_PER_QUERY = 200,
      WAIT_STATS_CAPTURE_MODE = ON
    );

次の例では、QUERY_CAPTURE_MODE を AUTO に設定し、SQL Server 2019 (15.x)SQL Server 2019 (15.x) のその他の推奨オプションを設定します。また、必要に応じて、新しい既定の AUTO キャプチャ モードではなく、既定の設定で CUSTOM キャプチャ ポリシーを設定します。The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2019 (15.x)SQL Server 2019 (15.x), and optionally sets the CUSTOM capture policy with its defaults, instead of the new default AUTO capture mode:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60,
      SIZE_BASED_CLEANUP_MODE = AUTO,
      MAX_PLANS_PER_QUERY = 200,
      WAIT_STATS_CAPTURE_MODE = ON,
      QUERY_CAPTURE_MODE = CUSTOM,
      QUERY_CAPTURE_POLICY = (
        STALE_CAPTURE_POLICY_THRESHOLD = 24 HOURS,
        EXECUTION_COUNT = 30,
        TOTAL_COMPILE_CPU_TIME_MS = 1000,
        TOTAL_EXECUTION_CPU_TIME_MS = 100
      )
    );

クエリ パフォーマンスのトラブルシューティングを開始するStart with query performance troubleshooting

次の図に示すように、クエリ ストアでのトラブルシューティングのワークフローはシンプルです。The troubleshooting workflow with Query Store is simple, as shown in the following diagram:

クエリ ストアのトラブルシューティングQuery Store troubleshooting

前のセクションで説明したように、Management StudioManagement Studio を使用してクエリ ストアを有効にするか、次の Transact-SQLTransact-SQL ステートメントを実行します。Enable Query Store by using Management StudioManagement Studio, as described in the previous section, or execute the following Transact-SQLTransact-SQL statement:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

クエリ ストアで、ワークロードを正確に表すデータ セットが収集されるまで、しばらく時間がかかります。It takes some time until Query Store collects the data set that accurately represents your workload. 通常は、非常に複雑なワークロードの場合でも 1 日で十分です。Usually, one day is enough even for very complex workloads. ただし、機能を有効にした後すぐにデータの探索を開始して、注意が必要なクエリを特定することができます。However, you can start exploring the data and identify queries that need your attention immediately after you enable the feature. Management StudioManagement Studio のオブジェクト エクスプローラーでデータベース ノードの下にある Query Store サブフォルダーに移動し、特定のシナリオのトラブルシューティング ビューを開きます。Go to the Query Store subfolder under the database node in Object Explorer of Management StudioManagement Studio to open troubleshooting views for specific scenarios.

Management StudioManagement Studio のクエリ ストア ビューの操作には、一連の実行メトリックを使用します。メトリックはそれぞれ、次のいずれかの統計関数で表されます。Query Store views operate with the set of execution metrics, each expressed as any of the following statistic functions:

SQL ServerSQL Server のバージョンversion 実行メトリックExecution metric 統計関数Statistic function
SQL Server 2016 (13.x)SQL Server 2016 (13.x) CPU 時間、実行時間、実行回数、論理読み取り、論理書き込み、メモリ消費量、物理読み取り、CLR 時間、並列処理の次数 (DOP)、行数CPU time, Duration, Execution count, Logical reads, Logical writes, Memory consumption, Physical reads, CLR time, Degree of parallelism (DOP), and Row count Average、Maximum、Minimum、Standard Deviation、TotalAverage, Maximum, Minimum, Standard Deviation, Total
SQL Server 2017 (14.x)SQL Server 2017 (14.x) CPU 時間、実行時間、実行回数、論理読み取り、論理書き込み、メモリ消費量、物理読み取り、CLR 時間、並列処理の次数、行数、ログ メモリ、TempDB メモリ、待機時間CPU time, Duration, Execution count, Logical reads, Logical writes, Memory consumption, Physical reads, CLR time, Degree of parallelism, Row count, Log memory, TempDB memory, and Wait times Average、Maximum、Minimum、Standard Deviation、TotalAverage, Maximum, Minimum, Standard Deviation, Total

次の図は、クエリ ストアのビューの場所を示しています。The following graphic shows how to locate Query Store views:

クエリ ストア ビューQuery Store views

次の表では、各クエリ ストア ビューの用途を説明します。The following table explains when to use each of the Query Store views:

SQL Server Management Studio ビューSQL Server Management Studio view シナリオScenario
機能低下したクエリRegressed Queries 実行メトリックが最近低下した (たとえば、悪化した) クエリを特定します。Pinpoint queries for which execution metrics have recently regressed (for example, changed to worse).
このビューを使用して、アプリケーションで確認されたパフォーマンスの問題と、修正や改善の必要がある実際のクエリを関連付けます。Use this view to correlate observed performance problems in your application with the actual queries that need to be fixed or improved.
全体的なリソース消費量Overall Resource Consumption 実行メトリックのいずれかについて、データベースの全体的なリソース消費量を分析します。Analyze the total resource consumption for the database for any of the execution metrics.
このビューを使用して、リソースのパターン (日中または夜間のワークロード) を特定し、データベースの全体的な消費量を最適化します。Use this view to identify resource patterns (daily vs. nightly workloads) and optimize overall consumption for your database.
最もリソースを消費するクエリTop Resource Consuming Queries 対象となる実行メトリックを選択し、指定された期間で最も極端な値を持つクエリを特定します。Choose an execution metric of interest, and identify queries that had the most extreme values for a provided time interval.
このビューを使用して、データベースのリソース消費量に最も大きな影響を与えている最も関連性の高いクエリに焦点を絞ります。Use this view to focus your attention on the most relevant queries that have the biggest impact to database resource consumption.
強制適用されたプランのあるクエリQueries With Forced Plans クエリ ストアを使って以前に強制適用されたプランを一覧表示します。Lists previously forced plans using Query Store.
このビューを使って、現在強制適用されているすべてのプランに簡単にアクセスします。Use this view to quickly access all currently forced plans.
高バリエーションのクエリQueries With High Variation 目的の期間の、実行時間、CPU 時間、IO、メモリ使用量など、使用可能なディメンションのいずれかに関連して実行バリエーションが高いクエリを分析します。Analyze queries with high-execution variation as it relates to any of the available dimensions, such as Duration, CPU time, IO, and Memory usage, in the desired time interval.
このビューを使用して、アプリケーション全体のユーザー エクスペリエンスに影響する可能性のある、パフォーマンスの差異が大きいクエリを特定します。Use this view to identify queries with widely variant performance that can be affecting user experience across your applications.
クエリ待機統計Query Wait Statistics データベースで最もアクティブな待機カテゴリ、および選択された待機カテゴリに対して最も影響を与えるクエリを分析します。Analyze wait categories that are most active in a database and which queries contribute most to the selected wait category.
このビューを使用して、待機統計を分析し、アプリケーション全体のユーザー エクスペリエンスに影響する可能性のあるクエリを特定します。Use this view to analyze wait statistics and identify queries that might be affecting user experience across your applications.

適用対象:SQL Server Management StudioSQL Server Management Studio v18.0 以降および SQL Server 2017 (14.x)SQL Server 2017 (14.x)Applies to: Starting with SQL Server Management StudioSQL Server Management Studio v18.0 and SQL Server 2017 (14.x)SQL Server 2017 (14.x).
追跡対象のクエリTracked Queries 最も重要なクエリの実行をリアルタイムで追跡します。Track the execution of the most important queries in real time. このビューは通常、強制適用されたプランを持つクエリがあり、クエリのパフォーマンスを安定させる必要がある場合に使用します。Typically, you use this view when you have queries with forced plans and you want to make sure that query performance is stable.

ヒント

Management StudioManagement Studio を使用して最もリソースを消費するクエリを特定し、プラン変更により機能低下したクエリを修正する方法の詳細については、Azure ブログのクエリ ストアに関する記事を参照してください。@AzureFor a detailed description of how to use Management StudioManagement Studio to identify the top resource-consuming queries and fix those that regressed due to the change of a plan choice, see Query Store Azure Blogs.

パフォーマンスが最適ではないクエリを特定する際のアクションは、問題の性質によって異なります。When you identify a query with suboptimal performance, your action depends on the nature of the problem.

  • クエリの実行プランが複数あり、最後のプランのパフォーマンスが前のプランよりも大幅に悪いような場合は、プランの強制適用メカニズムを使用することができます。If the query was executed with multiple plans and the last plan is significantly worse than the previous plan, you can use the plan forcing mechanism to force it. SQL ServerSQL Server がオプティマイザーのプランを強制しようとします。tries to force the plan in the optimizer. プランの適用に失敗した場合、XEvent が発生し、オプティマイザーは通常の方法で最適化するように指示します。If plan forcing fails, an XEvent is fired and the optimizer is instructed to optimize in the normal way.

    クエリ ストアの適用プランQuery Store force plan

    注意

    前の図では特定のクエリ プランに異なる図形が使われている場合があり、考えられる各状態の意味を次に示します。The previous graphic might feature different shapes for specific query plans, with the following meanings for each possible status:

    図形Shape 意味Meaning
    CircleCircle クエリ完了。これは、通常の実行が正常に終了したことを意味します。Query completed, which means that a regular execution successfully finished.
    SquareSquare キャンセル。これは、クライアントが開始した実行中止を意味します。Cancelled, which means that a client-initiated aborted execution.
    TriangleTriangle 失敗。これは、例外で実行が中止されたことを意味します。Failed, which means that an exception aborted execution.

    また、図形のサイズには、指定された期間内でのクエリ実行回数が反映されます。Also, the size of the shape reflects the query execution count within the specified time interval. 実行回数が多いと、サイズが大きくなります。The size increases with a higher number of executions.

  • クエリに最適な実行のためのインデックスが欠落している場合があります。You might conclude that your query is missing an index for optimal execution. この情報は、クエリの実行プラン内で確認できます。This information is surfaced within the query execution plan. 欠落しているインデックスを作成し、クエリ ストアを使用してクエリのパフォーマンスを確認します。Create the missing index, and check the query performance by usingQuery Store.

    クエリ ストアの表示プランQuery Store show plan

SQL DatabaseSQL Databaseでワークロードを実行している場合、 SQL DatabaseSQL Database Index Advisor にサインアップすると、推奨されるインデックスを自動的に取得できます。If you run your workload on SQL DatabaseSQL Database, sign up for SQL DatabaseSQL Database Index Advisor to automatically receive index recommendations.

  • 実行プランの推定行数と実際の行数に大きな差がある場合は、統計情報を強制的に再コンパイルすることもできます。In some cases, you might enforce statistic recompilation if you see that the difference between the estimated and the actual number of rows in the execution plan is significant.
  • たとえば、クエリのパラメーター化を利用したり、より最適なロジックを実装したりする場合は、問題のあるクエリを書き直します。Rewrite problematic queries, for example, to take advantage of query parameterization or to implement more optimal logic.

クエリ ストアでクエリ データが収集されていることを継続的に確認するVerify that Query Store collects query data continuously

クエリ ストアでは、操作モードが通知なしに変更されることがあります。Query Store can silently change the operation mode. クエリ ストアの状態を定期的に監視して、クエリ ストアが動作していることを確認し、回避できたはずのエラーが発生しないようにしてください。Regularly monitor the state of Query Store to ensure that Query Store is operating, and to take action to avoid failures due to preventable causes. 操作モードを確認して最も重要なパラメーターを表示するには、次のクエリを実行します。Execute the following query to determine the operation mode and view the most relevant parameters:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

actual_state_descdesired_state_desc の違いは、操作モードが自動的に変更されたことを示します。The difference between the actual_state_desc and desired_state_desc indicates that a change of the operation mode occurred automatically. 最も一般的な変更は、クエリ ストアが通知なしに読み取り専用モードに切り替わることです。The most common change is for Query Store to silently switch to read-only mode. 非常にまれな状況では、クエリ ストアが内部エラーにより、エラー状態になることがあります。In extremely rare circumstances, Query Store can end up in the ERROR state because of internal errors.

実際の状態が読み取り専用になっている場合は、 readonly_reason 列で根本原因を調べます。When the actual state is read-only, use the readonly_reason column to determine the root cause. 通常は、サイズ クォータを超えたために、クエリ ストアが読み取り専用モードに移行したことがわかります。Typically, you find that Query Store transitioned to read-only mode because the size quota was exceeded. その場合、readonly_reason は 65536 に設定されています。In that case, the readonly_reason is set to 65536. 他の理由については、「sys.database_query_store_options (Transact-SQL)」を参照してください。For other reasons, see sys.database_query_store_options (Transact-SQL).

クエリ ストアを読み取り/書き込みモードに戻してデータの収集を再開するには、次の手順を実行します。Consider the following steps to switch Query Store to read-write mode and activate data collection:

  • ALTER DATABASEMAX_STORAGE_SIZE_MBオプションを使用して、ストレージの最大サイズを増やします。Increase the maximum storage size by using the MAX_STORAGE_SIZE_MB option of ALTER DATABASE.

  • 次のステートメントを使用して、クエリ ストアのデータをクリーンアップする。Clean up Query Store data by using the following statement:

    ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
    

操作モードを明示的に読み取り/書き込みモードに戻す次のステートメントを実行することで、これらの手順のいずれかまたは両方を適用できます。You can apply one or both of these steps by executing the following statement that explicitly changes the operation mode back to read-write:

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

操作モードが変更されないよう事前に対処するには、次の手順を実行します。Take the following steps to be proactive:

  • 推奨事項を取り入れることで、操作モードが通知なしに変更されることを防ぐことができます。You can prevent silent changes of operation mode by applying best practices. クエリ ストアのサイズが許可される最大値を常に下回り、読み取り専用モードに移行される可能性が大幅に低くなるようにしてください。Ensure that Query Store size is always below the maximally allowed value to dramatically reduce a chance of transitioning to read-only mode. クエリ ストアの構成に関するセクションの説明に従って、サイズ ベースのポリシーを有効にし、クエリ ストアでサイズが制限に近づくと自動的にデータがクリーンアップされるようにします。Activate size-based policy as described in the Configure Query Store section so that Query Store automatically cleans data when the size approaches the limit.
  • 最新のデータを確実に保持するには、古くなった情報を定期的に削除するように時間ベースのポリシーを構成します。To make sure that most recent data is retained, configure time-based policy to remove stale information regularly.
  • 最後に、クエリ ストア キャプチャ モードAuto に設定することを検討してください。そうすることで、通常はワークロードにとってあまり関連性のないクエリが除外されるためです。Finally, consider setting Query Store Capture Mode to Auto because it filters out queries that are usually less relevant for your workload.

エラー状態ERROR state

クエリ ストアを復旧させるには、明示的に読み取り/書き込みモードに設定してみて、実際の状態を再度確認します。To recover Query Store, try explicitly setting the read-write mode and check the actual state again.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

それでも問題が解決しない場合は、ディスクに破損したクエリ ストア データが保存されていることを示しています。If the problem persists, it indicates that corruption of Query Store data is persisted on the disk.

SQL Server 2017 (14.x)SQL Server 2017 (14.x) 以降では、影響を受けたデータベース内で sp_query_store_consistency_check ストアド プロシージャを実行することで、クエリ ストアを復旧させることができます。Starting with SQL Server 2017 (14.x)SQL Server 2017 (14.x), Query Store can be recovered by executing the sp_query_store_consistency_check stored procedure within the affected database. 復旧操作を試みる前にクエリ ストアを無効にする必要があります。Query Store must be disabled before you attempt the recovery operation. SQL Server 2016 (13.x)SQL Server 2016 (13.x) の場合は、示されているようにクエリ ストアからデータをクリアする必要があります。For SQL Server 2016 (13.x)SQL Server 2016 (13.x), you need to clear the data from Query Store as shown.

復旧に失敗した場合は、読み取り/書き込みモードを設定する前にクエリ ストアをクリアしてみてください。If the recovery was unsuccessful, you can try clearing Query Store before you set the read-write mode.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

最適なクエリ ストア キャプチャ モードを設定するSet the optimal Query Store Capture Mode

最も重要なデータをクエリ ストアに保存します。Keep the most relevant data in Query Store. 次の表では、各クエリ ストア キャプチャ モードの一般的なシナリオについて説明します。The following table describes typical scenarios for each Query Store Capture Mode:

Query Store Capture Mode (クエリ ストアのキャプチャ モード)Query Store Capture Mode シナリオScenario
すべてAll すべてのクエリの図形とその実行頻度やその他の統計情報の観点から、ワークロードを詳しく分析します。Analyze your workload thoroughly in terms of all queries' shapes and their execution frequencies and other statistics.

ワークロード中の新しいクエリを特定します。Identify new queries in your workload.

アドホック クエリを使用してユーザーまたは自動化によるパラメーター化が特定されているかどうかを検出します。Detect if ad-hoc queries are used to identify opportunities for user or auto parameterization.

注:これは、SQL Server 2016 (13.x)SQL Server 2016 (13.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x) の既定のキャプチャ モードです。Note: This is the default capture mode in SQL Server 2016 (13.x)SQL Server 2016 (13.x) and SQL Server 2017 (14.x)SQL Server 2017 (14.x).
AutoAuto 関連するクエリと実用的なクエリに焦点を絞ります。Focus your attention on relevant and actionable queries. たとえば、定期的に実行されるクエリや、大量のリソースを消費するクエリなどがあります。An example is those queries that execute regularly or that have significant resource consumption.

注:SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降では、これが既定のキャプチャ モードです。Note: Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this is the default capture mode.
なしNone 実行時に監視する必要があるクエリ セットを既にキャプチャしており、他のクエリによって生じる可能性のある、集中を妨げるものを取り除きたいと考えています。You've already captured the query set that you want to monitor in runtime and you want to eliminate the distractions that other queries might introduce.

None は、テストおよびベンチマーク環境に適しています。None is suitable for testing and benchmarking environments.

このモードは、アプリケーションのワークロードを監視するよう構成したクエリ ストアの構成を販売するソフトウェア ベンダーにも適しています。None is also appropriate for software vendors who ship Query Store configuration configured to monitor their application workload.

重要な新しいクエリを追跡して最適化する機会を見逃す可能性があるため、None を使用する際は注意してください。None should be used with caution because you might miss the opportunity to track and optimize important new queries. シナリオで必要な特別な場合を除き、このモードは使用しないでください。Avoid using None unless you have a specific scenario that requires it.
CustomCustom SQL Server 2019 (15.x)SQL Server 2019 (15.x) では、ALTER DATABASE SET QUERY_STORE コマンドの下に Custom キャプチャ モードが導入されています。introduces a Custom capture mode under the ALTER DATABASE SET QUERY_STORE command. 有効にすると、新しいクエリ ストア キャプチャ ポリシーの設定で追加のクエリ ストア構成を使用して、特定のサーバーでのデータ収集を微調整することができます。When enabled, additional Query Store configurations are available under a new Query Store capture policy setting to fine-tune data collection in a specific server.

新しいカスタム設定では、内部キャプチャ ポリシーの時間のしきい値内で何が行われるかが定義されます。The new custom settings define what happens during the internal capture policy time threshold. これは、構成可能な条件が評価される時刻の境界であり、いずれかが true の場合、クエリがクエリ ストアによるキャプチャの対象となります。This is a time boundary during which the configurable conditions are evaluated and, if any are true, the query is eligible to be captured by Query Store. 詳細については、「ALTER DATABASE の SET オプション (Transact-SQL)」を参照してください。For more information, see ALTER DATABASE SET Options (Transact-SQL).

注意

クエリ ストア キャプチャ モードが AllAuto、または Custom に設定されている場合、カーソル、ストアド プロシージャ内のクエリ、ネイティブ コンパイル済みのクエリは常にキャプチャされます。Cursors, queries inside stored procedures, and natively compiled queries are always captured when Query Store Capture Mode is set to All, Auto, or Custom. ネイティブ コンパイル済みのクエリをキャプチャするには、sys.sp_xtp_control_query_exec_stats を使用して、クエリごとの統計情報の収集を有効にします。To capture natively compiled queries, enable collection of per-query statistics by using sys.sp_xtp_control_query_exec_stats.

最も重要なデータをクエリ ストアに保存するKeep the most relevant data in Query Store

関連データのみを含むようにクエリ ストアを構成して、継続的に実行されるようにし、通常のワークロードへの影響を最小限に抑えながら、優れたトラブルシューティング エクスペリエンスを提供します。Configure Query Store to contain only the relevant data so that it runs continuously and provides a great troubleshooting experience with a minimal impact on your regular workload. 次の表に、推奨事項を示します。The following table provides best practices:

ベスト プラクティスBest practice 設定Setting
保存する履歴データに制限を設ける。Limit retained historical data. 自動クリーンアップを有効にするように時間ベースのポリシーを構成します。Configure time-based policy to activate autocleanup.
関連しないクエリを除外する。Filter out nonrelevant queries. [クエリ ストア キャプチャ モード]Auto に設定します。Configure Query Store Capture Mode to Auto.
最大サイズに達したときに、関連性の低いクエリを削除する。Delete less relevant queries when the maximum size is reached. サイズ ベースのクリーンアップ ポリシーを有効にします。Activate size-based cleanup policy.

パラメーター化されていないクエリを使用しないAvoid using non-parameterized queries

パラメーター化されていないクエリを必要でないときに使用することは、ベスト プラクティスではありません。Using non-parameterized queries when that isn't necessary isn't a best practice. たとえば、アドホック分析の場合です。An example is in the case of ad-hoc analysis. キャッシュされたプランは再利用できません。再利用すると、クエリ オプティマイザーによって一意のクエリ テキストごとにクエリが強制的にコンパイルされます。Cached plans can't be reused, which forces Query Optimizer to compile queries for every unique query text. 詳細については、「Guidelines for using forced parameterization」 (強制パラメーター化使用のガイドライン) をご覧ください。For more information, see Guidelines for using forced parameterization.

また、さまざまなクエリ テキストが多数ある可能性があり、その結果として、同じような形のさまざまな実行プランが多数存在することになるため、クエリ ストアでサイズ クォータがすぐに制限を超える可能性があります。Also, Query Store can rapidly exceed the size quota because of a potentially large number of different query texts and consequently a large number of different execution plans with similar shape. その結果、ワークロードのパフォーマンスが最適でなくなり、クエリ ストアが読み取り専用モードに切り替わったり、後続のクエリへの対応を試みるためにデータが常に削除されるようになる可能性があります。As a result, performance of your workload is suboptimal, and Query Store might switch to read-only mode or constantly delete data to try to keep up with the incoming queries.

次のオプションを検討してください。Consider the following options:

  • 必要に応じて、クエリをパラメーター化します。Parameterize queries where applicable. たとえば、ストアド プロシージャまたは sp_executesql 内にクエリをラップします。For example, wrap queries inside a stored procedure or sp_executesql. 詳細については、「パラメーターと実行プランの再利用」をご覧ください。For more information, see Parameters and execution plan reuse.
  • ワークロードに 1 回限りのアドホック バッチが多数含まれており、そこで異なるクエリ プランが使用されている場合は、アドホック ワークロードの最適化オプションを使用します。Use the optimize for ad hoc workloads option if your workload contains many single-use ad-hoc batches with different query plans.
    • 個々の query_hash 値の数と、sys.query_store_query 内のエントリの総数を比較します。Compare the number of distinct query_hash values with the total number of entries in sys.query_store_query. この比率が 1 に近い場合、アドホック ワークロードで異なるクエリが生成されます。If the ratio is close to 1, your ad-hoc workload generates different queries.
  • 異なるクエリ プランの数が多くない場合は、データベースまたはクエリのサブセットに対して強制パラメーター化を適用します。Apply forced parameterization for the database or for a subset of queries if the number of different query plans isn't large.
    • 選択したクエリに対してのみパラメータ化を強制するには、プラン ガイドを使用します。Use a plan guide to force parameterization only for the selected query.
    • ワークロード内の異なるクエリ プランの数が少ない場合は、パラメーター化データベース オプション コマンドを使用して、強制パラメーター化を構成します。Configure forced parameterization by using the parameterization database option command, if there are a small number of different query plans in your workload. たとえば、個々の query_hash の数と sys.query_store_query 内のエントリの総数の比率が 1 よりもかなり小さい場合です。An example is when the ratio between the count of distinct query_hash and the total number of entries in sys.query_store_query is much less than 1.
  • リソース消費の少ないアドホック クエリを自動的に除外するには、QUERY_CAPTURE_MODE を AUTO に設定します。Set QUERY_CAPTURE_MODE to AUTO to automatically filter out ad-hoc queries with small resource consumption.

オブジェクトを格納するために DROP と CREATE のパターンを使用しないAvoid a DROP and CREATE pattern for containing objects

クエリ ストアでは、クエリ エントリと親オブジェクト (ストアド プロシージャ、関数、トリガー) を関連付けます。Query Store associates query entry with a containing object, such as stored procedure, function, and trigger. 親オブジェクトを再作成すると、同じクエリ テキストに対して新しいクエリ エントリが生成されます。When you re-create a containing object, a new query entry is generated for the same query text. これにより、そのクエリのパフォーマンス統計情報を経時的に追跡し、プランの強制適用メカニズムを使用できなくなります。This prevents you from tracking performance statistics for that query over time and using a plan forcing mechanism. この状況を回避するには、可能な限り、ALTER <object> プロセスを使用して親オブジェクトの定義を変更します。To avoid this situation, use the ALTER <object> process to change a containing object definition whenever it's possible.

強制適用されたプランの状態を定期的に確認するCheck the status of forced plans regularly

プランの強制適用は、重要なクエリのパフォーマンスを修正してより正確な予測を可能にするための便利なメカニズムです。Plan forcing is a convenient mechanism to fix performance for the critical queries and make them more predictable. プラン ヒントやプラン ガイドと同様に、プランの強制適用は、今後の実行で使用されることを保証するものではありません。As with plan hints and plan guides, forcing a plan isn't a guarantee that it will be used in future executions. 通常、実行プランによって参照されるオブジェクトが変更または削除されるような方法でデータベース スキーマが変更された場合、プランを強制的に適用できません。Typically, when database schema changes in a way that objects referenced by the execution plan are altered or dropped, plan forcing starts failing. その場合、SQL ServerSQL Server はクエリの再コンパイルに戻りますが、強制適用が失敗した実際の理由は sys.query_store_plan に示されます。In that case, SQL ServerSQL Server falls back to query recompilation while the actual forcing failure reason is surfaced in sys.query_store_plan. 次のクエリは、強制適用されたプランに関する情報を返します。The following query returns information about forced plans:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

理由の一覧については、「sys.query_store_plan」を参照してください。For a full list of reasons, see sys.query_store_plan. query_store_plan_forcing_failed XEvent を使用して、プラン強制の失敗を追跡してトラブルシューティングすることもできます。You can also use the query_store_plan_forcing_failed XEvent to track and troubleshoot plan forcing failures.

プランが強制適用されたクエリの場合はデータベースの名前を変更しないAvoid renaming databases for queries with forced plans

実行プランでは、database.schema.object のような 3 つの部分で構成される名前を使用して、オブジェクトを参照します。Execution plans reference objects by using three-part names like database.schema.object.

データベース名を変更すると、プランの強制適用が失敗し、その後のすべてのクエリ実行で再コンパイルが発生します。If you rename a database, plan forcing fails, which causes recompilation in all subsequent query executions.

ミッション クリティカルなサーバーでのクエリ ストアの使用Using Query Store in mission-critical servers

グローバル トレース フラグ 7745 と 7752 を使用すると、クエリ ストアを使ってデータベースの可用性を向上させることができます。The global trace flags 7745 and 7752 can be used to improve availability of databases by using Query Store. 詳しくは、「トレース フラグ」をご覧ください。For more information, see Trace flags.

  • トレース フラグ 7745 では、SQL ServerSQL Server がシャットダウンされる前に、クエリ ストアによってディスクにデータを書き込む既定の動作が行われないようにします。Trace flag 7745 prevents the default behavior where Query Store writes data to disk before SQL ServerSQL Server can be shut down. つまり、DATA_FLUSH_INTERVAL_SECONDS で定義された時間枠まで、収集されたもののディスクにはまだ保存されていないクエリ ストア データは失われます。This means that Query Store data that has been collected but not yet persisted to disk will be lost, up to the time window defined with DATA_FLUSH_INTERVAL_SECONDS.
  • トレース フラグ 7752 では、クエリ ストアの非同期読み込みが有効になります。Trace flag 7752 enables asynchronous load of Query Store. これにより、データベースをオンラインにすることができ、クエリ ストアが完全に復旧される前にクエリを実行できます。This allows a database to become online and queries to be executed before Query Store has been fully recovered. 既定の動作では、クエリ ストアの同期読み込みが行われます。The default behavior is to do a synchronous load of Query Store. 既定の動作では、クエリ ストアが復旧される前にクエリを実行することはできませんが、データ コレクションでクエリが失われることもありません。The default behavior prevents queries from executing before Query Store has been recovered but also prevents any queries from being missed in the data collection.

注意

SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降では、この動作はエンジンによって制御されるようになり、トレース フラグ 7752 に効力はありません。Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this behavior is controlled by the engine, and trace flag 7752 has no effect.

重要

SQL Server 2016 (13.x)SQL Server 2016 (13.x) の Just-In-Time ワークロード分析情報のためにクエリ ストアを使用している場合は、SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP2 CU2 におけるパフォーマンス スケーラビリティの強化 (KB 4340759) をできるだけ早くインストールするように計画してください。If you're using Query Store for just-in-time workload insights in SQL Server 2016 (13.x)SQL Server 2016 (13.x), plan to install the performance scalability improvements in SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) as soon as possible. これらの強化がない場合、データベースでワークロードが重いときにスピンロックの競合が発生し、サーバーのパフォーマンスが低速になる場合があります。Without these improvements, when the database is under heavy workloads, spinlock contention may occur and server performance may become slow. 特に、QUERY_STORE_ASYNC_PERSIST スピンロックまたは SPL_QUERY_STORE_STATS_COOKIE_CACHE スピンロックで激しい競合が発生する場合があります。In particular, you may see heavy contention on the QUERY_STORE_ASYNC_PERSIST spinlock or SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock. この強化を適用すると、クエリ ストアによってスピンロックの競合が発生しなくなります。After this improvement is applied, Query Store will no longer cause spinlock contention.

重要

(SQL Server 2017 (14.x)SQL Server 2017 (14.x) から SQL Server 2016 (13.x)SQL Server 2016 (13.x) の) SQL ServerSQL Server の Just-In-Time ワークロード分析情報のためにクエリ ストアを使用している場合は、SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP2 CU15、SQL Server 2017 (14.x)SQL Server 2017 (14.x) CU22、および SQL Server 2019 (15.x)SQL Server 2019 (15.x) CU8 のパフォーマンスのスケーラビリティ向上をできるだけ早くインストールするように計画してください。If you're using Query Store for just-in-time workload insights in SQL ServerSQL Server (SQL Server 2016 (13.x)SQL Server 2016 (13.x) through SQL Server 2017 (14.x)SQL Server 2017 (14.x)), plan to install the performance scalability improvement in SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x)SQL Server 2017 (14.x) CU22, and SQL Server 2019 (15.x)SQL Server 2019 (15.x) CU8 as soon as possible. この強化がない場合、データベースでアドホック ワークロードが重いときにクエリ ストアによって大量のメモリが使用され、サーバーのパフォーマンスが低速になる場合があります。Without this improvement, when the database is under heavy ad-hoc workloads, the Query Store may use a large amount of memory and server performance may become slow. この強化を適用すると、クエリ ストアでは、さまざまなコンポーネントが使用できるメモリ量に内部的な制限が設けられます。また、十分なメモリが データベース エンジンDatabase Engine に返されるまでの間、動作モードを読み取り専用に自動的に変更できます。After this improvement is applied, Query Store imposes internal limits to the amount of memory its various components can use, and can automatically change the operation mode to read-only until enough memory has been returned to the データベース エンジンDatabase Engine. クエリ ストアの内部的なメモリ制限は、変更の可能性があるため文書化されないことに注意してください。Note that Query Store internal memory limits are not documented because they are subject to change.

関連項目See also