I just started working for a new client who is all 11g and has decided that according to Oracles recommendations since 9i that all table connections will be via ANSI joins.
My question is this: Does ANSI or 11g substantively change how we tune?
I’m seeing some totally whacked out explain plans that I can’t explain at all and nothing I do seems to affect them.
Afternoon,
in my experience, at least since 9.2, ANSI syntax and old style is
mostly the same explain plan. I believe that at 9.1 there were bugs that
causes ANSI code to be dramatically more inefficient that the old style
joins, but since 9.2 that has all gone away.
I have been using ANSI joins for a while, whenever I can, and I see no
performance differences.
What sort of troubles are you seeing with the code you are looking at?
Is there actually a performance problem or is it a perceived one?
Have you tried running the code with 10046 level 8 or 12 trace running,
or DBMS_SUPPORT.START_TRACE_IN_SESSION and looking in the trace file -
the STAT lines will show you the actual plan that Oracle used whereas,
explain plan shows you the plan Oracle might use - they can be
different.
Having said that, no one has ever given me a good reason why they might
be different!
Cheers,
Norm. [TeamT]
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else. We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes. If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.
We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.
If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
It is most definitely not a perception problem. This query performs very poorly,
partially due to the nature of the data structures, but looking at the query and
looking at the plan…. It’s just nuts.
There are four or five main tables with half a dozen outer joined lookup tables.
The odd part is that in the explain plan it seems to start with the optional
tables first reads everything from them, hash joins them half a dozen different
ways and eventually gets around to looking at the main tables.
Maybe I’m completely misinterpreting what I’m seeing, but I’ve
been tuning SQL for 25 years (12 in Oracle) and my methodology has always worked
before, but what I’m seeing now has me baffled, hence the original
question. I didn’t think there should be a major difference without
massive publication and/or discussion of that fact.
There are some scenarios where the explain plans will be different. For example ANSI joins allow a bi-directional or full out join, whereas the old style requires a UNION between two one-way out joins. So the plans are different even though the results are the same. And I’ve yet to see the optimizer smart enough to rewrite the UNION with two one-ways as a bidirectional full outer join. I also wonder if the USING syntax results in anything extra for the optimizer (besides just being a syntax shorthand) …
I’ve heard on the grapevine that some customers see BETTER execution plans
when using ANSI JOINs…their reasoning was the Optimizer better understood
them, which never really made sense to me as it’s Oracle’s optimizer
reading Oracle’s join syntax.
Yeah, I really wouldn’t expect there to be a difference and if there was I
would expect Oracle’s non-ANSI to be better understood by the optimizer,
but I tried converting the offending query to non-ANSI and got basically the
same plan.
I know the optimizer tends to rewrite things and do what it thinks makes the
most sense given the circumstances and the data, but the plan I’m getting
displayed just seems totally wacky and I can’t explain why. The
performance is awful and if it truly is doing it the way the explain shows it I
certainly understand why.
At the risk of offering tuning advice to someone who has been tuning for
25 years .....
There are four or five main tables with half a dozen outer
joined lookup tables.
I'm almost certain that when an outer join is involved, Oracle has few
options for really optimising the query. I think it simply takes the
tables in the order that they are specified, either for the entire query
(similar to am ordered hint) or perhaps just for the outer joined tables
themselves.
As I said, I'm not sure.
Cheers,
Norm. [TeamT]
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else. We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes. If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.
We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.
If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk