Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Schema Placement for Purchased Apps

Re: Schema Placement for Purchased Apps

From: Howard J. Rogers <howardjr20002_at_yahoo.com.au>
Date: Fri, 11 Apr 2003 08:01:32 +1000
Message-ID: <NGlla.11490$1s1.179864@newsfeeds.bigpond.com>

"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message news:b7453k01kp4_at_drn.newsguy.com...
> 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.

Exactly. When I tell students that, however, I see looks of disbelief and disappointment spread across their faces. This is why it is so important we scotch the idea that you have any practical choice in the matter of block size: your O/S determines (well, your filesystem, anyway) not the nature of your database.

Incidentally, when I tested the use of non-appropriate block sizes on Linux and Windows 2000, I got degredations in the speed of queries of anywhere between 3 and 11%. I don't think 11% is 'very small', and whilst I grant that it isn't exactly 'crippling', either, it's certainly not optimal.

Regards
HJR
>
> 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 - 17:01:32 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US