パフォーマンスの監視とトラブルシューティング

  • 10 分

監視とトラブルシューティングは、一貫したパフォーマンスを提供するための重要な要素です。 Azure SQL には、パフォーマンスに加えて追加の機能を監視およびトラブルシューティングするための SQL Server と同じツールと機能があります。 これには、動的管理ビュー (DMV)、拡張イベント、Azure Monitor などの機能が含まれます。 また、これらのツールや機能を Azure SQL のさまざまなパフォーマンス シナリオで使用する方法を学習することも重要です。 これらのシナリオには、高い CPU 使用率やリソースの待機が含まれます。

パフォーマンスを監視するためのツールと機能

Azure SQL は、Azure エコシステムの監視およびトラブルシューティング機能のほか、SQL Server に付属する使い慣れたツールを提供します。 次の各セクションでは、これらについて説明します。

Azure Monitor

Azure Monitor は Azure エコシステムの一部であり、Azure SQL は Azure メトリックス、アラート、ログをサポートするために統合されています。 Azure portal では Azure Monitor のデータを視覚化できます。アプリケーションでは、Azure Event Hubs または API を使ってこのデータにアクセスできます。 Windows パフォーマンス モニターと同様に、Azure Monitor は、SQL Server ツールを使わずに Azure SQL のリソース使用状況メトリックにアクセスするのに役立ちます。

動的管理ビュー (DMV)

Azure SQL は SQL Server とほぼ同じ DMV インフラストラクチャを提供しますが、いくつかの違いがあります。 DMV は、標準の T-SQL クエリを使用して重要な SQL Server パフォーマンス データを表示できるため、パフォーマンス監視に非常に重要です。 たとえば、アクティブなクエリ、リソース使用状況、クエリ プラン、リソースの待機の種類などの情報を見ることができます。 Azure SQL での DMV の詳細については、このユニットの後の方で説明します。

拡張イベント

Azure SQL は SQL Server とほぼ同じ拡張イベント インフラストラクチャを提供しますが、いくつかの違いがあります。 拡張イベントを使用すると、Azure SQL に利用される SQL Server 内の実行の重要なイベントを追跡できます。 パフォーマンスに関しては、拡張イベントを使用すると個々のクエリの実行を追跡できます。 Azure SQL での拡張イベントの詳細については、このユニットの後の方で説明します。

軽量クエリ プロファイリング

軽量プロファイリングは、実行中の要求と高価値のクエリに対して実際の実行プランを取得する必要があるシナリオをトラブルシューティングするための高度な方法です。 オーバーヘッドが少ないため、まだ CPU 上限に達していないサーバーであれば、軽量プロファイリングを継続的に実行できます。また、データベース プロフェッショナルはいつでも処理中の実行を利用できます。たとえば、SQL Server Management Studio (SSMS) のアクティビティ モニターを使ったり、sys.dm_exec_query_profiles または sys.dm_exec_query_statistics_xml のクエリを直接実行したりすることができます。

クエリ プランや、アクティブなクエリの実行中の状態を調べるには、軽量クエリ プロファイリングを使用できます。 これは、実行中のステートメントのクエリ パフォーマンスをデバッグするための重要な機能です。 この機能により、拡張イベントなどのツールを使用してクエリ パフォーマンスを追跡する方法に比べて、パフォーマンスの問題を解決するための時間が短縮されます。 軽量クエリ プロファイリングには DMV 経由でアクセスできます。また、SQL Server 2019 以降のバージョンと同様に、これは Azure SQL の既定で有効になっています。

クエリ プランのデバッグ機能

状況によっては、個々の T-SQL ステートメントのクエリ パフォーマンスに関する追加の詳細が必要になることがあります。 SHOWPLAN や STATISTICS などの T-SQL SET ステートメントはこれらの詳細を提供でき、SQL Server と同様に Azure SQL で完全にサポートされています。

クエリ ストア

クエリ ストアは、ユーザー データベースに格納されたクエリのためのパフォーマンス実行の履歴レコードです。 クエリ ストアは Azure SQL では既定で有効になっており、自動プラン修正や自動チューニングなどの機能を提供するために使用されます。 Azure SQL では、ストアの SQL Server Management Studio (SSMS) レポートを使用できます。 クエリ プランの違いを含む上位のリソース消費クエリや、リソースの待機シナリオを調べるための上位の待機の種類を見つけるには、これらのレポートを使用します。

パフォーマンスの視覚化

Azure SQL Database では、視覚化によって Azure portal で統合されたクエリ ストアのパフォーマンス情報を見ることができます。 この方法で、クエリ ストアについて、SSMS などのクライアント ツールを使う場合と同じ情報の一部を確認できます。 Azure portal の [パフォーマンスの概要] と [クエリ パフォーマンスの分析情報] のオプションを使います。

DMV の詳細

DMV は、長年にわたって、SQL Server のパフォーマンスを監視およびトラブルシューティングするための原動力でした。 SQL Server の共通の DMV は Azure SQL でも使用でき、Azure に固有の DMV がいくつか追加されました。

Azure SQL Managed Instance

SQL Server の DMV はすべて SQL Managed Instance で使用できます。 一般的に、sys.dm_exec_requests や sys.dm_os_wait_stats などの主要な DMV はクエリのパフォーマンスを調べるために使われます。

sys.server_resource_stats システム ビューは Azure SQL Managed Instance に固有であり、リソース使用量の履歴が表示されます。 パフォーマンス モニターなどのオペレーティング システム ツールには直接アクセスできないため、これはリソース使用状況を確認できる重要なツールです。

Azure SQL Database

sys.dm_exec_requests や sys.dm_os_wait_stats など、パフォーマンスに必要な一般的な DMV のほとんどを使用できます。 これらの DMV では、論理サーバーのすべてのデータベースに関する情報ではなく、データベースに固有の情報のみが提供されることに注意してください。

sys.dm_db_resource_stats DMV は Azure SQL Database に固有であり、これを使ってデータベースのリソース使用量の履歴を表示できます。 この DMV は、マネージド インスタンスに対して sys.server_resource_stats を使用する場合と同様に使用します。

sys.elastic_pool_resource_stats DMV は sys.dm_db_resource_stats と似ていますが、これを使うと、エラスティック プール データベースのリソース使用量を表示できます。

必要な DMV

Azure SQL の特定のパフォーマンス シナリオを解決するには、次の DMV が必要です。

  • ファイルごとの I/O パフォーマンスのオペレーティング システム メトリックには直接アクセスできないため、sys.dm_io_virtual_file_stats は重要です。
  • sys.dm_os_performance_counters は、SQL Server の一般的なパフォーマンス メトリックを確認するために Azure SQL Database と SQL Managed Instance の両方で使用できます。 この DMV を使って、通常はパフォーマンス モニターで入手できる SQL Server のパフォーマンス カウンター情報を表示します。
  • sys.dm_instance_resource_governance を使用すると、マネージド インスタンスのリソース制限を表示できます。 この情報を表示すると、Azure portal を使用することなく、どれくらいのリソース制限が予測されるかを確認できます。
  • sys.dm_user_db_resource_governance を使用すると、デプロイ オプション、サービス レベル、Azure SQL Database デプロイのサイズごとの一般的なリソース制限を確認できます。 この情報を表示すると、Azure portal を使用することなく、どれくらいのリソース制限が予測されるかを確認できます。

詳細な分析情報のための DMV

これらの DMV は、Azure SQL のリソース制限やリソース ガバナンスの詳細な分析情報を提供します。 これらは、一般的なシナリオでの使用は想定されていませんが、複雑なパフォーマンスの問題を詳細に調べる場合に役立つことがあります。 これらの DMV の詳細については、各ドキュメントを参照してください。

  • sys.dm_user_db_resource_governance_internal (SQL Managed Instance のみ)
  • sys.dm_resource_governor_resource_pools_history_ex
  • sys.dm_resource_governor_workload_groups_history_ex

拡張イベントの詳細

拡張イベント機能は、SQL Server のトレース メカニズムです。 Azure SQL の拡張イベントは SQL Server エンジンに基づいているため、Azure SQL でもほぼ同じですが、注目すべき違いがいくつかあります。 次のセクションでは、これらの違いについて説明します。

Azure SQL Database の拡張イベント

Azure SQL Database では、SQL Server と同様に、セッションを作成し、イベント、アクション、ターゲットを使用することによって拡張イベントを使用できます。 拡張イベント セッションを作成するときは、次の重要な点を念頭においてください。

  • 最も一般的に使用されるイベントとアクションがサポートされています。
  • ファイル、ring_buffer、カウンター ターゲットがサポートされています。
  • 基になるオペレーティング システム ディスクにはアクセスできないため、ファイル ターゲットは Azure Blob Storage でサポートされています。

セッションを作成して開始するには、SSMS または T-SQL を使用できます。 SSMS を使うと、拡張イベント セッションのターゲット データまたはシステム関数 sys.fn_xe_file_target_read_file を表示できます。

Note

SSMS を使って Azure SQL Database のアクティブなデータを表示することはできません。

セッションに対して発生した拡張イベントはすべて、論理サーバー全体に適用するのではなく、特定のデータベースに固有のものであることを認識することが重要です。

Azure SQL Managed Instance の拡張イベント

SQL Managed Instance では、SQL Server と同様に、セッションを作成し、イベント、アクション、ターゲットを使用することによって拡張イベントを使用できます。 拡張イベント セッションを作成するときは、次の重要な点を念頭においてください。

  • すべてのイベント、ターゲット、アクションがサポートされています。
  • 基になるオペレーティング システム ディスクにはアクセスできないため、ファイル ターゲットは Azure Blob Storage でサポートされています。
  • インスタンスの管理や実行に固有のイベントを追跡するために、SQL Managed Instance では特定のイベントがいくつか追加されています。

セッションを作成して開始するには、SSMS または T-SQL を使用できます。 SSMS を使うと、拡張イベント セッションのターゲット データまたはシステム関数 sys.fn_xe_file_target_read_file を表示できます。 ライブ データを表示する SSMS の機能は、SQL Server と Azure SQL Managed Instance でサポートされています。

Azure SQL のパフォーマンス シナリオ

パフォーマンスの監視とトラブルシューティングのためのツールや機能を適用する方法を決定するには、シナリオを使用して Azure SQL のパフォーマンスを調べることが重要です。

一般的なパフォーマンス シナリオ

SQL Server パフォーマンスのトラブルシューティングの一般的な手法は、パフォーマンスの問題が実行中 (高い CPU 使用率) または待機中 (リソースの待機) のどちらであるかを調べることです。 次の図は、SQL Server のパフォーマンスの問題が実行中または待機中のどちらであるかを特定するためのデシジョン ツリーと、パフォーマンス ツールを使用して原因と解決策を特定する方法を示しています。

Diagram of running versus waiting.

この図の各側面の詳細を調べてみましょう。

実行中または待機中

まず、リソースの全体的な使用状況を確認します。 標準の SQL Server デプロイの場合は、Windows のパフォーマンス モニターや Linux の top などのツールを使うこともできます。 Azure SQL では、次の方法を使用できます。

  • Azure portal、PowerShell、アラート

    Azure Monitor には、Azure SQL のリソース使用状況を表示するためのメトリックが統合されています。 また、リソース使用状況の状態を検出するためのアラートを設定することもできます。

  • sys.dm_db_resource_stats

    Azure SQL Database の場合は、この DMV を調べて、データベース デプロイの CPU、メモリ、I/O のリソース使用状況を確認できます。 この DMV は、このデータのスナップショットを 15 秒ごとに取得します。

  • sys.server_resource_stats

    この DMV は sys.dm_db_resource_stats と同様に動作しますが、SQL マネージド インスタンスの CPU、メモリ、I/O のリソース使用状況を確認するために使用されます。 この DMV もまた、スナップショットを 15 秒ごとに取得します。

  • sys.dm_user_db_resource_governance

    Azure SQL Database の場合は、この DMV によって、現在のデータベースまたはエラスティック プールのリソース ガバナンス メカニズムによって使用されている実際の構成と容量の設定が返されます。

  • sys.dm_instance_resource_governance

    Azure SQL Managed Instance の場合は、この DMV によって、sys.dm_user_db_resource_governance と同様の情報が、現在の SQL Managed Instance に対して返されます。

実行中

問題が高い CPU 使用率であると特定した場合、これは実行中のシナリオと呼ばれます。 実行中のシナリオには、コンパイルや実行でリソースを消費するクエリが含まれる場合があります。 詳細な分析を行うには、次のツールを使用します。

  • クエリ ストア

    どのクエリがほとんどの CPU リソースを消費しているかを見つけるには、SSMS の [Top Consuming Resource] (上位のリソース消費) レポート、[クエリ ストア] カタログ ビュー、または Azure portal の Query Performance Insight (Azure SQL Database のみ) を使用します。

  • sys.dm_exec_requests

    アクティブなクエリの状態のスナップショットを取得するには、Azure SQL でこの DMV を使用します。 十分な CPU 容量があるかどうかを確認するには、状態が RUNNABLE で、待機の種類が SOS_SCHEDULER_YIELD であるクエリを探します。

  • sys.dm_exec_query_stats

    この DMV をクエリ ストアと同様に使用すると、上位のリソース消費クエリを見つけることができます。 クエリ ストアがパフォーマンスの永続的な履歴レコードを提供するのに対して、これはキャッシュされたクエリ プランにしか使用できないことに注意してください。 この DMV ではまた、キャッシュされたクエリのクエリ プランを見つけることもできます。

  • sys.dm_exec_procedure_stats

    この DMV は、パフォーマンス情報をストアド プロシージャ レベルで表示できる点を除き、sys.dm_exec_query_stats と同様の情報を提供します。

    どのようなクエリが最も多くのリソースを消費しているかを特定したら、ワークロード用に十分な CPU リソースがあるかどうかを調べることが必要になる場合があります。 軽量クエリ プロファイリング、SET ステートメント、クエリ ストア、拡張イベント トレースなどのツールを使用してクエリ プランをデバッグできます。

待機中

問題が高い CPU リソース使用率ではないと思われる場合は、リリソースの待機に関連するパフォーマンスの問題である可能性があります。 リソースの待機に関連するシナリオには次のものがあります。

  • I/O の待機
  • Lock waits
  • ラッチの待機
  • バッファー プールの制限
  • メモリ許可
  • プラン キャッシュの削除

待機中のシナリオに対する分析を実行するには、通常、次のツールを調べます。

  • sys.dm_os_wait_stats

    データベースまたはインスタンスの上位の待機の種類を確認するには、この DMV を使用します。 これにより、上位の待機の種類に応じて、次に実行すべきアクションに関するガイドが提供されます。

  • sys.dm_exec_requests

    アクティブなクエリの特定の待機の種類を見つけて、どのようなリソースを待機しているかを確認するには、この DMV を使います。 これは、他のユーザーからのロックを待機している標準的なブロックのシナリオである可能性があります。

  • sys.dm_os_waiting_tasks

    この DMV を使うと、現在実行中の特定のクエリの特定のタスクの待機の種類を見つけて、通常よりも時間がかかっている理由を確認できます。 sys.dm_os_waiting_tasks には、sys.dm_os_wait_stats が時間の経過と共に集計したライブ待機統計が含まれます。

  • クエリ ストア

    クエリ ストアは、クエリ プラン実行の上位の待機の集計を示すレポートとカタログ ビューを提供します。 CPU の待機が "実行中" の問題と同等であることを認識することが重要です。

ヒント

拡張イベントは、どの実行中または待機中のシナリオにも使用できます。 これを行うには、クエリをトレースする拡張イベント セッションを設定する必要があります。 パフォーマンスの問題をデバッグするこの方法は高度であり、DMV よりも多くのパフォーマンス オーバーヘッドと引き換えに多くの情報を返すことができます。

Azure SQL に固有のシナリオ

Azure SQL に固有のいくつかのパフォーマンス シナリオ (実行中と待機中の両方) があります。 これには、ログ ガバナンス、ワーカーの制限、Business Critical サービス レベルで発生した待機、Hyperscale デプロイに固有の待機が含まれます。

ログ ガバナンス

Azure SQL では、ログ レート ガバナンスを使用して、トランザクション ログの使用に関するリソース制限を適用できます。 この適用は、リソース制限を確保し、約束された SLA を満たすために必要になります。 ログ ガバナンスは、次の待機の種類から確認できます。

  • LOG_RATE_GOVERNOR: Azure SQL Database を待機します
  • POOL_LOG_RATE_GOVERNOR: エラスティック プールを待機します
  • INSTANCE_LOG_GOVERNOR: Azure SQL Managed Instance を待機します
  • HADR_THROTTLE_LOG_RATE*: Business Critical と geo レプリケーションの待機時間を待機します

ワーカーの制限

SQL Server はスレッドのワーカー プールを使用しますが、ワーカーの最大数に関する制限があります。 同時ユーザー数が多いアプリケーションは、Azure SQL Database と SQL Managed Instance に適用されているワーカー制限に近づく可能性があります。

  • Azure SQL Database には、サービス レベルとサイズに基づいた制限があります。 この制限を超えた場合は、新しいクエリにエラーが返されます。
  • 現時点で、SQL Managed Instance は max worker threads を使っているため、この制限を超えたワーカーには THREADPOOL 待機が表示される可能性があります。

Business Critical HADR 待機

Business Critical サービス レベルを使用している場合は、次の待機の種類が予期せず表示されることがあります。

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

これらの待機によりアプリケーションの速度は低下しないかもしれませんが、あなたはこれらの表示を予期していない可能性があります。 通常、これらは Always On 可用性グループの使用に固有のものです。 Business Critical レベルでは、可用性グループ テクノロジを使用して Business Critical サービス レベルの SLA と可用性機能を実装するため、これらの待機の種類が予測されます。 長い待機時間は背後の I/O 待機時間やレプリカなどのボトルネックを示している可能性があることに注意してください。

Hyperscale

Hyperscale アーキテクチャでは、先頭に RBIO (ログ ガバナンスを示している可能性があります) の付いたいくつかの固有の待機の種類が生成される場合があります。 さらに、DMV、カタログ ビュー、拡張イベントが、ページ サーバー読み取りのメトリックを示すように拡張されています。

次の演習では、このユニットで取得したツールと知識を使って、Azure SQL のパフォーマンスの問題を監視して解決する方法について説明します。