为什么Oracle用户查询跨Schema表时报ORA-00942

ORA-00942错误需逐层排查：先确认CURRENT_SCHEMA与表owner是否一致，再检查表名大小写敏感性（是否带双引号），接着验证同义词有效性及可见性，最后核实SELECT权限是否直接授予（角色权限在PL/SQL中不生效）。

当前会话的 CURRENT_SCHEMA 不是目标表所在 schema

Oracle 默认只在 CURRENT_SCHEMA 下查找未带前缀的表名。比如你用 USER_A 登录，执行 SELECT * FROM emp，Oracle 实际查的是 USER_A.emp，哪怕 SCOTT.emp 存在且你有权限，也会报 ORA-00942。

验证方式：

1. 查当前 schema：SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL;
2. 查表真实 owner：SELECT OWNER FROM ALL_TABLES WHERE TABLE_NAME = 'EMP';（注意 TABLE_NAME 存储为大写）
3. 临时切换：ALTER SESSION SET CURRENT_SCHEMA = SCOTT;（仅当前会话有效）

生产环境更稳妥的做法是显式写全限定名：SELECT * FROM SCOTT.emp;

表名因双引号导致大小写敏感，引用时未严格匹配

建表时加了双引号（如 CREATE TABLE "QueryHistory"），表名就变成严格大小写存储；之后所有引用都必须带引号且完全一致，否则 Oracle 按默认规则转成大写去查，必然找不到。

查真实表名（含引号）：SELECT TABLE_NAME FROM ALL_TABLES WHERE UPPER(TABLE_NAME) = 'QUERYHISTORY';

1. 如果返回 "QueryHistory"，查询必须写：SELECT * FROM "QueryHistory";
2. 如果返回 QUERYHISTORY（无引号），说明建表没加引号，SELECT * FROM queryhistory; 或 SELECT * FROM QUERYHISTORY; 都行

建表时不加引号是安全习惯；已加引号的，别靠记忆，以 ALL_TABLES.TABLE_NAME 返回值为准。

同义词失效或不可见

很多应用依赖同义词隐藏 schema，但同义词本身可能失效：指向的表被删、owner 改名、拼写错误，甚至建成了私有同义词却在另一用户下查。

1. 查当前用户下的同义词：SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME FROM USER_SYNONYMS WHERE SYNONYM_NAME = 'EMP';
2. 查公有同义词：SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS WHERE SYNONYM_NAME = 'EMP';（需 DBA 权限）
3. 确认同义词指向的 TABLE_OWNER 和 TABLE_NAME 是否真实存在（再跑一遍 ALL_TABLES 查询）

私有同义词只对创建者可见；跨用户访问必须用公有同义词，或直接走全限定名。

用户有对象权限但角色权限在 PL/SQL 中未启用

即使 schema 对、表名对、同义词也对，没有 SELECT 权限照样报 ORA-00942。Oracle 的权限模型里，角色权限在 PL/SQL（包括存储过程、函数、Hibernate 动态 SQL）中默认不生效，除非显式 SET ROLE。

1. 查是否被直接授权：SELECT PRIVILEGE FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'EMP' AND GRANTEE = 'YOUR_USERNAME';
2. 查是否通过角色获得权限：SELECT * FROM SESSION_ROLES;，再确认该角色是否真有 SELECT 权限
3. DBA 授权示例：GRANT SELECT ON SCOTT.emp TO USER_A;

最易被忽略的是：权限检查失败时 Oracle 故意不告诉你“没权限”，而是统一返回 ORA-00942 —— 这不是 bug，是安全设计。所以不能只看错误字面意思，得一层层排除解析路径上的每个环节。