1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@asahide
in

Select AI Agent の実行は New Relic と Datadog でどう見えるか試してみた

1
Posted at

1. はじめに

これまでに、Oracle Autonomous Database（以下 ADB）を New Relic の Database 3601 と Datadog の Database Monitoring（以下 DBM）2 で監視する記事を書きました。どちらも「普段の SQL が外からどう見えるか」までを確かめた記事です。その前には、Select AI Agent のチームを DBMS_CLOUD_AI_AGENT.RUN_TEAM で動かしたときに DB の中で何が起きているかを、V$ ビューと SQL トレースで調べました3。そこでは、Agent の実行は呼び出したセッションの中だけで進むことを確かめました。LLM の応答待ちは、TCP Socket (KGAS) という待機イベントとして記録されます。

では、同じ Agent の実行を外の監視 SaaS から見るとどう見えるのでしょうか。LLM の応答待ちは監視画面で何に見えるのか。Agent のツールが実行する SQL は、普段の SQL と同じ画面に並ぶのか。ユーザーが Agent に入力した質問文は、監視 SaaS に送られるのか。今回は、前の 2 本と同じ Always Free の ADB に New Relic と Datadog の両方をつないだまま Select AI Agent を動かし、DB の中の記録と 2 つの SaaS の画面を突き合わせてみます。以下、DB の中で取った記録（V$ ビュー・ASH・SQL トレース）を「中の記録」、監視 SaaS の画面を「外の画面」と書きます。

本文では、2 つの SaaS で同じように見えたことを扱います。SaaS ごとに違って見えた点は、採取の方法や設定がそろっていないため、付録（8 章）にまとめました。

1.1. 結論（先出し）

  • LLM の応答待ちは、両方の SaaS で TCP Socket (KGAS) の待機として、Agent を呼んだ DB ユーザーのセッションに付いて見えた。待機の分類（待機クラス）は Network である
  • Agent のツールは BEGIN :result := ...RUNSQL_FUNC(...) という PL/SQL の呼び出しとして、両方の SaaS で普段の SQL と同じ画面に並んだ
  • バインド変数で渡した質問文は、両方の SaaS で SQL 本文に出なかった
  • トレースでは 5 回あった LLM 呼び出しが、外の画面では run_team を呼ぶ SELECT 1 本の Network 待ちに見えた。回数はトレースで、失敗は Agent の履歴ビューで確かめる必要がある

1.2. 検証ゴール

# 確かめること 確認できれば OK の条件
1 Agent の LLM 応答待ちが、外の監視画面でどう見えるか 両方の SaaS で、Agent を実行した DB ユーザーのセッションに TCP Socket (KGAS) の待機が付いて見える
2 Agent のツールが実行する SQL が、外から見えるか 両方の SaaS で、ツールの PL/SQL 呼び出しが普段の SQL と同じ画面に並ぶ
3 バインド変数で渡した質問文が監視 SaaS に送られるか 両方の SaaS で、SQL 本文に質問文が出るかどうかを言える

2. 検証環境

項目 値
DB Oracle Autonomous Database Serverless（Always Free、1 OCPU）
DB バージョン Oracle AI Database 26ai（23.26.3.3.0）
LLM OCI Generative AI（大阪リージョン）の Llama 3.3 70B。認証はリソース・プリンシパル
Agent のチーム OPS_SUPERVISOR_TEAM（Supervisor Agent の下に NL2SQL のワーカーと統計のワーカー）
クライアント Windows 11 の Python 3.12、python-oracledb 4.0.1（Thin モード）
New Relic Database 360（収集プロセスの NRDOT Collector 2.5.0 を WSL2 の Ubuntu で実行）
Datadog Database Monitoring（収集プロセスの Datadog Agent 7.83.2 を WSL2 の Ubuntu で実行。ASH（Active Session History）から採取する設定）

監視の構成は前の 2 本のままです。NRDOT Collector と Datadog Agent は、どちらも手元の WSL から ADB に TLS で接続しています。接続の手順はそれぞれの記事の 3 章にあります12。2 つの収集プロセスの違いは、付録の 8.1 章にまとめました。以下、単に「Agent」と書いたときは Select AI Agent を指し、Datadog の収集プロセスは「Datadog Agent」と書きます。

チーム OPS_SUPERVISOR_TEAM は、Supervisor Agent の記事で作ったものをそのまま使っています4。Supervisor が質問を受けてワーカーに振り分けます。NL2SQL のワーカーは、自然言語から SQL を作るツール（NL2SQL）で、Top SQL のビュー V_TOP_SQLAREA を読みます。LLM は前の調査記事3の Gemini ではなく Llama 3.3 70B です。そのため所要時間の秒数は前の記事と比べず、回数と構造だけを扱います。

3. 構成・実装

3.1. 中の記録と外の画面を同時に取る

Agent を呼ぶセッションを、以下セッション A と呼びます。図 1 の構成で、セッション A の実行を中の記録と外の画面の両方に残しました。

図 1: 構成図（セッション A が ADB で Agent を実行し、サンプラーと 2 つの収集プロセスが同じ ADB から記録を読む）

図 1: 構成図（セッション A が ADB で Agent を実行し、サンプラーと 2 つの収集プロセスが同じ ADB から記録を読む）

中の記録には、別セッションから V$SESSION と実行中のスケジューラ・ジョブを 1 秒ごとに読んで表に保存するサンプラー、ASH の行、DBMS_USERDIAG で取得した SQL トレース5を使いました。

外の画面は 2 つの SaaS です。New Relic の ADB 向け設定例では、セッションのサンプルが 10 秒ごと、Top SQL が 60 秒ごとに 200 本です6。New Relic のセッションのサンプルは 10 秒刻みなので、16〜125 秒だった今回の実行では 1 回あたり 1〜12 点ほどになります。Datadog は、ASH の 1 秒ごとの行を Datadog Agent が 10 秒ごとにまとめて回収する設定にしています（設定は Datadog の記事の 3.4 章、説明は 5.2 章2）。バインド渡しの 3 回は、SaaS の画面で回が混ざらないように、回と回の間を 45 秒空けました。

3.2. 自分の実行を見分ける目印

監視画面には、監視ツール自身の SQL や ADB の内部の SQL も並びます。自分が実行した Agent を見分けるために、セッション A に module・action・client_identifier を付けました。

# セッション A に目印を付ける
cur.execute("begin dbms_session.set_identifier('V4E'); "
            "dbms_application_info.set_module('V4E', :act); end;", act=args.label)

トレース付きの 5 回目だけは、client_identifier を V4E_TRACE、action を TRACE にしました。

RUN_TEAM の中で動く SQL は、ADB の内部ユーザー C##CLOUD$SERVICE が解析（parse）したものも含めて、セッション A で実行されます3。そのため、V$SQL の MODULE 列が V4E の行で Agent の実行が発行した SQL をまとめて取り出せ、ACTION 列で回を区別できます。

4. 手順・実行

チームに「いま一番重いSQLはどれ？」と質問します。質問文の渡し方を 2 通り用意しました。

-- バインド渡し（3 回）
select dbms_cloud_ai_agent.run_team(team_name => :t, user_prompt => :p, params => :prm) as answer from dual;

-- リテラル渡し（1 回）。質問文を SQL 本文に直接埋める
select dbms_cloud_ai_agent.run_team(team_name => 'OPS_SUPERVISOR_TEAM', user_prompt => 'いま一番重いSQLはどれ？', params => '{"conversation_id":"..."}') as answer from dual;

リテラル渡しは、質問文が SQL 本文に入ったときに、収集プロセスが SaaS に何を送るかを見るための対照です。SQL を文字列で組み立てて発行するツールでは、質問文が SQL 本文に入ることがあります。結果は SaaS ごとに違ったので、付録の 8.3 章で扱います。

最後に、SQL トレースを取りながら 1 回実行しました。実行の一覧は次のとおりです（時刻は日本時間）。

回 質問の渡し方 開始 終了 所要 チームの状態 1 秒サンプラー
1 バインド 06:17:03 06:19:09 125.4 秒 FAILED（Maximum failed iterations reached without completion.） あり
2 バインド 06:19:54 06:20:25 30.8 秒 SUCCEEDED あり
3 バインド 06:21:10 06:21:52 41.9 秒 SUCCEEDED あり
4 リテラル 06:22:00 06:22:16 16.1 秒 SUCCEEDED あり
5 バインド（トレース付き） 06:23:00 06:23:23 22.9 秒 SUCCEEDED なし

1 回目の失敗は 6 章の最後で触れます。実行後に 2 つの SaaS の画面でこの時間帯を表示し、Agent を呼んだセッションの待機、ツールの SQL、質問文を確かめました。

5. 計測・実行結果

5.1. LLM の応答待ちは TCP Socket (KGAS) として見える

New Relic の待機イベントの画面（Wait events）では、Agent を実行した時間帯だけ TCP Socket (KGAS) の線の値が上がり、待機の内訳にも同じ名前が並びました（図 2）。表示した 60 分間の TCP Socket (KGAS) の待機は 2 分 56 秒（画面の表記は 2 min 56 s）です。下の待機中クエリの一覧（Queries waiting）には、セッション 18317 の SQL が TCP Socket (K... で待っている行が出ています。この SQL の SQL_ID（SQL ごとに振られる識別子）は 950pa0fbb1j7g で、run_team を呼ぶ SELECT です。

図 2: New Relic の Wait events（TCP Socket (KGAS) が内訳と待機中クエリに出る）

図 2: New Relic の Wait events（TCP Socket (KGAS) が内訳と待機中クエリに出る）

Datadog で、待機イベント別の負荷グラフを TCP Socket (KGAS) だけの表示にすると、5 回の実行の時間帯（06:17〜06:23 ごろ）にだけ棒が表示され、ほかの時間には何もありません（図 3）。

図 3: Datadog の待機イベント別の負荷（TCP Socket (KGAS) だけを表示）

図 3: Datadog の待機イベント別の負荷（TCP Socket (KGAS) だけを表示）

1 件のサンプルを開くと、run_team を呼ぶ SELECT が wait_event: TCP Socket (KGAS)、wait_event_group: Network の状態で記録されていました（図 4）。

図 4: Datadog のサンプルの属性（wait_event が TCP Socket (KGAS)）

図 4: Datadog のサンプルの属性（wait_event が TCP Socket (KGAS)）

中の記録でも、セッション A の 1 秒サンプルの大半が TCP Socket (KGAS) の待機でした。バインド渡しの 3 回では、セッション A のサンプルのうち待機中（WAITING）の TCP Socket (KGAS) が 87〜93%（123 点中 114、30 点中 26、41 点中 37）です。その間に実行中の PL/SQL は SYS.UTL_HTTP でした。Oracle の Database Reference には、このイベントについて「要求したデータを外部ホストがネットワーク・ソケット経由で提供するのを待機」していると記載されています7。

5.2. ツールの SQL は普段の SQL と同じ画面に並ぶ

New Relic の SQL の一覧（Query performance）には、ツールの呼び出しが 9tjx18z2gju1c（BEGIN :result := "DBA_COPILOT"."NL2SQL_DATA_RETRIEVAL_FUNCTIONS"."RUNSQL_FUNC"(USER_PROMPT => :USER_PROMPT); END;、5 回実行）として出ていました。ツールが作った SQL も、SELECT JSON_ARRAYAGG(JSON_OBJECT(* RET... で始まる V_TOP_SQLAREA の問い合わせ（3 回実行）として出ています。

一覧の 1 位は run_team を呼ぶ SELECT 自身で、平均 31.05 秒（画面の表記は 31s 52ms）でした（図 5）。LLM の応答待ちを含めた時間が、この SELECT 1 本の実行時間として数えられています。2 位以下には、New Relic 自身が実行計画を取る SQL（? SELECT ACCESS_PREDICATES, BYTES, CARDINALITY, ...、1 回 11 秒台）が、画面に見えている範囲で 8 本並んでいます。Agent の答えも、成功した 4 回すべてでこの 950pa0fbb1j7g を「一番重い SQL」に挙げていました。NL2SQL のワーカーが読む V_TOP_SQLAREA は 1 回あたりの経過時間の順に並べたビューで、LLM の応答待ちを含むこの SELECT が 1 位に来ていました。

図 5: New Relic の Query performance（1 位が run_team を呼ぶ SELECT）

図 5: New Relic の Query performance（1 位が run_team を呼ぶ SELECT）

New Relic のクエリのサンプル（Query samples）を DB ユーザー DBA_COPILOT で絞ると、run_team のほかに、ツールの呼び出し、ツールの引数を調べる SELECT DISTINCT argument_name, data_type, in...、トレースを取り出す PL/SQL（5 回目の実行で使ったもの）が並びました（図 6）。

図 6: New Relic のクエリのサンプル（DB user = DBA_COPILOT）

図 6: New Relic のクエリのサンプル（DB user = DBA_COPILOT）

Datadog のサンプルにも、BEGIN :result := DBA_COPILOT.NL2SQL_DATA_RETRIEVAL_FUNCTIONS.RUNSQL_FUNC (USER_PROMPT => :USER_PROMPT); END; と、グラフを作るツールの GENERATE_CHART_FUNC の呼び出し、ツール定義を調べる SELECT COUNT(*) FROM sys.all_procedures WHERE owner = :owner ... が出ていました。

5.3. バインドで渡した質問文は SQL 本文に出ない

バインド渡しの回では、両方の SaaS で SQL 本文が run_team(team_name => :t, user_prompt => :p, params => :prm) のままで、質問文は含まれていませんでした（Datadog は図 4 の statement、New Relic は SQL の一覧の 950pa0fbb1j7g）。中の記録でも、質問文はトレースのバインド値の行 1 行にだけ現れ、V$SQL の本文にはありませんでした。

5.4. 中の記録で確かめた構造

外の画面と並べるため、中の記録の値も確かめました。構造は前の調査3と同じでした。

値 今回
実行中のスケジューラ・ジョブ 0 件（1〜4 回目、1 秒サンプルで 1 件も無し）
TCP Socket (KGAS) の待機区間の数（5 回目のトレース） 5 区間（Supervisor 2、ワーカー 2、NL2SQL の SQL 生成 1）
トレースで SQL を解析したユーザー（PARSING の件数） C##CLOUD$SERVICE 170 件、SYS 92 件、DBA_COPILOT 34 件

DBA_COPILOT のセッションは、通常はセッション A の 1 本です。1〜4 回目のうち 3 回では、主に開始直後の 0〜3 秒に、PX スレーブ（並列実行のサーバープロセス）が同時に 2〜4 本、同じ DBA_COPILOT のセッションとして見えました。1 回目は、開始から 19 秒後にも待機中の 1 本がありました。3 回目と 4 回目で SQL を確認できたスレーブは、ツールの引数を調べる ALL_ARGUMENTS の問い合わせを実行しており、module と action はセッション A のものを引き継いでいます。New Relic のセッションの一覧にも、このうち 4 本が DBA_COPILOT のセッション（Session duration 0s）として並んでいました（図 7）。

図 7: New Relic の Sessions（DBA_COPILOT の PX スレーブ 4 本とセッション A）

図 7: New Relic の Sessions（DBA_COPILOT の PX スレーブ 4 本とセッション A）

6. 考察

6.1. トレースで 5 回あった LLM 呼び出しは、外からは「Network 待ちの長い SELECT 1 本」に見える

トレースを取った 5 回目の RUN_TEAM の中には、TCP Socket (KGAS) の待機区間が 5 つありました。その間に履歴表への DML やツールの SQL が挟まっています。一方、SaaS の Top SQL では、この全体が run_team を呼ぶ SELECT 1 本（950pa0fbb1j7g）の実行時間として数えられ、待機クラスは Network でした（図 2・図 5）。

Datadog は ASH の 1 秒の行を回収しているので、接続の一覧で 1 秒ごとにセッション A の状態を追えます。それでも 5 つの区間の切れ目は、外の画面からは分かりません。1 秒の行にも「run_team の SELECT が Network で待機している」という状態しか出ず、どのワーカーが LLM を待っているかまでは出ないためです。

Oracle の Database Reference には、この待機イベントにかかる時間は問題ではなく、待機時間が長くても Oracle サポートに連絡する必要はない、と書かれています7。理由として、ホスト間のデータのやり取りに時間がかかることに加えて、リモート・ホストが受け取った要求を処理する時間も含まれることが挙げられています。今回のリモート・ホストは OCI Generative AI なので、外の画面で Agent の SQL が長い Network 待ちに見えても、その大半は LLM が答えを作っている時間です。

外の画面からは、「Agent の実行中は大半の時間を LLM 待ちに使っている」ことまでは分かります。何回 LLM を呼んだか、どのツールの前後で待ったかは、今回はトレースで確かめました。失敗も外の画面には出ません。1 回目は 125.4 秒で FAILED になりましたが、run_team は失敗しても例外を返さず、チームの状態を答えとして返すため、外の画面では長い SELECT の 1 回としか見えませんでした。失敗を監視したい場合は、Agent の履歴ビューの状態を見る必要があります8。

7. まとめ

Always Free の ADB で Select AI Agent を動かし、同じ実行を New Relic と Datadog の画面から見ました。

  • LLM の応答待ちは、両方の SaaS で TCP Socket (KGAS)（待機クラスは Network）として見えた
  • ツールの呼び出しは RUNSQL_FUNC の PL/SQL として、両方の SaaS で普段の SQL と同じ画面に並んだ
  • バインド変数で渡した質問文は、両方の SaaS で SQL 本文に出なかった
  • トレースで 5 回あった LLM 呼び出しは、外からは run_team の SELECT 1 本の Network 待ちに見える。回数はトレースで、失敗は Agent の履歴ビューで確かめる

SaaS ごとに違って見えた点は、次の付録にまとめています。

8. 付録: SaaS ごとに違って見えた点

ここでは、2 つの SaaS で見え方が違った点をまとめます。採取の方法（Datadog は ASH の 1 秒の行、New Relic は V$SESSION の 10 秒のサンプルと 60 秒ごとの Top SQL）も、画面を見た時間の幅も、設定もそろえていません。製品の優劣ではなく、今回の設定で観測した結果として読んでください。

採取の方法の違いは、今回の設定によるものです。Datadog のデフォルトは、Datadog Agent がアクティブなセッションを 10 秒ごとに自分でサンプルする方法で、New Relic と同じです。ASH の行を読む方法はオプションで、今回は Datadog の記事の設定のまま有効にしています2。設定ファイルの例には、ASH を読むには Oracle の追加ライセンスが必要になり費用がかかる場合がある、という注意書きがあります9。New Relic の公式の設定例には、ASH を読むオプションは見当たりませんでした6。

提供を始めた時期も違います。Datadog Agent が ADB に対応したのは、2023 年 8 月の 7.47.0 です10。New Relic の ADB 向けの手順は 2026 年 8 月にドキュメントへ加わったもので、執筆時点ではプレビューとして提供されています611。今回 Datadog のほうが設定の選択肢が多かったのは、この提供期間の差も関係していると考えられます。

8.1. 収集プロセスの違い

2 つの収集プロセスは、ADB に接続して V$ ビューを SELECT し、結果を SaaS に送るところまでは同じです。違うのは、プロセスの種類と SaaS への送り方です。

New Relic Datadog
収集プロセスの種類 OpenTelemetry Collector の New Relic 版（NRDOT は New Relic Distribution of OpenTelemetry の略） Datadog 独自のエージェント
ADB から集める部品 Collector の Oracle 用レシーバー nroracledb Agent に内蔵の Oracle チェック
SaaS への送り方 OTLP（OpenTelemetry の送信形式）で otlp.nr-data.net へ。認証は License key HTTPS で ap1.datadoghq.com へ。認証は API key
画面 Database 360 Database Monitoring

Datadog も OTLP を受け取る経路を持っていますが12、Database Monitoring の公式ドキュメントは、データベースを設定して Datadog Agent を入れるところから始まります13。今回の Database Monitoring の画面は、Datadog Agent の Oracle チェックが送った値から作られています。

8.2. 履歴表への DML

Agent は実行のたびに、C##CLOUD$SERVICE の履歴表に書き込みます3。今回のトレースでは、実行時に DML が入った表は DBMS_AI_AGENT_TEAM_HIST$・DBMS_AI_AGENT_TASK_HIST$・DBMS_AI_AGENT_TOOL_HIST$・DBMS_CLOUD_AI_CONVERSATION$・DBMS_CLOUD_AI_CONVERSATION_PROMPT$・DBMS_CLOUD_TASK$ の 6 つでした。

New Relic の SQL の一覧で hist$ を検索すると、名前が _HIST$ で終わる 3 表への INSERT と UPDATE が 16 本出てきました（図 8 はそのうち画面に見えている 9 本）。平均 CPU 時間が 0〜1 ms の文も一覧に入っていました。

図 8: New Relic で hist$ を検索した結果

図 8: New Relic で hist$ を検索した結果

Datadog では、表示した 20 分間の正規化クエリ（リテラルを ? にして、同じ形の SQL を 1 本に数えたもの）153 本を、2 ページ通して見ました。履歴表への INSERT と UPDATE は見つかりませんでした。C##CLOUD$SERVICE が解析した SELECT ... FROM dbms_cloud_ai_profile$ WHERE name = :profile_name ...（64 回）は一覧に載っていたので、DB ユーザーで除かれているわけではありません。

Datadog の公式ドキュメント（Data Collected）には、クエリのメトリクスはホスト上で実行時間の合計が多い上位 200 本の正規化クエリについて集め、この上限は採取の間隔（デフォルトで 10 秒）ごとに掛かる、とあります14。

Datadog Database Monitoring collects per-query metrics for the top 200 normalized queries measured by their total time spent executing on the host. This limit is applied only to each collection interval (10 seconds by default)

ただし、今回の 20 分間に一覧に出た正規化クエリは 153 本で、どの採取の間隔でも 200 本の上限には届いていなかったことになります。そのため、この上限では履歴表の DML が出なかったことを説明できません。原因は切り分けていません。

8.3. リテラルで渡した質問文

リテラル渡しの 4 回目は、V$SQL の本文（6nq9qqc9s5pp0）に質問文が原文で残っていました。Datadog のサンプルでは、この SQL が select dbms_cloud_ai_agent.run_team(team_name => ?, user_prompt => ?, params => ?) from dual として送られており、チーム名と質問文の両方が ? に置き換わっていました（図 9）。Datadog の公式ドキュメントには、Datadog Agent がクエリを正規化するので、Datadog に送られるクエリのパラメータは難読化される、とあります。例として WHERE id = 13345 が WHERE id = ? になる SQL が載っています14。

図 9: Datadog のサンプル（リテラル渡しの質問文が ? になっている）

図 9: Datadog のサンプル（リテラル渡しの質問文が ? になっている）

New Relic では、リテラル渡しの 6nq9qqc9s5pp0 は Top SQL の一覧にもクエリのサンプルにも見つかりませんでした。セッションのサンプルは 10 秒ごとなので 16 秒の実行でも 1 回は掛かるはずですが、見つからなかった理由は分かっていません。そのため今回は、New Relic でリテラルの質問文が ? になるかは確かめられていません。New Relic の記事では、SQL 本文のリテラルは ? に置き換わっていました（同記事の 6.5 章1）。

なお前の 2 本では、実行計画の絞り込み条件（述語）のリテラルは New Relic にそのまま送られ1、SQL コメントは Datadog にそのまま送られていました2。質問文を WHERE 句の条件や SQL コメントに埋めるアプリケーションでは、SaaS に送られる可能性があります（今回は試していません）。

8.4. 接続元の情報

New Relic のクエリのサンプルには、DB ユーザーと Client host（PC 名）の列がありました（図 6 の Client host 列は黒塗り）。module・action・client_identifier の列はありません。

Datadog のサンプルの属性には、oracle.module: V4E、oracle.action: TRACE、oracle.client_identifier: V4E_TRACE と、3.2 章で付けた目印がそのまま入っていました（図 10）。ほかに、プログラムのパス（db.application に python.exe のフルパス）と OS ユーザー名も入っています（図 4・図 10 では黒塗り）。Client IP の欄は空でした。

図 10: Datadog のサンプルの oracle 節（module・action・client_identifier）

図 10: Datadog のサンプルの oracle 節（module・action・client_identifier）

参考

  1. New Relic Database 360 で Oracle Autonomous Database を監視してみた（New Relic の記事。ADB 側で TLS 接続を許可する手順は 3.2 章。SQL 本文のリテラルが ? になること、実行計画の絞り込み条件（述語）にはリテラルが残ることは 6.5 章） ↩ ↩2 ↩3 ↩4

  2. Datadog Database Monitoring で Oracle Autonomous Database を監視してみた（Datadog の記事。ASH から採取する設定は 3.4 章、1 秒刻みの採取の説明は 5.2 章。SQL コメントが原文のまま送られることは 6.2 章） ↩ ↩2 ↩3 ↩4 ↩5

  3. Select AI Agent が DB の中でどう動いているか V$ ビューと SQL トレースで確かめてみた（RUN_TEAM は呼び出したセッションの中で進むこと、HTTP の待機区間 5 つ、$ 付きの表への DML を調べた記事） ↩ ↩2 ↩3 ↩4 ↩5

  4. Oracle Autonomous AI Database の Select AI Supervisor Agent を試してみた（今回使ったチームの構成） ↩

  5. DBMS_USERDIAG（Oracle 公式ドキュメント。ENABLE_SQL_TRACE_EVENT と TRACE） ↩

  6. Install & configure NRDOT Collector for ADB monitoring（New Relic 公式ドキュメント。設定例の collection_interval: 10s、top_query_collection の top_query_count: 200 と collection_interval: 60s） ↩ ↩2 ↩3

  7. 待機イベントの説明（Oracle AI Database 26ai リファレンス）（Oracle 公式ドキュメント。C.3.184 TCP Socket (KGAS)） ↩ ↩2

  8. DBMS_CLOUD_AI_AGENT History Views（Oracle 公式ドキュメント。チーム・タスク・ツールの履歴ビューと STATE の値） ↩

  9. oracle.d/conf.yaml.example（7.83.2）（datadog-agent リポジトリの検証した版のタグ。min_collection_interval はアクティブなセッションのサンプル間隔でデフォルト 10 秒。query_samples.active_session_history はデフォルト false で、ASH を読むには Oracle の追加ライセンスが必要な場合があるという注意書き） ↩

  10. Datadog Agent 7.47.0 のリリースノート（2023 年 8 月 31 日。「Add support for Oracle Autonomous Database (Oracle Cloud Infrastructure)」） ↩

  11. New Relic ドキュメントの更新履歴 2026 年 8 月 17 日〜21 日（Oracle Database monitoring with NRDOT に ADB 向けの手順が加わった週） ↩

  12. OpenTelemetry in Datadog（Datadog 公式ドキュメント。DDOT Collector、Datadog Agent の OTLP 受信、OpenTelemetry Collector の Datadog エクスポーター、OTLP の受け口への直接送信） ↩

  13. Database Monitoring（Datadog 公式ドキュメント。導入は「データベースを設定し、Datadog Agent をインストールする」から） ↩

  14. Data Collected（Database Monitoring）（Datadog 公式ドキュメント。上位 200 本の正規化クエリと採取の間隔ごとの上限、クエリのパラメータの難読化。日本語版は上限の記述が英語版と異なるため英語版を参照） ↩ ↩2

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?