RE: optimizer parameters

And as it happened, more than one configurable off the shelf suite, and especially including the average case implementation of Oracle's own Ebiz at the time, gained a lot more than it lost by using this shotgun. Since any change to the underlying queries in these off the shelf packages by the customer was a customization and the cycle time to get individual "performance bugs" cycled through support was not conducive to a happy work environment, an indiscriminate swipe across the whole database was a reasonable reaction. The people who understood it was a win some lose some proposition, but in the case of Ebiz actually a win most proposition were unfortunately quickly outnumbered in internet presence by folks advising this particular magic bullet being used in shotgun pellet form everywhere.  

So the evidence of it working broadly for Ebiz and some other suites with very few important plans being degraded indeed led to a phase of popularity of magic bullets being applied out of scope. In context, knowing that a suite built by folks who believed in heavy indexing on balance and rates of insert and update that scaled within expectations at the time with time to finish month end report dominated close processes being paramount, tilting plans broadly in favor of index based plans without changing a lick of code made sense. Out of context, where an appropriate narrow scope was available, it made no sense but became popular anyway by dint of being shouted.  

Tuning a "big knob" on a test system and measuring the outcome differential is a reasonable thing to do if you've got a pandemic of bad plans. If it is an overall win, super. That reduces the urgency and head count of remaining bad plans to address at a smaller scope. If it is a loser, it takes almost nothing to reverse the decision. But folks have correctly recognized that a shotgun approach to a narrow problem on a generally healthy system is a risky game.  

mwf

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Niall Litchfield
Sent: Tuesday, April 26, 2011 7:41 AM
To: eglewis71_at_gmail.com
Cc: ORACLE-L
Subject: Re: optimizer parameters  

Historically (8i and earlier) those two parameters were made available to alter the cost of execution plans to make index access 'cheaper'. They did this, broadly, by reducing the cost calculations for certain index access paths. Prior to 9i this was pretty much the only way to make the CBO artificially favour indexed plans. Whether this was smart or not is debateable, but it did become popular (largely because it and other system wide tuning changes via parameter setting tended to appear on page 1 of google searches at that time). The introduction of system statistics (which can have similar effects but does it by increasing calculated costs thus avoiding some of the rounding side effects of the earlier approach) and the cpu costing model has arguably made the earlier approach obsolete, but once an approach becomes popular it takes forever to die!

On Tue, Apr 26, 2011 at 11:05 AM, ed lewis <eglewis71_at_gmail.com> wrote:

Hi Dave,
  Yes, I can trace the query in both environments, and compare the results.

  I also doubt that the vendor will push to get these parameters implemented, knowing that they will be accountable. In the meantime, I plan to go forward, and handle each sql query on an individual basis.

     I'm still curious though, if anyone has modified, and implemented these parameters. If you were installing a new application, would modifying these parameters be a general practice, even if it was not a vendor recommendation ?

  thanks

      ed

• Original Message ----- From: "David Mann" <dmann99_at_gmail.com> To: <oracle-l_at_freelists.org> Sent: Monday, April 25, 2011 11:06 AM Subject: Re: optimizer parameters

>Stephane,

  Thanks for you input.

  I did change these parameters on the session level, but it did not change the original plan for this particular query. So even making these changes, does not guarantee the desired or expected results. As been mentioned, the focus should be on the actual query.

  Also, this particular query takes 14 seconds on prod, but 6 seconds in dev. They both generate the same plan. The environments also differ in data volume and user activity. The vendor is questioning why the times are not comparable.

So the plans are the same - I would let the vendor know what you found - especially that their recommendation did not solve the issue. I avoid "Big Knob" tuning on established systems as well. Unless the client has a way to test the system and determine if any performance got worse because of the changes.

In the meantime anything stopping you from tracing execution (with WAIT info captured) on Dev and Prod to see differences in what the query is spending its time on?

-Dave

-- 
Dave Mann
www.brainio.us
www.ba6.us - Database Stuff - http://www.ba6.us/rss.xml
--
http://www.freelists.org/webpage/oracle-l



--
http://www.freelists.org/webpage/oracle-l






-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info



--
http://www.freelists.org/webpage/oracle-l