RE: *****SPAM***** RE: Any performance benefits in going to db_16k_cache_size or db_32k_cache_size
- From: "Hameed, Amir" <Amir.Hameed@xxxxxxxxx>
- To: <tanel.poder.003@xxxxxxx>, <cary.millsap@xxxxxxxxxx>, <mark.powell@xxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 10 Jan 2007 11:51:14 -0500
For those who are running 11i suite, multiple block sizes are not
supported by Oracle support and they will make a big stink if you try to
change it even if made perfect sense to you. We tried to make a change
for one table when we were implementing RAC based upon recommendations
from Steve Adams but Oracle's 11i performance group pushed back really
hard and stated that if we did that then we would not be supported.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tanel Poder
Sent: Wednesday, January 10, 2007 11:36 AM
To: cary.millsap@xxxxxxxxxx; mark.powell@xxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: *****SPAM***** RE: Any performance benefits in going to
db_16k_cache_size or db_32k_cache_size
Yeah, I agree with Cary and Mark and would add a comment that a
tricky thing like changing block size (thinking about granularity of
buffer locking) should be tested with simulating real concurrency.
E.g. your single session index lookup might run faster due lower
index height, but on the other hand you could have more buffer busy
waits in high-concurrency environments, etc..
Tanel.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Cary Millsap
Sent: Thursday, January 11, 2007 00:13
To: mark.powell@xxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Any performance benefits in going to
db_16k_cache_size or db_32k_cache_size
I have the same opinion as the one Mark describes here.
One more comment: Why guess, when you can KNOW.
If you need to know, test it, and measure the
performance.
Other related posts: