Database Watcher のデータ コレクションとデータセット (プレビュー)

適用対象: Azure SQL Database Azure SQL Managed Instance

Database Watcher は、SQL システム ビューから監視データを収集し、データセットの 形式でデータ ストアに取り込みます。 各データセットは、1 つ以上の SQL システム ビューのデータを使用して形成されます。 データセットごとに、データ ストアに個別のテーブルがあります。

データ コレクション

Database Watcher は、T-SQL クエリを使用して定期的に監視データを収集します。 クエリの各実行で収集されるデータは、サンプルと呼ばれます。 サンプルの収集頻度はデータセットによって異なります。 たとえば、SQL パフォーマンス カウンターなどの頻繁に変更されるデータは 10 秒ごとに収集されますが、データベース構成などのほとんどの静的データは 5 分ごとに収集される場合があります。 詳細については、「データセット」に関するページを参照してください。

Database Watcher は、Azure Data Explorer のストリーミング インジェストとMicrosoft Fabric の Real Time Analytics を利用して、凖リアルタイムの監視を提供します。 通常、収集された SQL 監視データは、10 秒未満でレポートと分析に使用できるようになります。 インジェスト統計リンクを使用して、Database Watcher のダッシュボードでデータ インジェストの待機時間を監視できます。

Database Watcher ワークロードとアプリケーション ワークロード間の相互作用

データベース ウォッチャーを有効にしても、アプリケーション ワークロードのパフォーマンスに対して目に見える影響が出ることはないでしょう。 通常、より頻繁な監視クエリは 1 秒未満の範囲で実行されますが、大規模なデータセットを返すなど、より多くの時間が必要になる可能性があるクエリは、頻度の低いサイクル間隔で実行されます。

USE master;
GO

CREATE OR ALTER FUNCTION dbo.dbw_classifier()
RETURNS sysname
WITH SCHEMABINDING
AS
BEGIN

DECLARE @WorkloadGroupName sysname = 'default';

IF APP_NAME() IN (N'SQLExternalMonitoring',N'x_ms_reserved_sql_external_monitoring')
    SET @WorkloadGroupName = N'database_watcher_workload_group'

RETURN @WorkloadGroupName;

END;
GO

BEGIN TRY

IF EXISTS (
          SELECT 1
          FROM sys.resource_governor_configuration
          WHERE classifier_function_id <> 0 OR is_enabled <> 0
          )
    THROW 50001, 'Resource Governor is already configured. No changes were made.', 1;

CREATE RESOURCE POOL database_watcher_resource_pool
WITH (MIN_CPU_PERCENT = 5, MAX_CPU_PERCENT = 10, CAP_CPU_PERCENT = 30);

CREATE WORKLOAD GROUP database_watcher_workload_group
WITH (REQUEST_MAX_MEMORY_GRANT_PERCENT = 10)
USING database_watcher_resource_pool;

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.dbw_classifier);

ALTER RESOURCE GOVERNOR RECONFIGURE;

END TRY
BEGIN CATCH
    THROW;
END CATCH;

Azure SQL リソースで実行されているデータ コレクション ワークロードとデータベース ワークロード間のブロックやデッドロック状態などのコンカレンシーの競合を回避するために、監視クエリでは短い ロック タイムアウトと低いデッドロック優先度が使用されます。 コンカレンシーの競合がある場合は、アプリケーション ワークロード クエリに優先順位が与えられます。

全体的なリソース使用率が高い場合、またはコンカレンシーの競合が発生した場合は、収集されたデータにギャップが見られる可能性があります。 このような場合、アプリケーション ワークロードが優先され、監視クエリが優先されないことがあります。

エラスティック プールでのデータ コレクション

エラスティック プールを監視するには、プール内の 1 つのデータベースをアンカー データベースとして指定する必要があります。 Database Watcher はアンカー データベースに接続します。 Watcher はVIEW SERVER PERFORMANCE STATEアクセス許可を保持するため、アンカー データベースのシステム ビューはプール全体の監視データを提供します。

アンカー データベースから収集されたデータには、プール レベルのメトリックと、プール内のデータベースそれぞれに対する特定のデータベース レベルのパフォーマンス メトリックが含まれます。これには、データベースごとのリソース使用率や要求レート メトリックなどがあります。 シナリオによっては、エラスティック プール SQL ターゲットを追加してエラスティック プール全体を監視すれば、プール内の各データベースを監視する必要がなくなる場合があります。

プール レベルの CPU、メモリ、ストレージ使用率、待機統計などの特定の監視データは、プール内の個々のデータベースに属性を付けることができないため、Elastic Pool レベルでのみ収集されます。 逆に、クエリ ランタイム統計、データベース プロパティ、テーブル、インデックス メタデータなど、個々のデータベースを SQL ターゲットとして追加する場合にのみ使用できるデータも他にあります。

エラスティック プールから個々のデータベースを SQL ターゲットとして追加する場合は、エラスティック プールも SQL ターゲットとして追加する必要があります。 これにより、データベースとプールのパフォーマンスをより完全に確認できます。

高密度エラスティック プールを監視する

高密度のエラスティック プールには多数のデータベースが含まれていますが、コンピューティング サイズは比較的小さくなります。 この構成により、顧客は、プール内の少数のデータベースのみが同時にアクティブであるという前提で、コンピューティング リソースの割り当てを最小限に抑えることで、大幅なコスト削減を実現できます。

高密度エラスティック プール内の Database Watcher クエリで使用できるコンピューティング リソースは、アプリケーション クエリへの影響を回避するためにさらに制限されます。 このため、Database Watcher は、高密度エラスティック プール内のすべてのデータベースから監視データを収集できない場合があります。

データの保存場所

次の 3 つのデータ ストア タイプのいずれかに、収集された SQL 監視データを保存することを選択できます。

• Azure Data Explorer クラスターのデータベース。 既定では、新しい Watcher ごとに新しい Azure Data Explorer クラスターが作成され、Watcher と同じ Azure リージョンに配置されます。

  Azure Data Explorer クラスターとデータベースの場所として、Azure 地域内の特定の Azure リージョンを選択できます。 Azure Data Explorer のデータ レプリケーション機能に関する詳細は、「事業継続とディザスター リカバリーの概要」を参照してください。

• 無料のAzure Data Explorer クラスターのデータベース。

  お客様は、特定の Azure 地域を選択できますが、無料の Azure Data Explorer クラスターとデータベースの場所として特定の Azure リージョンを選択することはできません。 別のリージョンまたは地域へのデータ レプリケーションはサポートされていません。

• Microsoft Fabric の Real-Time Analytics のデータベース。

  データベースの地域の場所を選択することはできません。

収集された SQL 監視データのデータ所在地を完全に制御するには、Azure Data Explorer クラスター上のデータベースをデータ ストアとして選択する必要があります。

お客様は Azure Data Explorer クラスターの地域とリージョンを、監視対象の Azure SQL リソースの地域とリージョンに合わせて調整できます。 Azure SQL リソースが複数のリージョンにある場合、データ所在地の要件を満たすために、複数の Watcher と複数の Azure Data Explorer クラスターを作成する必要がある場合があります。

データセット

このセクションでは、データ ストア内の収集頻度やテーブル名など、SQL ターゲットの種類ごとに使用できるデータセットについて説明します。

共通列

次の表に示すように、データセットには SQL ターゲットの種類ごとに共通の列があります。

データセットには、Database Watcher によって行が収集される前に観察されたサンプルが含まれている場合は、sample_time_utc と collection_time_utc の両方の列があります。 それ以外の場合、観測時間と収集時間は同じであり、データセットには sample_time_utc 列のみが含まれます。

たとえば、sqldb_database_resource_utilization データセットは、sys.dm_db_resource_stats 動的管理ビュー (DMV) から派生します。 DMV には、15 秒間隔の集計リソース統計を報告する各行の観測時間である end_time 列が含まれています。 この時間は sample_time_utc 列で報告されます。 Database Watcher がこの DMV に対してクエリを実行すると、結果セットには、それぞれが異なる end_time を持つ複数の行が含まれる場合があります。 これらの行すべてに、同じ collection_time_utc 値があります。

関連するコンテンツ

• Database Watcher を使用して Azure SQL ワークロードを監視する (プレビュー)
• クイック スタート: Azure SQL を監視する Database Watcher を作成する (プレビュー)
• Database Watcher の作成と構成 (プレビュー)
• Database Watcher の監視データの分析 (プレビュー)
• Database Watcher に関するよくあるご質問