Re: 32K block size tablespace for indexes
- From: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
- To: hrishys@xxxxxxxxxxx
- Date: Thu, 29 Jan 2009 16:38:48 -0800
On Thu, Jan 29, 2009 at 12:35 AM, hrishy <hrishys@xxxxxxxxxxx> wrote:
> Thanks for the reply after going through the thread its sounds like the
> pereceived benfit by moving to a large block size must be thoroughly tested
> its no gaurantee that performance will improve.
Not only tested, but understood. Generally it is best to have a good
theory why something would change performance and then try and collect
data to support that theory. Trying to prove your theory wrong is
also an important part of this. Too often people stop at proving
something "right".
> I was wundering why did oracle come out with multiple block size feature
> considering that in my whole carrer as a DBA i have used large block size
> only for BLOB column storage and nothing else.
I think others have mentioned this, but to reiterate:
- first and foremost transportable tablespaces
- multiple buffer caches for benchmarks (see TPC-C)
- other special conditions (blob, etc)
> Is exadata the reason for large blocksize ?
Exadata cares not and knows not of block size, only I/O size. 8k
block size on Exadata scans just as fast as 16k or 32k.
--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l
Other related posts:
