语句级触发器在整条DML语句执行完毕后触发一次，不依赖行数；关键区别在于它不可访问:NEW/:OLD，仅能用INSERTING/UPDATING/DELETING和SQL%ROWCOUNT，且必须显式声明FOR EACH STATEMENT。
什么是语句级触发器：和行级触发器的关键区别
语句级触发器在整条 insert、update 或 delete 语句执行完毕后触发一次，不管它影响了多少行；而行级触发器对每一行都触发一次。如果你只想记录“谁在什么时候执行了哪条修改语句”，而不是“哪几行被改了”，就必须用语句级——否则日志会爆炸式膨胀，还可能因 :new/:old 在语句级不可用而报 ora-04082: reference to a column in a trigger is not allowed。
常见错误现象：
– 在 BEFORE STATEMENT 里写 IF :NEW.id IS NOT NULL THEN ...
– 把本该用 AFTER STATEMENT 记录操作元信息（如 USER、SYSDATE、SQL%ROWCOUNT）的逻辑，错放到行级触发器里
- 语句级触发器中不能访问
:NEW和:OLD，只可读INSERTING/UPDATING/DELETING布尔变量 - 想记录影响行数？用
SQL%ROWCOUNT，但它必须在触发器体中立即读取（不能放在函数调用后再查） - Oracle 12c+ 支持
DBMS_UTILITY.FORMAT_CALL_STACK，但语句级触发器里拿不到调用 SQL 文本，别白费劲
怎么写一个最小可用的语句级审计触发器
核心是声明 FOR EACH STATEMENT，并用 AFTER 阶段保证操作已提交（或回滚）完成，日志才落盘。别用 BEFORE——它无法反映最终是否成功，且容易因异常中断导致日志缺失。
示例：监控 orders 表的 DML 操作
CREATE OR REPLACE TRIGGER log_orders_statement
AFTER INSERT OR UPDATE OR DELETE ON orders
FOR EACH STATEMENT
DECLARE
v_op VARCHAR2(10);
v_rows NUMBER := SQL%ROWCOUNT;
BEGIN
IF INSERTING THEN v_op := 'INSERT';
ELSIF UPDATING THEN v_op := 'UPDATE';
ELSIF DELETING THEN v_op := 'DELETE';
END IF;
INSERT INTO audit_log (table_name, operation, op_user, op_time, rows_affected)
VALUES ('orders', v_op, USER, SYSDATE, v_rows);
END;
- 必须显式声明
FOR EACH STATEMENT，漏写就默认变成行级 -
SQL%ROWCOUNT在触发器体第一行就读，避免被后续INSERT覆盖 - 日志表
audit_log的rows_affected字段建议用NUMBER，别用VARCHAR2存数字字符串
为什么触发器没生效：权限与启用状态检查清单
即使语法全对，语句级触发器也可能静默失效。最常被忽略的是：触发器本身被禁用，或者创建者没有 CREATE ANY TRIGGER 权限导致依赖对象（如日志表）不可见。
常见错误现象：
– 执行 INSERT 后查 audit_log 空空如也
– SELECT status FROM user_triggers WHERE trigger_name = 'LOG_ORDERS_STATEMENT' 返回 DISABLED
– 日志表 audit_log 在另一个 schema 下，但触发器里没加 schema 前缀，报 ORA-00942: table or view does not exist
- 新建触发器默认启用，但迁移或脚本重跑时可能带
DISABLE子句，执行前先确认：ALTER TRIGGER log_orders_statement ENABLE - 如果日志表不在当前用户下，必须写成
schema_name.audit_log，且触发器所有者要有INSERT权限（不是SELECT） - 应用连接用的是普通用户，但触发器由
DBA创建？检查user_triggers视图是否能查到该触发器——查不到说明不是当前用户所有
性能和维护风险：语句级触发器的真实代价
它不逐行触发，但每次 DML 都强制多一次 INSERT 到日志表，IO 和锁开销实实在在。尤其在批量导入场景（比如 INSERT /*+ APPEND */ INTO ... SELECT），单条语句影响百万行，触发器只执行一次看似轻量，但日志表的插入可能成为瓶颈，特别是没建索引或归档策略缺失时。
- 日志表务必加主键（如自增
ID）和时间字段索引：CREATE INDEX idx_audit_time ON audit_log(op_time) - 别在触发器里调用远程 DBLINK 或外部 HTTP 接口——超时会卡住整个 DML
- 生产环境上线前，用
EXPLAIN PLAN看看日志表 INSERT 是否走索引，避免全表扫描拖慢语句级触发
真正难处理的从来不是怎么写，而是日志表爆满后怎么清理、历史数据如何分区、以及当业务要求“只审计特定条件语句”时，你得在触发器里加一堆 IF 判断——这时候就得考虑用 DBMS_FGA 细粒度审计替代了。
