alter user default role 会完全重置默认角色列表，而非追加；密码认证角色不可设为默认；验证需查session_roles而非role_role_privs；连接池中默认角色仅在新建连接时生效。
alter user default role 会覆盖所有已有默认角色
执行 alter user default role 时，oracle 不是“追加”，而是**完全重置**当前用户的默认角色列表。哪怕只加一个新角色，原来设为默认的其他角色也会被自动取消默认状态。
- 错误做法：
ALTER USER scott DEFAULT ROLE CONNECT;—— 这会让scott只有CONNECT是默认角色，即使之前还默认启用了RESOURCE或自定义角色 - 正确做法：必须显式列出所有你想保留为默认的角色，例如：
ALTER USER scott DEFAULT ROLE CONNECT, RESOURCE, my_app_role; - 若想清空所有默认角色（即登录后不自动启用任何角色），必须写成：
ALTER USER scott DEFAULT ROLE NONE;，不能省略或写DEFAULT ROLE []等无效语法
DEFAULT ROLE 对角色中带密码的角色无效
如果某个角色是用 IDENTIFIED BY 创建的（比如 CREATE ROLE mgr_role IDENTIFIED BY mgr123;），它**永远不能被设为默认角色**。执行 ALTER USER ... DEFAULT ROLE 时包含该角色，语句会直接报错：ORA-01957: cannot specify password-authenticated role in DEFAULT ROLE。
- 这是 Oracle 的硬性限制，和权限无关，也和用户是否知道密码无关
- 这类角色只能通过
SET ROLE mgr_role IDENTIFIED BY mgr123;在会话中手动启用 - 如果你依赖默认角色简化日常操作，就不要给业务角色设密码；密码角色更适合临时提权或审计敏感操作场景
验证默认角色是否生效，别只看 ROLE_ROLE_PRIVS
ROLE_ROLE_PRIVS 视图只展示“谁被授予了哪个角色”，不反映“哪个角色被设为默认”。真正体现默认状态的是 SESSION_ROLES（当前会话已启用的角色）和 DBA_USERS 中的 DEFAULT_ROLE 列。
- 查当前用户默认角色配置：
SELECT default_role FROM dba_users WHERE username = 'SCOTT';—— 返回值可能是YES、NO或具体角色列表（取决于 Oracle 版本） - 更可靠的方式是登录目标用户后执行：
SELECT * FROM session_roles;，只有出现在这里的角色才是本次连接实际默认启用的 - 注意：
SESSION_ROLES结果受ALTER SESSION SET ROLE影响，测试前确保没手动切换过角色
应用部署时容易忽略角色启用时机
Web 应用或中间件（如 Tomcat + JDBC）通常复用连接池，而 Oracle 的默认角色只在**新连接建立时**由服务端自动启用。如果连接被池化复用，且之前被 SET ROLE NONE 关闭过角色，后续请求可能意外缺失权限。
- 典型现象：SQL Developer 登录正常，但 Java 应用报
ORA-00942: table or view does not exist，尽管表权限已通过角色授予 - 排查点：检查应用连接字符串是否含
defaultRowPrefetch类干扰项；更关键的是确认连接池是否开启了 “reconnect on failure” 或 “init SQL” 功能 - 稳妥方案：在数据源初始化 SQL 中加入
SET ROLE ALL;（需用户有相应权限），或改用直接授权（GRANT SELECT ON ... TO user;）替代角色间接授权
角色默认状态不是“设一次就永久生效”的静态配置，它和连接生命周期、角色认证方式、客户端行为都耦合紧密。尤其在容器化或连接池场景下，光看 ALTER USER 语句是否执行成功远远不够。
