Which makes perfect sense -- now. :) I was incorrectly looking at the = trace info... The job and it's trace eventually completed. A quick tkprof showed the = obvious query in question. The explain plan didn't look great, but when = FTSing a table for creation of a mini-DM, how could it? By creating = another index on the joined table, that's how. From the query, it was obvious to me that the column to be joined was = ACCOUNTNO, and the optimizer happily chose a unique index to join on. = If I had looked closer (doh), I would have seen that ACCOUNTNO was not = in that index! The optimizer chose that index because it was in a = filter for that table, but not in a join. Thus, the nasty IO. I added = a non-unique key for ACCOUNTNO on that table and the IO dropped from = 300M to 2M. And the job completed in 14 minutes. The procedure still isn't scalable at all, but at least it runs -- for = now. Since it's a month-end job and it's month-end, it'll have to do = for now. And we'll be throwing hardware at our nasty SQLs in a month to = make them run reasonably well again for a few years. And the cycle = continues... <sigh> THANKS for the help!!! I'm Rich Jesse, and I approve of this message. Rich Jesse System/Database Administrator rich.jesse@xxxxxxxxxxxxxxxxx QuadTech, Sussex, WI USA > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] > Sent: Thursday, April 29, 2004 9:09 PM > To: oracle-l@xxxxxxxxxxxxx > Subject: RE: INSERT...SELECT pegs CPU, but is waiting on=20 > scattered read? >=20 >=20 > Rich, >=20 > The Oracle kernel is not going to emit a trace line until=20 > either (a) it > completes a "timed event" (like an OS read() call), or (b) it=20 > completes > a db call (like an EXEC). >=20 ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------