PL/SQL触发器中禁止COMMIT/ROLLBACK，因其无独立事务上下文，须与宿主DML共享事务；唯一合法绕过方式是声明PRAGMA AUTONOMOUS_TRANSACTION，开启完全隔离的新事务并显式提交。
PL/SQL触发器中不能写 COMMIT 或 ROLLBACK，不是语法限制松紧的问题，而是事务模型根本没给它留出口——它压根没有自己的事务上下文。
触发器和宿主DML共享同一个事务ID
当你执行一条 INSERT INTO orders，Oracle 启动一个事务；这个事务的 ID、undo log、隔离快照，全部被随后触发的 BEFORE INSERT 触发器继承。触发器里所有语句（比如往 audit_log 插一条记录）都自动绑定在这个事务上。
你写 COMMIT，等于试图把“部分变更”钉死，但此时主语句还没执行完——数据库无法判断后续是否失败，强行提交会导致数据不一致。所以 Oracle 在解析阶段就拦截，报 ORA-04092: cannot commit in a trigger。
- 哪怕用
EXECUTE IMMEDIATE 'COMMIT'，也会在编译时报错，不是运行时 -
TRUNCATE TABLE、CREATE INDEX这类 DDL 会隐式提交，同样触发该错误 - 系统级触发器（如
AFTER STARTUP）除外，它不依附于任何 DML 事务
自治事务是唯一合法绕过方式，但不是“子事务”
如果你真需要在触发器里持久化日志、发通知或调用外部服务，必须显式声明 PRAGMA AUTONOMOUS_TRANSACTION，且必须放在声明区第一行：
CREATE OR REPLACE TRIGGER log_order_insert
BEFORE INSERT ON orders
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION; -- 必须第一行
v_id NUMBER;
BEGIN
INSERT INTO audit_log (msg) VALUES ('order inserted');
COMMIT; -- 必须手动提交，否则退出时自动回滚
END;注意：PRAGMA AUTONOMOUS_TRANSACTION 开启的是**全新事务**，和宿主事务完全隔离：
- 它有自己的 undo log、SCN、锁空间，不影响主事务的可见性或阻塞状态
- 它必须显式
COMMIT或ROLLBACK，否则退出时自动回滚（日志全丢） - 它调用的其他存储过程，若没加同样
PRAGMA，仍属于该自治事务，不是再嵌套一层
误用非事务操作，比写 COMMIT 更危险
很多人以为“只要不碰 COMMIT 就安全”，却在触发器里调用 UTL_HTTP.request、写文件、甚至只做一次 SELECT FOR UPDATE——这些动作都不受主事务保护：
-
UTL_HTTP发出的请求一旦发出就不可撤回，ROLLBACK对它完全无效 -
SELECT FOR UPDATE可能触发隐式提交（尤其跨表或含子查询时），导致前面所有 DML 提前落盘 - 哪怕只是
DBMS_OUTPUT.PUT_LINE，在某些调试配置下也可能引发缓冲区刷新副作用
真正要验证事务是否还在跑，得靠 SELECT * FROM V$TRANSACTION 或 SELECT * FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV', 'SID') 查 TADDR 字段，不能凭“没写 COMMIT”就默认安全。
