For r in (select) loop: execution plan question

Question

Hi there,
I have a procedure which does the following (on Oracle 11.1.0.7):
begin
  for r in (select col1,max(col2) as col2 from tab@remote_db group by col1 ) loop
    update tab2
       set col_a = r.co1
       where col_b = r.col2;
    commit;
  end loop;
end;The subselect from the remote table delivers about 4000 rows.
When executing fast, the procedure runs about 20 seconds, the trace shows that the select is executed 1 time, fetches 49 times. The update executes 4000 times.
When executing slow, the procedure runs about 20 minutes (!), the trace shows that the select is executed 1 times, fetches 4000 times. The update executes 4000 times.
This happens without changing the code, from the same client (sqlplus on the server, same version as database).
Can anyone probably give me a clue how I could track down the plsql execution steps like the optimizer trace that let you see why a certain sqlplan was not taken or what might cause that change in behavior?
I cannot produce that behavior at will - most times the procedure runs fast.
thanks,
Heimo

Answer 1

Hi again,
regarding the "faulty test" and what is fastest: user tested both versions and came up with the for-loop to satisfy him best. I would, of course, utilize event 10046 and tkprof and a repeatable dataset to have solid data. Sorry for not setting enough emphasis on my real question, which is described in the following.
But, and that is what is really causing awkward feelings for me: when doing plain sql, I can use events 10046, 10053 and learn from the tracefiles why a decision was taken (now that is making me feel good, actually). But when it comes to plsql, I have not yet such a handy toolset that helps me understand what influences the plsql-engine to go this or that way.
Thus, I valued the posts pointing to dbms_trace and plsql_optimization_level as helpful answers.
Because of that I learned about the views %_PLSQL_OBJECT_SETTINGS and remembered to check for other plsql-initora settings.
I also verified that neither the 10046 nor the 10053 trace files contain any reference to plsql-parameters/settings, and that the 10053 trace only shows the subselect and update, but no info if it would "bulkify" or not.
Meanwhile I did start to utilize dbms_trace (which causes the statement to go the unbulkifyed by the way) and maybe I can learn from that output or from following posts?
best regards
Heimo