我们有一个很大的包,但总是会遇到性能问题。我们平均在一个月内收到6-10张为这个问题筹集的罚单。有时程序会成功运行几分钟,有时会运行几天,结果却出现了一个无法解释的错误。
我开始深入研究这个问题,发现有许多可能的原因导致了性能问题,例如大量未调优的SQL和糟糕的编码实践等。
今天给我留下深刻印象的一件事是在代码中,它在执行一些大操作(例如一个巨大的Select语句和许多DML语句)之前,在多个地方多次调用Gather Table Statistics。
根据组织的实践,该计划每天、每周和每月运行一次。
不幸的是,我无法复制性能问题来了解更多信息,但我猜对多个表多次运行聚集表统计数据可能会导致程序中的主要性能问题。我找不到任何资源来支持这个想法。有人能确认一下吗?
发布于 2021-04-06 17:48:55
是的,可以确认,我已经看到了花费80%的运行时收集统计数据的代码。考虑到您的限制,我将按以下顺序尝试:
DELETE语句,检查它们是否可以被DELETE调用。假设每天或每周的数据差异不会足够大,从而导致不同的查询计划。DBA_TAB_MODIFICATIONS,至少检查自上次统计数据收集以来表是否发生了足够的更改。https://stackoverflow.com/questions/66959580
复制相似问题