Oracle存储过程执行时突发ORA-01555错误：并行重建索引及收集统计信息是否为诱因？

先直接给结论：你的并行索引重建操作确实有可能引发ORA-01555（快照过旧）错误，并行重建索引也会消耗回滚段，间接导致旧快照所需的undo数据被清除。下面分点拆解细节：

一、ORA-01555的本质 #

ORA-01555的核心原因是：长时间运行的查询需要读取一致性快照，但构建这个快照所需的undo数据已经被Oracle回收覆盖了——因为undo表空间是循环复用的，当空间不足或超过UNDO_RETENTION设置的时长时，旧的undo块会被新的undo数据覆盖。

二、并行索引重建对ORA-01555的影响 #

1. 并行重建索引会消耗回滚段 #

不管是离线还是在线并行重建索引，都会产生undo数据：

• 离线重建：Oracle会创建新的索引段，将原索引的数据导入新段，这个过程中产生的undo用于记录索引段的创建、数据插入等操作；
• 在线重建：除了索引段的操作，还会创建临时日志表来记录重建期间的基表DML，这会产生更多的undo开销。

这些undo数据会占用回滚段空间，如果你的undo表空间余量不足，Oracle会优先回收最旧的、已提交的undo块——这其中就可能包含你的存储过程查询所需的基表旧快照对应的undo数据。

2. 间接触发ORA-01555的两种场景 #

• 空间挤占导致undo被覆盖：并行重建索引消耗大量undo空间，迫使Oracle回收存储过程查询需要的旧undo块，导致无法构建一致性快照；
• 资源竞争延长查询时间：并行重建会占用大量CPU、IO资源，导致你的存储过程查询运行时间被拉长。查询越久，需要保留的undo数据就越旧，被覆盖的概率也就越高。

三、统计信息收集的影响 #

收集表统计信息（DBMS_STATS.GATHER_TABLE_STATS）本身是只读操作，不会产生DML，因此不会直接生成undo数据。但如果并行收集统计信息，同样会占用系统资源，间接延长存储过程的运行时间，增加undo被覆盖的风险。

四、避免此类问题的建议 #

• 确保undo表空间足够大，并且设置合理的UNDO_RETENTION参数（如果是自动扩展的undo表空间，Oracle会尽量满足这个时长的保留需求）；
• 尽量在业务低峰期执行索引重建和统计信息收集，避免和长时间运行的存储过程冲突；
• 在线重建索引时，可以适当降低并行度，减少资源消耗；
• 优化存储过程的查询逻辑，比如调整执行计划、减少单次查询的数据量，缩短运行时间。

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