スキーマは、データモデルのパフォーマンス、使用状況、変更を監視するのに役立ち、問題の特定と修正を迅速化します。
スキーマトラッキングは、PostgreSQL、SQL Server、および MySQL で利用可能です。
構成
スキーマ機能を有効にするには、 Database Monitoring 構成に collect_schemas パラメータを追加します。
init_config:
instances:
- dbm: true
host: localhost
port: 5432
username: datadog
password: 'ENC[datadog_user_database_password]'
collect_schemas:
enabled: true
## Optional: Connect to a different database if needed for `custom_queries`
# dbname: '<DB_NAME>'
スキーマ収集の調整
利用可能な collect_schemas オプションとそのデフォルト値は、データベースエンジンによって異なります。
| オプション | デフォルト | 説明 |
|---|
enabled | true | スキーマ収集を無効にするには false に設定します。Datadog Agent バージョン 7.80.0 以降でデフォルトで有効になっています。 |
max_tables | 300 | Agent がインスタンスから収集するテーブルの最大数。この制限を超えるテーブルは収集されません。 |
max_columns | 50 | テーブルごとに Agent が収集する列の最大数。 |
max_query_duration | 60 | スキーマ情報を収集するクエリの最大実行時間 (秒)。 |
collection_interval | 600 | スキーマ収集の実行間隔 (秒)。 |
collect_schemas:
enabled: true
max_tables: 1000
パーティションが PostgreSQL の max_tables の制限にカウントされるかどうかは、パーティション分割方法によって異なります。宣言的パーティショニング (PARTITION BY、PostgreSQL 10 以降) はパーティション数に関係なくテーブルを 1 つとしてカウントしますが、継承パーティショニング (INHERITS、PostgreSQL 9.6 での唯一のオプション) は親テーブルと各子テーブルを個別にカウントします。つまり、継承パーティショニングされたデータベースでは、予想よりもはるかに少ない論理テーブル数でデフォルトの制限である 300 に達し、他のテーブルを圧迫する可能性があります。スキーマページにテーブルが表示されない場合は、継承パーティショニングを確認し、それに応じて max_tables を引き上げてください。
max_tables を引き上げると、各収集実行のコストが増加します。テーブル数が多いインスタンスでは、データベースへの負荷を軽減するために max_query_duration と collection_interval を引き上げることも検討してください。
| オプション | デフォルト | 説明 |
|---|
enabled | false | スキーマ収集を有効にするには true に設定します。 |
max_tables | 300 | Agent がインスタンスから収集するテーブルの最大数。この制限を超えるテーブルは収集されません。 |
collection_interval | 600 | スキーマ収集の実行間隔 (秒)。 |
collect_schemas:
enabled: true
max_tables: 1000
| オプション | デフォルト | 説明 |
|---|
enabled | false | スキーマ収集を有効にするには true に設定します。 |
collection_interval | 600 | スキーマ収集の実行間隔 (秒)。 |
max_execution_time | 60 | スキーマ情報を収集するクエリの最大実行時間 (秒)。 |
collect_schemas:
enabled: true
collection_interval: 300
テーブルの概要
テーブルの概要には、データベース全体で追跡されているすべてのテーブルがテーブル名ごとにグループ化され、以下の列が表示されます。
| 列 | 説明 |
|---|
| バリアント数 | すべてのホストにおけるテーブルの異なるバージョン数。 |
| インスタンス数 | すべてのホストにおけるテーブルインスタンスの合計数。たとえば、あるテーブルに 7 つのインスタンスを持つバリアントと 8 つのインスタンスを持つバリアントがある場合、インスタンスの合計数は 15 になります。 |
| 列数 | すべてのホスト上のテーブルのすべてのバリアントにわたる一意の列数。たとえば、あるバリアントに列 A、B、C があり、別のバリアントに A、B、D がある場合、一意の列の合計は 4 つ (A、B、C、D) になります。 |
| データベース | すべてのホストにおいて、このテーブルを含むすべてのデータベース名。 |
| スキーマ | すべてのホストでこのテーブルが存在するスキーマ。 |
| データベースホスト | このテーブルが存在するホスト。 |
各テーブル行を展開すると、そのテーブルのバリアントと以下の列を確認できます。
| 列 | 説明 |
|---|
| バリアント ID | このテーブルのバリアント (バージョン) の一意の識別子。 |
| インスタンス数 | このバリアントにおけるこのテーブルのインスタンス数。 |
| 列数 | このテーブルのバリアント内の一意の列数。 |
| データベース | このテーブルのバリアントを含むデータベースのアルファベット順の一覧。 |
| スキーマ | このテーブルのバリアントを含むスキーマのアルファベット順の一覧。 |
| データベースホスト | このテーブルのバリアントが存在するホストのアルファベット順の一覧。 |
テーブルのバリアントの詳細を確認
テーブルのバリアントの詳細を確認するには、その行をクリックしてテーブルのバリアントパネルを開きます。
このパネルには、以下のようなバリアント (バージョン) に関する情報が表示されます。
- Definition: このテーブルのバリアントの列、インデックス、および外部キーが含まれます。
- Table Instances: このテーブルのバリアントに関連付けられたすべてのインスタンス。
- Metrics: テーブルサイズ、シーケンシャルスキャン、およびその他の関連メトリクス (デフォルトでは過去 7 日間)。
- Queries: このテーブルのバリアントに関連するクエリ (デフォルトでは過去 7 日間)。
- Changes: このテーブルのバリアントに影響を与えるスキーマの変更 (デフォルトでは過去 7 日間)。
テーブルインスタンスの詳細を確認
特定のテーブルインスタンスの詳細を確認するには、テーブルのバリアントパネルの Table Instances タブを開き、行をクリックします。
これにより、テーブルのバリアントパネルと同様の表示が開き、選択したテーブルインスタンスに関する以下の情報が表示されます。
- Definition: このテーブルインスタンスの列、インデックス、および外部キーが含まれます。
- Metrics: テーブルサイズ、シーケンシャルスキャン、およびその他の関連メトリクス (デフォルトでは過去 7 日間)。
- Queries: このテーブルインスタンスに関連するクエリ (デフォルトでは過去 7 日間)。
- Changes: このテーブルインスタンスに影響を与えるスキーマの変更 (デフォルトでは過去 7 日間)。
推奨事項
推奨事項では、テーブル全体のスキーマを最適化するための潜在的な機会を確認できます。
各推奨事項には以下が含まれます。
- 主キーの欠落や非効率なインデックスなど、検出された問題。
- その問題が重要である理由と、データベースのパフォーマンスや整合性に与える影響の説明。
- 推奨される修正案。多くの場合、影響を受けるデータベースで実行できる SQL ステートメントです。
推奨事項は、集計 (ページ上部) およびテーブルごとに利用でき、該当する各テーブルに対応する推奨事項が表示されます。詳細については、推奨事項を参照してください。
メトリクスの概要
メトリクスの概要では、各 DBMS で追跡されているテーブルに関連するメトリクスのダッシュボードが表示されます。
各ダッシュボードには、以下のメトリクスが含まれます。
- テーブルインスタンスの合計数
- 変更頻度が最も高いインスタンス (%)
- 変更量が最も多いインスタンス (バイト)
- アクセス数が最も多いインスタンス
- 最大のインスタンス
- ライブ行数が最も多いインスタンス
- インデックスサイズが最も大きいインスタンス
- アクセス排他ロックがあるインスタンス
- デッド行数が最も多いインスタンス
- 前回のバキュームからの経過時間が最も長いインスタンス
- 前回の自動バキュームからの経過時間が最も長いインスタンス
