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! [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > <granaman@cox cc: > .net> Subject: Re: disk subsystem performance >question > Sent by: > root@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" <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > > > 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: [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). > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Don Granaman > INET: [EMAIL PROTECTED] > > 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: [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). > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: > INET: [EMAIL PROTECTED] > > 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: [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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Charlie Mengler INET: [EMAIL PROTECTED] 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: [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).
