Re: Bigger blocksize on index TBS

From: <>
Date: Tue, 15 Jan 2008 14:53:30 -0800 (PST)
Message-ID: <>

On Jan 15, 5:31 am, joel garry <> wrote:
> On Jan 14, 6:47 am, Helma <> wrote:
> > On 14 jan, 14:54, "Jonathan Lewis" <>
> > wrote:
> > Thank you for the pointers. I've read opinions about the use of
> > different blocksizes, but they were often anecdotical. I don't have
> > the opportunity to test if it makes a difference - the database is
> > just too big for such high impact experiments with low revenue
> > expectations.
> > I think i've got bigger fish to catch.
> > thanks again,
> > H.
> One more con:
> Eliminates your option of multiple buffer pools for anything in the TS
> in question.
> (hey, 11g docs still mention hit ratios! ĦAy Caramba! Take these docs
> with a margarita rimmed in salt.)
> jg
> --
> is bogus.

As I've pointed out many times in the past: the use of non-default block size caches not only rules out the use of multiple buffer pools within those non-standard block size caches, but you also rule out the use of ASMM to manage them. That is, memory allocations to these nonstandard  caches is manual and must remain so. This will probably change at some point, but until it does, if you have any desire at all to make full use of ASMM, then non-standard caches would be a definite 'con'.

The bottom line is: if you want to use non-standard block sizes, you are effectively saying to Oracle, 'My database is peculiar (or parts of it are). So peculiar that your memory management techniques are suboptimal.  I, however, understand my application and database better than you, and I understand how memory management ought to be carried out better than you. Therefore, I will take charge of things which you would normally do for me, and I'm going to make a better fist of it than you ever could"

If you can't sign up to all of that, then don't use multiple block sizes in the one database. Received on Tue Jan 15 2008 - 16:53:30 CST

Original text of this message