I just started a couple days ago at this client. They're using Hitachi technology in the QA and prod environment with 181G disk. I asked the SA twice and he confirmed the 181 G disk.
I'll ask more details to the SA as soon as I know him better. --- "Deshpande, Kirti" <[EMAIL PROTECTED]> a �crit�: > John, > I agree with the 18GB drives implementation and > pushing for more 'parity > groups'. That's what we did. Now, HDS was back to > sell more disk and backup > soultions to us. I am not sure what we have agreed > to purchase. A cache of > 10GB for the 400GB database is nothing. I bet you > will have tables larger > than the cache size. A single FTS on these tables > will flush the whole > cache... We have 16GB cache (I think I remember that > right, and is the max > for 7700E), and that is not enough for several > servers that the cabinet > supports. > > - Kirti > > -----Original Message----- > Sent: Wednesday, April 10, 2002 7:08 PM > To: Multiple recipients of list ORACLE-L > > > > 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 > === message truncated === ===== St�phane Paquette DBA Oracle, consultant entrep�t de donn�es Oracle DBA, datawarehouse consultant [EMAIL PROTECTED] ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?paquette=20stephane?= 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).
