New Relic Database 360 で Oracle Autonomous Database を監視してみた

Posted at 2026-09-16

1. はじめに

New Relic の Database 360 は、データベースの遅いクエリや待機イベント、セッションの状態を New Relic 上で追える機能です。New Relic 石橋さんの記事¹ で Oracle Database に対応したことを知り、公式ドキュメントを見ると Oracle Database monitoring with NRDOT のページに「For ADB」というタブがありました²。Oracle Autonomous Database（以下 ADB）向けの手順で、2026 年 8 月 17〜21 日の週のドキュメント更新で追加されたものです³。

ADB はデフォルトで mTLS（相互 TLS。クライアント側にも証明書が必要な方式）が必須で、接続にはウォレットと呼ばれる証明書一式を使います。一方、公式の ADB 向け手順の接続文字列は通常の TLS を前提にしていて、ADB 側でどのような設定変更が必要なのかは書かれていません。そこで、Always Free の ADB を公式の手順どおり通常の TLS で New Relic に接続し、何が見えるかを実際に試してみます。ADB 側の設定を変えられない場合のウォレットでの接続は付録（8 章）にまとめました。

1.1. 結論（先出し）

公式の接続文字列で接続するために ADB 側で変えるのは、ACL の登録と mTLS 必須の解除の 2 つ。これでウォレット無しの通常の TLS で接続できた。監視ユーザーのパスワードは英数字だけにする
Overview の CPU 使用率など 5 枚のパネルは空のままで、公式ドキュメントの「ADB では取れないメトリクス」一覧に含まれる。一覧に無いのに 0 のままのパネルも 2 枚ある
遅い SQL の一覧、実行計画の図、セッション、待機イベント、DB ユーザー別の集計は ADB でも表示された
Top SQL には監視ユーザー NR_MONITOR が実行する SQL（以下、監視 SQL）が並ぶ。Always Free の 1 Oracle CPU では監視 SQL の P95 が 11〜15 秒あった

1.2. 検証ゴール

#	確かめること	確認できれば OK の条件
1	公式手順どおり通常の TLS で NRDOT Collector が ADB に接続できる（ADB 側に必要な設定を含めて）	Collector が ADB のバージョンと PDB を認識し、New Relic に Oracle のエンティティが現れる
2	Database 360 の各画面で ADB の何が見えて何が見えないか	負荷をかけた状態で各画面を開き、空のパネルが公式の非対応メトリクス一覧で説明できる
3	監視そのものが DB にどれだけ負荷をかけるか	監視ユーザーが実行する SQL の実行時間が、Query performance と Clients の画面に数値で出る

2. 検証環境

項目	値
監視対象	Oracle Autonomous Database Serverless（Always Free、Autonomous Transaction Processing）
DB バージョン	Oracle AI Database 26ai（Collector からは 23.0.0.0.0 と見える）
構成	Always Free のインスタンス（ap-tokyo-1）
Collector	NRDOT Collector 2.5.0（New Relic Distribution of OpenTelemetry）
Collector のホスト	Windows 11 上の WSL2 Ubuntu 24.04
New Relic	無料アカウント（US リージョン）

ADB はホストにログインできないので、Collector 用のマシンが別に 1 台必要になります。今回は手元の WSL を使いました。本番なら OCI の Compute を VCN 内に置き、プライベートエンドポイントで接続する構成になりそうです（この構成は試していません）。公式の対応環境は Linux の AMD64 と ARM64 ですが²、GitHub Releases には Windows 版のパッケージもあります。Windows 版 2.5.0 を同じ設定ファイルで動かしたところ、ADB への接続と New Relic への送信は Linux 版と同じログで成功しました（前面プロセスとして 150 秒動かして確認。Windows サービスとしての常時稼働は試していません）。

今回の構成を図 1 に示します。左が監視対象の ADB、中央が Collector を動かす手元の PC、右が New Relic です。Collector が ADB に TLS で接続して V$ ビューを 10 秒ごとに読み、その結果を New Relic の OTLP エンドポイントへ送ります。

図 1: 構成図（WSL 上の Collector が ADB へ TLS で接続し、New Relic の OTLP エンドポイントへ送る）

3. 構成・実装

3.1. 公式手順と今回の差分

公式の ADB タブ² の手順は 4 つあります。

Linux に NRDOT Collector をインストールする
ADB にローカルの監視ユーザーを作り、V$ ビューと DBA_ ビューに SELECT 権限を付ける
adb-config.yaml を作り、nroracledb/adb レシーバーに接続文字列と取得するメトリクスを書く
Collector を再起動する

公式手順と違うのは、公式の接続文字列で接続するために ADB 側のネットワーク設定を 2 か所変えたこと（3.2 章）と、パスワードと License key を設定ファイルに書かず環境変数から読むようにしたこと（3.4 章）です。

3.2. 接続文字列と ADB 側のネットワーク設定

公式の接続文字列は次のとおりです。

oracle://<USERNAME>:<PASSWORD>@<YOUR_DB_HOST>:<YOUR_DB_PORT>/<YOUR_SERVICE_NAME>?ssl=true&ssl%20verify=true

ssl=true は TLS を使う指定で、クライアント証明書の指定はありません。ADB Serverless はデフォルトで mTLS 必須（1 章）なので、この文字列のままでは接続が拒否されます。

この文字列で接続するには、ADB 側で ACL（アクセス制御リスト）へ Collector のグローバル IP を登録し、相互 TLS 認証の「必要」設定を解除します。Oracle の公式ドキュメントによれば、TLS 接続を許可する条件は ACL かプライベートエンドポイントのどちらかで、パブリックエンドポイントなら ACL が必須です⁴。OCI コンソールでは、ADB の詳細画面の「ネットワーク」で操作します。アクセス制御リストの編集では「自分の IP アドレスを追加」で今の接続元を登録できます。相互 TLS 認証の編集では「必要」のチェックを外します。OCI CLI で行う場合は次のように 2 回に分けます。--whitelisted-ips と --is-mtls-connection-required を 1 回の update に同時に指定すると InvalidParameter で拒否されました。所要時間はそれぞれ 20〜30 秒でした。

# 1 回目: ACL を登録（既存の ACL は置き換わる）
oci db autonomous-database update --autonomous-database-id <ADB の OCID> \
  --whitelisted-ips '["<Collector のグローバル IP>/32"]' --force --wait-for-state AVAILABLE
# 2 回目: mTLS を不要にする
oci db autonomous-database update --autonomous-database-id <ADB の OCID> \
  --is-mtls-connection-required false --force --wait-for-state AVAILABLE

変更後は OCI コンソールの「データベース接続」一覧に tls-authentication を SERVER とするプロファイルが追加されます（MUTUAL のプロファイルも残るため、ウォレットでの接続も引き続き可能です）。

この接続文字列は go-ora という純 Go 製の Oracle ドライバの書式です⁵。NRDOT の Oracle レシーバーは go-ora を使っているので、Oracle Instant Client のインストールは不要です。監視用のホストに Oracle のクライアントライブラリをインストールせずに済むのは運用上の利点で、その代わり接続オプションは go-ora が受け付けるものに限られます。今回使った接続文字列は次のとおりです。パスワードは環境変数から渡しています（3.4 章）。

oracle://NR_MONITOR:${env:NR_MONITOR_PASSWORD_URLENC}@adb.ap-tokyo-1.oraclecloud.com:1522/g4256714d933780_adbtest01_low.adb.oraclecloud.com?ssl=true&ssl%20verify=true

ホスト名・ポート・サービス名は、OCI コンソールの「データベース接続」に表示される TLS 用の接続文字列の値をそのまま使います。ssl verify=true でサーバー証明書を検証する指定にしていて、ADB のパブリックエンドポイントの証明書は Collector ホストの CA ストアで検証できました。

3.3. 監視ユーザーと権限

ADB では SYS でログインできないので、公式手順の「Run as SYS」は ADMIN ユーザーで読み替えます。ユーザー作成と権限付与は公式手順のとおりで、V$ 系 17 本と DBA_ 系 7 本のビューに SELECT 権限を付けます。

-- ADMIN で実行。パスワードは英数字だけにする
CREATE USER NR_MONITOR IDENTIFIED BY "<パスワード>";
GRANT CREATE SESSION TO NR_MONITOR;

GRANT SELECT ON SYS.V_$INSTANCE   TO NR_MONITOR;
GRANT SELECT ON SYS.V_$DATABASE   TO NR_MONITOR;
GRANT SELECT ON SYS.V_$CONTAINERS TO NR_MONITOR;
GRANT SELECT ON SYS.V_$DATAFILE   TO NR_MONITOR;
GRANT SELECT ON SYS.V_$PDBS       TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SYSSTAT                    TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SYSMETRIC                  TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SESSION                    TO NR_MONITOR;
GRANT SELECT ON SYS.V_$RESOURCE_LIMIT             TO NR_MONITOR;
GRANT SELECT ON SYS.V_$OSSTAT                     TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SGAINFO                    TO NR_MONITOR;
GRANT SELECT ON SYS.V_$ROWCACHE                   TO NR_MONITOR;
GRANT SELECT ON SYS.V_$PARAMETER                  TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_TABLESPACE_USAGE_METRICS  TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_TABLESPACES               TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_DATA_FILES                TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_FREE_SPACE                TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_RECYCLEBIN                TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SQL            TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SQL_PLAN_STATISTICS_ALL       TO NR_MONITOR;
GRANT SELECT ON SYS.V_$LOCK           TO NR_MONITOR;
GRANT SELECT ON SYS.V_$SESSION_EVENT  TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_PROCEDURES    TO NR_MONITOR;
GRANT SELECT ON SYS.DBA_OBJECTS       TO NR_MONITOR;

Always Free の ADB でもこの 24 本はすべて ADMIN から付与できました。監視ユーザーのパスワードは英数字だけにします。記号を含むパスワードでは、URL エンコードして接続文字列に入れても認証に失敗し、ADB 側でアカウントがロックされました。

3.4. パスワードと License key を設定ファイルに書かない

公式の adb-config.yaml はパスワードと License key を平文で書きます。Collector は systemd のサービスとして動くので、systemd の EnvironmentFile で環境変数を渡し、設定ファイルからは ${env:変数名} で参照するようにしました。OpenTelemetry Collector の設定はこの書き方で環境変数を展開します。

# /etc/nrdot-collector/nrdot.env（root:root, 600）
NR_MONITOR_PASSWORD_URLENC=<URL エンコード済みのパスワード>
NEW_RELIC_LICENSE_KEY=<License key>

# /etc/systemd/system/nrdot-collector.service.d/override.conf
[Service]
EnvironmentFile=/etc/nrdot-collector/nrdot.env

adb-config.yaml の該当箇所は次のようになります。レシーバー名を nroracledb/adb にする点と、エクスポーターの種別を otlphttp にする点は公式どおりです。

receivers:
  nroracledb/adb:
    datasource: "oracle://NR_MONITOR:${env:NR_MONITOR_PASSWORD_URLENC}@adb.ap-tokyo-1.oraclecloud.com:1522/g4256714d933780_adbtest01_low.adb.oraclecloud.com?ssl=true&ssl%20verify=true"
    collection_interval: 10s
    events:
      db.server.query_sample:
        enabled: true
      db.server.top_query:
        enabled: true
      db.server.session.wait_sample:
        enabled: true
    top_query_collection:
      max_query_sample_count: 1000
      top_query_count: 200
      collection_interval: 60s
    # （metrics: の一覧は公式の ADB タブのものをそのまま使用）

exporters:
  otlphttp/newrelic:
    endpoint: "https://otlp.nr-data.net"
    headers:
      api-key: "${env:NEW_RELIC_LICENSE_KEY}"
    compression: gzip

service:
  pipelines:
    metrics/oracledb:
      receivers: [nroracledb/adb]
      processors: [resource/add_event_name, batch]
      exporters: [otlphttp/newrelic]
    logs/oracledb:
      receivers: [nroracledb/adb]
      processors: [resource/add_event_name, batch]
      exporters: [otlphttp/newrelic]

なお NRDOT には、AES で暗号化した文字列を ${aes:...} で置く方法と、AWS Secrets Manager から ${secretsmanager:...} で取得する方法も用意されています⁶。OCI Vault はこの一覧にないので、OCI 上で運用するなら環境変数か AES 暗号化のどちらかになります。メトリクスは 10 秒間隔、Top SQL は 60 秒間隔です。events の 3 つは New Relic 側では Log として届き、Query performance や Wait events の画面の元データになります。

4. 手順・実行

4.1. New Relic 側の準備

無料アカウントを作成したあと、必要なのは License key だけです。API keys の画面の「Create a key」で Key type を Ingest - License にして作成し、表示された値を控えます⁷。

公式ドキュメントにはこの機能が Preview であり、Previews & Trials の画面から有効化すると書かれています²。今回の無料アカウントでは Previews & Trials に何も表示されませんでしたが、Integrations & Agents で「Oracle」を検索すると「Oracle (OpenTelemetry)」が出ており、そのまま使えました。

4.2. Collector の導入と起動

導入は公式の 1 行コマンドで、GitHub Releases から最新版の deb パッケージをダウンロードしてインストールします。

NRDOT_VERSION=$(curl -s https://api.github.com/repos/newrelic/nrdot-collector-releases/releases/latest | grep '"tag_name":' | awk -F'"' '{print $4}')
curl -L "https://github.com/newrelic/nrdot-collector-releases/releases/download/${NRDOT_VERSION}/nrdot-collector_${NRDOT_VERSION}_linux_amd64.deb" --output nrdot-collector.deb
sudo dpkg -i nrdot-collector.deb

3.4 章のファイルを置いたら、サービスが読む設定ファイルの指定を adb-config.yaml に変えて再起動します。

sudo sed -i 's|^OTELCOL_OPTIONS=.*|OTELCOL_OPTIONS="--config=/etc/nrdot-collector/adb-config.yaml"|' /etc/nrdot-collector/nrdot-collector.conf
sudo systemctl daemon-reload
sudo systemctl restart nrdot-collector
sudo journalctl -u nrdot-collector -n 100 --no-pager

接続に成功すると、ログに次の 2 行が出ます。ADB のバージョンは 23.0.0.0.0 と報告されました。

info  oracledbreceiver: detected Oracle version  {"version": "23.0.0.0.0"}
info  oracledbreceiver: connected to PDB  {"pdb_name": "G4256714D933780_ADBTEST01"}

warn レベルで 1 件、CDB_SERVICES が無いという ORA-00942 が出ます。メッセージに "hosting type detection may be inaccurate" とあるとおり、DB がどこにホストされているかを推定する処理で、監視データの取得には影響していません。推定に失敗した結果、New Relic 側の属性 oracle.db.hosting_type は self-managed になります（5.5 章）。

New Relic 側では数分後に Catalogs の Infrastructure タブに Database として 1 件現れます。エンティティ名は adb.ap-tokyo-1.oraclecloud.com:1522 で、接続先のホストとポートがそのまま名前になります。ADB の名前は Database 名の列に G4256714D933780_ADBTEST01（DB の一意名）として出ます。

4.3. 負荷のかけ方

各画面にデータを出すために、SCOTT スキーマの索引なしテーブル LOAD_TEST_NOIDX（50 万行、ID・NAME・SCORE の 3 列）に対して SELECT だけの負荷をかけました。ADB の結果キャッシュで 2 回目以降が速くなりすぎないよう、すべての SQL に NO_RESULT_CACHE ヒントを付け、バインド変数の値を毎回変えています。

役割	SQL	1 回の所要時間（中央値）
全表走査の集計	`COUNT(*), MIN(score), MAX(score) ... WHERE name LIKE :b`	1.8 秒
自己結合	`t a JOIN t b ON a.id = b.id WHERE a.score BETWEEN :lo AND :hi`	0.06 秒
並べ替えて上位 100 件	`... WHERE score >= :s ORDER BY name, id FETCH FIRST 100 ROWS ONLY`	1.0 秒
GROUP BY 集計	`MOD(id, :m), COUNT(*), AVG(score), MAX(name) ... GROUP BY MOD(id, :m)`	8.7 秒
遅い 3 重自己結合	`t a JOIN t b ON a.score = b.score JOIN t c ON b.score = c.score WHERE a.id BETWEEN :lo AND :hi`	33.7 秒

上の 4 種を 3 スレッドで順に繰り返し、遅い結合は別スレッドで繰り返します。確認前の 5 分間で合計 319 回実行し、エラーはありませんでした（表の所要時間はこの 5 分間の値）。

5. 実行結果

5.1. Overview

図 2: Overview。Active Session Count は描画され、Database CPU Utilization % など 6 枚は 0 か空

Active Session Count には負荷中のセッション数が出ています。一方で Database CPU Time、SQL Execution Rate、Database CPU Utilization %、Host CPU Utilization %、SQL Execution Efficiency %、Database Wait Time % の 6 枚は 0 か空のままです。図 2 の下にある SQL Service Response Time も空でした。合わせて 7 枚あり、6.1 章で公式の一覧と突き合わせます。

5.2. Query performance

図 3: Query performance。Normalized queries の一覧に負荷 SQL と Collector 自体の SQL が並ぶ

Avg duration の降順で並べると、上位 10 件のうち 9 件が Collector 自体の SQL で、負荷側の SQL は 1 件だけです。V$SQL から SQL ID で本文を取得する問い合わせが 18.4 秒、V$SQL_PLAN_STATISTICS_ALL から実行計画を取得する問い合わせが 9.4 秒かかっています。負荷側の GROUP BY 集計（044fty3mvpj1q）は 152 回で平均 15.2 秒でした。4.3 章の表はクライアント側で測った 5 分間の中央値で、ここは New Relic が集計した 30 分間の平均なので値は一致しません。

SQL ID をクリックすると Query details が開き、実行回数と所要時間の推移、そして Plans タブに実行計画が出ます。

図 4: Query details。集計値の下に Plans (1 observed) として plan hash が出る

図 5: 実行計画の図。SELECT STATEMENT → SORT GROUP BY → TABLE ACCESS FULL に NO INDEX の印

実行計画は plan hash ごとに木として描画され、各ノードにコストと見積もり行数が付きます。全表走査のノードには「NO INDEX」の印が付いていました。V$SQL_PLAN_STATISTICS_ALL への SELECT 権限を付けているので、ADB でも実行計画は取れています。

5.3. Sessions と Wait events

図 6: Sessions。58 セッション、平均 1 分 55 秒、Blocked セッション 3

Sessions にはセッション ID・DB ユーザー・ログオン時刻・Blocked 回数が並びます。Blocked count が 2〜4 の行は負荷スクリプトの長時間接続セッションで、3 重自己結合がパラレル実行された際の待ちをカウントしていると推測されます（Blocked の内訳までは追っていません）。APM の列は今回アプリケーション側の計装をしていないのですべて Uninstrumented です。

図 7: Wait events。待機時間の 85.63% が resmgr:cpu quantum

Wait events では、30 分間の待機時間 1 時間 7 分のうち 85.63% が resmgr:cpu quantum でした。これは Oracle のリソースマネージャが CPU の割り当て待ちにしている時間で、Always Free の 1 Oracle CPU で 4 スレッドの全表走査を実行したので、CPU が足りない分がそのまま待機として見えています。残りは db file sequential read が 10.11%、control file sequential read が 4.26% です。Queries waiting の表には待機中の SQL とセッションが並びます。

5.4. Clients

図 8: Clients。DB ユーザー別の実行回数と P95 の推移と、Connected DB users の表

Clients は接続元をまとめた画面で、今回は DB ユーザー単位で 3 行になりました。確認時点の値を表にします。

DB user	Active sessions	Blocked sessions	Execution count	P95 query duration
SCOTT（負荷）	36	3	19	30 秒
NR_MONITOR（監視）	1	0	55	11.06 秒
ADMIN	1	0	1	1 秒

監視ユーザー NR_MONITOR の実行回数が負荷側より多く、P95 が 11 秒あります。負荷を始めた直後の時点では同じ画面で 15.06 秒でした。

5.5. Diagnose

図 9: Diagnose の Golden signals。実行回数・セッション数・デッドロック・論理読み取りなど 7 つの推移

Diagnose は直前の期間と比べて変化を探す画面です。上段の Golden signals には実行回数やセッション数、論理読み取りの推移が並びます。その下の Workload change には、直前 30 分と比べて変化のあった属性が並びます。

図 10: Diagnose の Workload change。16 の属性の変化率と、oracle.db.hosting_type が self-managed になっている

確認時点では 16 個の属性が挙がりましたが、変化率はいずれも 3% 以内でした。負荷を始めた直後に見たときは「No event attribute deviations found」でした。比較対象の期間にも同じ負荷をかけていたためです。この画面で確認できるのは oracle.db.hosting_type が self-managed になっている点で、4.2 章の CDB_SERVICES の警告のとおり、ホスティング種別の推定が ADB では実際と合っていません。

6. 考察

6.1. 空のパネル 7 枚のうち 5 枚は公式の非対応一覧にある

Oracle Database monitoring with NRDOT の ADB タブには「The following metrics are not supported in ADB」として 23 個のメトリクスが列挙されています²。5.1 章で空だったパネルを、その一覧と突き合わせます。

空か 0 だったパネル	対応するメトリクス	非対応一覧に
Database CPU Utilization %	`oracledb.database.cpu.utilization`	ある
Host CPU Utilization %	`oracledb.host.cpu.utilization`	ある
Database Wait Time %	`oracledb.database.wait.utilization`	ある
SQL Execution Efficiency %	`oracledb.execution.utilization`	ある
SQL Service Response Time	`oracledb.sql_service.response.duration`	ある

7 枚のうち 5 枚は一覧にあり、公式の記述で説明が付きます。一覧にはほかに processes / sessions / transactions の limit と usage、buffer cache や shared pool の使用率も含まれます。これらは V$OSSTAT や V$RESOURCE_LIMIT のようにインスタンス全体の値を返すビューを元にしており、ADB Serverless では共有インフラの値が公開されていないためと見られます。ADB のリソース使用状況は OCI コンソールのメトリクスから確認できるため、Database 360 は SQL やセッションの監視用途に向いています。

残る 2 枚、Database CPU Time と SQL Execution Rate は一覧に無いのに 0 のままでした。元になる oracledb.cpu_time と oracledb.executions の取得は有効にしているため、パネル側の集計処理に問題があるか、取得自体は成功しても値が 0 で返されているかのどちらかと思われます（未確認）。

6.2. 監視そのものの負荷

5.2 章と 5.4 章のとおり、監視 SQL は Top SQL の上位 10 件のうち 9 件を占め、P95 は 11〜15 秒でした。V$SQL_PLAN_STATISTICS_ALL から実行計画を取得する問い合わせは 1 回あたり 9 秒前後かかっています。

公式の設定例では Collector は Top SQL を 60 秒ごとに最大 200 件取得し、それぞれの実行計画を V$SQL_PLAN_STATISTICS_ALL から取得します²。top_query_count と collection_interval は設定で変えられます。

1 Oracle CPU の Always Free では監視 SQL 自体も CPU 割り当て待ちとなっており、5.3 章の resmgr:cpu quantum にも監視 SQL の分が含まれていると推測されます。本番の ADB では CPU コア数が多いため同じ比率にはならないはずですが、Top SQL の取得件数や間隔は公式の設定例（200 件・60 秒）をそのまま使わず、必要最小限に絞るのが安全です。

6.3. エンティティ名がホストとポートになる

4.2 章のとおり、エンティティ名は接続先のホストとポートになり、ADB の名前は Database 名の列にしか出ません。

OCI コンソールの「データベース接続」に並ぶ 5 つの接続文字列は、ホスト名とポートが共通で、サービス名だけが違いました。同じリージョンに複数の ADB が存在し、Collector を分けて接続した場合は、エンティティ名が重複して判別しづらくなりそうです。今回は 1 インスタンスのため未検証ですが、公式の Multi-receiver configuration の手順² にレシーバー名を分ける方法があるため、複数台を監視する際はこちらの手順を適用します。

6.4. Preview の扱い

公式ドキュメントには、Preview のため Previews & Trials から有効化すると書かれています²。4.1 章のとおり今回は有効化の操作を行わずに利用できました。有効化が求められる具体的な条件は不明なため、統合が見当たらない場合は Previews & Trials の画面を確認してみてください。

6.5. New Relic に何が送られるか

監視を入れると DB の中身がどこまで外に出るのかは、DBA が先に確認する点です。New Relic の Logs 画面で届いたイベントを 1 件ずつ開いて属性を確認しました。Collector が ADB に対して実行するのは V$ ビューと DBA_ ビューへの SELECT だけなので、監視対象の表のデータや SQL の実行結果が送られることはありません。送られるのは次の 3 種類のイベントです。

イベント	主な属性
Top SQL（`db.server.top_query`）	SQL 本文（リテラルを `?` に置き換えたもの）、SQL ID、plan hash、実行回数、CPU 時間、論理読み取り、実行計画の各ステップ
実行中の SQL のサンプル（`db.server.query_sample`）	SQL 本文（同上）、DB ユーザー名、OS ユーザー名、接続元のマシン名、プログラム名、セッション ID、待機イベント、ブロック元の情報
セッションの待機（`db.server.session.wait_sample`）	セッション ID、待機イベント名、待機クラス、回数と時間

SQL 本文は文字列と数値のリテラルが ? に置き換わり、バインド変数は :s のように名前だけが残ります。実例では WHERE parsing_schema_name='SCOTT' と書いた SQL が parsing_schema_name=? になっていました。ヒントを含むコメントも ? になります（設定の allowed_comment_keys に挙げたキーだけが残ります）。

ただし実行計画は別です。Top SQL のイベントに付く実行計画（oracledb.query_plan）には、V$SQL_PLAN_STATISTICS_ALL のアクセス述語とフィルタ述語がそのまま入っていて、同じ SQL のフィルタ述語は "KGLOBTS4"='SCOTT' でした。本文では伏せた 'SCOTT' が、述語には残っています。FETCH FIRST 10 ROWS ONLY の 10 も、本文では ?、述語では ROWNUM<=10 でした。バインド変数で書いた SQL の述語は "SCORE">=:S のように変数名のままなので、値は出ません。SQL にリテラルを直接埋め込む運用（個人情報を WHERE 句に直接記述するアプリケーションなど）では、その値が New Relic 側に送信される前提で設定を検討する必要があります。また、実行計画の投影（PROJECTION）には列名とデータ型も含まれます。

接続元のマシン名（client.address）は V$SESSION の MACHINE に相当し、今回は Collector を動かした PC の名前でした。アプリケーションのセッションが対象になれば、アプリサーバーのホスト名がそのまま送られます。

7. まとめ

確かめたこと	結果
公式の接続文字列での接続	ADB 側で ACL の登録と mTLS 必須の解除の 2 つを変えれば、そのまま通常の TLS で接続できた
見えるもの	遅い SQL の一覧、実行計画の図、セッション、待機イベント、DB ユーザー別の集計
見えないもの	CPU 使用率・待機率・応答時間など 5 枚のパネル（公式の非対応一覧 23 個に含まれる）と、一覧に無いのに 0 の 2 枚
監視の負荷	監視 SQL が Top SQL に並ぶ。Always Free の 1 Oracle CPU では P95 が 11〜15 秒
New Relic に送られるもの	SQL 本文（リテラルは `?`）、実行計画、セッション情報。表のデータと SQL の結果は送られない。実行計画の述語にはリテラルが残る

ADB 側で必要な変更は表の 1 行目に挙げた 2 点で、これに加えて監視ユーザーのパスワードを英数字のみにしておきます（3.3 章）。収集できないメトリクスは 2 枚を除き公式の一覧どおりなので、CPU 使用率は OCI 側で確認すると割り切れば、Database 360 で SQL や待機イベントを追う運用は ADB でも十分成り立ちます。

8. 付録: ウォレットで接続する場合（ADB 側を変えないとき）

ADB のネットワーク設定を変えられない場合は、mTLS 必須のまま Collector 側にウォレットを置いて接続します。go-ora の接続文字列には wallet というパラメータがあり、ディレクトリを指定すると中の cwallet.sso を読んで mTLS で接続します⁵。ウォレット自体のパスワードを渡すパラメータは、今回使った go-ora のバージョン（NRDOT 2.5.0 同梱、2026 年 9 月時点）にはありません（自動ログイン用の cwallet.sso を使うためです）。3.2 章の設定を変える前にこの方法でも接続できることを確かめました。接続文字列は次のとおりです。

oracle://NR_MONITOR:${env:NR_MONITOR_PASSWORD_URLENC}@adb.ap-tokyo-1.oraclecloud.com:1522/g4256714d933780_adbtest01_low.adb.oraclecloud.com?ssl=true&ssl%20verify=false&wallet=/etc/nrdot-collector/wallet

ssl verify=false はサーバー証明書の検証を go-ora 側で行わない指定です。ウォレットではこの指定で接続を確かめており、ssl verify=true との組み合わせは試していません。ウォレットは OCI コンソールの ADB 詳細画面から「データベース接続」でダウンロードした zip を展開し、Collector の実行ユーザーだけが読める場所に置きます。

# ウォレットを Collector 専用の場所へ置く（サービスの実行ユーザーは nrdot-collector）
sudo mkdir -p /etc/nrdot-collector/wallet
sudo cp Wallet_adbtest01/{cwallet.sso,ewallet.p12,ewallet.pem,tnsnames.ora,sqlnet.ora} /etc/nrdot-collector/wallet/
sudo chown -R nrdot-collector:nrdot-collector /etc/nrdot-collector/wallet
sudo chmod 700 /etc/nrdot-collector/wallet
sudo find /etc/nrdot-collector/wallet -type f -exec chmod 600 {} \;

実際に読み込まれるのは cwallet.sso のみですが、他のファイルも同じ場所に置いておくと、接続文字列を書くときに tnsnames.ora を手元ですぐ参照できて便利です。

参考

New Relic Database 360 の Oracle 対応を紹介した記事（New Relic 石橋さんの Qiita 記事） ↩
Oracle Database monitoring with NRDOT（New Relic 公式ドキュメント。「For ADB」タブに ADB 向けの手順、監視ユーザーの権限、adb-config.yaml の全文、ADB で非対応のメトリクス 23 個の一覧がある） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
New Relic ドキュメントの更新履歴 2026 年 8 月 17 日〜21 日（Oracle Database monitoring with NRDOT に ADB 向けの手順が追加された週） ↩
Update Network Options to Allow TLS or Require Only Mutual TLS (mTLS) Authentication on Autonomous AI Database（Oracle 公式ドキュメント。TLS 接続を許可するには ACL かプライベートエンドポイントが必要） ↩
go-ora の接続文字列パラメータ（純 Go 製 Oracle ドライバ。wallet パラメータの実装は connection_string.go） ↩ ↩²
Set up database service identification（New Relic 公式ドキュメントの Secret management 節。AES 暗号化と AWS Secrets Manager の 2 方式と設定例） ↩
New Relic API keys（ingest 用の License key と User key の違い） ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up