Re: Enable 32K Block in 8K Block DB

From: Frank van Bortel <fvanbortel_at_netscape.net>
Date: Sun, 04 Apr 2004 14:07:28 +0200
Message-ID: <c4otl4$3fg$1@news3.tilbu1.nb.home.nl>

Howard J. Rogers wrote:

> "Charles" <cdavis10717_at_comcast.net> wrote in message
> news:83dbb3cd.0403290528.7dae3736_at_posting.google.com...
>
>

>>Thank you for replying.
>>
>>The database I am working with is a 1.8TB SAP R/3 oracle database.  I
>>wanted to reorganize its indices into 32K tablespaces since some
>>Oracle Performance book author(s) have indicated that's a good idea
>>for indices.

>
>
> It's not, and the advice is utter nonsense.
>
> Unless you are running on raw, or have a file system that can do direct I/O,
> then mucking about with your block sizes is (a) a complete waste of time and
> (b) is actually going to introduce performance problems.
[SNIP!] And it's that exception, that gets forgotten, not emphasized enough, or whatever, that feeds the general impression of "big is better" .

Even in Steve's article (http://www.ixora.com.au/tips/block_size.htm), it's quite easy to read over it, and get the impression you can do it on *any* filesystem.

Bottom line (still) is - don't use buffered IO; use direct or raw (why do you think every benchmark of oracle still uses raw?!?)

Now - how do I convince the SA to go raw on his HP machine with VX7100, where he found a benchmark that proofs he was right to create the filesystem with 8k blocks?

-- 

Regards,
Frank van Bortel

Received on Sun Apr 04 2004 - 07:07:28 CDT