Re: Hints

From: Greg Rahn <greg_at_structureddata.org>
Date: Mon, 15 Aug 2011 13:53:32 -0700
Message-ID: <CAGXkmiuP_RYhj1W6HMt_oHgsRWJp4mgbeaY+uoWCcJNuu51q=A_at_mail.gmail.com>

Or to put it another way: "make sure the scope of the solution matches the scope of the problem".

On Mon, Aug 15, 2011 at 1:50 PM, Tim Gorman <tim_at_evdbt.com> wrote:
>
> I like the point you raise, which I tend to express as "don't burn down the
> forest while trying to light your cigarette".
>
> -----Original Message-----
> From: Neil Chandler [mailto:neil_chandler_at_hotmail.com]
> Sent: Monday, August 15, 2011 02:25 PM
> To: ian_at_slac.stanford.edu
> Cc: oracle-l_at_freelists.org
> Subject: Re: Hints
>
> There are 2 problems with using optimizer_index_cost_adj. Tim covered the
> first extensively (it's a problematic parameter). However, the main reason
> for me is that you shouldn't use global parameters to get around a problem
> with a few of sections of code. There are so many other options to control
> optimisation; object stats, histograms, system stats, hints, outlines,
> profiles and baselines to name a few. as well as rewriting the code of
> course. Try not to use the sledgehammer of global change unless you have
> global problems and will see an overall net benefit from such an
> implementation. Regs Neil Chandler sent from my phone On 15 Aug 2011, at
> 18:13, "MacGregor, Ian A." wrote: > It may be that Oracle has incorrect
> statistics concerning your I/O system, or even if those statistics are good,
> has still misjudged its capabilities. It may be the OS statistics were
> gathered at an inappropriate time. I am of the opinion that Oracle still
> overrates full table scans as compared to index lookups. There is an
> initialization parameter which addresses this. > > optimizer_index_cost_adj

-- 
Regards,
Greg Rahn
http://structureddata.org
--
http://www.freelists.org/webpage/oracle-l

Received on Mon Aug 15 2011 - 15:53:32 CDT