RE: San Performance gurus

We've got a Hitachi 9960, and have done all of our striping at the hardware level. The database is sharing the same disks as several large flat-file systems (e.g. Genbank databases used for BLAST). We're using Veritas, but not using it to do any RAID or striping. We're using Quick I/O for the DB but I'm not convinced that it makes much of a difference in our environment.

I can't tell you much about the actual setup (stripe width, write cache, etc). I just know that back in the days when I was SA/DBA, and the database sat on 5 or 6 different volumes (each a separate RAID set), I had to juggle files to reduce disk contention, and it was a big pain. Now I don't, and neither does the current SA. We've both got plenty of other work to do.

> -----Original Message-----
> From: Spears, Brian [mailto:BSpears_at_Limitedbrands.com]
> Sent: Wednesday, April 23, 2003 6:07 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: San Performance gurus
>
>
>
> Chris, what is your type of SAN are you using?
>
>
> Brian
> -----Original Message-----
> Sent: Wednesday, April 23, 2003 12:37 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I'm not sure I understand the question (but I'm not a
> SAN guru either). We run our database on a SAN,
> and we also use SAME (more or less; see below). The two
> concepts aren't necessarily related (though I'd guess
> it's easier to use SAME on a SAN rather than otherwise).
>
> We're running RAID 5 without apparent ill effects. We spend
> a lot more time reading than writing. We're also in a situation
> (shared by many others, I understand) where tuning a query
> can have a dramatic effect on performance, and I/O tweaks
> are pretty ho-hum by comparison.
>
> Maybe I'm misusing the acronym SAME - I've always used
> it somewhat casually - that is, I assume that building
> across several RAID-5 sets, rather than across RAID 1
> or 10 or 0+1, gives an acceptable amount of protection
> against hardware failure. The one thing I've fought for
> is to have a separate volume, on top of physically
> separate disks, for multiplexing of redo and control files.
>
> -Chris
>

LEGAL NOTICE:
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Sarnowski, Chris
  INET: csarnows_at_CuraGen.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).