不能在DELETE触发器中使用ROLLBACK，因ORA-04092禁止DML触发器显式事务控制；唯一合法中断方式是RAISE_APPLICATION_ERROR，配合SESSION_USER、对象属主等条件精准拦截非法全表删除，并需以权限管控为首要防线。
为什么不能在DELETE触发器里写ROLLBACK
行级 BEFORE DELETE 触发器中执行 ROLLBACK 会直接报错 ORA-04092，因为 DML 触发器不允许显式事务控制。DDL 触发器也不行，更别说隐式提交的上下文了。唯一合法且生效的中断方式是 RAISE_APPLICATION_ERROR，它会让整个语句失败并回退到语句前状态。
如何精准拦截非授权用户的全表DELETE
重点不是“拦所有 DELETE”，而是识别哪些 DELETE 是非法的——比如普通应用用户对核心表发起无 WHERE 条件的删除。实际要结合以下判断：
-
DELETING条件谓词必须为真（确保是 DELETE 操作） -
SYS_CONTEXT('USERENV', 'SESSION_USER')不在白名单（如'APP_USER','WEB_SERVICE'） -
ora_dict_obj_owner属主匹配目标 schema（如UPPER(ora_dict_obj_owner()) = 'CORE'） - 避免用
WHEN (DELETING)简单兜底：它无法区分DELETE FROM t和DELETE FROM t WHERE id = 1
示例片段：
CREATE OR REPLACE TRIGGER prevent_core_table_delete
BEFORE DELETE ON core.users
FOR EACH ROW
DECLARE
v_user VARCHAR2(30) := SYS_CONTEXT('USERENV', 'SESSION_USER');
BEGIN
IF v_user NOT IN ('SYS', 'DBA_ADMIN') THEN
RAISE_APPLICATION_ERROR(-20001, 'DELETE on CORE.USERS not allowed for ' || v_user);
END IF;
END;
误删防护不能只靠触发器，权限才是第一道防线
触发器是补救手段，不是替代方案。真正该做的前置控制包括：
- 生产账号不授予
DELETE ANY TABLE或DBA角色 - 对高危表只授
SELECT和INSERT，显式拒掉UPDATE/DELETE - 若必须支持部分更新，用存储过程封装逻辑，而非开放直连 DML
- 触发器仅作为兜底：防绕过应用层、防 DBA 临时提权误操作
注意：GRANT DELETE ON core.users TO app_user 这种授权一旦存在，触发器就得全程扛住压力——它不会因为权限被收就自动失效。
容易被忽略的兼容性与调试陷阱
上线前必须验证这些细节，否则等于没拦：
- 错误号必须落在
-20001到-20999区间，否则抛出的是ORA-21700而非你预期的拦截提示 -
ora_dict_obj_name()和ora_dict_obj_owner()在 DDL 触发器中才可用，在 DML 触发器中不可用——别抄混了 - 测试时一定要用真实业务账号连接（不是
/ AS SYSDBA），否则看到的全是“权限不足”，不是触发器生效 -
DBMS_OUTPUT.PUT_LINE在触发器里完全静默，别指望它打日志来确认是否运行
最常踩的坑是：写了触发器，但没检查 SESSION_USER 实际值大小写，或把 UPPER() 忘了，导致白名单判断永远失败。
