Performance Oracle日期范围不一致性

我正在对特定的日期范围运行一个相当大的查询。除了在2011年1月10日至2011年1月31日期间进行查询外，查询大约需要30秒。由于某种原因，射程永远不会结束。例如，2011年1月1日至2011年1月31日，以及几乎所有其他范围，都在预期时间内完成

---

此外，我注意到，执行较小的范围（如一周）比执行较大的范围需要更长的时间。

当Oracle在表上收集统计信息时，它会在日期列中记录低值和高值，并使用它们来估计谓词的基数。如果在列上创建直方图，它将收集有关列中数据分布的更详细信息。否则，Oracle的基于成本的优化器（CBO）将采用统一的分布

例如，如果您有一个包含100万行的表和一个

DATE

列，该列的低值为2001年1月1日，高值为2011年1月1日，它将假设大约10%的数据在2001年1月1日至2002年1月1日的范围内，大约0.027%的数据将来自2008年3月3日的某个时间（1）/（10年*每年365天+闰日）

只要您的查询使用的日期在已知范围内，优化器的基数估计值通常是相当好的，因此它关于使用什么计划的决定是相当好的。如果您稍微超出上限或下限，估计值仍然是相当好的，因为优化器假定可能存在较大或较小的数据小于它在采样数据以收集统计数据时看到的值。但是，当您离优化器统计数据预期看到的范围太远时，优化器的基数估计值就会偏离范围太远，它最终选择了一个错误的计划。在您的情况下，在刷新统计数据之前，优化器的最大值是expecting可能是2011年9月25日或26日。当您的查询查找2011年10月的数据时，优化器很可能预期查询将返回很少的行，并选择了针对该场景而不是针对实际返回的更多行进行优化的计划。这导致计划变得更糟给定返回的实际数据量

在Oracle 10.2中，当Oracle为加载到共享池中的查询执行硬解析并生成计划时，它会查看绑定变量值，并使用这些值来估计查询将返回的行数，从而估计出最有效的查询计划。一旦创建了查询计划，直到计划从共享池中过时池中，同一查询的后续执行将使用相同的查询计划，而不管绑定变量的值如何。当然，下一次由于计划已过时而必须对查询进行硬解析时，Oracle将查看并可能看到新的绑定变量值

不是特别受欢迎的功能（11g中的自适应光标共享更好）因为这使得DBA或开发人员很难预测在任何特定时刻将使用什么计划，因为您永远无法确定优化器在硬解析过程中看到的绑定变量值是否代表您通常看到的绑定变量值。例如，如果您在1天的范围内搜索n索引扫描几乎肯定会更有效率。如果您在5年的范围内搜索，表扫描几乎肯定会更有效率。但您最终会使用在硬解析期间选择的任何计划

最有可能的是，您只需确保更频繁地收集基于单调递增值范围（日期列是目前最常见的此类列）而频繁查询的表上的统计信息，即可解决此问题。在您的情况下，在问题出现之前，统计数据已经收集了大约6周，因此，根据收集统计数据的成本，确保每月或每两周在此表上收集统计数据可能是安全的

---

您还可以使用此过程更定期地显式设置此列的统计信息。这需要更多的编码和工作，但可以节省您收集统计信息的时间。这在数据仓库环境中非常有用，但在更正常的OLTP环境中可能会有过多的问题。

您使用的是bind variabl吗或者您使用的是硬编码文字？您使用的是什么版本的Oracle？日期列上是否有直方图？统计数据（包括直方图）是否准确？您是否得到了不同的查询计划？如果是，那么“好”计划是什么样的，“坏”计划是什么样的计划是什么样子的？我们使用的是10g，我使用的是绑定变量。我很确定日期列上没有直方图。我实际上是一名Java开发人员，我对直方图不太熟悉。该列上有一个索引，正在使用它。当我更改日期时，查询计划非常不同。我从未想过检查t正如我所认为的，如果查询是相同的，那么计划将是相同的。坏的计划使用大量嵌套循环，而好的计划不使用任何循环。此外，坏的计划使用的操作我在“视图谓词”之前从未见过.查看统计栏，我注意到上一次分析是在2011年9月26日。通过强制更新分析，问题得到了解决。我现在的问题是，为什么统计数据过时，我可以告诉我们的DBA如何确保它们保持最新？感谢您的详细解释Justin。您让我想重温一下我的DB调优技能。