Oracle触发器无法挂起事务，须用“拦截+记录+异步调度”：BEFORE触发器校验并阻止非法变更，AFTER触发器写入审批表且共享事务，外部服务轮询驱动审批。
Oracle 触发器本身不能“挂起”事务或阻塞执行流等待人工审批——它运行在数据库事务上下文中，必须同步完成，否则会直接报错或回滚。真要实现审批流控制，得绕开“挂起”这个不现实的设想，转为“拦截 + 记录 + 异步调度”三步走。
BEFORE 触发器里不能调用 DBMS_SCHEDULER 或发起 HTTP 请求
很多人想在 BEFORE UPDATE 里直接调用审批系统接口，或者用 DBMS_SCHEDULER.CREATE_JOB 推送待办。这会失败，因为：
-
DBMS_SCHEDULER创建作业需要 COMMIT，而 BEFORE 触发器处于未提交事务中，不允许提交 - 网络 I/O（如 UTL_HTTP）在触发器中被 Oracle 明确禁止，会抛出
ORA-06502或ORA-29273 - 任何耗时操作都会拖慢主 DML，导致锁等待加剧，尤其在高并发更新敏感字段（如
salary、status）时
真正可行的拦截模式：用状态字段 + AFTER 触发器落库 + 外部轮询
核心是把“审批中”状态固化到业务表本身，让触发器只做两件事：拦住非法变更、记下待审记录。后续由外部服务（不是触发器）查表驱动流程。
- 给目标表加一个
approval_status VARCHAR2(20) DEFAULT 'APPROVED'字段，取值如'PENDING'、'APPROVED'、'REJECTED' - 在
BEFORE UPDATE中检查：如果用户试图直接改敏感列（如UPDATE employees SET salary = 20000 WHERE emp_id = 101），且当前:OLD.approval_status = 'APPROVED'，就用RAISE_APPLICATION_ERROR(-20002, 'Salary change requires approval')拦住 - 另建一个审批申请表
approval_requests，含table_name、row_id、requested_value、request_time等字段 - 在
AFTER UPDATE（或单独的INSTEAD OF视图触发器）里，把变更写入approval_requests并设approval_status = 'PENDING'—— 这一步能成功，因为 AFTER 已在事务内，可安全 INSERT
为什么不用 INSTEAD OF 触发器直接接管 UPDATE？
有人想用 INSTEAD OF UPDATE 在视图上完全替代原语句，看起来更干净。但要注意：
-
INSTEAD OF只能建在视图上，不能建在表上；你得额外维护一个与原表结构一致的视图，增加对象管理成本 - 触发器内部仍不能做 COMMIT 或远程调用，所以它顶多把数据暂存到中间表，还是得靠外部服务驱动审批
- 如果业务代码里混用表和视图（比如 ORM 默认映射到表），容易漏掉触发逻辑，导致审批被绕过
- 调试困难：错误堆栈里看不到原始 SQL，只有触发器里的 PL/SQL 行号
最易被忽略的事务边界问题
所有写进 approval_requests 的记录，必须和主表更新在同一个事务里提交或回滚。否则会出现“审批单生成了，但主表没改成功”，或者“主表改了，但审批单丢了”。这意味着：
- 不要在触发器里写
INSERT INTO approval_requests ...; COMMIT;—— 这会报错 - 也不要依赖自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）来单独提交审批单，否则审批单无法随主事务回滚，数据会不一致 - 正确做法是：只做 INSERT，让 Oracle 自动把它绑进当前事务；外部服务轮询时，只查
approval_status = 'PENDING'且已 COMMIT 的记录
