Oracle FOR ALL更新在SAS 4GL中对随机分区无效问题排查

先还原下你的操作场景：

• 从Oracle每日分区表的单个分区里读取ID列和16位长度的varchar2(128)信用卡号字段
• 通过SAS的proc groovy加4GL转换，在Oracle建临时表存ID和对应信用卡号的128位哈希值
• 用游标+FOR ALL语句把原表的卡号更新成哈希值

你遇到的问题是：昨晚处理900个分区，结果有60个随机非连续的分区没更新，SAS和Oracle都没报错，数据库也没重启；重新跑对应分区的代码还是没用，单独测其中一个分区时，临时表的记录数和待更新数匹配，哈希值也正常，所以你怀疑是原表更新环节出了问题。而且这套代码在同表800+分区、其他表3000+分区都正常跑，你问DBA后还是好奇：有没有可能Oracle分区/块损坏了，但访问、修改都不报错？怎么检测？

关于Oracle分区/块损坏无报错的可能性及检测方法 #

确实存在极少数情况，Oracle的分区或数据块损坏了，但不会立刻抛出明显报错，不过这类情况大多和损坏类型有关：

1. 可能的损坏场景 #

• 逻辑损坏而非物理损坏：比如数据块里的行目录、事务槽这些内部逻辑结构出问题，但块本身物理上能被读取。如果你的FOR ALL更新刚好没涉及这些异常行，或者Oracle内部跳过了异常行但没触发报错，就可能出现更新遗漏但无提示的情况——不过这种真的非常罕见，Oracle的一致性校验机制一般会直接抛出ORA-01578这类块损坏错误。
• 分区统计信息异常：如果分区的统计信息严重过时或者损坏，会导致执行计划出问题，比如FOR ALL语句没正确定位到分区里的行，结果就是更新没生效但没报错。这种不算块损坏，但表现和你遇到的情况很像。
• 隐性约束/触发器干扰：比如原表有你没注意到的唯一约束、触发器，更新时触发了约束冲突，但SAS的错误处理机制把这个错误屏蔽了，也会出现无报错但没更新的情况——不过你单独测临时表是正常的，这个可能性相对低，但可以排查下。

2. 检测方法 #

• 检查块损坏：
  • 用DBVERIFY工具：针对可疑分区对应的数据文件跑，比如dbv file=/u01/oradata/yourdb/datafile.dbf blocksize=8192（块大小要和你的数据库配置一致），它会扫描数据文件里的块，报告物理或逻辑损坏。
  • 查V$DATABASE_BLOCK_CORRUPTION视图：这个视图会记录Oracle已经检测到的所有损坏块，直接查询就能知道有没有可疑的损坏。
  • 用DBMS_REPAIR包：调用DBMS_REPAIR.CHECK_OBJECT检查目标分区的表，能找出损坏的块，后续还可以用这个包做修复（不过修复前记得备份）。
• 检查分区统计信息：
  • 先查统计状态：SELECT table_name, partition_name, last_analyzed, stale_stats FROM user_tab_partitions WHERE table_name='YOUR_TABLE';，如果stale_stats是YES，说明统计信息过时了，重新收集：EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'YOUR_SCHEMA', tabname => 'YOUR_TABLE', partname => 'PROBLEM_PARTITION', cascade => TRUE);
• 排查更新语句的执行计划：
  • 给可疑分区的更新语句生成执行计划：EXPLAIN PLAN FOR UPDATE your_table t SET t.card_number = (SELECT hash_value FROM temp_table tt WHERE tt.id = t.id) WHERE t.partition_key = 'PROBLEM_PART_VALUE';，然后查询PLAN_TABLE看看执行计划是不是正确定位到了目标分区，有没有因为索引用错或者全表扫描导致行没匹配上。

补充：问题最终根因 #

@编辑：已经解决问题了，原因是这些分区里存在重复的ID值——当多个行对应同一个ID时，更新语句里的子查询会返回多行，Oracle本来会抛出ORA-01427（单行子查询返回多行）的错误，但可能因为SAS的错误处理配置或者日志没开全，这个错误没被你看到，导致看起来无报错但更新没生效。

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