> Well, that is not quite true. If there are big tables that need to be read by using
> full table scan, than 16k buffer pool can act as recycle buffer pool and those
> big tables will be read faster then if the block size was 8k. You can still
> create normal indexes which reside in 8k tablespace onto 16k table. I can
> see mixed sizes buffer pools being used in the mixed mode (OLTP & DSS)
> databases, especially with RAC, when the big transaction history tables
> are used for reporting purposes from the designated "batch node".
> I tested a configuration like that, and 16k buffers provide real
> benefits for the large full table scans, even if there were only 2048
> 16k buffers (32M in all). Pete, you have wrong ideas about absolute zero.
> Absolutely wrong ideas.
For the time being, I would be cautious about using multiple block sizes on a
large (VLM) linux database or a RAC system - minimize risk. The former because
things are weird enough (is it even supported?). For the latter, I'd be more
concerned about oddities in the block shipping code with variable sized blocks
running around the interconnect - this is where some of the single instance
wins can turn into latency killers or debugging headaches.
Received on Mon Jun 21 2004 - 00:55:00 CDT
