不能直接用 CREATE USER 加 GRANT CONNECT, RESOURCE，因二者是19c中已标记为legacy的预定义角色：RESOURCE隐式授予UNLIMITED TABLESPACE引发磁盘耗尽风险，CONNECT仍含CREATE VIEW等非必要权限，且均缺失失败登录限制、密码过期等等保三级必需策略；必须改用自定义PROFILE控制密码生命周期、显式QUOTA隔离空间、最小权限角色授予权限，并确保连接池正确激活角色。
直接给结论：不能用 CREATE USER 加 GRANT CONNECT, RESOURCE 了事；必须显式创建最小权限角色、绑定 PROFILE 控制密码生命周期、禁用 ANY 权限、配额隔离表空间，且连接池初始化时需避免复用已授权会话的权限上下文。
为什么不能直接用 CONNECT/RESOURCE 角色
这两个预定义角色在 Oracle 19c 中已被标记为“legacy”，且实际包含大量冗余甚至危险权限：
-
RESOURCE隐式授予UNLIMITED TABLESPACE，一旦账号被攻破，攻击者可填满磁盘触发拒绝服务 - 两者都未限制失败登录次数或密码过期策略，不符合等保三级对口令周期和锁定的要求
-
CONNECT在 19c 中仍保留CREATE VIEW、CREATE SYNONYM等非必要能力，与应用只读/增删改场景严重不匹配
创建专用用户必须带 PROFILE 和 QUOTA
PROFILE 不是可选项，而是强制控制点。以下语句才是生产可用的起点：
CREATE PROFILE app_pool_profile LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_TIME 365 PASSWORD_LOCK_TIME 1/24 PASSWORD_GRACE_TIME 7;
配套用户创建要明确约束空间和初始状态：
-
QUOTA 500M ON users—— 防止应用逻辑缺陷导致无限插入耗尽表空间 -
PASSWORD EXPIRE—— 强制首次连接时调用ALTER USER ... IDENTIFIED BY修改密码（JDBC 连接池需配合connectionInitSql执行） - 必须指定
DEFAULT TABLESPACE和TEMPORARY TABLESPACE，避免继承 SYSTEM 或默认临时表空间引发争用
权限必须通过自定义角色授予，且禁用 ANY 权限
直接 GRANT SELECT ON schema_a.orders TO app_user 是错的——批量维护不可行，也不满足 RBAC 原则。正确路径是：
- 用
CREATE ROLE app_rw_role显式声明角色，不设口令（除非跨服务共享） - 逐个
GRANT SELECT, INSERT, UPDATE ON schema_a.orders TO app_rw_role，绝不出现SELECT ANY TABLE - 检查是否误授系统权限：
SELECT * FROM ROLE_SYS_PRIVS WHERE role = 'APP_RW_ROLE'，结果必须为空 - 最后
GRANT app_rw_role TO app_user，而非直接授对象权限
注意：新授角色对已建立的连接池连接不生效，必须重启连接池或执行 SET ROLE ALL（部分连接池如 HikariCP 支持 connectionInitSql 自动触发）。
连接池初始化阶段容易忽略的权限上下文问题
JDBC 连接池（如 HikariCP、Druid）默认复用物理连接，但 Oracle 的角色激活状态是会话级的。常见陷阱：
- 若用户未默认启用角色（
ALTER USER app_user DEFAULT ROLE ALL），每次 getConnection() 返回的连接可能无权访问表 - Spring Boot 的
spring.datasource.hikari.connection-init-sql=SET ROLE app_rw_role只在初始化连接时执行，但若连接被连接池回收后重用，角色状态不会自动恢复 - 更稳妥的做法是：建用户时加
DEFAULT ROLE app_rw_role，并确保连接池配置isReadOnly=false（否则某些驱动会跳过角色激活）
最易被忽略的一点：Oracle 19c 多租户环境下，若应用用户在 CDB$ROOT 创建，却试图访问 PDB 中的对象，必须确认该用户已通过 ALTER SESSION SET CONTAINER = pdb_name 切换容器，或直接在目标 PDB 内创建用户。
