Oracle触发器默认以DEFINER权限执行，完全忽略会话角色，必须为触发器所有者直接授予所需对象权限（如GRANT SELECT ON hr.employees TO trigger_owner），动态SQL和AUTHID CURRENT_USER在触发器中均不生效。
触发器执行时根本看不到角色权限
Oracle 触发器在运行时默认使用 DEFINER 权限模式，也就是以定义者（即触发器所有者）身份执行。此时它**完全忽略当前会话的角色状态**，哪怕 SESSION_ROLES 里显示你激活了 DBA，只要触发器所有者没被直接授予 CREATE TABLE 或 SELECT ON hr.employees，一碰就报 ORA-01031 或 ORA-00942。
AUTHID CURRENT_USER 在触发器里不生效
你不能给触发器加 AUTHID CURRENT_USER——语法根本不允许。Oracle 明确禁止在触发器定义中指定该属性，尝试写会直接报 PLS-00103 编译错误。所以别想靠“切换权限上下文”绕过限制。
动态 SQL 也救不了触发器里的角色依赖
就算你在触发器里用 EXECUTE IMMEDIATE 执行建表或查跨 schema 表，权限检查依然落在触发器所有者身上：
- 如果语句是
'CREATE TABLE tmp AS SELECT * FROM hr.emp'，需要触发器所有者有CREATE TABLE+SELECT ON hr.emp - 如果只靠角色给了这些权限，而没直授，照样失败
-
EXECUTE IMMEDIATE不会去读调用者的SESSION_ROLES，它只认定义者的静态权限
真正能用的解法只有两个
要么把权限焊死在触发器所有者身上，要么换架构避开触发器：
- 对触发器所有者直授必要权限，例如：
GRANT CREATE TABLE TO trigger_owner、GRANT SELECT ON hr.employees TO trigger_owner - 如果涉及跨 schema 访问，且目标表所有者无法授
WITH GRANT OPTION，那就别在触发器里硬写逻辑——改用应用层调用存储过程，再由该过程设AUTHID CURRENT_USER，并确保调用者已SET ROLE ALL - 切记：触发器里任何对外部对象的引用（包括同义词、视图、序列），都必须能被触发器所有者显式访问，否则编译可能通过，但运行必崩
最常被跳过的其实是依赖链中间环节：比如触发器查一个视图，视图查一张表，表上有行级安全策略或 VPD 策略，而策略函数又调用了某个包——那个包的执行权限是否也已直授？这种嵌套断点不会在 CREATE TRIGGER 时暴露，只在 DML 触发时炸开。
