又看不懂EM里的这个执行计划，

sqysl

ZALBB 发表于 2017-9-8 15:01
忘记了，不过你看执行计划里的第1个动作，是读取那个6000＋记录的临时表，只要1秒，照理，这个应该也只要 ...

正常来说，几千条记录的读取或转换，都不会是太大问题，系统资源紧张的情况就不好说。
另外，你这个图似乎是通过计划监视获取到的，但不清楚是否准确。就图中节点2来说吧，这个节点的cost是合情理的，但耗时却对不上，对两个行源（都耗时510s+）做了NL操作后，这个节点的耗时起码也得1000以上吧，但还是511s。

ZALBB

对，那个嵌套循环起码得上千秒才对，，，所以，我怀疑这个图有BUG，耗时这一块，把握不准，

sqysl

ZALBB 发表于 2017-9-8 17:18
对，那个嵌套循环起码得上千秒才对，，，所以，我怀疑这个图有BUG，耗时这一块，把握不准，

是的，细看的话，有些地方是不太准确的。

Yong Huang

According to
Slow Query Using Pipeline Function TABLE with Plan 'COLLECTION ITERATOR PICKLER FETCH' (Doc ID 2224317.1)
"Statement is using pipeline function TABLE().  Statistics are not considered when using pipeline function."
And the note suggests using the cardinality hint to tell CBO the number of rows in the table, or raising dynamic sampling level, or using extensible optimizer.

Also, Jonathan Lewis's article at
https://jonathanlewis.wordpress.com/2010/11/30/collection-costs/
is useful. Read from "Here’s a suggestion for use with the table() operator" to the end.