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

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 を使用して表示できます。この動的管理ビューでは、レコメンデーションの詳細、種類、状態が表示されます。データベースの自動チューニングが有効になっているかを確認するには、ビュー sys.database_automatic_tuning_options を確認します。

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

自動チューニングの通知を有効にする方法は、自動チューニングのメール通知をご覧ください

インデックスの自動管理

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

Screenshot of Automatic tuning Options for 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 つのクエリが表示されます。下にあるグリッド内の行を選択すると、個々のクエリの詳細を表示できます。各行は、バーグラフの色と一致する個別の色でマークされています。

カスタムタブでは、他のオプションよりも柔軟性の高い内容を表示できます。これにより、視覚化するデータの内容を決める複数のドロップダウンメニューを使用して、パフォーマンスデータのよりカスタマイズされた調査が可能になります。主要なメトリックには、CPU、ログ IO、データ IO、メモリなどがあります。これは、Azure SQL Database のサービスレベルとコンピューティングリソースによって制限されるパフォーマンスの要素です。

個々のクエリの詳細情報を表示すれば、クエリ ID とクエリ自体のほか、クエリの集計の種類と関連する期間を確認できます。

Screenshot of the details of Query ID 3204 in Query Performance Insight.

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 のシングルテナント分離モデルに基づいています。あるデータベースのイベントセッションは他のデータベースのデータやイベントにアクセスできません。マスターデータベース¹ のコンテキストで、CREATE EVENT SESSION ステートメントを発行することはできません。
ストレージ: Azure SQL Database では、データベースが置かれているサーバーのファイルシステムにアクセスできないため、拡張イベントセッションを格納する保存先のストレージアカウントを構成できます。

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