{IT168.}故障：11月11日上午，我收到系统应用程序人员的反馈：Sales Daily无法查询结果，已经等待了一个小时，屏幕仍然是灰色的，前一份报告可以在2分钟内生成。我在IT部门的同事查看了所发生的事情，领导正在等待报告。我登录数据库，查询当前系统的过程状况图（2），发现一些过程已经运行了3600+秒，捕获了它们的执行计划，例如：Re（3）
    
     在印象中，报告之前已经过优化，并且需要几秒到几十秒，所以效率非常高。观察这个执行计划，CBO预测的数据很少，但是因为报告的SQL语句使用了临时表（TYBBSALED AILYBD21）和临时表ry表中的数据在数据库中是不可见的，我不知道临时表数据是如何生成的，因此，不可能判断临时表CBO预测的行数是否是。
    
     此时，考虑一下测试环境，在上个月对库进行RMAN恢复测试之后，还剩下一个测试库。因此，启动测试中间件，让测试中间件指向测试库，并尝试查询其上的报告，看看它是如何工作的。
    
     如您所见，测试库上的执行计划与正式库上的执行计划完全不同，并且测试库上的查询效率是正常的。像以前一样，结果将在几十秒内显现出来。显然，问题在于正式图书馆的执行计划。
    
     正式图书馆的实施计划是什么样的，这会给我留下这样的印象，以至于我最近没有对正式图书馆做任何改变。此外，当昨天报告（第10号）时，这是正常的。今天，它突然变得不正常了。这种变化给人一种奇怪的感觉：报告中涉及的数据量已经达到一定数量。由变化引起的质量变化程度导致执行计划的异常变化。然而，无论如何变化，表的统计信息必然导致e异常执行计划，使得报表无法查询结果。现在我们必须考虑如何恢复原始的实现计划。
    
     1。重新收集SQL语句中涉及的表的统计信息，但不包括临时表（因为它是另一个进程中的收集操作，并且临时表此时没有数据，并且收集毫无意义）。收集之后，重新运行报告，发现执行计划保持不变，表明方法无效。
    
     为什么官方图书馆的执行计划不是从这一步开始的索引的聚类因子值是否太高而无法比较这两个库结果发现，官方图书馆仅略高于考试图书馆，但考试图书馆仅是9月份的数据，而官方图书馆是10月份的数据。相信它，但不要试图不愿意。但是，修改参数值（dBMSiSTATS）仍然是无效的。再次测试它。
    
     由于这只是第11个问题，这意味着10号或以前的情况可以，因此请考虑将这些表的统计信息恢复到9号，然后再试一次（默认情况下，保存的统计信息的长度是dbms_stats.get_stats_._.=31），这是无效的；恢复到5.No.1，无效；恢复到1号或无效。
    
     4此时，统计信息引起的执行计划可能不是例外，这是值得怀疑的，但再一次，除了统计信息，似乎没有其他原因。因为测试库的执行计划是OK，所以在测试库中导入这些表的统计信息（dbms_stats）。此外，为了安全起见，对两个库的系统参数值aux_stats$(dbms_stats.._system_stats获取)和当时两个报告的Sesion的参数(v$ses_optimr_env)进行了比较。环境变量的变化是相同的，但测试结果仍然无效！爱你的人
    
     5想想，只有最后一步了。由于测试库中的报告查询是OK，而正式库中是例外，所以比较两个库中语句的执行计划，看看有什么不同，希望找到线索。获取SQL语句执行计划的生成过程只有一种方法，即使用10053事件命令来跟踪：