存储过程和触发器编译成功但执行遇ORA-01403无数据错误求助

这种单独运行存储过程/触发器正常，但执行完整脚本时报ORA-01403: no data found的情况，核心原因在于完整脚本的执行上下文、数据状态或逻辑分支和你单独测试时存在差异。结合错误栈指向FUZZYTEST1.T_CUST_FUZZY_PERFORMANCE_MV第23行，我整理了几个高概率的排查方向：

1. 执行上下文的权限/环境差异 #

你单独测试时用的会话和完整脚本的执行会话可能存在关键差异：

• 用户或当前 schema 不同：比如你单独跑用的是FUZZYTEST1用户，但完整脚本切换到了其他用户，导致虽然你能看到表有数据，但执行存储过程的用户没有该表的访问权限，或者默认schema不对，查询的是另一个空表。
• 会话参数不一致：比如NLS_DATE_FORMAT、TIME_ZONE这类参数，若存储过程/触发器里的查询依赖这些参数（比如日期条件匹配），参数不同会导致查询过滤掉所有数据。

排查方法：

• 在完整脚本报错前添加语句：SELECT USER, CURRENT_SCHEMA, NLS_DATE_FORMAT FROM DUAL;，和你单独运行时的结果对比。
• 检查执行存储过程的用户对目标表的权限：SELECT GRANTEE, PRIVILEGE FROM USER_TAB_PRIVS WHERE TABLE_NAME = '你的目标表名';

2. 事务隔离与数据可见性问题 #

完整脚本的执行流程中，事务状态可能影响数据读取：

• 未提交的事务：如果脚本在调用存储过程前执行了数据修改但未COMMIT，而存储过程的逻辑依赖其他会话的数据，或者用了SERIALIZABLE隔离级别，会导致看不到最新数据。
• 物化视图刷新时机：T_CUST_FUZZY_PERFORMANCE_MV是物化视图，若它是REFRESH ON DEMAND类型，完整脚本里调用存储过程时可能还没触发刷新，导致物化视图本身是空的，而你看到的是基础表的数据。

排查方法：

• 在脚本调用存储过程前添加COMMIT;语句，看是否解决问题。
• 检查物化视图的状态和刷新时间：SELECT STATUS, LAST_REFRESH_DATE FROM USER_MVIEWS WHERE MVIEW_NAME = 'T_CUST_FUZZY_PERFORMANCE_MV';，确认它是VALID状态且刷新时间在脚本执行之后。

3. 代码逻辑的分支或参数差异 #

你单独运行和脚本调用时的逻辑分支可能不同：

• 调用参数不一致：如果p_update_cust_fuzzy_perform_mv需要传入参数，脚本里的参数值和你单独测试时的参数不同，导致内部查询过滤后无数据。
• 触发器/物化视图的条件分支：错误栈指向的第23行大概率是SELECT ... INTO语句（这种语句没查到数据就会抛ORA-01403），完整脚本的执行流程触发了该语句的执行，但此时查询条件匹配不到任何数据。

排查方法：

• 对比脚本中EXECUTE p_update_cust_fuzzy_perform_mv的调用参数和你单独运行时的参数，确保完全一致。
• 找到FUZZYTEST1.T_CUST_FUZZY_PERFORMANCE_MV第23行的代码，把对应的SELECT语句单独拿出来，在脚本执行到报错前的节点手动执行，看是否真的没有返回数据，以此定位条件问题。

4. 物化视图的触发器异常 #

因为错误栈指向物化视图，很可能是它的刷新触发器出了问题：

• 物化视图的刷新触发器（比如ON COMMIT触发器）在脚本执行时被触发，但此时触发器内部的查询逻辑因为数据状态问题找不到数据，进而抛出错误。

排查方法：

• 查询物化视图的触发器代码：SELECT TEXT FROM USER_TRIGGERS WHERE BASE_OBJECT_TYPE = 'MATERIALIZED VIEW' AND TABLE_NAME = 'T_CUST_FUZZY_PERFORMANCE_MV';，分析其中的逻辑，特别是第23行附近的代码。

内容的提问来源于stack exchange，提问作者Sh_ar