您好，

最近我们的一个生产箱出现了一个问题。

用户抱怨，在某个日期后，返利模式，作业的运行时间突然增加。

我们检查了执行计划，淘客cms，处理了数据量，什么叫物联网，spool和许多其他人，但除了执行计划的更改外，一切都看起来正常。

我们调查了执行计划更改的原因。

我们注意到，表VTTK的统计数据得到更新，此后作业开始减速。

然后我们将统计数据恢复到性能最佳的日期，问题得到解决。

下面是我们遵循的调查步骤。STAD在VTTP上显示高时间。

2。我们使用ST12跟踪作业。

跟踪指向VTTP上长时间运行的查询。

3。正在检查VTTP上长时间运行的查询的执行计划。

在执行计划屏幕截图中检查到，索引VTTK~A的统计数据已于2015年4月24日00:08更新。如计划历史中所示，计划在2015年4月24日00:16:03刷新。

由于作业的频率为15分钟，00:08更新的统计信息触发了执行计划从00:16:53（对于下一个作业）的更改。

在我们的环境中，我们在单个框中维护表中所有框的作业运行时历史，以便进行分析。

如下所示是截图，如下图所示，stats更新后作业的运行时间增加了

如图所示，stats更新后运行时间增加了

作为参考，淘客推广联盟，我们选择了不同的SQL ID框，得到了不同的执行计划，特别是涉及VTTP的join是一个嵌套循环，不是hash join

所以，医疗物联网，我们得出的结论是，在stats更新后，执行计划被切换。

然后我们尝试在性能良好时恢复旧的统计信息，然后作业运行时恢复到正常范围

Oracle提供了两种方法来完成此操作–统计信息恢复和统计信息导出。我们使用了统计还原方法。

我们使用dbms程序还原了统计_stats.restore\表\统计.

在还原之前，我们在DBA view DBA\U TAB\U stats\U HISTORY中检查了可用的统计时间戳。

并选择了性能良好的时间戳。

下面是统计还原之后的作业运行时历史。

Hi Kunal，

我是从共享游标缓存得到的，通过ST04访问。

另外，我们可以从/SDF/RSORADLD\u NEW report得到。此报表提供了昂贵的SQL列表，可以根据SQL ID进行筛选。