我有一个报表查询，它连接了DW中的19个表。我知道我们的DW架构设计并不好。 这个查询每晚都在运行并收集昨天的活动。我们的系统于2008年6月上线，因此与整个数据量相比，1天的数据量只占一小部分。
查询执行时间一般为5~10分钟，执行成本约为70,000。 它使用索引/嵌套循环。成本低。一切都很好看。
在这个月，查询越来越慢，但执行成本保持不变。 它仍在使用索引，执行成本仍然很低，但运行时间超过1小时。
任何想法??
答案 0 :(得分：3)
也许您的优化统计信息已过期。优化器计算的成本基于它具有的统计数据，因此如果这些成本没有改变，也不会产生成本。但是，如果有比以往更多的数据，实际运行查询所需的时间将会改变。
答案 1 :(得分：2)
我有一些想法会导致突然放缓，但最好的出发点是从数据库中获取有关花费时间的信息。
如果您有权访问代码和SQL * Plus，那么起点就是：
set autotrace on
然后运行查询。
（这会自动执行以下步骤以启用SQL跟踪，然后输出tkprof。）
另一种选择是让Statspack在你的糟糕工作周围有一个快照周期。
这应该至少缩小它花费时间的时间（物理I / O，CPU等）。
可能只是数据的累积增加使您的查询超出了资源限制。
答案 2 :(得分：1)
我过去也有同样的问题。在我的情况下，我们的一些表具有高水位标记（由于每天运行多个删除语句）。
我们使用ALTER TABLE MOVE降低了高水位标记并恢复到正常速度。
此致 维卡斯