系統表 IDL_UB1$ 解析：PL/SQL 編譯中間碼倉庫與高階複寫隱形增長源

現象

SYSTEM 表空間暴增，Top 段位居然是 `SYS.IDL_UB1$`（近 3GB），遠超 `SOURCE$`、`IDL_UB2$` 等字典表。

表結構與用途

CREATE TABLE idl_ub1$  -- "idl table for ub1 pieces"
( obj#     NUMBER NOT NULL,  -- 物件編號
  part     NUMBER NOT NULL,  -- 0=DIANA, 1=可攜 P-code, 2=機器相關 P-code
  version  NUMBER,           -- 版本號
  piece#   NUMBER NOT NULL,  -- 片段號
  length   NUMBER NOT NULL,  -- 片段長度
  piece    LONG RAW NOT NULL -- ub1 piece (編譯中間碼)
)
STORAGE (INITIAL 10K NEXT 100K MAXEXTENTS UNLIMITED PCTINCREASE 0);

• IDL = Interface Definition Language。
• 儲存 PL/SQL 程式單元的 **DIANA 树**與 **P-code**（可攜/機器碼），是編譯後的中間表示。
• 資料字典四大表之一（`IDL_UB1$`、`IDL_UB2$`、`SOURCE$`、`ERROR$`）共同支撐 PL/SQL 編譯/執行/除錯。

為何暴增？

1. 高階複寫：複製環境下大量包裝程式、內部觸發器、RPC 存根產生海量中間碼。
2. 頻繁編譯/重編譯：歷史版本片段未自動清理（10g 前無自動回收機制）。
3. 大量動態 PL/SQL：`EXECUTE IMMEDIATE`、`DBMS_SQL` 大量匿名區塊編譯。

應對策略

• 10g+：啟用 `PLSQL_CCFLAGS`、`PLSQL_OPTIMIZE_LEVEL`，編譯器更精簡；且有自動清理機制。
• 定期重編譯失效物件（`UTL_RECOMP`），觸發中間碼重建並釋放舊片段。
• 監控 `DBA_SEGMENTS` 追蹤 `IDL_UB1$` 增長趨勢，設定告警閾值。
• 複寫環境評估是否可簡化複製群組、減少包裝層級。

關聯視圖

SELECT * FROM dba_objects WHERE object_name LIKE 'IDL_%';
-- IDL_UB1$, IDL_UB2$, IDL_SB4$, IDL_CHAR$, IDL_UB1$ 索引等

參考

原文：Eygle 專欄 | Oracle 內部文件 `sql.bsq`