Oracle 19c多租户权限隔离依赖容器边界、角色类型和授权作用域三层显式控制，缺一不可；公共用户须在CDB$ROOT创建且以C##开头并配CONTAINER=ALL，本地用户仅限PDB内创建；授予权限时CONTAINER子句决定生效范围，误用将导致ORA-01045等权限失效。
在 oracle 19c 多租户中，用户权限隔离不是靠“自动生效”，而是靠三层显式控制：容器边界（cdb/pdb）、角色类型（公用/本地）、授权作用域（container = all 或 current）。漏掉任意一层，权限就可能跨库泄露或完全失效。
创建用户时必须区分 CDB 和 PDB 两级命名与位置
公共用户只能在 CDB$ROOT 创建，且用户名必须以 C## 或 c## 开头；本地用户只能在具体 PDB 内创建，命名无此限制，但不能与公共用户同名（否则登录时会冲突）。
常见错误现象：ORA-65096: invalid common user or role name —— 在 PDB 中执行 CREATE USER c##appuser...；或在 CDB$ROOT 执行 CREATE USER appuser... 后，误以为该用户能在所有 PDB 登录。
- 公共用户示例：
CREATE USER c##admin IDENTIFIED BY pwd CONTAINER = ALL;（必须加CONTAINER = ALL才能跨 PDB 存在） - 本地用户示例：先
ALTER SESSION SET CONTAINER = salespdb;，再CREATE USER sales_app IDENTIFIED BY pwd; - 切记：公共用户账户本身存在所有容器，但默认没有任何权限——包括
CREATE SESSION，必须单独授予
授角色时 CONTAINER 子句决定权限是否跨 PDB
角色本身是“公用”还是“本地”，和“把角色授给谁”无关，只取决于 GRANT ... TO ... CONTAINER = ? 的写法。同一角色，用不同 CONTAINER 授予，行为完全不同。
典型错误：给公共用户 c##dba 授了 DBA 角色，却用 CONTAINER = CURRENT，结果该用户进任何 PDB 都报 ORA-01045: user lacks CREATE SESSION privilege。
-
GRANT CONNECT TO c##dba CONTAINER = ALL;→ 用户在所有 PDB 都能登录 -
GRANT DBA TO c##dba CONTAINER = ALL;→ 用户在所有 PDB 都有 DBA 权限（慎用） -
GRANT hr_manager TO sales_user CONTAINER = CURRENT;→ 仅在当前 PDB 生效，且hr_manager必须是本地角色（不能是C##开头的公用角色） - 即使角色是公用的（如
C##HR_ROLE），若用CONTAINER = CURRENT授予，也只在当前容器生效
PDB 级资源限制与权限协同才真正实现隔离
光靠权限控制不够，PDB 自身的存储和内存上限必须设好，否则高权限用户可能耗尽整个 CDB 的资源。权限 + 资源配额才是完整隔离。
容易被忽略的点：STORAGE(MAXSIZE) 是 PDB 级硬限制，但表空间配额（QUOTA）是用户级软限制，两者要配合使用。只设表空间配额，用户仍可通过创建多个对象绕过；只设 PDB 总上限，又无法约束单个用户滥用。
- 建 PDB 时限制总容量：
CREATE PLUGGABLE DATABASE finpdb ADMIN USER finadm IDENTIFIED BY pwd STORAGE (MAXSIZE 50G); - 在 PDB 内限制用户空间：
ALTER USER fin_app QUOTA 2G ON users; - 动态调整 PDB 内存上限：
ALTER SYSTEM SET SGA_TARGET = 1G SCOPE = BOTH;（需先ALTER SESSION SET CONTAINER = finpdb） - 验证当前 PDB 实际使用：
SELECT con_id, pdb_name, total_size FROM cdb_pdbs;
最常被跳过的动作：确认 CON_ID 和当前容器状态。几乎所有权限问题，根源都是在错误容器里执行了 DDL 或 DCL。每次执行前，务必跑一遍 SHOW CON_NAME 和 SELECT SYS_CONTEXT('USERENV', 'CON_ID') FROM DUAL; —— 这不是仪式感，是唯一能避免“明明写了权限却不起作用”的底线操作。
