不能直接激活，但可间接实现：after logon触发器无法执行set role，但能通过alter user修改默认角色（下次登录生效）或调用安全应用程序角色启用过程。
Oracle 登录触发器能自动激活角色吗？不能直接激活，但可以间接实现
Oracle 的 AFTER LOGON 触发器本身无法执行 SET ROLE（该语句只能在会话中由用户显式调用或通过应用程序发送），也不能在触发器内提交事务或调用会话级 DDL。所以「登录即自动启用某角色」这个需求，不能靠触发器内部直接调用 SET ROLE 完成。真实可行路径是：用登录触发器检查条件 → 修改用户默认角色配置（需 DBA 权限）→ 下次登录生效；或配合应用层，在首次查询前注入 SET ROLE 语句。
使用 AFTER LOGON ON DATABASE 触发器动态设置默认角色
这是最接近“动态激活”的标准做法：在用户登录后，根据其属性（如 IP、时间、用户组）决定是否将其某个角色设为默认角色。注意：这需要 ALTER USER 权限，且修改的是用户元数据，不是当前会话。
- 触发器必须用
CREATE OR REPLACE TRIGGER ... AFTER LOGON ON DATABASE创建，且需以具有ADMINISTER DATABASE TRIGGER权限的用户（如SYS）执行 - 不能在触发器里直接执行
SET ROLE，但可调用DBMS_SCHEDULER或写入中间表，再由外部调度任务批量执行ALTER USER ... DEFAULT ROLE - 更实用的做法是：把角色启用逻辑下沉到连接池或应用初始化脚本中，在
SELECT 1 FROM DUAL后立即执行SET ROLE role_name IDENTIFIED BY password（如果角色带密码） - 若角色是安全应用程序角色（Secure Application Role），则必须通过指定的 PL/SQL 过程启用 —— 此时可在登录触发器中调用该过程（前提是该过程不依赖会话状态且已授予权限）
ORA_LOGIN_USER 和 ORA_CLIENT_IP_ADDRESS 在登录触发器中的实际用途
这两个系统变量仅在数据库级触发器（ON DATABASE）中可用，是判断上下文的关键依据。但要注意它们的值受限于网络配置：
-
ORA_LOGIN_USER返回实际登录用户名（非代理用户），可用于匹配USER_ROLE_PRIVS视图判断该用户是否已被授予目标角色 -
ORA_CLIENT_IP_ADDRESS在直连场景下有效；若经负载均衡或 Oracle Connection Manager，则可能返回中间节点 IP，需配合DBMS_APPLICATION_INFO.SET_CLIENT_INFO由应用层透传真实终端标识 - 不要在触发器中对这些变量做复杂逻辑（如远程 HTTP 请求、长事务更新），否则会导致登录卡顿甚至超时失败
- 示例判断逻辑：
IF ORA_LOGIN_USER = 'APP_USER' AND ORA_CLIENT_IP_ADDRESS LIKE '192.168.10.%' THEN EXECUTE IMMEDIATE 'ALTER USER ' || ORA_LOGIN_USER || ' DEFAULT ROLE app_reader_role'; END IF;
（⚠️该语句需触发器拥有ALTER ANY USER权限，且应避免高频执行）
为什么不用 BEFORE LOGON？它根本拿不到 ORA_LOGIN_USER
BEFORE LOGON 触发器在身份验证完成前触发，此时 Oracle 尚未确定登录主体，ORA_LOGIN_USER 值为空或不可靠，ORA_CLIENT_IP_ADDRESS 也可能未就绪。所有依赖用户身份的动态决策都必须放在 AFTER LOGON 中。
另外，AFTER LOGON 触发器中的异常（如 RAISE_APPLICATION_ERROR）不会导致登录失败，只会写入告警日志 —— 所以它不适合做访问控制（如“禁止某 IP 登录”），这类需求必须用 BEFORE LOGON + 网络层策略或细粒度访问控制（FGAC）替代。
真正容易被忽略的是权限继承链：即使你在触发器里成功执行了 ALTER USER ... DEFAULT ROLE，该用户下次登录才生效；而当前会话的角色集仍按登录瞬间的默认角色快照加载 —— 这个时间差必须由应用自行处理。
