ora-04082错误源于在无行上下文的触发器（如after logon、ddl、系统级触发器）中误用:new/:old，必须改用sys_context等函数获取会话信息，并确保触发器启用、作用域正确、字段类型兼容。
不能用 :NEW 或 :OLD —— 登录触发器、DDL 触发器、系统级触发器根本没有行上下文，一写就报 ORA-04082，且触发器直接失效。
ORA-04082 错误的直接原因和修复方式
这个错误不是配置问题，是语法硬伤。只要在 AFTER LOGON、BEFORE DROP 这类无行上下文的触发器里出现 :NEW 或 :OLD，Oracle 就拒绝编译。
- 必须改用
SYS_CONTEXT('USERENV', 'xxx')获取会话信息：比如SYS_CONTEXT('USERENV', 'SESSION_USER')取登录名，SYS_CONTEXT('USERENV', 'IP_ADDRESS')取客户端 IP（注意 IPv6 长度，字段至少VARCHAR2(46)） -
SYSDATE或SYSTIMESTAMP替代时间字段，别用CURRENT_DATE—— 后者依赖会话时区，审计时间必须统一为数据库服务器时间 - INSERT 语句里不能带冒号绑定变量，所有值都得是函数调用或字面量：
INSERT INTO audit_login_log VALUES (SYS_CONTEXT('USERENV', 'SESSION_USER'), SYS_CONTEXT('USERENV', 'IP_ADDRESS'), SYSTIMESTAMP);
AFTER DELETE ON table_name FOR EACH ROW 中的 :OLD 使用限制
这里可以安全用 :OLD，但仅限于 DML 行级触发器，且必须明确作用域：
-
:OLD字段名必须和源表列名完全一致，大小写敏感（尤其当源表用双引号建了大小写混合列名时） - 如果源表有
LONG、BLOB、CLOB字段，:OLD.clob_col在触发器中不可直接读取，会报ORA-00997；需改用DBMS_LOB.SUBSTR(:OLD.clob_col, 1000, 1)截断 - DELETE 操作若带
WHERE条件但没命中任何行，触发器仍不会执行 —— Oracle 不会为“零影响”触发FOR EACH ROW
audit_log 表字段类型与源表不兼容导致静默失败
Oracle 不像 PostgreSQL 那样报明确类型错误，而是直接跳过 INSERT，日志表空空如也，查不出原因。
- 源表字段是
NUMBER(10,2)，日志表对应字段必须是NUMBER或更宽（如NUMBER(12,4)），不能是NUMBER(5)或VARCHAR2(10) - 源表用
VARCHAR2(200 CHAR)，日志表字段若定义为VARCHAR2(200 BYTE)，中文插入时可能截断或报ORA-12899，但触发器里不抛异常，INSERT 被静默丢弃 - 时间字段别用
DATE存毫秒级操作时间 ——DATE只精确到秒，应统一用TIMESTAMP(6)
触发器启用状态和容器作用域常被忽略
编译成功 ≠ 生效。很多 DBA 测试时发现日志没写入，第一反应是代码错，其实是触发器根本没跑。
- 查状态必须用：
SELECT trigger_name, status FROM dba_triggers WHERE trigger_name = 'YOUR_TRIGGER_NAME';，结果必须是ENABLED - 多租户环境下，触发器默认只在当前 PDB 生效；如果应用连的是 CDB$ROOT，而触发器建在 PDB1，那它对所有连接都不可见
- SYS 用户登录默认绕过
AFTER LOGON触发器，测试务必用普通用户（如conn hr/hr），别用/ AS SYSDBA
最易漏的一点：Oracle 的 AFTER 触发器仍运行在主事务中，一旦审计表 INSERT 失败（比如空间不足、唯一键冲突），整个 DELETE/UPDATE 就会回滚。真要保审计，得在触发器里套 EXCEPTION WHEN OTHERS THEN NULL;，但这样又失去错误反馈 —— 平衡点只能靠提前建好足够大的表空间、禁用非必要约束、并定期清理归档日志表。
