Oracle不支持跨PDB直接授权，GRANT语句必须在目标PDB内执行且对象须存在于该PDB中；在CDB$ROOT执行GRANT SELECT ON hr.emp会报ORA-00942，因对象不可见。
不能跨PDB直接授予查询权限——Oracle不支持跨容器对象授权，所有GRANT语句必须在目标PDB内执行，且对象必须存在于该PDB中。
为什么 GRANT SELECT ON hr.emp TO user_a 在 CDB$ROOT 里报 ORA-00942
执行者当前容器是 CDB$ROOT，而 hr.emp 实际属于某个 PDB（比如 HRPDB），CDB$ROOT 中根本看不到这个表。Oracle 的对象可见性严格受限于容器边界：dba_tables 在 CDB$ROOT 查的是所有 PDB 的元数据，但你不能用它来直接授权跨容器对象。
常见错误现象：
- 在 CDB$ROOT 执行
GRANT SELECT ON hr.emp TO user_a→ 报ORA-00942: table or view does not exist - 在 CDB$ROOT 查
SELECT * FROM hr.emp→ 同样报错，除非已ALTER SESSION SET CONTAINER = HRPDB - 误以为创建了公共用户
c##user_a就能天然访问所有 PDB 的表 → 实际上连CREATE SESSION都没授，根本登不进任何 PDB
正确做法：先切到目标PDB，再对本地对象授权
授权动作必须发生在目标表所在的 PDB 内部。假设你要让 user_a 查询 HRPDB 中 hr 用户下的所有表，操作顺序如下：
以具备 DBA 权限的账号（如 SYS）登录：
sqlplus / as sysdba
切换容器并确认位置：
ALTER SESSION SET CONTAINER = HRPDB;<br>SHOW CON_NAME;
此时才能安全执行授权。两种常用方式：
- 单表授权：
GRANT SELECT ON hr.employees TO user_a; - 批量授权（需动态 SQL）：
BEGIN<br> FOR r IN (SELECT 'GRANT SELECT ON hr.' || table_name || ' TO user_a;' stmt<br> FROM dba_tables<br> WHERE owner = 'HR' AND nested = 'NO' AND temporary = 'N') LOOP<br> EXECUTE IMMEDIATE r.stmt;<br> END LOOP;<br>END;
注意：dba_tables 在 PDB 内查出的是本 PDB 的表；普通用户应改用 all_tables，但仅限自己有权限看到的对象。
跨PDB访问的替代方案：数据库链接 + 同义词（非授权）
如果业务确实需要从 PDB A 的用户访问 PDB B 的表，Oracle 不提供“跨PDB授权”，但允许通过数据库链接间接访问。前提是：
- PDB B 中已为源用户（如
hr）授予CREATE DATABASE LINK权限 - PDB A 中创建指向 PDB B 的数据库链接：
CREATE DATABASE LINK hr_link CONNECT TO hr IDENTIFIED BY pwd USING 'hrpdb'; - PDB A 用户用
SELECT * FROM hr.employees@hr_link查询 —— 这走的是远程查询，权限校验发生在 PDB B 端，与 PDB A 的授权无关
该方式本质是“代理访问”，不是权限授予；性能、网络、事务一致性都需额外评估，且无法用于物化视图或某些 DML 场景。
容易被忽略的关键点
真正卡住人的往往不是语法，而是容器上下文和权限链：
- 执行
GRANT的账号必须在目标 PDB 内拥有GRANT ANY OBJECT PRIVILEGE，或者由对象所有者（如hr）亲自授权并带WITH GRANT OPTION - 目标用户
user_a必须已在该 PDB 中存在（本地用户），或为公用用户且已显式授予CREATE SESSION（CONTAINER = CURRENT或ALL） - 新创建的表不会自动继承授权，脚本或 job 必须定期重跑，否则上线即失效
-
SELECT ANY TABLE是系统权限，可在 CDB$ROOT 授予，但它只对当前容器生效 —— 在 CDB$ROOT 授予，只允许查 CDB$ROOT 的字典表，不覆盖任何 PDB
