Oracle存储过程调用异常：TableA记录消失及TableB无数据问题

从你描述的现象来看，核心矛盾点在于调用ChildProc3后TableA的数据被清空且TableB无数据，不调用则TableA数据保留，结合你提到的已执行COMMIT操作，大概率是ChildProc3内部的逻辑或事务控制出了问题，以下是具体的排查方向：

可能的核心原因 #

• ChildProc3包含ROLLBACK操作：如果ChildProc3执行时触发异常（比如插入TableB违反约束），且异常处理块中执行了ROLLBACK，若你的COMMIT仅在父过程最后执行，回滚会撤销之前所有未提交操作；若子过程已单独COMMIT，那要排查是否ChildProc3里有显式删除/清空TableA的逻辑。
• ChildProc3误操作清空TableA：比如插入TableB后执行了TRUNCATE TABLE TableA或DELETE FROM TableA，但插入TableB的逻辑因约束不满足、语法错误等原因失败，却仍执行了删除操作并提交，导致TableA数据丢失、TableB无数据。
• 插入TableB的逻辑存在隐性错误：比如INSERT INTO TableB SELECT * FROM TableA被错误添加了WHERE 1=0这类过滤条件，或者TableB字段与TableA不匹配导致插入失败，且过程用EXCEPTION WHEN OTHERS THEN NULL吞掉了错误，同时后续执行了清空TableA的操作。

具体排查步骤 #

• 检查ChildProc3源代码：
  • 逐行查看是否有ROLLBACK、TRUNCATE、DELETE操作，重点关注这些操作的触发条件（比如是否在异常块里无条件回滚，或插入后不管成功与否都删除TableA）。
  • 验证插入TableB的SQL：确认SELECT * FROM TableA无额外过滤条件，TableB的字段类型、长度、约束与TableA兼容，排查是否存在主键冲突等约束问题。
• 验证事务执行顺序：
  • 在ChildProc1、ChildProc2的插入语句后添加日志记录（比如插入自定义日志表，记录插入行数、执行时间、COMMIT执行状态），确认这两个子过程的COMMIT确实执行，数据已持久化到TableA。
  • 检查父过程是否存在全局事务控制：比如父过程用BEGIN ... END包裹所有调用，但最后未COMMIT反而在某个分支执行了ROLLBACK。
• 跟踪执行过程：
  • 启用Oracle的SQL Trace（执行ALTER SESSION SET SQL_TRACE=TRUE;），调用父过程后用TKPROF分析生成的跟踪文件，查看每个SQL的执行行数、返回结果，确认是否有回滚、删除等操作被执行。
  • 查看数据库Alert日志，检查是否有与TableB插入相关的ORA-开头约束违反错误。
• 单独测试ChildProc3：
  • 手动向TableA插入几条测试数据，单独调用ChildProc3，观察TableB是否有数据插入、TableA的数据是否被删除，以此隔离父子过程的事务影响。

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