This reminds me of my experiences with IBM a couple of years ago.
The IBM Shark is a decent piece of storage HW, but does have some funky aspects. Regarding the vendor claims, when I took a close look at their claimed throughput numbers, it became clear that the only way to achieve their claims was to get a 100% hit rate on the Disk Cache. That didn't seem too likely to me. Here's a tidbit: unless they've changed their architecture, IBM Shark only does Raid 5. And you can't get the same number of physical disks in each physical volume. And you must split a PV into at least 2 LV, as the volume manager couldn't make a logical volume as large as the physical volume. Jared "Don Granaman" <granaman@home To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> .com> cc: Sent by: Subject: Re: RAID system max throughput [EMAIL PROTECTED] om 12/07/01 03:15 PM Please respond to ORACLE-L Whenever someone (especially a vendor) says something like "Don't worry about it...", I worry about it. Who told you that this was "simplistic thinking"? I've been told similar things a number of times - and proved them wrong in every single case. "With hardware RAID, RAID-5 is just as fast as RAID 1+0". "With EMC Symmetrix you don't want to stripe". "SAME - Just splatter all your files randomly across a monster stripe set using every possible disk". And the ever popular one you are encountering now. A lot of those things are at true - to a point. Beyond that point it matters. Hardware RAID, cache, and such can buy you performance, but there is still some threshold beyond which the old-timey DBA intelligent file placement, striping and such will be necessary. There is a difference between "good enough for now" and "optimal". I would rather build it better from the start, even if I don't need the performance immediately, than wait until its a crisis and only then frantically rebuild everything. See Gaja's paper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . -Don Granaman [OraSaurus] ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, December 07, 2001 4:31 PM > Jack - Well, that's what I thought. I could see where the disk would be a > lot better about streaming data off the disk if the data was arranged in a > favorable manner rather than randomly located. However, I was told that was > simplistic thinking and that modern RAID systems are much more sophisticated > than that. And I'm willing to concede that a RAID system is more complex > than simple drives. I'm just hoping that someone on this list has more > experience on the database/hardware interface. Thanks. > > -----Original Message----- > Sent: Friday, December 07, 2001 3:25 PM > To: Multiple recipients of list ORACLE-L > > > Dennis, > > I'm no RAID guru, but I can sure imagine disk heads thrashing around, trying > to satisfy a mix of sequential and random reads and writes, causing the DB > to wait, but not getting anywhere near the rated throughput for the RAID > controller or channel. > > Could that possibly be the case? > > Jack > > -------------------------------- > Jack C. Applewhite > Database Administrator/Developer > OCP Oracle8 DBA > iNetProfit, Inc. > Austin, Texas > www.iNetProfit.com > [EMAIL PROTECTED] > (512)327-9068 > > > -----Original Message----- > WILLIAMS > Sent: Friday, December 07, 2001 10:40 AM > To: Multiple recipients of list ORACLE-L > > > Whenever I discuss disk waits with my system administrator, I always get the > reply that "the RAID system isn't anywhere near its rated throughput". Maybe > I'm wrong, but I don't see any of the tuning books mentioning that as a > relevant performance characteristic. However, I've never been able to move > the discussion beyond this point. Can anyone straighten me out on this point > or point me to a resource that might be applicable. > > Our system is Oracle 8.1.6, Compaq Tru64. We use hardware RAID-5 with a > battery-backed RAM cache, and have about 3 RAID sets (plus some extra disks > for redo logs, etc.), and performance is fine, but I'm always looking as to > how we can improve Oracle performance. The application is our corporate ERP > system. > > Dennis Williams > DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Jack C. Applewhite > 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: DENNIS WILLIAMS > 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).