Share via

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

  • [アーティクル]

適用対象:Azure SQL データベース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 ワークロードとアプリケーション ワークロード間の相互作用

Database Watcher を有効にすることは、アプリケーションのワークロードに対して観察可能な影響を与える可能性はありません。 通常、より頻繁な監視クエリは 1 秒未満の範囲で実行されますが、大規模なデータセットを返すなど、より多くの時間が必要になる可能性があるクエリは、頻度の低いサイクル間隔で実行されます。

アプリケーション ワークロードへの影響のリスクをさらに軽減するために、Azure SQL データベースのすべての Database Watcher クエリは、内部ワークロードとしてリソース管理されます。 リソースの競合が存在する場合、監視クエリによるリソース消費量は、データベースまたはエラスティック プールで使用可能なリソースの合計数のごく一部に制限されます。 これにより、監視クエリよりもアプリケーションのワークロードが優先されます。

Azure SQL Managed Instance では、必要に応じて、Resource Governor が同様の方法で監視クエリによってリソース消費量を管理できます。

次の例では、SQL Managed Instance で Resource Governor を構成します。 CPU の競合がない場合、Database Watcher クエリによる CPU 消費量が 30% に制限されます。 CPU の競合がある場合、この構成では監視クエリの CPU の 5% が予約され、CPU 使用率が 10% に制限されます。 また、各監視クエリのメモリ許可サイズは、使用可能なメモリの 10% に制限されます。

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;

Note

SQL Managed Instance の高可用性セカンダリ レプリカで Resource Governor 構成をすぐに有効にするには、レプリカに接続して ALTER RESOURCE GOVERNOR RECONFIGURE; を実行します。

Azure SQL リソースで実行されているデータ コレクション ワークロードとデータベース ワークロード間のブロックやデッドロック状態などのコンカレンシーの競合を回避するために、監視クエリでは短い ロック タイムアウトと低いデッドロック優先度が使用されます。 コンカレンシーの競合がある場合は、アプリケーション ワークロード クエリに優先順位が与えられます。 アプリケーションのワークロード パターンによっては、一部のデータセットで収集されたデータに不定期にギャップが生じる可能性があります。

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

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

ヒント

監視する各エラスティック プールに空のデータベースを追加し、アンカー データベースとして指定できます。 これにより、エラスティック プールの監視を中断することなく、プール内外またはプール間で他のデータベースを移動できます。

アンカー データベースから収集されたデータには、プール レベルのメトリックと、プール内のすべてのデータベースの特定のデータベース レベルのパフォーマンス メトリックが含まれます。 たとえば、これには、各データベースのリソース使用率と要求レートメトリックが含まれます。 一部のシナリオでは、エラスティック プール全体を監視すると、プール内の各データベースを監視する必要がなくなります。

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

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

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

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

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

ヒント

高密度エラスティック プールを監視するには、エラスティック プールをターゲットとして追加することで、プール レベルで監視を有効にします。

高密度エラスティック プール内の個々のデータベースをいくつか監視することはお勧めしません。 Database Watcher クエリで使用できるコンピューティング リソースが不足しているため、収集されたデータにギャップが生じる場合や、データ サンプル間の間隔が予想を超える場合があります。

データセット

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

Note

プレビュー期間中は、データセットが追加および削除される場合があります。 名前、説明、コレクションの頻度、使用可能な列などのデータセット プロパティは変更される可能性があります。

データセット名 テーブル名 収集頻度 (hh:mm:ss) 説明
アクティブなセッション sqldb_database_active_sessions 00:00:30 各行は、要求を実行しているセッション、ブロック、または開いているトランザクションを持つセッションを表します。
バックアップ履歴 sqldb_database_sql_backup_history 00:05:00 各行は、正常に完了したデータベース バックアップを表します。
変更処理 sqldb_database_change_processing 00:01:00 各行は、変更データ キャプチャや変更フィード (Azure Synapse Link) などの変更処理機能の集計ログ スキャン統計のスナップショットを表します。
変更処理エラー sqldb_database_change_processing_errors 00:01:00 各行は、変更データ キャプチャや変更フィード (Azure Synapse Link) などの変更処理機能を使用するときに、変更処理中に発生したエラーを表します。
接続 sqldb_database_connectivity 00:00:30 各行は、データベースの接続プローブ (ログインとクエリ) を表します。
geo レプリカ sqldb_database_geo_replicas 00:00:30 各行は、geo レプリケーション メタデータや統計を含むプライマリまたはセカンダリの geo レプリカを表します。
インデックス メタデータ sqldb_database_index_metadata 00:30:00 各行は、インデックス パーティションを表し、インデックスの定義、プロパティ、および操作の統計情報が含まれます。
メモリ使用率 sqldb_database_memory_utilization 00:00:10 各行はメモリ クラークを表し、データベース エンジン インスタンスのクラークによるメモリ消費量が含まれます。
欠落したインデックス sqldb_database_missing_indexes 00:15:00 各行は、作成された場合にクエリのパフォーマンスを向上させる可能性があるインデックスを表します。
メモリ不足のイベント sqldb_database_oom_events 00:01:00 各行は、データベース エンジンのメモリ不足イベントを表します。
パフォーマンス カウンター (共通) sqldb_database_performance_counters_common 00:00:10 各行は、データベース エンジン インスタンスのパフォーマンス カウンターを表します。 このデータセットには、一般的に使用されるカウンターが含まれています。
パフォーマンス カウンター (詳細) sqldb_database_performance_counters_detailed 00:01:00 各行は、データベース エンジン インスタンスのパフォーマンス カウンターを表します。 このデータセットには、詳細な監視とトラブルシューティングに必要なカウンターが含まれています。
プロパティ sqldb_database_properties 00:05:00 各行はデータベースを表し、データベース オプション、リソース ガバナンスの制限、およびその他のデータベース メタデータが含まれます。
クエリのランタイム統計 sqldb_database_query_runtime_stats 00:15:00 各行は、クエリ ストア ランタイム間隔を表し、クエリ実行統計が含まれます。
クエリ待機統計 sqldb_database_query_wait_stats 00:15:00 各行は、クエリ ストア ランタイム間隔を表し、待機カテゴリの統計を含みます。
レプリカ sqldb_database_replicas 00:00:10 各行は、レプリケーションメタデータや統計を含むデータベースレプリカを表します。 プライマリで収集された場合はプライマリ レプリカと geo レプリカ、セカンダリで収集された場合はセカンダリ レプリカが含まれます。
リソース使用率 sqldb_database_resource_utilization 00:00:15 各行は、データベースの CPU、データ IO、ログ IO、およびその他のリソース消費統計を期間で表します。
セッション統計 sqldb_database_session_stats 00:01:00 各行は、データベースのセッション統計の概要を表し、ログイン名、ホスト名、アプリケーション名などの非追加セッション属性によって集計されます。
SOS スケジューラ sqldb_database_sos_schedulers 00:01:00 各行は SOS スケジューラを表し、スケジューラ、CPU ノード、メモリ ノードの統計情報が含まれます。
ストレージ IO sqldb_database_storage_io 00:00:10 各行はデータベース ファイルを表し、ファイルの累積 IOPS、スループット、待機時間の統計情報が含まれます。
ストレージの使用 sqldb_database_storage_utilization 00:01:00 各行はデータベースを表し、tempdb、クエリ ストア、永続化バージョン ストアなどのストレージ使用状況が含まれます。
テーブル メタデータ sqldb_database_table_metadata 00:30:00 各行はテーブルまたはインデックス付きビューを表し、行数、領域使用量、データ圧縮、列、制約などのメタデータが含まれます。
待機統計 sqldb_database_wait_stats 00:00:10 各行は待機の種類を表し、データベース エンジン インスタンスの累積待機統計が含まれます。 エラスティック プール内のデータベースの場合、データベース スコープの待機統計のみが収集されます。

Note

エラスティック プール内のデータベースの場合、プール レベルのデータを含む SQL Database データセットは収集されません。 これには、メモリ使用率、メモリ不足イベント、パフォーマンス カウンター (共通)、パフォーマンス カウンター (詳細) データセットが含まれます。 待機統計データセットは収集されますが、データベース スコープの待機のみが含まれます。 これにより、プール内のすべてのデータベースから同じデータを収集できなくなります。

プール レベルのデータは、SQL エラスティック プール データセットで収集されます。 特定のエラスティック プールの場合、パフォーマンス カウンター (共通) とパフォーマンス カウンター (詳細) データセットには、プール レベルのメトリックと、CPU、データ IO、ログ書き込み、要求、トランザクションなどの特定のデータベース レベルのメトリックが含まれます。

共通列

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

列名 説明
sample_time_utc 行の値が観察された時刻 (UTC)。
collection_time_utc Watcher によって行が収集された時刻 (UTC)。 この列は、収集時間がサンプル時間と異なる可能性があるデータセットに存在します。
replica_type 次のうちの 1 つ: プライマリ、HA セカンダリ、geo レプリケーション フォワーダー、名前付きセカンダリ。
logical_server_name 監視対象のデータベースまたはエラスティック プールを含む Azure SQL データベース内の論理サーバーの名前。
database_name 監視対象のデータベースの名前。
database_id 論理サーバー内で一意である監視対象のデータベースの データベース ID。
logical_database_id ユーザー データベースの有効期間中に変更されない一意のデータベース識別子。 データベースの名前を変更したり、サービス目標を変更したりすると、この値は変更されません。
physical_database_id ユーザー データベースに対応する現在の物理データベースの一意のデータベース識別子。 データベース サービス目標を変更すると、この値が変更されます。
replica_id Hyperscale コンピューティング レプリカの一意識別子。

データセットには、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 値があります。

関連するコンテンツ