データベース パフォーマンスの監視

  • 7 分

データベースのパフォーマンスのトラブルシューティングに使用するトラブルシューティング手法の主な部分は、Azure SQL でも変わりません。

SQL Server の監視とトラブルシューティングに通常使用されるすべてのツールは、パフォーマンス モニターなどのツールを含め、Azure 仮想マシン上で実行されている SQL Server にも適用できます。 ただし、サービスとしてのプラットフォーム (PaaS) の性質上、Azure SQL Database と Azure SQL Managed Instance には異なるツール セットが用意されています。 次に、Azure の PaaS オファリングの特定のツールとその機能について説明します。

パフォーマンスの結果とベースラインを比較する

ベースラインを確立するプロセスは、通常、実際のデータベース移行の前に開始されます。 これには、元の環境でのデータベースの標準パフォーマンスを反映した包括的なデータ測定セットの収集が含まれます。 これらの測定値には、CPU 使用率、応答時間、トランザクション レート、エラー率が含まれますが、これらに限定されません。

このベースラインは、移行されたデータベースのパフォーマンスを比較できる参照ポイントとして機能します。 ただし、このベースライン データと移行されたデータベースのパフォーマンス メトリックの評価または比較は、移行が完了した後にのみ行われます。

移行後、新しいデータベース環境のパフォーマンスが監視および測定されます。 これらの移行後のメトリックは、移行前のベースラインと比較され、不一致やパフォーマンスの問題を特定します。 この比較は、移行がデータベースのパフォーマンスに悪影響を与えたかどうか、またはパフォーマンス向上のために最適化が必要な領域があるかどうかを理解するのに役立ちます。

自動チューニング

自動チューニング は、ワークロードから継続的に学習し、潜在的な問題と改善点を特定し、クエリ ストア データに基づいて推奨事項を提供する機能です。 スキーマまたはインデックスの変更、またはデータの更新によって発生する実行プランの変更に適応します。

Azure portal を使用してチューニングの推奨事項を手動で適用するか、または自動チューニングでチューニングの推奨事項を自律的に適用することができます。 Azure SQL Database では、インデックスをチューニングすることでクエリのパフォーマンスを向上させることもできます。

自動プラン修正

クエリ ストアの助けを借りて、データベース エンジンは、クエリ実行プランのパフォーマンスが低下したことを検出できます。 退行したプランはユーザー インターフェイスを通して手動で識別できますが、クエリ ストアには自動的に通知するオプションも用意されています。

後退したプラン修正の [クエリ ストア] ビューのスクリーンショット。

この例では、プラン ID 1 横にチェック マークが表示され、プランが強制されていることを示します。

自動チューニングを有効にすると、次の条件下で、推奨されるクエリ実行プランがデータベース エンジンによって自動的に適用されます。

  • 前のプランのエラー率が推奨プランのエラー率を超えています
  • 推定 CPU ゲインが 10 秒を超える
  • 強制計画は、前のプランよりも優れ

自動プランの強制が発生すると、データベース エンジンは最後の適切なプランを適用し、そのパフォーマンスを監視します。 強制プランのパフォーマンスが以前のプランよりも優れていない場合は、強制が解除され、新しいプランがコンパイルされます。 前のプランよりも優れた場合は、再コンパイルが行われるまで強制されます。

プランの自動修正を有効にするには、次の T-SQL クエリを使用します。

ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

自動チューニングの推奨事項は、動的管理ビュー (sys.dm_db_tuning_recommendations) を使用して表示できます。 この DMV では、推奨事項の詳細、種類、および状態が提供されます。 データベースの自動チューニングが有効になっているかどうかを確認するには、ビュー sys.database_automatic_tuning_optionsを参照してください。

Azure SQL Managed Instance の自動チューニングでは、FORCE LAST GOOD PLANのみがサポートされます。

自動チューニングの通知を有効にするには、自動チューニングの 電子メール通知を参照してください。

インデックスの自動管理

Azure SQL Database では、インデックスの自動チューニングがサポートされています。 つまり、時間の経過と同時に、データベースには既存のワークロードについて学習し、パフォーマンスを向上させるためにインデックスの追加または削除に関する推奨事項を提供する機能があります。 改善されたクエリ プランを強制する場合と同様に、既存のインデックスのパフォーマンスに応じて、インデックスの自動作成または削除を許可するようにデータベースを構成できます。

Azure SQL Database の自動チューニング オプションのスクリーンショット。

または、次のクエリを使用して、データベースで有効になっている自動チューニング機能を確認します。

SELECT name,
    desired_state_desc,
    actual_state_desc,
    reason_desc
FROM sys.database_automatic_tuning_options

インデックスの作成はリソースを集中的に消費するため、作成が成功することは、ワークロードに悪影響を与えないようにするために不可欠です。

Azure SQL Database は、パフォーマンスの低下を防ぐために、新しいインデックスを自動的に実装するために必要なリソースを監視します。 チューニング アクションは、たとえば、既存のワークロードに必要なリソースがインデックスの作成を妨げるときに、リソースが使用可能になるまで遅延されます。

Query Performance Insight を調べる

データベース パフォーマンス最適化タスクの最初のフェーズでは、最もリソースを消費するクエリを特定する必要があります。 以前のバージョンの SQL Server では、これには広範なトレースと複雑な SQL スクリプトのセットが必要であり、データ収集プロセスが面倒になりました。

問題のあるクエリを特定する

Azure SQL Database には、管理者がコストの高いクエリをすばやく識別できる Query Performance Insight と呼ばれるツールが用意されています。 これは、Azure SQL Database のメイン ブレードの [ インテリジェント パフォーマンス ] セクションにあります。

Azure SQL Database の Query Performance Insight には、実行時間の長いクエリ、リソースを消費する上位のクエリ (既定)、またはカスタム フィルターの 3 つのフィルターオプションが用意されています。 選択したリソース (CPU、データ IO、ログ IO など) で並べ替えられた上位 5 つのクエリが表示されます。 下のグリッド内の行を選択することで、個々のクエリをドリルダウンできます。 各行は、棒グラフの色と一致する個別の色でマークされます。

Azure portal の Query Performance Insights ダッシュボードのスクリーンショット。

カスタム タブでは、他のオプションよりも柔軟性が高くなります。 これにより、データの視覚化に影響を与えるいくつかのドロップダウン メニューを使用して、パフォーマンス データをより調整した調査が可能になります。 主要なメトリックには、 CPU、 ログ IO、 データ IO、 メモリが含まれます。これは、Azure SQL Database のサービス レベルとコンピューティング リソースによって制限されるパフォーマンスの側面です。

Query Performance Insight のカスタム ダッシュボードのスクリーンショット。

個々のクエリをドリルダウンすると、クエリ ID とクエリ自体、およびクエリ集計の種類と関連付けられた期間を確認できます。

Query Performance Insight のクエリ ID 3204 の詳細のスクリーンショット。

Query Performance Insight にクエリの実行プランは表示されませんが、そのクエリをすばやく特定し、その情報を使用してデータベースのクエリ ストアからプランを抽出することができます。

アラート

Azure portal を使用して、Azure SQL Database のデータベースのパフォーマンス アラートを設定できます。 これらのアラートは、特定のメトリック (データベース サイズや CPU 使用率など) がしきい値に達したときに、電子メールで通知したり、Webhook を呼び出したりできます。

アラートを設定するプロセスは、SQL Database と SQL Managed Instance の間で似ています。 Azure SQL Database のパフォーマンス アラートを設定するには、[ 監視 ] セクションに移動し、[アラート] を選択 します。 そこから、新しいアラート ルールを確立し、条件を定義し、アクション グループを作成する必要があります。

Azure SQL Managed Instance のアラートの詳細については、Azure portal を使用した Azure SQL Managed Instance のアラートの作成に関するページを参照してください。 Azure SQL Database に関心がある場合は、Azure portal を使用した Azure SQL Database と Azure Synapse Analytics のアラートの作成に関するページを参照してください。

Azure SQL Insights

Azure SQL Insights は、対話型ですぐに使用できる視覚化を提供することで、監視エクスペリエンスを強化します。 テレメトリの収集と頻度をカスタマイズし、複数のソースのデータを 1 つの監視エクスペリエンスに結合できます。 また、この一連のメトリックが長期間保持されるので、過去に発生した可能性のあるパフォーマンスの問題を調査できます。

重要

移行されたデータベースが運用環境に完全に統合された後にのみ、Azure SQL Insights を設定することをお勧めします。 これにより、移行とテストのフェーズ中にツールがノイズの多いデータをキャプチャできなくなります。

SQL Insights の使用を開始するには、SQL サーバーからデータを監視してリモートで収集する専用の仮想マシンが必要です。 この専用仮想マシンには、次のコンポーネントがインストールされている必要があります。

  • Azure Monitor エージェント
  • ワークロードの分析情報に関する拡張機能

さらに、SQL Insights を設定するには、次のコンポーネントが必要です。

監視プロファイル – 監視するグループ サーバー、インスタンス、またはデータベース。

Log Analytics ワークスペース - SQL 監視データの送信先。

コレクション設定 – プロファイルのデータ収集をカスタマイズできます。 既定の設定は、ほとんどの監視シナリオに対応しており、通常は変更する必要はありません。

拡張イベント

拡張イベント ツールは、サーバーとデータベースの詳細なアクティビティをキャプチャする堅牢な監視システムです。 フィルターを適用して、データ収集のオーバーヘッドを軽減し、特定のパフォーマンスの問題に焦点を当てることができます。 すべての Azure SQL オファリングでは、拡張イベントがサポートされています。

拡張イベントのセットアップは SQL Server、Azure SQL Database、Azure SQL Managed Instance で似ていますが、このモジュールでは、セットアップ プロセスを教えるのではなく、それらの違いに焦点を当てています。

Azure SQL Database で拡張イベントを構成するときの主な違いを次に示します。

  • Transact-SQL: SQL Server で CREATE EVENT SESSION コマンドを実行するときは、 ON SERVER 句を使用します。 ただし、Azure SQL Database では、代わりに ON DATABASE 句を使用します。 ON DATABASE 句は、ALTER EVENT SESSION コマンドと DROP EVENT SESSION Transact-SQL コマンドにも適用されます。 Azure SQL Database では、データベース スコープのセッションのみがサポートされています。

  • データベース スコープ セッション: 拡張イベントは、Azure SQL Database のシングルテナント分離モデルに基づいて作成されます。 あるデータベースのイベント セッションは、別のデータベースのデータまたはイベントにアクセスできません。 master データベース¹ のコンテキストで CREATE EVENT SESSION ステートメントを発行することはできません。

  • ストレージ: データベースが Azure SQL Database に存在するサーバーのファイル システムにアクセスできないため、拡張イベント セッションを格納するようにストレージ アカウント ターゲットを構成できます。