Re: 9i multi cache buffer

15 Nov 2002 01:40:33 -0800, Geoff Ingram said (and I quote):

> Do i "believe" Linux/Intel/10i is a great platform for running Oracle
> in terms of performance and value for money running all kinds of
> Oracle apps?
>
> 100% yes. I'll go further. I believe its the Oracle architecture of
> the future.

Geoff, "10i" is not a platform to run Oracle...

>
> TPC-C gives it a certain credibility.
>

Who said it doesn't? That is not the problem.

>
> db_8k_cache_size = 512M
> db_16k_cache_size = 3000M
>
> Either these are wasted (your view?) or they benefit performance.

Probably wasted given that there is no mention anywhere of the use of the 16K one. What's the point of having it reserved if not used?

> > >
> > > TPC-C is an extreme OLTP workload characterised by small transactions
> > > and concurrent block access by multiple sessions. In this case a small
> > > blocksize is good - evidenced by the fact the TPC-C database uses
> > > db_block_size=2048.

So, the TPC benchmark is using exclusively a 2K block size. What is the point of having the other block sizes configured then? And in what way, shape or format are they benefiting performance of said TPC?
> typically costs OEMs > $1million. Personally, i've learnt a huge
> amount from reading about TPC.

Geoff, you're talking to people that have read TPC-C benchmarks and even performed a few themselves. We're perfectly aware of what is involved in doing one.
That means nothing regarding its applicability to real life.

> >
> > > Multiple buffer caches can significantly improve performance in the
> > > right circumstances.
>
> i stand by that. Not just for TPC-C.

Preaching to the converted. See below.

>
> Net result: the DBA obsession with blocksize/buffersize resulting in
> poor I/O is a myth a lot of the time, especially for storage used by
> most large commercial organizations these days.

Precisely. So, what is the relevance of block size and the different buffer caches for them? ;)

>
> There is a place for multiple buffer caches in some cases. If you see
> buffer contention don't rule it out. Keep an open mind.

As it happens and going back to google, you can find that both myself, Howard and Jonathan have talked here about the need for Oracle to support different block sizes on the same database literally years ago. Long before Oracle supported that.
This should give you an indication that the subject is not exactly new to us.

Moreover:
The problem is not with multiple block/buffer caches and their potential impact on performance.

The problem is that it is a new feature of Oracle and in our experience, these new features take a couple of releases to "sort themselves out". If you catch my meaning.

Besides the implementation is currently flawed. What is needed is not different buffer caches for different block sizes. What is needed is different buffer caches (maybe with different block sizes) for different tablespaces.

Exactly like DB2 has. There is a reason why IBM uses it, and it has to do with a lot of performance predictability. Which is much more important than the peak performance between two checkpoints measured in a TPC-C benchmark.

Clearer now why our perspective sounded a bit on the negative side?

> hype is as extreme as basing everthing you do on TPC-C results. I fit
> in the grey area between them.
>

We all do, Geoff. We all do.

-- 
Cheers
Nuno Souto
nsouto_at_optusnet.com.au.nospam