As a test to verify what was likely causing the change, that seems reasonable and unlikely to yield wrong answers or lose out much in the short haul. But you’re right on target as regards using a wide scope change as a band-aid: some sort of plan stability for the particular statement would be much better. mwf From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Taylor Sent: Thursday, October 30, 2014 11:07 AM To: Andrew Kerber Cc: Mauro Pagano; howard.latham@xxxxxxxxx; oracle-l Subject: Re: Really strange performance issue Wouldn't it be better to attack the problem instead of changing the whole "world" by setting the db parameter? If it's one SQL statement, I'd use a SQL Profile to guarantee the plan that I want is used before forcing something at the db level. Chris On Thu, Oct 30, 2014 at 10:03 AM, Andrew Kerber <andrew.kerber@xxxxxxxxx> wrote: And we have a winner. The actual plan must have changed, even though when I just ran the explain command it did not. I turned off _optimizer_use_feedback and that fixes it. The question is why? Sent from my iPad On Oct 30, 2014, at 9:49 AM, Mauro Pagano <mauro.pagano@xxxxxxxxx> wrote: Does the execution plan change between first and second execution? If no the ignore the rest of my message but if yes then an educated guess (since we have no other info available) would be "cardinality feedback", you can test it setting "optimizer_use_feedback" = false On Thu, Oct 30, 2014 at 10:42 AM, Howard Latham <howard.latham@xxxxxxxxx> wrote: Any chance of seeing the Query please? -- //www.freelists.org/webpage/oracle-l -- http://about.me/mauro.pagano