ORA-00942错误主因是权限未生效，而非未授予：需确认是否为直接授权（非角色授权）、表名解析路径正确（CURRENT_SCHEMA/同义词/目标对象权限）、物化视图或视图定义中表名带schema前缀，且权限链完整（GRANTABLE='YES'）。
授了权限还报 ORA-00942，大概率不是权限没给，而是权限没“生效”——Oracle 的权限模型里，对象可见性、解析路径和执行上下文三者不匹配，就会卡在这一步。
查权限是否真被授予（且可直接使用）
用户看到 GRANT SELECT ON SSB1.DATES TO APP_USER; 执行成功，就以为完事了，但 Oracle 有两套权限路径：直接授权（direct grant）和角色授权（role-based grant）。后者在多数场景下不自动生效。
-
SELECT PRIVILEGE FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'DATES' AND GRANTEE = 'APP_USER';—— 只有这条能返回SELECT，才说明是直接授权；如果为空，说明权限是通过角色给的 -
SELECT * FROM SESSION_ROLES;看当前会话激活了哪些角色；再查SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'APP_USER' AND GRANTED_ROLE = 'YOUR_ROLE';确认角色存在 - 关键点：角色权限在 PL/SQL 块、存储过程、物化视图定义中默认不可用；哪怕
SESSION_ROLES里有，EXECUTE IMMEDIATE 'SELECT COUNT(1) FROM SSB1.DATES'仍会报ORA-00942
确认表名解析时走的是哪条路径
执行 SELECT * FROM DATES; 时，Oracle 不是直接去查你“以为”的那个表，而是按固定顺序找：
- 先查当前
CURRENT_SCHEMA（即SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA')返回值）下有没有DATES - 没有，再查
USER_SYNONYMS里有没有私有同义词叫DATES；再查DBA_SYNONYMS里有没有公有同义词 - 同义词指向的
TABLE_OWNER.TABLE_NAME必须真实存在，且你对该目标对象有直接 SELECT 权限（不是对同义词本身） - 如果同义词指向
HR.EMPLOYEES，而你只有SELECT权限给HR.EMPLOYEES，那没问题；但如果你只有SELECT权限给同义词名EMP，Oracle 不认这个
检查物化视图或视图定义里的表引用
这类错误常在刷新物化视图或查询视图时爆发，但根源不在调用语句，而在定义体内部：
-
SELECT QUERY FROM USER_MVIEWS WHERE MVIEW_NAME = 'MV_SALES';—— 看里面写的是SALES还是SCHEMA_A.SALES - 如果只写
SALES，那它就在物化视图所有者自己的 schema 下找；若该用户没权限访问基表，刷新就崩 - 视图同理：
SELECT TEXT FROM ALL_VIEWS WHERE OWNER = 'APP_SCHEMA' AND VIEW_NAME = 'V_CUSTOMERS';，检查里面每张表是否都带 schema 前缀，否则依赖当前 session 的CURRENT_SCHEMA - 特别注意：即使视图所有者有权限，如果视图定义里用了函数包（如
pkg.get_name()）或同义词，那些依赖项也得一一验证权限
最易被忽略的是权限链断裂：比如 A 授予 B 对某表的 SELECT 权限时没加 WITH GRANT OPTION，B 再转授给 C 就无效；或者中间某层角色没激活，整个链就断在那儿。查 DBA_TAB_PRIVS.GRANTABLE 字段才是唯一依据。
