Oracle DB中使用SPM是否会引发SQL临时性能回归问题

场景结论 #

你描述的场景确实会由SPM默认机制触发临时SQL性能回归，且此类特殊场景下无法100%依赖自动SPM机制规避问题。

SPM的核心设计目标是避免统计信息变更、游标失效等场景下的执行计划随机突变，常规业务场景下可以大幅降低性能抖动概率。但在你提到的短时间内海量数据加载、统计信息发生量级级别的突变场景下，SPM优先沿用已验证旧计划的机制会反向导致性能问题：适配旧数据分布的旧计划完全不匹配新的数据特征，性能会显著下降，该问题会持续到待验证的新执行计划在预设维护窗口完成演进、被标记为可接纳状态为止。

可行处理方案 #

1. 手动触发计划演进（最适配当前场景的方案） #

在海量数据加载、统计信息收集作业完成后，无需等待预设维护窗口，直接手动执行SPM演进任务即可快速完成新计划验证接纳。Oracle环境下的执行命令如下：

SELECT DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE() FROM DUAL;

你也可以指定SQL_ID、计划哈希值等参数，只演进目标SQL的待验证计划，降低演进任务本身的资源消耗。演进完成后新的最优计划会直接生效，不会出现业务高峰时段的性能回归。

2. 调整SPM策略适配固定批量作业场景 #

如果你的业务有固定的周期性批量数据加载流程，可以提前调整SPM规则从根源规避问题：

• 临时调整SPM接纳策略：批量加载前临时开启新计划自动接纳，不需要验证，加载完成、统计信息更新后再恢复原有策略，适合固定窗口的批量作业
• 调整SPM维护窗口：将SPM默认的维护窗口调整到周末统计信息收集作业完成后、周一业务高峰到来前的时间段，让新计划自动完成演进，不需要人工介入

3. 手动绑定基线（紧急恢复场景方案） #

如果已经在业务高峰时段出现性能问题，来不及完成全量计划演进，可以直接将优化器生成的新最优计划手动绑定为已接纳的基线，跳过演进验证流程，最快速度恢复业务性能。

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