我有一个sql select语句需要很长时间（约3分钟）。
我想知道发生了什么。所以我做了
explain plan for MY_STATEMENT，但这完成于＆lt; 1秒。
和
SELECT * FROM TABLE (dbms_xplan.display);告诉我没什么可疑的
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT|
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 943 | 86756 | 15 (0)| 00:00:01 | | |
|* 1 | HASH JOIN RIGHT OUTER | | 943 | 86756 | 15 (0)| 00:00:01 | | |
| 2 | TABLE ACCESS FULL | PTSAREA | 442 | 12376 | 5 (0)| 00:00:01 | | |
|* 3 | HASH JOIN RIGHT OUTER| | 943 | 60352 | 10 (0)| 00:00:01 | | |
| 4 | TABLE ACCESS FULL | PTSAREA | 442 | 12376 | 5 (0)| 00:00:01 | | |
| 5 | REMOTE | M_SUPP | 943 | 33948 | 5 (0)| 00:00:01 | IXXX_~ | R->S |
------------------------------------------------------------------------------------------------------------------
但是当我真正执行这个判断时，需要大约3分钟。有没有办法找出需要这么长时间的事情？
答案 0 :(得分：1)
您应该首先考虑的是检查为什么优化程序会估算出如此低的成本和耗时。
最可能的原因是错误或过时的对象统计信息。验证PTSAREA和M_SUPP中的行数。
真的只有442 resp。 943行？我怀疑音量更高。
如果是这样，请收集表格统计数据并重复解释计划。你应该看到很多现实的成本和时间。 在某些情况下，事件是不同的执行计划。
换句话说，在大多数情况下，当您在执行计划中看到意外情况时，这是优化程序输入的问题（对象统计信息，系统统计信息和/或优化程序参数）。