ODI代理调用删除类存储过程执行成功但未实际删除数据

• 优先验证会话上下文与删除条件匹配性
  远程代理和本地代理的数据库会话参数可能存在差异，最常见的是NLS_DATE_FORMAT、NLS_TIMESTAMP_FORMAT这类格式参数，如果存储过程的删除逻辑依赖日期/字符串格式匹配，参数差异会导致WHERE条件匹配行数为0，无数据可删。
  排查方法：在存储过程中增加调试日志，将删除条件的取值、执行删除后返回的SQL%ROWCOUNT写入自定义日志表，确认执行时是否真的匹配到了待删除的行。
• 排查事务提交逻辑是否生效
  虽然你已开启ODI自动提交、存储过程内写了COMMIT，但仍存在两个隐藏问题：
  1. ODI过程组件的事务级别配置如果设置为「继承父事务」，若父事务最终执行回滚，存储过程内的DELETE操作会被一同回滚；而TRUNCATE是DDL操作，执行后自动提交，不受父事务回滚影响，刚好符合你提到的TRUNCATE类存储过程可正常执行的特征。
  2. 存储过程内的COMMIT可能被分支逻辑跳过，比如仅当满足某条件时才执行COMMIT，其他分支未写提交逻辑。
     排查方法：在存储过程COMMIT语句前后增加日志标记，确认执行时COMMIT语句确实被触发；检查ODI过程组件的事务配置，将其改为独立事务验证效果。
• 验证权限授予方式是否符合PL/SQL要求
  PL/SQL执行时默认不识别角色授予的权限，仅识别直接授予用户的权限。你提到的DELETE权限如果是通过角色授予给连接用户的，在存储过程执行时会失效，而TRUNCATE需要的ALTER TABLE权限如果是直接授予用户的，就会出现TRUNCATE可执行、DELETE无权限但被异常块吞掉的情况。
  排查方法：检查DELETE权限的授予方式，执行GRANT DELETE ON 待删除表名 TO 连接用户名;直接授予权限后验证效果；检查存储过程是否存在EXCEPTION WHEN OTHERS THEN NULL这类吞掉报错的异常逻辑，导致无权限时ODI仍提示执行成功。
• 确认远程代理的数据源指向正确性
  远程代理绑定的物理数据源可能和本地代理的配置不一致，存在连错库、连错schema的可能。
  排查方法：在存储过程中增加数据库实例信息查询逻辑，将v$instance.instance_name、当前登录用户名、当前schema写入日志，确认远程代理执行时确实连接到了目标库的目标schema。
• 排查对象指向是否存在偏差
  如果存储过程中操作的表使用了同义词，远程代理会话的同义词配置可能和本地会话不一致，导致实际操作的是非目标表。
  排查方法：在存储过程中查询user_synonyms确认待操作表的实际所有者和对象名，和预期一致再执行删除。

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