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).
