after ddl触发器中不能直接执行alter ... compile，因其本质是嵌套ddl，会触发ora-04092等递归错误；即使加autonomous_transaction也无法绕过oracle的ddl上下文限制。
不能直接用 AFTER DDL 触发器自动重新编译失效对象，因为触发器内执行 ALTER ... COMPILE 会引发递归 DDL，导致 ORA-04092 错误。
为什么 AFTER DDL 触发器里不能直接编译对象
Oracle 在 DDL 执行过程中会持有数据字典锁，AFTER DDL 触发器虽然在 DDL 提交后触发，但仍在同一事务上下文或内部会话环境中。此时执行 ALTER PACKAGE ... COMPILE 等语句，会被视为嵌套 DDL，违反 Oracle 的递归限制：
- 报错典型为
ORA-04092: cannot COMMIT in a trigger或ORA-00604: error occurred at recursive SQL level 1 - 即使加
PRAGMA AUTONOMOUS_TRANSACTION，也无法绕过 DDL 递归校验（该 pragma 只隔离事务，不解除 DDL 上下文限制） - 所有
COMPILE类操作本质是 DDL，无法在触发器中安全发起
替代方案：用触发器只记录 + 外部异步任务处理
真正可行的做法是把“检测”和“编译”解耦：触发器只负责捕获变更并落库，再由独立 Job 或外部调度调用编译逻辑。
- 创建日志表：
CREATE TABLE invalid_obj_log (log_time DATE, owner VARCHAR2(30), object_name VARCHAR2(128), object_type VARCHAR2(19)) - 建
AFTER DDL ON DATABASE触发器，仅插入日志（不查dba_objects，避免性能拖累）：
CREATE OR REPLACE TRIGGER ddl_capture_trigger
AFTER DDL ON DATABASE
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO invalid_obj_log (log_time, owner, object_name, object_type)
VALUES (SYSDATE, ORA_DICT_OBJ_OWNER, ORA_DICT_OBJ_NAME, ORA_DICT_OBJ_TYPE);
COMMIT;
EXCEPTION WHEN OTHERS THEN NULL;
END;
DBMS_SCHEDULER job，每 5 分钟扫描 invalid_obj_log 和 dba_objects，对 status = 'INVALID' 的对象批量编译（用存储过程 + EXECUTE IMMEDIATE）编译时必须注意的三类对象顺序和语法
包（PACKAGE）和包体（PACKAGE BODY）有依赖关系，视图可能依赖其他失效对象，顺序错了会白编译：
-
PACKAGE必须先于PACKAGE BODY编译；否则COMPILE BODY会失败 - 视图（
VIEW）和物化视图（MATERIALIZED VIEW）要最后编译，因为它们常依赖函数、包等 - 触发器（
TRIGGER）编译前，确保其引用的表、函数已有效；否则报PLS-00201 - 正确语法示例：
ALTER PACKAGE SCOTT.MY_PKG COMPILE，ALTER PACKAGE SCOTT.MY_PKG COMPILE BODY，ALTER FUNCTION SCOTT.MY_FUNC COMPILE
更稳妥的兜底策略：定期全量扫描 + 异步重试
纯靠 DDL 触发器漏检率高（比如依赖对象被删、dblink 不通、权限回收等不会触发 DDL），建议保留每天定时扫描：
- 用
DBMS_SCHEDULER.CREATE_JOB创建凌晨 2 点执行的 job，查询dba_objects中status = 'INVALID'的全部对象 - 编译逻辑里对每个对象加异常捕获，记录到
recompile_log表，不中断整个循环 - 对反复失败的对象（如因权限缺失），单独告警，人工介入；不要无限重试
- 避免在高峰期执行，尤其是含大量
PACKAGE BODY的用户，编译过程会短暂锁住对象元数据
DDL 触发器适合做“轻量捕获”，不是“自动修复”。真正健壮的自愈机制，一定是由触发器+日志+异步 Job+人工反馈通道组成的闭环，而不是指望一行 ALTER 能在触发器里跑通。
