Checking the description of the bug it seems to say that it's the creation of
the internal GTT that is the threat. In the context of the bug - it's Siebel
(which typically means large numbers of columns) and a very large number of
(possibly small ?) queries. This would make the recursive SQL a significant
fraction of the total work done, and for concurrent queries introduce a degree
of latch contention.
In your case you are talking about the execution of a single big query;
moreover, if the problem were recursive SQL then the Tanel snapshot would show
a high value for STAT execute count. Finally, if you check the monitoring
execution plan you can see (lines 12/13) that the Load as Select starts 8
seconds into the query and completes within one second - that's the point at
which the bug would apply.
There is one oddity that I would like an explanation for - how come line 18
started at +4 seconds, when line 12 didn't start until +8 seconds ? The only
(non-buggy) thing I can think of is that there's a run-time dependency that
doesn't show up in the execution plan - even then that's only showing (at
worst) only a 4 second anomaly, not a very slow query.
