RE: Long execute phase for SELECT query
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 29 Jun 2006 11:01:47 -0700
Sorry if I'm beating this subject to death, but here is a new twist on
it.
I've confirmed that the query is simply taking a long time for the CBO
to optimize, but I'm not sure why. I just upgraded this system from
8.0.6 to 10.2.0.2 and on 8.0.6 this exact same query only took .03
seconds to hard parse - so why is it now taking 12 seconds? I'm
guessing it is due to some increased complexity in the CBO, but for the
most part this system is running great. So far there are only two
queries (out of thousands) I've seen this behaviour on and they are both
very similar - outer joins of 20+ tables - so it seems there may be a
bug/degradation in the way the CBO is handling such queries.
Has anyone else seen this behaviour in 10g? Any ideas where to look for
a solution other than trying to ensure that the query never gets hard
parsed? I guess I could try digging through a 10053 trace, but I'm not
very familiar with them and not sure really what to look for.
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
