环境背景
- 登录用户：
KANGKANG_CHEN（全程仅用此账号登录 PL/SQL Developer，连接别名 UTFMIS）。 - 表真实属主：
OADBA.WO9T0（表在 OADBA 下，KANGKANG_CHEN 有同义词/角色权限）。 - 存储过程：
WO_INSERT_WO9T0...，由KANGKANG_CHEN登录后在窗口直接创建/执行（属主就是 KANGKANG_CHEN，非 OADBA）。 - 现象：
- 窗口直接执行
delete from wo9t0 where ...✅ 成功。 - 将上述 SQL 放入存储过程（属主 KANGKANG_CHEN）执行 ❌ 报
ORA-00942: 表或视图不存在。
排查历程（误区纠正）
- 误以为过程属主是 OADBA：曾因界面显示
@UTFMIS及表属主为 OADBA 产生混淆。实际 UTFMIS 仅是连接别名，过程就是 KANGKANG_CHEN 创建的。 - 同账号为何表现不同：既然都是 KANGKANG_CHEN，为什么窗口能删、过程内不能？核心在于 Oracle 的权限解析机制差异。
根因（核心知识点）
- 窗口 SQL：认同义词（自动指向
OADBA.WO9T0），认角色权限（通过角色获得 DELETE 权限），所以直接执行通畅。 - 存储过程（默认定义者权限）：
- 过程属主是
KANGKANG_CHEN，内部写裸表名wo9t0，优先找KANGKANG_CHEN.WO9T0（实际不存在）。 - 不认角色权限：过程编译/执行只认直接授权（
GRANT ... TO KANGKANG_CHEN），角色权限在 PL/SQL 中失效。 - 同义词解析差异：过程内未显式写 Schema 时，同义词未必生效，导致找不到表或无权限，Oracle 统一报
ORA-00942。
- 本质：不是表不存在，而是过程内权限（角色失效）+ 解析路径（同义词失效）双重变化，导致无法访问
OADBA.WO9T0。
解决方案
方案 1（规范、根治）：显式全名 + 直接授权
- 存储过程代码改为：
CODE0
- 让 OADBA（或 DBA）给 KANGKANG_CHEN 直接授权（不走角色）：
CODE1
方案 2（懒人、不推荐生产）：调用者权限
- 过程头加
AUTHID CURRENT_USER，沿用窗口的角色/同义词权限：
CODE2
- 风险：依赖会话环境，生产不安全。
经验总结
- 存储过程操作跨用户表，必写
属主.表名，勿依赖同义词。 - 跨用户权限必须直接授权，角色权限在 PL/SQL 中无效。
- ORA-00942 可能是“无权限”：Oracle 对“找不到”和“无权限”统一返回 942。
- 同账号不同上下文：窗口 SQL（认角色+同义词）≠ 存储过程（只认直接授权+显式 Schema）。
- 连接别名 ≠ 用户：
@UTFMIS只是 TNS 别名，与 Schema 无关。
诊断 SQL 备忘
-- 查表真实属主
SELECT owner, table_name FROM all_tables WHERE table_name = 'WO9T0';
-- 查同义词
SELECT owner, synonym_name, table_owner, table_name
FROM all_synonyms WHERE synonym_name = 'WO9T0';
-- 查直接授权（过程内生效的权限，必须有记录）
SELECT grantor, privilege
FROM user_tab_privs_recd
WHERE table_name = 'WO9T0' AND owner = 'OADBA';
-- 查角色（窗口生效，过程内不生效）
SELECT granted_role FROM user_role_privs;一句话复盘：全程 KANGKANG_CHEN 账号，窗口靠同义词+角色能删 OADBA.WO9T0，但自己写的存储过程默认不认角色/同义词，裸表名解析失败报 942；改全名 OADBA.WO9T0 + 直接授权，彻底解决。