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: Long execute phase for SELECT query

RE: Long execute phase for SELECT query

From: Allen, Brandon <Brandon.Allen_at_OneNeck.com>
Date: Wed, 28 Jun 2006 14:02:54 -0700
Message-ID: <04DDF147ED3A0D42B48A48A18D574C45059E19AD@NT15.oneneck.corp>


There is an ORDER BY, but seems that shouldn't be too bad considering there are only 22 rows being returned. The query does actually include a FIRST_ROWS hint already, and the execution plan is purely NESTED LOOPS OUTER operations (I forgot to mention in my original email that it is an *outer* join). It appears that the CBO is actually coming up with a good plan - just taking a long time to parse it due to the large number of tables, and since it's using bind variable peeking - that long parse time is being recorded in the EXECUTE phase rather than the PARSE phase. I think my best option is to just avoid hard parsing on this baby - I'll have to look into options for doing that. I'm not sure if you can pin plain old SQL statements or only PL/SQL, but I'll find out soon - I'm off to RTFM . . .

Thanks!   

-----Original Message-----
From: Stephane Faroult [mailto:sfaroult_at_roughsea.com] Sent: Wednesday, June 28, 2006 10:37 AM
To: Allen, Brandon
Cc: oracle-l_at_freelists.org
Subject: Re: Long execute phase for SELECT query

It may come from sorts (explicit or implicit ones, eg GROUP BY) especially if they take place on disk, or from big hash joins that would also take place on disk. With 27 tables the number of combinations is rather high and the optimizer can be forgiven for getting confused. As a first approach, and since the number of returned rows is low, I would try to favor a nested loop approach with a hint in the FIRST ROWS family. Unfortunately I doubt it will be enough. I suspect that there is a rather selective criterion in your query that doesn't look so to Oracle. You may find this useful:
http://roughsea.com/article.php3?id_article=60

HTH Stéphane Faroult

Allen, Brandon wrote:
> I've got a monster join (27 tables) coming from my Baan ERP app. It's
> taking 0.00 seconds to parse and only .05 seconds to fetch, but is
> taking 15.05 seconds for the execute phase - see below from tkprof:
>
> call count cpu elapsed disk query current
> rows
> ------- ------ -------- ---------- ---------- ---------- ----------
> ----------
> Parse 1 0.00 0.00 0 0 0
> 0
> Execute 2 13.94 15.05 0 0 0
> 0
> Fetch 4 0.00 0.05 16 420 0
> 22
> ------- ------ -------- ---------- ---------- ---------- ----------
> ----------
> total 7 13.94 15.12 16 420 0
> 22
>
>
> I've never seen a SELECT query with such a high Execute time before -
> usually only DML queries take time in this phase and SELECT queries
> spend their time in the Fetch phase. Any ideas what would cause this
> behaviour? Oracle version 10.2.0.2 on AIX 5.3
>
> If you want to see the query and explain plan, let me know and I'd be
> happy to provide it - I just didn't include it here because it's huge
> and I'm not sure it's relevant.
>
> Thanks,
> Brandon
>
> Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jun 28 2006 - 16:02:54 CDT

Original text of this message

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