Re: Schema Placement for Purchased Apps

In article <Xw5la.10928$1s1.174289_at_newsfeeds.bigpond.com>, "Howard says...
>
>
>"Gabriel Gonzalez" <no-spam_at_no-spam.com> wrote in message
>> It used to be that the disk usage was also an issue, but it is not anymore
>> because Oracle now allows you specify different block sizes for each
>> tablespace, and so you can have one tablespace be 2k while another is 64k
>in
>> the same database.
>
>And you'll cripple I/O operations in the process. Please visit
>www.ixora.com.au, and read Steve's advice on using the multiple block sizes
>feature in 9i. I'll give you the precis: don't, if you are running on a file
>system without direct I/O, because otherwise, the block size must match the
>filesystem buffer size exactly. And that doesn't change.
>
>Block size is a function of filesystem, not whim, application type, or
>anything else.
>
>Regards
>HJR
>

I think saying "cripple" might be a bit of overkill, Howard. Depends on the amount of I/O being done to those particular tablespaces that don't end up matching the filesystem buffer size.

Regardless, though, the point needs to be very clear that there has been a LOT of testing, both internally and externally, on using different block sizes for performance gains, and all that testing points to very samll performance differences. There are other ways of getting much more performance improvement that you would need to address before even looking at different block sizes. Different block sizes are there for one reason only - to transport tablespaces from different block sized databases into a staging database before summarization and so on into the data warehouse.

Pete
>
>
>
>
>> Combined with the ability to have multiple drive arrays
>> with different RAID levels each, disk usage issues alone will not force
>you
>> to create another database/instance.
>>
>>
>>
>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Thu Apr 10 2003 - 11:11:32 CDT