Re: db block size

> 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.

-- craig
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: