0
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

V$DIAG_ALERT_EXTは廃止済み！ADB-S 26aiでアラートログやトレースを読む正しい方法

0
Last updated at Posted at 2026-05-15

2026年5月15日時点の情報になります

1. はじめに

Autonomous Database Serverless (ADB-S) でも、DBA の本能としてアラートログやトレースファイルを覗きたくなる場面は多いです。しかし実機を触ると、従来の Autonomous Database で使えていた V$DIAG_ALERT_EXT や V$DIAG_INFO が空になったりと、想定外の挙動に遭遇します。

ADB のデプロイ形態には ADB-S (Serverless) と ADB-D (Dedicated) の 2 種類があり、ADB-D マニュアルに残るアラートログ参照手順は ADB-S には当てはまりません。検索で出てくる「ADB でアラートログを見る方法」の多くは ADB-D 前提か 2024 年以前の古い情報で、現在の ADB-S には通じない、というのが混乱の元になっています。

結論先出し

  • V$DIAG_ALERT_EXT は ADB-S では廃止済み (2025-07-22 リリースで公式明示)。代替は V$CLIENT_ERRORS
  • V$DIAG_TRACE_FILE のメタ情報は見えるが、V$DIAG_TRACE_FILE_CONTENTS の中身は空。こちらは公式 Docs に明示されていない
  • ユーザー主導 SQL Trace は SESSION_CLOUD_TRACE + Object Storage で取得

2. 検証ゴールと環境

検証ゴール

# 検証項目
1 アラートログ系ビュー (V$DIAG_ALERT_EXT, V$DIAG_INFO) はどこまで見えるか
2 トレースファイル系ビュー (V$DIAG_TRACE_FILE, V$DIAG_TRACE_FILE_CONTENTS) はどこまで見えるか
3 ユーザー主導の SQL Trace は機能するか、結果はどこで読めるか

検証環境

項目 内容
リージョン ap-tokyo-1
データベースバージョン Oracle Autonomous AI Database 26ai（ADB-S）

3. 実機検証

3.1. アラートログ系 — V$DIAG_ALERT_EXT は廃止済み

SELECT COUNT(*) FROM v$diag_alert_ext;
-- 結果: 0 件 (空)

SELECT * FROM v$diag_info;
-- 結果: 0 件 (空)

Oracle は 2025 年 7 月 22 日付のリリースノート1で以下を明示しています:

ビュー V$DIAG_ALERT_EXT は、アラート・ログ・データには使用できません。
置換として、V$CLIENT_ERRORS を使用してアラート・ログ関連のエラー・データを検索します。

これは ADB-S における公式仕様変更であり、「NULL が返る」現象はバグでも権限不足でもなく 設計通りの挙動 でした。代替の V$CLIENT_ERRORS のスキーマ2は次のとおりです:

カラム 型 説明
SID / SERIAL# NUMBER セッション識別子
USERNAME VARCHAR2(128) 操作実行ユーザー
MODULE / ACTION VARCHAR2(64) DBMS_APPLICATION_INFO で設定された値
SQLID VARCHAR2(13) エラーを引き起こした SQL/PLSQL 識別子
ERROR_NUM NUMBER エラースタック先頭の ORA エラー番号
ERROR_MESSAGE VARCHAR2(4000) PL/SQL コールスタックを含む完全なエラーメッセージ (※4,000 バイトを超える長大なコールスタックはサイレントに切り捨てられる点に注意)
OCCURRENCES NUMBER 同一エラーの発生回数 (公式ドキュメントの列定義には記載されていないが、実機の DESCRIBE で存在を確認)
ERROR_TIME TIMESTAMP(9) エラー発生時刻 (UTC)
CON_ID NUMBER コンテナ ID

旧 V$DIAG_ALERT_EXT にあった MESSAGE_LEVEL (Critical / Severe / Important / Normal) や汎用 MESSAGE_TEXT フィールドはなく、ORA エラー特化のスキーマ になっている点に注意してください。

実機での記録挙動

意図的に ORA-942 / ORA-1722 を発生させて V$CLIENT_ERRORS への記録を観察した結果は以下の通りです:

ERROR_TIME (UTC) ERROR_NUM SQLID MODULE ACTION
26-05-14 14:29:46 1722 19xt52hrhw95b vce_test ora942_action
26-05-14 14:28:43 942 9qgj74km6ckn6 vce_test ora942_action
26-05-14 14:01:35 942 6xdgs7v1rsqxr SQL Developer (空)
26-05-14 13:35:14 942 3huu74r5dz9x0 SQL Developer (空)
26-05-14 13:35:12 41900 b397dy1bcqu26 SQL Developer (空)

ERROR_MESSAGE の中身の例 (ORA-1722 のケース):

ORA-01722: 'a'を含む文字列値を数値に変換できません:
ORA-03302: (ORA-01722詳細)文字列値が無効です: abc

確認できたポイント:

  • MODULE / ACTION: DBMS_APPLICATION_INFO.SET_MODULE で設定した値 (vce_test / ora942_action) がそのまま記録される
  • SQLID: エラーを起こした SQL の SQL_ID と一致する
  • ERROR_MESSAGE: 複合エラーは複数の ORA- 行が連結されて 1 セルに記録される (例: ORA-1722 + ORA-03302)
  • 認可系エラーも対象: ORA-41900: READ権限がありません のような権限エラーも V$CLIENT_ERRORS に入る
  • PDB 再起動を跨いでも残る: V$PDBS.OPEN_TIME より古い (= 再起動以前の) エラー行が見えていた。V$CLIENT_ERRORS は内部的に永続化された XML アラートログを読みに行く実装と推測され、メモリ上のデータではないため再起動でも失われない

3.2. トレース系 — メタ情報は見える、中身は見えない

V$DIAG_* 系の可視性は一律ではなく、ビューごとに細かく境界線が引かれていました。推測ですが、システムトレース系の情報は必要な場合には SR で直接 Oracle 側に確認してもらう必要がありそうです。

V$DIAG_TRACE_FILE (メタ情報) — 確認はできる:

SELECT adr_home, trace_filename, modify_time
  FROM v$diag_trace_file
 ORDER BY modify_time DESC
 FETCH FIRST 5 ROWS ONLY;
ADR_HOME TRACE_FILENAME MODIFY_TIME
/u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 xxx1pod8_cjq0_181668.trc 26-05-14 14:34:00 GMT
/u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 xxx1pod8_ora_173700.trc 26-05-14 14:31:57 GMT
/u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 xxx1pod8_mz00_367511.trc 26-05-14 14:31:57 GMT
/u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 xxx1pod8_m00f_66325.trc 26-05-14 14:31:00 GMT
/u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 xxx1pod8_dbrm_22092.trc 26-05-14 14:30:30 GMT

ファイル名から バックグラウンドプロセス種別 (mz00 = Manageability Monitor, dbrm = Resource Manager, cjq0 = Job Queue Coordinator, m00f = MMON, ora = ユーザーセッションを含むサーバープロセス) が読み取れます。ADR_HOME は /u02/app/oracle/diag/rdbms/xxx1pod/xxx1pod8 の構造で、バックエンドの CDB 名 (xxx1pod) と SID (xxx1pod8)、および OS パスがメタ情報として露出していました。なお SELECT DISTINCT adr_home FROM v$diag_trace_file の結果は 1 件のみでした。

V$DIAG_TRACE_FILE_CONTENTS (中身) — 完全に空:

SELECT payload
  FROM v$diag_trace_file_contents
 WHERE trace_filename = (
   SELECT trace_filename FROM v$diag_trace_file
    ORDER BY modify_time DESC FETCH FIRST 1 ROW ONLY)
 FETCH FIRST 50 ROWS ONLY;
-- 結果: 0 行

メタ情報は見えるのに、中身は 1 行も取得できませんでした。

Oracle 公式ドキュメントには「V$DIAG_TRACE_FILE_CONTENTS は ADB-S では空になります」と明示されていません。V$DIAG_ALERT_EXT の廃止はリリースノートで明示されましたが、トレース系については同等の記述が現時点では見当たりませんでした。

3.3. ユーザー主導 SQL Trace — 公式手順で機能する

ユーザーが明示的に有効化する SQL Trace (10046 相当) は ADB-S でも公式にサポートされており、結果は Object Storage と SESSION_CLOUD_TRACE ビューに書き出されます。

セットアップの要点:

-- 1. Object Storage バケット用 Credential を作成
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'DEF_CRED_NAME',
    username        => 'adb_user@example.com', -- ※IAM Identity Domains 配下のフェデレーションユーザーの場合は 'oracleidentitycloudservice/adb_user@example.com' のようにドメイン名プレフィックスが必要なケースあり
    password        => '<auth_token>'
  );
END;
/

-- 2. ロギング先バケットと既定 Credential を設定
ALTER DATABASE PROPERTY SET
  DEFAULT_LOGGING_BUCKET = 'https://objectstorage.ap-tokyo-1.oraclecloud.com/n/<namespace>/b/<bucket>/o/';
ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'ADMIN.DEF_CRED_NAME';

トレース取得の流れ:

EXEC DBMS_SESSION.SET_IDENTIFIER('sqlt_test');           -- ファイル名に使われる
EXEC DBMS_APPLICATION_INFO.SET_MODULE('modname', NULL);

ALTER SESSION SET SQL_TRACE = TRUE;
-- ここで対象ワークロードを実行
ALTER SESSION SET SQL_TRACE = FALSE;  -- ← OFF にした時点で書き出される

結果は次の 2 ルートで読めます:

  • ルート A: SELECT trace FROM SESSION_CLOUD_TRACE ORDER BY row_number; — セッション継続中のみ有効
  • ルート B: Object Storage に sqltrace/<clientID>/<moduleName>/sqltrace_<numID1>_<numID2>.trc で保存 → ローカルに DL して TKPROF で人間可読化
  • バケットは Standard ストレージ階層 で作成する必要があります (Archive では保存されません)
  • トレース停止 (SQL_TRACE = FALSE) するまで、Object Storage にもビューにも書き出されません (従来の Oracle DB と挙動が異なる)
  • 同一セッションで複数回 ON/OFF や並列実行 (PDML, PQ) では複数 .trc が生成され、TKPROF 前にマージが必要なケースあり

詳細手順は公式 Docs Autonomous AI DatabaseでのSQLトレースの実行 を参照してください。

実機での確認: 上記手順で取得したトレースファイルのヘッダには CLIENT ID:(sqlt_trace_test) / MODULE NAME:(modname) がそのまま記録され、Object Storage 上のパスも sqltrace/<clientID>/<moduleName>/sqltrace_<SID>_<SERIAL#>.trc の規則通りでした

4. 可視性マトリクスと境界線

検証結果から、ADB-S 26ai の診断系ビュー仕様は以下と想定されます。

ビュー / 機能 可視性 内容 用途
V$DIAG_ALERT_EXT ❌ 空 廃止扱い (公式明示) —
V$DIAG_INFO ❌ 空 OS パス非公開 —
V$DIAG_TRACE_FILE ⭕ 4,415 件 メタ情報のみ トレース生成傾向の把握
V$DIAG_TRACE_FILE_CONTENTS ❌ 空 中身は閉鎖 —
V$CLIENT_ERRORS ⭕ ORA エラー履歴 アラートログ代替
SESSION_CLOUD_TRACE ⭕ ユーザー主導トレース SQL Trace 結果閲覧
ALTER SESSION SET EVENTS 10046/10053 △ 一部制限あり 10046/10053実機検証

境界線を図示すると次のようになります:

[公開]   ファイル名・タイムスタンプ・プロセス種別 (メタ情報)
         ユーザーが自分で取得した SQL Trace
─────────────────────────────────────────── 境界線
[非公開] ファイルの中身 (V$DIAG_TRACE_FILE_CONTENTS の payload)
         自動生成されたインシデント / トレースの中身
         ADR ディレクトリへの直接アクセス
         ORA-600 / 7445 等の内部エラートレース

公式ドキュメントが 明示している部分 (V$DIAG_ALERT_EXT 廃止) と、明示されていない部分 (V$DIAG_TRACE_FILE_CONTENTS が空、V$DIAG_INFO が空) が混在している点が、ADB-S の診断系を扱う上で注意が必要です。

5. まとめ

# 検証項目 結論
1 アラートログ系ビューはどこまで見えるか V$DIAG_ALERT_EXT は廃止。V$CLIENT_ERRORS が公式代替
2 トレースファイル系ビューはどこまで見えるか メタ情報 (V$DIAG_TRACE_FILE) は見える、中身 (V$DIAG_TRACE_FILE_CONTENTS) は空
3 ユーザー主導 SQL Trace は機能するか SESSION_CLOUD_TRACE + Object Storage で十分機能

実運用での落としどころ:

目的 推奨手段
普段のエラー監視 V$CLIENT_ERRORS をエラー番号別に集計
パフォーマンス問題の原因究明 Database Actions → パフォーマンス・ハブなど
特定 SQL の詳細トレース ALTER SESSION SET SQL_TRACE=TRUE + Object Storage / SESSION_CLOUD_TRACE
内部エラー (ORA-600 等) の調査 Oracle Support (SR)

ADB-S の診断系を扱う際は、検索でヒットした手順が ADB-D 向け か ADB-S 向け か、また 2024 年以前のものではないか を必ず確認することをおすすめします。

参考

  1. https://docs.oracle.com/ja-jp/iaas/releasenotes/autonomous-database-serverless/2025-07-query-for-client-errors.htm ↩

  2. https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/v-client-errors.html ↩

0
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
0
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?