クエリストアを使用してワークロードを監視するためのベストプラクティス

[アーティクル]
11/19/2024

適用対象: SQL Server 2016 (13.x) 以降のバージョンAzure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (専用 SQL プールのみ))、Microsoft Fabric の SQL データベース

この記事では、ワークロードで SQL Server クエリストアを使用するためのベストプラクティスについて説明します。

クエリストアを使用した構成と管理の詳細については、「クエリストアを使用したパフォーマンスの監視」を参照してください。
アクションにつながる情報を検出し、クエリストアを使用してパフォーマンスを調整する方法については、「クエリストアを使用したパフォーマンスの調整」を参照してください。
Azure SQL Database におけるクエリストアの運用の詳細については、「 Azure SQL Database でクエリストアを運用する」を参照してください。
Azure Synapse Analytics では、クエリストアは専用 SQL プールに対して既定では有効になっていませんが、有効にできます。クエリストアの追加の構成オプションはサポートされていません。詳しくは、「Azure Synapse Analytics での履歴クエリのストレージと分析」を参照してください。

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

Azure SQL データベースでクエリストアを実行する場合、クエリパフォーマンスの分析情報を使用して、経時的にリソース消費量を分析できます。 Management Studio と Azure Data Studio を使用して、CPU、メモリ、I/O など、すべてのクエリの詳細なリソース消費量を取得することができますが、クエリパフォーマンスの分析情報を使用すると、データベースの DTU 全体の消費量に対する影響を簡単かつ効率的に確認できます。詳細については、「 Azure SQL Database Query Performance Insight」を参照してください。

Fabric SQL データベースのパフォーマンスを監視するにはパフォーマンスダッシュボードを使用します。

エラスティックプールデータベースでクエリストアを使用する

クエリストアは、すべてのデータベースで (高密度でパックされたAzure SQL データベースエラスティックプールであっても) 問題なく使用できます。エラスティックプール内の多数のデータベースに対してクエリストアを有効にすると発生する可能性があった、リソースの過剰使用に関連するすべての問題は解決されました。

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

次の図に示すように、クエリストアでのトラブルシューティングのワークフローはシンプルです。

クエリストアのトラブルシューティングの図: クエリストアの有効化。クエリストアがデータ収集できるようにする。問題のあるクエリのピンポイントと修正を行う。

前のセクションで説明したように、Management Studio を使用してクエリストアを有効にするか、次の Transact-SQL ステートメントを実行します。

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

クエリストアで、ワークロードを正確に表すデータセットが収集されるまで、しばらく時間がかかります。通常は、非常に複雑なワークロードの場合でも 1 日で十分です。ただし、機能を有効にした後すぐにデータの探索を開始して、注意が必要なクエリを特定することができます。 Management Studio のオブジェクトエクスプローラーでデータベースノードの下にあるクエリストアサブフォルダーに移動し、特定のシナリオのトラブルシューティングビューを開きます。

Management Studio のクエリストアビューの操作には、一連の実行メトリックを使用します。メトリックはそれぞれ、次のいずれかの統計関数で表されます。

SQL Server のバージョン	実行メトリック	統計関数
SQL Server 2016 (13.x)	CPU 時間、実行時間、実行回数、論理読み取り、論理書き込み、メモリ消費量、物理読み取り、CLR 時間、並列処理の次数 (DOP)、行数	Average、Maximum、Minimum、Standard Deviation、Total
SQL Server 2017 (14.x)	CPU 時間、実行時間、実行回数、論理読み取り、論理書き込み、メモリ消費量、物理読み取り、CLR 時間、並列処理の次数、行数、ログメモリ、TempDB メモリ、待機時間	Average、Maximum、Minimum、Standard Deviation、Total

次の図は、クエリストアのビューの場所を示しています。

クエリストアビューの場所を示す SSMS のスクリーンショット。

次の表では、各クエリストアビューの用途を説明します。

SQL Server Management Studio ビュー	シナリオ
機能低下したクエリ	実行メトリックが最近低下した (たとえば、悪化した) クエリを特定します。このビューを使用して、アプリケーションで確認されたパフォーマンスの問題と、修正や改善の必要がある実際のクエリを関連付けます。
全体的なリソース消費量	実行メトリックのいずれかについて、データベースの全体的なリソース消費量を分析します。このビューを使用して、リソースのパターン (日中または夜間のワークロード) を特定し、データベースの全体的な消費量を最適化します。
最もリソースを消費するクエリ	対象となる実行メトリックを選択し、指定された期間で最も極端な値を持つクエリを特定します。このビューを使用して、データベースのリソース消費量に最も大きな影響を与えている最も関連性の高いクエリに焦点を絞ります。
強制適用されたプランのあるクエリ	クエリストアを使って以前に強制適用されたプランを一覧表示します。このビューを使って、現在強制適用されているすべてのプランに簡単にアクセスします。
高バリエーションのクエリ	目的の期間の、実行時間、CPU 時間、IO、メモリ使用量など、使用可能なディメンションのいずれかに関連して実行バリエーションが高いクエリを分析します。このビューを使用して、アプリケーション全体のユーザーエクスペリエンスに影響する可能性のある、パフォーマンスの差異が大きいクエリを特定します。
クエリ待機統計	データベースで最もアクティブな待機カテゴリ、および選択された待機カテゴリに対して最も影響を与えるクエリを分析します。このビューを使用して、待機統計を分析し、アプリケーション全体のユーザーエクスペリエンスに影響する可能性のあるクエリを特定します。適用対象: SQL Server Management Studio v18.0 と(SQL Server 2017 (14.x) 以降)。
追跡対象のクエリ	最も重要なクエリの実行をリアルタイムで追跡します。このビューは通常、強制適用されたプランを持つクエリがあり、クエリのパフォーマンスを安定させる必要がある場合に使用します。

ヒント

Management Studio を使用して最もリソースを消費するクエリを特定し、プラン変更により機能低下したクエリを修正する方法の詳細については、Query Store Azure Blogs を参照してください。

パフォーマンスが最適ではないクエリを特定する際のアクションは、問題の性質によって異なります。

クエリの実行プランが複数あり、最後のプランのパフォーマンスが前のプランよりも大幅に悪いような場合は、プランの強制適用メカニズムを使用することができます。 SQL Server がオプティマイザーのプランを強制しようとします。プランの適用に失敗した場合、XEvent が発生し、オプティマイザーは通常の方法で最適化するように指示します。

クエリストアの [プランの強制] ボタンの SSMS のスクリーンショット。

Note

前の図では特定のクエリプランに異なる図形が使われている場合があり、考えられる各状態の意味を次に示します。

図形	意味
白丸	クエリ完了。これは、通常の実行が正常に終了したことを意味します。
Square	キャンセル済み。これは、クライアントが開始した実行中止を意味します。
三角形	失敗。これは、例外で実行が中止されたことを意味します。

また、図形のサイズには、指定された期間内でのクエリ実行回数が反映されます。実行回数が多いと、サイズが大きくなります。

クエリに最適な実行のためのインデックスが欠落している場合があります。この情報は、クエリの実行プラン内で確認できます。欠落しているインデックスを作成し、クエリストアを使用してクエリのパフォーマンスを確認します。

不足しているインデックス通知が強調表示されている、クエリストアプランの SSMS のスクリーンショット。

SQL Database でワークロードを実行している場合、SQL Database Index Advisor にサインアップすると、推奨されるインデックスを自動的に取得できます。

実行プランの推定行数と実際の行数に大きな差がある場合は、統計情報を強制的に再コンパイルすることもできます。
たとえば、クエリのパラメーター化を利用したり、より最適なロジックを実装したりする場合は、問題のあるクエリを書き直します。

ヒント

Azure SQL Database では、コードを変更せずにクエリに対するクエリヒントを適用するためのクエリストアヒント機能を検討してください。詳細と例については、「クエリストアヒント」を参照してください。

クエリストアでクエリデータが収集されていることを継続的に確認する

クエリストアでは、操作モードが通知なしに変更されることがあります。クエリストアの状態を定期的に監視して、クエリストアが動作していることを確認し、回避できたはずのエラーが発生しないようにしてください。操作モードを確認して最も重要なパラメーターを表示するには、次のクエリを実行します。

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_desc と desired_state_desc の違いは、操作モードが自動的に変更されたことを示します。最も一般的な変更は、クエリストアが通知なしに読み取り専用モードに切り替わることです。非常にまれな状況では、クエリストアが内部エラーにより、エラー状態になることがあります。

実際の状態が読み取り専用になっている場合は、readonly_reason 列で根本原因を調べます。通常は、サイズクォータを超えたために、クエリストアが読み取り専用モードに移行したことがわかります。その場合は readonly_reason を 65536 に設定します。他の理由については、「sys.database_query_store_options (Transact-SQL)」を参照してください。

クエリストアを読み取り/書き込みモードに戻してデータの収集を再開するには、次の手順を実行します。

ALTER DATABASE のMAX_STORAGE_SIZE_MB オプションを使用して、ストレージの最大サイズを増やします。
次のステートメントを使用して、クエリストアのデータをクリーンアップする。
```
ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
```

操作モードを明示的に読み取り/書き込みモードに戻す次のステートメントを実行することで、これらの手順のいずれかまたは両方を適用できます。

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

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

推奨事項を取り入れることで、操作モードが通知なしに変更されることを防ぐことができます。クエリストアのサイズが許可される最大値を常に下回り、読み取り専用モードに移行される可能性が大幅に低くなるようにしてください。クエリストアの構成に関するセクションの説明に従って、サイズベースのポリシーを有効にし、クエリストアでサイズが制限に近づくと自動的にデータがクリーンアップされるようにします。
最新のデータを確実に保持するには、古くなった情報を定期的に削除するように時間ベースのポリシーを構成します。
最後に、クエリストアキャプチャモードを Auto に設定することを検討してください。そうすることで、通常はワークロードにとってあまり関連性のないクエリが除外されるためです。

エラー状態

クエリストアを復旧させるには、明示的に読み取り/書き込みモードに設定してみて、実際の状態を再度確認します。

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;

それでも問題が解決しない場合は、ディスクに破損したクエリストアデータが保存されていることを示しています。

SQL Server 2017 (14.x) 以降では、影響を受けたデータベース内で sys.sp_query_store_consistency_check ストアドプロシージャを実行することで、クエリストアを復旧させることができます。復旧操作を試みる前にクエリストアを無効にする必要があります。 QDS の整合性チェックと復旧を実行するために使用または変更するサンプルクエリを次に示します。

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) 
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY
 
  BEGIN CATCH 
    SELECT  
      ERROR_NUMBER() AS ErrorNumber  
      ,ERROR_SEVERITY() AS ErrorSeverity  
      ,ERROR_STATE() AS ErrorState  
      ,ERROR_PROCEDURE() AS ErrorProcedure  
      ,ERROR_LINE() AS ErrorLine  
      ,ERROR_MESSAGE() AS ErrorMessage; 
  END CATCH;   
END

SQL Server 2016 (13.x) の場合は、示されているようにクエリストアからデータをクリアする必要があります。

復旧に失敗した場合は、読み取り/書き込みモードを設定する前にクエリストアをクリアしてみてください。

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;

パラメーター化されていないクエリを使用しない

パラメーター化されていないクエリを必要でないときに使用することは、ベストプラクティスではありません。たとえば、アドホック分析の場合です。キャッシュされたプランは再利用できません。再利用すると、クエリオプティマイザーによって一意のクエリテキストごとにクエリが強制的にコンパイルされます。詳細については、「Guidelines for using forced parameterization」 (強制パラメーター化使用のガイドライン) をご覧ください。

また、さまざまなクエリテキストが多数ある可能性があり、その結果として、同じような形のさまざまな実行プランが多数存在することになるため、クエリストアでサイズクォータがすぐに制限を超える可能性があります。その結果、ワークロードのパフォーマンスが最適でなくなり、クエリストアが読み取り専用モードに切り替わったり、後続のクエリへの対応を試みるためにデータが常に削除されるようになる可能性があります。

次のオプションを検討してください。

必要に応じて、クエリをパラメーター化します。たとえば、ストアドプロシージャまたは sp_executesql 内にクエリをラップします。詳細については、「パラメーターと実行プランの再利用」をご覧ください。
ワークロードに 1 回限りのアドホックバッチが多数含まれており、そこで異なるクエリプランが使用されている場合は、アドホックワークロードの最適化オプションを使用します。
- 個々の query_hash 値の数と、sys.query_store_query 内のエントリの総数を比較します。この比率が 1 に近い場合、アドホックワークロードで異なるクエリが生成されます。
異なるクエリプランの数が多くない場合は、データベースまたはクエリのサブセットに対して強制パラメーター化を適用します。
- 選択したクエリに対してのみパラメータ化を強制するには、プランガイドを使用します。
- ワークロード内の異なるクエリプランの数が少ない場合は、パラメーター化データベースオプションコマンドを使用して、強制パラメーター化を構成します。たとえば、個々の query_hash の数と sys.query_store_query 内のエントリの総数の比率が 1 よりもかなり小さい場合です。
リソース消費の少ないアドホッククエリを自動的に除外するには、QUERY_CAPTURE_MODE を AUTO に設定します。

ヒント

Entity Framework (EF) などのオブジェクトリレーショナルマッピング (ORM) ソリューションを使う場合、手動の LINQ クエリツリーや特定の未加工の SQL クエリのようなアプリケーションクエリがパラメーター化されない可能性があります。これは、プランの再利用とクエリストアでクエリを追跡する機能に影響します。詳細については、EF クエリのキャッシュとパラメーター化および EF の未加工の SQL クエリに関する記事を参照してください。

クエリストアでパラメーター化されていないクエリを検索する

クエリストアに格納されているプランの数は、クエリストア DMV、SQL Server、Azure SQL Managed Instance、または Azure SQL Database を使用して、次のクエリを使用して確認できます。

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

次のサンプルを使用すると、拡張イベントセッションが作成されて、イベント query_store_db_diagnostics がキャプチャされます。これは、クエリリソースの消費量を診断するのに役立ちます。 SQL Server では、この拡張イベントセッションによって、SQL Server ログフォルダーにイベントファイルが既定で作成されます。たとえば、Windows の既定の SQL Server 2019 (15.x) インストールでは、フォルダー C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log にイベントファイル (.xel ファイル) を作成する必要があります。 Azure SQL Managed Instance の場合は、代わりに Azure Blob Storage の場所を指定します。詳細については、Azure SQL Managed Instance の XEvent event_file に関する記事を参照してください。イベント "qds.query_store_db_diagnostics" は、Azure SQL Database には使用できません。

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER 
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

このデータを使用すると、クエリストアのプラン数だけでなく、他の多くの統計情報も見つけることができます。クエリストアによって追跡されるメモリの使用量とプランの数を把握するために、イベントデータ内の plan_count列、query_count 列、max_stmt_hash_map_size_kb 列、および max_size_mb 列を探します。プラン数が通常よりも多い場合は、パラメーター化されていないクエリの増加を示している可能性があります。次のクエリストア DMV クエリを使用して、クエリストア内のパラメーター化されたクエリとパラメーター化されていないクエリを確認します。

パラメーター化されたクエリ:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

パラメーター化されていないクエリ:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE query_parameterization_type=0;

コンテインオブジェクトのために DROP と CREATE のパターンを使用しない

クエリストアでは、クエリエントリと親オブジェクト (ストアドプロシージャ、関数、トリガー) を関連付けます。親オブジェクトを再作成すると、同じクエリテキストに対して新しいクエリエントリが生成されます。これにより、そのクエリのパフォーマンス統計情報を経時的に追跡し、プランの強制適用メカニズムを使用できなくなります。この状況を回避するには、可能な限り、ALTER <object> プロセスを使用して親オブジェクトの定義を変更します。

強制適用されたプランの状態を定期的に確認する

プランの強制適用は、重要なクエリのパフォーマンスを修正してより正確な予測を可能にするための便利なメカニズムです。プランヒントやプランガイドと同様に、プランの強制適用は、今後の実行で使用されることを保証するものではありません。通常、実行プランによって参照されるオブジェクトが変更または削除されるような方法でデータベーススキーマが変更された場合、プランを強制的に適用できません。その場合、SQL Server はクエリの再コンパイルに戻りますが、強制適用が失敗した実際の理由は sys.query_store_plan に示されます。次のクエリは、強制適用されたプランに関する情報を返します。

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」を参照してください。 query_store_plan_forcing_failed XEvent を使用して、プラン強制の失敗を追跡してトラブルシューティングすることもできます。

ヒント

プランが強制適用されたクエリの場合はデータベースの名前を変更しない

実行プランでは、database.schema.object のような 3 つの部分で構成される名前を使用して、オブジェクトを参照します。

データベース名を変更すると、プランの強制適用が失敗し、その後のすべてのクエリ実行で再コンパイルが発生します。

ミッションクリティカルなサーバーでのクエリストアの使用

グローバルトレースフラグ 7745 と 7752 を使用すると、クエリストアを使ってデータベースの可用性を向上させることができます。詳しくは、「トレースフラグ」をご覧ください。

トレースフラグ 7745 では、SQL Server がシャットダウンされる前に、クエリストアによってディスクにデータを書き込む既定の動作が行われないようにします。つまり、DATA_FLUSH_INTERVAL_SECONDS で定義された時間枠まで、収集されたもののディスクにはまだ保存されていないクエリストアデータは失われます。
トレースフラグ 7752 では、クエリストアの非同期読み込みが有効になります。これにより、データベースをオンラインにすることができ、クエリストアが完全に復旧される前にクエリを実行できます。既定の動作では、クエリストアの同期読み込みが行われます。既定の動作では、クエリストアが復旧される前にクエリを実行することはできませんが、データコレクションでクエリが失われることもありません。

Note

SQL Server 2019 (15.x) 以降では、この動作はエンジンによって制御されるようになり、トレースフラグ 7752 に効力はありません。

重要

クエリストアの SQL Server 2016 (13.x)におけるJust-In-Time ワークロード分析情報のためにクエリストアを使用している場合は、SQL Server 2016 (13.x) SP2 CU2 におけるパフォーマンススケーラビリティの強化 (KB 4340759) をできるだけ早くインストールするように計画してください。これらの強化がない場合、データベースでワークロードが重いときにスピンロックの競合が発生し、サーバーのパフォーマンスが低速になる場合があります。特に、QUERY_STORE_ASYNC_PERSIST スピンロックまたは SPL_QUERY_STORE_STATS_COOKIE_CACHE スピンロックで激しい競合が発生する場合があります。この強化を適用すると、クエリストアによってスピンロックの競合が発生しなくなります。

重要

Just-In-Time ワークロード分析情報を得るために SQL Server (SQL Server 2016 (13.x) から SQL Server 2017 (14.x)) のクエリストアを使用している場合は、できるだけ早く、SQL Server 2016 (13.x) SP2 CU15、SQL Server 2017 (14.x) CU23、SQL Server 2019 (15.x) CU9 をインストールし、パフォーマンスのスケーラビリティ改善を行うことを検討してください。この強化がない場合、データベースでアドホックワークロードが重いときにクエリストアによって大量のメモリが使用され、サーバーのパフォーマンスが低速になる場合があります。この強化を適用すると、クエリストアでは、さまざまなコンポーネントが使用できるメモリ量に内部的な制限が設けられます。また、十分なメモリがデータベースエンジンに返されるまでの間、動作モードを読み取り専用に自動的に変更できます。クエリストアの内部的なメモリ制限は、変更の可能性があるため文書化されません。

Azure SQL データベースのアクティブ geo レプリケーションでクエリストアを使用する

Azure SQL Database のセカンダリアクティブ geo レプリカのクエリストアは、プライマリレプリカでのアクティビティの読み取り専用コピーになります。

Azure SQL Database geo レプリケーションで階層の不一致が起こらないようにしてください。セカンダリデータベースは、プライマリデータベースと同じまたはそれに近いコンピューティングサイズで、プライマリデータベースと同じサービスレベルにある必要があります。 sys.dm_db_wait_stats で HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO という待機の種類を探します。これは、セカンダリラグが原因でプライマリレプリカのトランザクションログレートを調整することを示します。

アクティブ geo レプリケーションのセカンダリ Azure SQL データベースのサイズの推定と構成の詳細については、「セカンダリデータベースの構成」を参照してください。

ワークロードに合わせてクエリストアをチューニングする

クエリストアの構成と管理に関するベストプラクティスと推奨事項については、クエリストアを管理するためのベストプラクティスに関する記事を参照してください。

次の方法で共有

クエリストアを使用してワークロードを監視するためのベストプラクティス

最新の SQL Server Management Studio を使用する

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

エラスティックプールデータベースでクエリストアを使用する

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

クエリストアでクエリデータが収集されていることを継続的に確認する

エラー状態

パラメーター化されていないクエリを使用しない

クエリストアでパラメーター化されていないクエリを検索する

コンテインオブジェクトのために DROP と CREATE のパターンを使用しない

強制適用されたプランの状態を定期的に確認する

プランが強制適用されたクエリの場合はデータベースの名前を変更しない

ミッションクリティカルなサーバーでのクエリストアの使用

Azure SQL データベースのアクティブ geo レプリケーションでクエリストアを使用する

ワークロードに合わせてクエリストアをチューニングする

フィードバック

その他のリソース

次の方法で共有

クエリ ストアを使用してワークロードを監視するためのベスト プラクティス

最新の SQL Server Management Studio を使用する

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

エラスティック プール データベースでクエリ ストアを使用する

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

クエリ ストアでクエリ データが収集されていることを継続的に確認する

エラー状態

パラメーター化されていないクエリを使用しない

クエリ ストアでパラメーター化されていないクエリを検索する

コンテイン オブジェクトのために DROP と CREATE のパターンを使用しない

強制適用されたプランの状態を定期的に確認する

プランが強制適用されたクエリの場合はデータベースの名前を変更しない

ミッション クリティカルなサーバーでのクエリ ストアの使用

Azure SQL データベースのアクティブ geo レプリケーションでクエリ ストアを使用する

ワークロードに合わせてクエリ ストアをチューニングする

関連するコンテンツ

フィードバック

その他のリソース

クエリストアを使用してワークロードを監視するためのベストプラクティス

エラスティックプールデータベースでクエリストアを使用する

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

クエリストアでクエリデータが収集されていることを継続的に確認する

クエリストアでパラメーター化されていないクエリを検索する

コンテインオブジェクトのために DROP と CREATE のパターンを使用しない

ミッションクリティカルなサーバーでのクエリストアの使用

Azure SQL データベースのアクティブ geo レプリケーションでクエリストアを使用する

ワークロードに合わせてクエリストアをチューニングする