Re: disk subsystem performance question

I believe RAID-1+0 has more cost than benefit. I want to see & measure total I/O's to each spindle. While RAID-1 has higher cost to maintain, it gives me maximum flexibility to evenly distribute I/O loads. I contend that with proper table partitioning I can achieve & sustain higher I/O rates with RAID-1 than can be gotten from RAID-1+0.

HTH & YMMV HAND! John.Dailey_at_ing-fsi-na.com wrote:
>
> Thanks for all the replies. We are determined to lay out the data as
> well as we can across the disks we are about to purchase - with the goal of
> striping across array groups and smaller, faster drives. The real
> argument for us is 18GB vs. 73GB disk drives and how we can stripe. The
> Hitachi is configured into groups of 4 physical disks called "parity
> groups" and you can choose RAID 5 or RAID 1+0 for that 4 disk set. If
> you have 73GB drives in a 4-disk RAID 5 configuration you get roughly 219GB
> of usable space in each parity group (this is what we are being told is the
> best option for us). This means our heavily concurrently accessed 400GB
> production database goes on 2 parity groups (2 sets of 4 disks). To
> me, this sounds like a nightmare waiting to happen and we are trying to
> stop it. The 18GB drives are less capacity but we can get ourselves
> spread over more parity groups for better concurrency. We do have about
> 10GB of cache but it is being shared across the enterprise with various
> other applications. We as a DBA group are really trying to sell the
> 18GB RAID 1+0 drive solution especially after reading the groups'
> experiences - unfortunately we are fighting a lot of marketing hype.
>
> If anyone has additional experiences or feedback with Hitachi or EMC they
> would like to share or comments (agree/disagree) with my thoughts, I'd love
> to hear them. I'm open for learning!
>
> Thanks,
>
> John Dailey
> Oracle DBA
> ING Americas - Application Services
> Atlanta, GA
>
>
> "Don
> Granaman" To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> <granaman_at_cox cc:
> .net> Subject: Re: disk subsystem performance question
> Sent by:
> root_at_fatcity.
> com
>
>
> 04/10/2002
> 01:08 PM
> Please
> respond to
> ORACLE-L
>
>
>
> Short answer - NO! Nobody's disk subsystem is so fast that no intelligence
> is required in the layout. This is common vendor blather and one of the
> most popular myths. I have been hearing it for at least six years - and it
> still isn't true. Layout still makes a huge difference. RAID levels still
> make a huge difference. Cache won't solve all your problems (it does help
> though). I've redone the disk layout on some of the biggest, fastest
> fully-loaded with cache EMC Syms available that had some "don't worry about
> it" layout and seen database throughput go up by as much as 8x.
>
> See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf
> .
>
> Don Granaman
> [certifiable oraSaurus]
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Wednesday, April 10, 2002 10:38 AM
>
> > Hi all,
> >
> > We are running both a Hitachi 7700E and a 9960 disk subsystem here and we
> > are getting ready to move our production DBs from the old(7700E) to the
> > new(9960) Hitachi. We have had trouble in the past on the 7700E due
> to
> > disk contention and layout, i.e. we weren't striped across the array
> groups
> > very well.... this caused pretty poor I/O performance. This has
> been
> > a learning experience for the DBAs and the SAs here for the logical vs.
> > physical aspects of our disks. Anyway, to make a long story short,
> we
> > are ordering disk for the move to the 9960 and we have 2 choices in disk
> > sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would
> like
> > to get the smaller, faster 18GB drives in a RAID 1+0 configuration and
> > stripe our data across the array groups as wide as possible. However,
> I
> > am running into objections from the Hitachi people that their system is
> > "soooo fast we need not worry about such minor details". I'm having a
> > hard time believing that given our I/O problems on the 7700E.
> Performance
> > is given a high priority here.
> >
> > What I would like to know is others' experience with disk subsystems -
> > specifically Hitachi but EMC and others as well.... have you been able
> to
> > "throw the disk in and forget it" or have you had success in getting to
> the
> > dirty details? Have you tested or noticed an improvement with
> smaller,
> > faster drives in a disk subsystem like the Hitachi or have you traveled
> > that path and found no noticeable improvement? I'm looking for
> either
> > a) ammunition that my view is correct, or b) I'm wrong and we can get
> > bigger drives which will make Enterprise Planning very happy from a $$$
> > standpoint because our Hitachi capacity will last longer.
> >
> > We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version
> 8.
> > 2 production databases , one 400 GB and the other about 1TB. We've
> got
> > some other production DBs but these are our big guys.
> >
> > Thanks in advance for any and all input - any help is greatly
> appreciated.
> > I'd be happy to share any info we have found up to this point and our
> > experiences on the 7700E as well if anyone is interested - despite the
> fact
> > I will probably bore you to death :-)
> >
> > John Dailey
> > Oracle DBA
> > ING Americas - Application Services
> > Atlanta, GA
> >
> >
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author:
> > INET: John.Dailey_at_ing-fsi-na.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (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).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Don Granaman
> INET: granaman_at_cox.net
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: John.Dailey_at_ing-fsi-na.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Charlie Mengler
  INET: charliem_at_mwh.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).