# 11g, tuning and ANSI **URL:** \ **Category:** Toad for Oracle & DevOps Toolkit\ **Created:** [November 3, 2009, 9:30am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931 "2009-11-03T09:30:23Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 3, 2009, 9:30am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/1 "2009-11-03T09:30:23Z")
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. ---
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 3, 2009, 10:48am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/2 "2009-11-03T10:48:30Z")
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](http://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](http://www.environment-agency.gov.uk) ---
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 3, 2009, 11:13am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/3 "2009-11-03T11:13:43Z")
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. ---
**Author:** ![Bert\_Scalzo](https://sea1.discourse-cdn.com/quest/user_avatar/forums.toadworld.com/bert_scalzo/32/274_2.png) [@Bert\_Scalzo](https://forums.toadworld.com/u/Bert_Scalzo)\ **Post date:** [November 3, 2009, 11:17am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/4 "2009-11-03T11:17:49Z")
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) … ---
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 3, 2009, 11:54am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/5 "2009-11-03T11:54:29Z")
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. ---
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 3, 2009, 1:53pm UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/6 "2009-11-03T13:53:04Z")
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. ---
**Author:** ![Guest](https://avatars.discourse-cdn.com/v4/letter/g/8dc957/32.png) [@Guest](https://forums.toadworld.com/u/Guest)\ **Post date:** [November 4, 2009, 9:20am UTC](https://forums.toadworld.com/t/11g-tuning-and-ansi/8931/7 "2009-11-04T09:20:06Z")
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](http://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](http://www.environment-agency.gov.uk)