I've cussed and discussed the topic of one big stripe versus multiple small
stripes with different people and have yet to come across anyone who has
conducted a real test of various scenarios.  If you stripe across all disks,
then you have the advantage of guaranteed, perfectly balance I/O -- there's
certainly something to be said for that!  But, then you have a mix of reads
and writes going across all drives too.  A good argument can be made for
taking those parts of the database that tend to be only one kind of
operation -- for example, archive logs are writes -- and putting them in
their own area.  So the drives handling the writing of archived logs are
doing only one kind of operation (or are they?!), but you subtract from the
drives allocated for other operations.  But then there is the issue of: Just
exactly how do hard drives work?  For example, when doing a large "write
only" operation (like creating an archived log) is the drive really doing
this neat and tidy write only, one track after the next, each track right
beside the other?  Or does the drive actually write a little bit, read a
little bit (like a check sum or verify operation), then write some more.
And when writing, does it do this smooth, nicely contiguous write, all in
one operation?  Or does it write a little bit (like an OS buffer full), then
move to a different track to update an allocation table (then perhaps read
the allocation table), then perhaps go pick up a timing mark, etc.?

I suspect some of the answer is dependent on the number of drives and
controllers available.  (And I must say, that when I read your original
question, I wondered why on earth would an organization ready to drop a
bundle on a 15K be scrounging for drives -- if I interpreted your post
correctly.  Is this a Dilbert sort of thing?)

The only time I have striped across all drives was the only time I was in a
position to make that decision.  This was a few years ago, and it was when I
did Solaris/AIX admin.  It was on a Sparc 4500 with 6 250Mhz CPU's.  Since
we did not have an Oracle DBA, and I didn't have the time or inclination to
devote to setting up and maintaining and "official" OFA compliant structure,
I just made one giant (considered giant at the time) 250 Gb filesystem that
would hold all things Oracle and be done with it.  I made two 30-drive (8.4
Gb drives) stripes and mirrored them using Solstice Disk Suite.  There were
10 wide scsi controllers.  Each controller had a 6-drive JBOD attached to
it.  An eleventh controller had an additional JBOD to be used for hot
spares.  As you might guess, with a I/O pipe this big, there was no way the
6 CPU's could generate enough I/O to bog things down or even cause a hint of
an I/O wait.

So the stripe across all drives does work.  In my case, I had 60 drives on
10 controllers to work with. Could this have been made more efficient by
making a collection of smaller stripes?  I have never found anyone who could
answer that.  The Disk Suite folk can tell you that there is an optimal
striping configuration for Disk Suite if we leave Oracle out of the picture.
But with Oracle in the picture, who knows?

One configuration that sounds reasonable is to put data files with random
reads and writes on one stripe, put even numbered redo logs on a stripe, put
odd numbered redo logs on a stripe, put archived logs on a stripe.  The
reasoning (or arm-chair theory) behind the even/odd redo logs is that at a
log switch, one file system can be doing writes, while the other is doing
reads for the log archiving.  This is sorta kinda the way we do things at
our shop here with some modifications depending on the app -- like maybe
dedicate a stripe to servicing the outrageous temp requirements of a "data
warehouse" (more correctly, a data landfill).

If you have only a few drives, my inclination (with no proof whatsoever) is
that the one big stripe approach might be a good idea.  Thus far, all I have
ever gotten on this subject is a lot of "religion" and very few proven
facts.
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephen Lee
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to