在pdb中查不到cdb$root创建的公用角色，是因为dba_roles是本地视图，只返回当前容器的角色；需用cdb_roles跨容器查询，且角色使用须满足pdb已打开、授权用户有set container权限、被授权者为common用户等前提。
为什么在cdb$root创建的公用角色，select * from dba_roles 在 pdb 里查不到
因为公用角色（common role）默认只存在于 cdb$root 和所有已打开的 pdb 的数据字典中，但 dba_roles 是本地视图——它只返回当前容器（con_id）下的角色。你在 pdb 中执行该查询，自然看不到 cdb$root 创建的角色，哪怕它带 container = all。
常见错误现象：
- 在 CDB$ROOT 执行
CREATE ROLE c##app_admin CONTAINER = ALL;成功，但切到 PDB 后SELECT ROLE FROM DBA_ROLES WHERE ROLE = 'C##APP_ADMIN';返回空 - 直接
GRANT c##app_admin TO app_user;报ORA-01917: user or role 'C##APP_ADMIN' does not exist - 误以为角色没同步，反复重试或改用双引号、大小写混用，结果仍失败
正确验证方式是查跨容器视图：SELECT ROLE, CON_ID, ORIGIN_CON_ID FROM CDB_ROLES WHERE ROLE = 'C##APP_ADMIN';。你会看到多行记录，CON_ID 对应每个已打开 PDB 的 ID，ORIGIN_CON_ID = 1 表示它源自 CDB$ROOT。
CONTAINER = ALL 不等于“自动可用”，必须满足三个前提
CONTAINER = ALL 只控制角色定义的传播范围，不解决权限可见性或启用问题。以下任一缺失都会导致角色在 PDB 中“看不见”或“用不了”：
- 目标 PDB 必须处于
OPEN状态（SELECT NAME, OPEN_MODE FROM V$PDBS验证），MOUNTED或RESTRICTED下角色元数据不会加载 - 执行
GRANT的用户必须拥有SET CONTAINER权限（如SYS或显式授过该权限的账号），否则无法在 PDB 上对公用角色授权 - 被授权用户（
app_user）本身要是common user（即用户名以c##开头），否则ORA-65094: invalid local username；本地用户不能被授予公用角色
例如，在 PDB 中运行：GRANT c##app_admin TO app_user; —— 如果 app_user 是本地用户（没 c## 前缀），这条语句会直接报错，和角色是否存在无关。
在 PDB 中给本地用户授权，别碰 CONTAINER = ALL
如果你只是想让某个 PDB 内的本地用户（比如 app_user）拥有特定权限，就不要创建公用角色，也别用 CONTAINER = ALL。那不是设计用途，反而引发错误：
-
CREATE ROLE app_admin;（不加c##，不加CONTAINER）→ 在当前 PDB 创建本地角色 -
GRANT SELECT ON hr.employees TO app_admin;→ 授对象权限 -
GRANT CREATE SESSION, CREATE TABLE TO app_admin;→ 授系统权限 -
GRANT app_admin TO app_user;→ 最后把本地角色赋给本地用户
这种组合完全绕开多租户命名与作用域陷阱，且权限严格限定在本 PDB 内。强行把本地用户塞进公用角色体系，只会触发 ORA-65094、ORA-01917 或权限失效等连锁问题。
真正容易被忽略的一点：角色名大小写和引号
公用角色名在 CDB$ROOT 中创建时，Oracle 默认转为大写存储。所以 CREATE ROLE c##reader CONTAINER = ALL; 实际存为 C##READER。你在 PDB 中 GRANT 时写 GRANT c##reader TO ... 没问题（大小写不敏感），但若当初用了双引号：CREATE ROLE "c##reader" CONTAINER = ALL;，那它就严格按小写存，后续所有引用都必须带引号，漏一个就报 ORA-01917。
这不是 bug，是 Oracle 对标识符的统一处理逻辑。建议统一用小写无引号方式创建公用角色，避免在脚本、CI/CD 或跨环境迁移时因大小写解析差异出问题。
