container=all 不自动同步所有pdb权限，仅对create user和grant语句生效，且只遍历当前open状态的pdb；mounted或restricted状态的pdb会被跳过，不报错；本地用户授权必须先alter session set container到对应pdb。
不能直接批量同步，必须分容器显式授权 —— CONTAINER=ALL 不等于“自动同步所有PDB权限”，它只对 CREATE USER 和 GRANT 语句生效时起作用，且仅限于当前已存在、且处于 OPEN 状态的 PDB。
CONTAINER=ALL 的真实行为
当你在 CDB$ROOT 中执行 GRANT CONNECT TO C##USER CONTAINER=ALL，Oracle 实际做的是：遍历所有 CON_ID 对应的容器（包括 CDB$ROOT 和每个 OPEN 状态的 PDB），并在每个容器中单独执行一次 GRANT。如果某个 PDB 处于 MOUNTED 或 RESTRICTED 状态，该 PDB 内的授权会跳过，不报错也不提示。
- 常见错误现象：
GRANT ... CONTAINER=ALL执行成功，但登录某 PDB 时仍报ORA-01045: user C##USER lacks CREATE SESSION privilege - 使用场景：适合新创建完 PDB 并已
ALTER PLUGGABLE DATABASE xxx OPEN后的集中授权 - 性能影响：CONTAINER=ALL 会触发 N+1 次权限写入（N = OPEN 的 PDB 数量），对含 20+ PDB 的 CDB 有明显延迟
- 关键限制：
CONTAINER=ALL仅适用于 DDL 类权限语句（GRANT/REVOKE），不适用于ALTER USER、PROFILE修改等操作
为什么 ALTER SESSION SET CONTAINER 后再 GRANT 更可靠
手动切换容器执行授权，能精确控制目标 PDB 状态、避免隐式跳过，并支持非标准权限（如对象级授权）。这是生产环境推荐的落地方式。
- 必须先确认 PDB 已 OPEN：
SELECT CON_ID, NAME, OPEN_MODE FROM V$PDBS WHERE NAME = 'XEPDB1'，确保返回READ WRITE - 切换后执行授权：
ALTER SESSION SET CONTAINER=XEPDB1→GRANT CONNECT, RESOURCE TO C##USER - 若需批量处理多个 PDB，可用脚本生成语句：
SELECT 'ALTER SESSION SET CONTAINER=' || NAME || '; GRANT CONNECT TO C##USER;' FROM V$PDBS WHERE OPEN_MODE = 'READ WRITE'; - 容易踩的坑：在未
ALTER SESSION的情况下，误以为GRANT ... CONTAINER=CURRENT会作用于当前连接的 PDB —— 实际上，除非显式切换，否则默认始终在 CDB$ROOT 上下文
本地用户无法用 CONTAINER=ALL 授权
本地用户（如 SCOTT）只存在于单个 PDB，其创建和授权必须在对应 PDB 内完成，CONTAINER=ALL 对其无效，强行使用会报 ORA-65048: error encountered when processing statement in container X。
- 验证是否为本地用户：
SELECT USERNAME, COMMON FROM CDB_USERS WHERE USERNAME = 'SCOTT'，若COMMON = 'NO'则为本地用户 - 正确做法：先
ALTER SESSION SET CONTAINER=PDB_NAME，再CREATE USER SCOTT IDENTIFIED BY tiger，然后在同一会话内GRANT ... TO SCOTT - 参数差异：
CREATE USER在 PDB 中无需C##前缀；在 CDB$ROOT 中创建则强制要求 - 兼容性注意：Oracle 12.1 不支持 PDB 内创建公共用户；12.2+ 允许但需显式指定
CONTAINER=CURRENT，且该用户仅存在于当前 PDB（非真正“公共”）
最易被忽略的一点：PDB 的 OPEN 模式不是永久状态。服务器重启后，PDB 默认为 MOUNTED，此时 CONTAINER=ALL 授权完全失效 —— 必须配合 ALTER PLUGGABLE DATABASE ALL OPEN 或设置 STARTUP TRIGGER，否则每次重启都得重跑授权逻辑。
