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。
验证方式：
- 查当前 schema：
SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL; - 查表真实 owner：
SELECT OWNER FROM ALL_TABLES WHERE TABLE_NAME = 'EMP';（注意TABLE_NAME存储为大写） - 临时切换：
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';
- 如果返回
"QueryHistory"，查询必须写：SELECT * FROM "QueryHistory"; - 如果返回
QUERYHISTORY（无引号），说明建表没加引号，SELECT * FROM queryhistory;或SELECT * FROM QUERYHISTORY;都行
建表时不加引号是安全习惯；已加引号的，别靠记忆，以 ALL_TABLES.TABLE_NAME 返回值为准。
同义词失效或不可见
很多应用依赖同义词隐藏 schema，但同义词本身可能失效：指向的表被删、owner 改名、拼写错误，甚至建成了私有同义词却在另一用户下查。
- 查当前用户下的同义词：
SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME FROM USER_SYNONYMS WHERE SYNONYM_NAME = 'EMP'; - 查公有同义词：
SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS WHERE SYNONYM_NAME = 'EMP';（需 DBA 权限） - 确认同义词指向的
TABLE_OWNER和TABLE_NAME是否真实存在（再跑一遍ALL_TABLES查询）
私有同义词只对创建者可见；跨用户访问必须用公有同义词，或直接走全限定名。
用户有对象权限但角色权限在 PL/SQL 中未启用
即使 schema 对、表名对、同义词也对，没有 SELECT 权限照样报 ORA-00942。Oracle 的权限模型里，角色权限在 PL/SQL（包括存储过程、函数、Hibernate 动态 SQL）中默认不生效，除非显式 SET ROLE。
- 查是否被直接授权：
SELECT PRIVILEGE FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'EMP' AND GRANTEE = 'YOUR_USERNAME'; - 查是否通过角色获得权限：
SELECT * FROM SESSION_ROLES;，再确认该角色是否真有SELECT权限 - DBA 授权示例：
GRANT SELECT ON SCOTT.emp TO USER_A;
最易被忽略的是：权限检查失败时 Oracle 故意不告诉你“没权限”，而是统一返回 ORA-00942 —— 这不是 bug，是安全设计。所以不能只看错误字面意思，得一层层排除解析路径上的每个环节。
