Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: INSERT...SELECT pegs CPU, but is waiting on scattered read?

RE: INSERT...SELECT pegs CPU, but is waiting on scattered read?

From: Jesse, Rich <Rich.Jesse_at_quadtechworld.com>
Date: Fri, 30 Apr 2004 10:06:47 -0500
Message-ID: <FBE1FCA40ECAD41180400050DA2BC54004E938F5@qtiexch2.qgraph.com>


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_at_quadtechworld.com      QuadTech, Sussex, WI USA


> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org]
> Sent: Thursday, April 29, 2004 9:09 PM
> To: oracle-l_at_freelists.org
> 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_at_freelists.org 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
-----------------------------------------------------------------
Received on Fri Apr 30 2004 - 10:04:47 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US