在 Oracle 官方文件 Interoperability Notes: Oracle E-Business Suite Release 12.2 with Oracle Database 19c-KA1056 中指出
When upgrading your Oracle E-Business Suite to Oracle Database 19c, your database will be converted to the multitenant architecture, with a container database (CDB) and a single pluggable database (PDB).
意指將 Oracle E-Business Suite 升級到 Oracle Database 19c 時，您的資料庫會轉換為多租用戶架構，包含一個容器資料庫 (CDB) 和一個可插拔資料庫 (PDB)。
容器資料庫 (CDB) 和可插拔資料庫 (PDB)是什麼呢?
從 New FAQ: EBS 12.2 and 12.1 and the Oracle Multitenant (CDB) Architecture 下面的架構圖可以大概有些輪廓。
也就代表在容器資料庫 (CDB) 之上可以有多個可插拔資料庫 (PDB)。在 eBS R12.2 跟 R12.1 中，一個容器資料庫 (CDB) 和一個 EBS的可插拔資料庫 (PDB)是被Oracle官方認證可以運作的。
原本的 Alert/ Trace Log
原本實體文字檔 (.log) 與 Trace 檔目錄：在 $ORACLE_BASE/diag/rdbms/prod/<SID>/trace/ ，這裡面可以找到您最熟悉的 alert_<SID>.log。但升級到 19C 以後，錯誤訊息就不再寫入這個檔案，主要錯誤訊息會匯總到 CDB Root 的 alert.log
CDB Root 的 Alert Log 與 Trace 目錄
在 19c 中，主要的純文字 Alert Log (alert_<SID>.log) 與背景行程 Trace 檔案（如 LGWR、DBWR）全部統一存放在 CDB 的路徑下。
「Oracle 19c 預設並不會為每個 PDB 產生一個獨立的外部 alert.log 檔案。」 PDB 的特定運行錯誤與資料庫字典檢查等核心訊息，會直接寫入到上方 CDB 的主 alert_<SID>.log 中，並加上 PDB 標籤（例如：PDB_NAME(3):提示訊息）。
假設 $ORACLE_BASE 位於 /tk/PROD/db/19.0.0，那麼 alert_<SID>.log 會位於目錄: $ORACLE_BASE/diag/rdbms/ebscdb/<CDB_GUID_或CDB_名稱>/trace 裡。例如： /tk/PROD/db/19.0.0/diag/rdbms/ebscdb/EBSCDB/trace
附註：如果個別 PDB 的使用者 Session 或是特定伺服器行程觸發了 Dump 錯誤，它會在 ADR 底下開闢獨立的 PDB 追蹤資料夾 $ORACLE_BASE/diag/rdbms/ebscdb/，例如： <CDB_GUID_或CDB_名稱>/<PDB_GUID_或PDB_名稱>/tk/PROD/db/19.0.0/diag/rdbms/ebscdb/EBSCDB/PROD/trace
SQL 查詢 CBD 的 Trace Files 相關資訊
如果不確定 $ORACLE_BASE 被設定在何處，請直接用 sysdba 權限登入資料庫並查詢
-- 查詢相關 log file
SELECT NAME, VALUE FROM V$DIAG_INFO;
-- To find the trace file for your current session
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';
--To find all trace files for the current instance:
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';
--To determine the trace file for each Oracle Database process:
SELECT PID, PROGRAM, TRACEFILE FROM V$PROCESS;
查找 PDB 的 alert 資訊
查出 容器資料庫 (CDB) 的 alert_<SID>.log 位於的目錄位置後，可以用下列的指令來查出 EBS可插拔資料庫 (PDB) 的 alert 訊息
$ cd /tk/PROD/db/19.0.0/diag/rdbms/ebscdb/EBSCDB/trace
# 使用 grep 快速過濾出特定的 ORA 錯誤程式碼（例如 ORA-00600 或 ORA-04031）
$ grep "ORA-" alert_EBSCDB.log
$ awk '/ORA-/{c=1} c&&c--' alert_EBSCDB.log | tail -n 10
$ awk '/PROD/{c=1} c&&c--' alert_EBSCDB.log | tail -n 10
SQL 即時查詢（直接抓取近期的 ORA 錯誤）
以 SYSDBA 登入並切換到 PDB 進行字典表查詢最快
sqlplus / as sysdba
-- 確保在 Root 容器
ALTER SESSION SET CONTAINER = CDB$ROOT;
-- 再次查詢（限制只抓最新的 50 筆，避免資料量太大卡住）
SELECT origin_timestamp, message_text
FROM V$DIAG_ALERT_EXT
WHERE message_text LIKE '%ORA-%' AND rownum <= 50
ORDER BY origin_timestamp DESC;應用程式層：追查是哪個 EBS 元件引發 ORA 錯誤
通常 ORA 錯誤是由 EBS 應用層主動觸發的（例如：表單、背景排程、網頁網頁網頁），必須去對應的 EBS 12.2 檔案系統（Run File System）中調閱日誌：
背景排程錯誤（Concurrent Program Log）
如果是在跑報表或過帳時出現 ORA 錯誤，直接去查看該 Request 的 Log 檔案（注意：12.2 的環境變數已被 AutoConfig 封裝）：
$su - applmgr
$cd $APPLCSF/log
$ pwd
/tk/PROD/apps/fs_ne/inst/PROD_s822/logs/appl/conc/log
# 檔案名稱格式通常為 l<request_id>.req
# 或者是客製化程式輸出的 o<request_id>.out
# 可以使用 view text 或是 cat l<request_id>.req | grep ORA- 來定位Web 介面
如果是使用者在網頁（HTML 畫面）操作，跳出「系統發生無法預期的錯誤」並懷疑底層與 19c 連線中斷或報錯，請至 WebLogic 節點查看：與 OAF 網頁錯誤（OACore Logs）
$ cd $FMW_HOME/user_projects/domains/EBS_domain_<SID>/servers/oacore_server1/logs
$ tail -n 500 oacore_server1.out
# 此日誌會印出完整的 Java Stack Trace，裡面會包含類似 java.sql.SQLException: ORA-XXXXX 的錯誤。
Forms 介面連線錯誤（FRM-40735 觸發 ORA-XXXXX）
如果是 Chrome/Edge 透過 JWS 開啟的 Forms 畫面彈出 ORA 錯誤，除了看上述 PDB Trace 外，可以檢查 Forms 伺服器端的日誌：
$ cd $FMW_HOME/user_projects/domains/EBS_domain_<SID>/servers/forms_server1/logs
$ tail -n 200 forms_server1.out
