Update: Seems the tracefile went to the bdump dir instead of udump and my tracefile_identifier was ignored (thanks Laimutis). One mystery solved. I will analyze it shortly. I have also been able to replicate the issue by schedule the procedure calls directly. V$session_wait shows the wait event causing the issue to be direct path read temp waiting 635 seconds already followed by a 139+ second wait for direct path write temp. -----Original Message----- From: Ken Naim [mailto:kennaim@xxxxxxxxx] Sent: Monday, November 20, 2006 12:21 PM To: 'oracle-l@xxxxxxxxxxxxx' Subject: Tuning issue, 10046 trace and Scheduled Jobs I have a pl/sql batch process running on 10g (using scheduled programs/schedules/jobs) on windows that runs nightly starting at 3 am and part of it calls 2 similar procedures; 3 inserts into global temporary tables, followed by a call to dbms_stats to set the number of records, followed by an insert as select full outer joining the 3 GTT's (~155k narrow records each) with a bit of logic into a permanent table. These insert statements when run at night as part of the batch take 35+ minutes, when they are run at any other time they take less than 10 seconds (210 times slower) whether by calling the package or just running the insert statements. I have looked into everything I can think of. I have checked the explain plans on the 2 queries and they are optimal, statistics and indexes are fine. Yesterday I added 10046 tracing around the 2 procedure calls to see what was taking so long within those queries however no trace file was created. When I just ran the package, it ran quickly and the trace file was generated. 1. Has anyone ever seen a 10046 not generate a trace file when called by a scheduled job? 2. Any ideas on why these "insert as selects" from the 3 GTT's would perform differently when run as a schedule job? Thanks, Ken -- //www.freelists.org/webpage/oracle-l