Message-ID: <F001.005D1109.20030925102941@fatcity.com>
Date: Thu, 25 Sep 2003 10:29:41 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sender: ml-errors@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: "Matthew Zito" <mzito@gridapp.com>
Subject: RE: BAARF
Organization: Fat City Network Services, San Diego, California
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 8bit


I would strongly advise against redo logs on RAID-0 with oracle duplexing.
Different operating systems respond more or less gracefully to the vanishing
of a storage device (which is the normal behavior of a failed disk on a
RAID-0 set on a HW array).  There's too many variables possible to list out
the scenarios, but I would definitely definitely test failing a RAID-0 set
under load before I would go live with redo logs on raid-0.

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito@gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com

> -----Original Message-----
> From: ml-errors@fatcity.com [mailto:ml-errors@fatcity.com] On 
> Behalf Of Thomas Day
> Sent: Thursday, September 25, 2003 2:05 PM
> To: Multiple recipients of list ORACLE-L
> Subject: BAARF
> 
> 
> 
> I would love to have a definitive site that I could send all 
> RAID-F advocates to where it would be laid out clearly, 
> unambiguously, and definitively what storage types should be 
> used for what purpose.
> 
> Redo logs on RAID 0 with Oracle duplexing (y/n)?
> Rollback (or undo) ditto?
> Write intensive tablespaces on RAID 1+0 (or should that be 
> 0+1)? Read intensive tablespaces on RAID ? (I guess 5 is OK 
> since it's cheaper than 1+0 and you won't have the write penalty)
> 
> While we're at it could we blow up the OFA myth?  Since 
> you're tablespaces are on datafiles that are on logical 
> volumns that are on physical devices which may contain one or 
> many actual disks, does it really make sense to worry (from a 
> performance standpoint) about separating tables and indexes 
> into different tablespaces?
> 
> We have killed the "everything in one extent" myth haven't 
> we?  Everybody's comfortable with tables that have 100's of extents?
> 
> And while we're at it, could we include the Oracle 9 multiple 
> blocksizes and how to use them.  The best that I've seen is 
> indexes in big blocks, tables in small blocks --- uh, oh, 
> time to separate tables and indexes.
> 
> Maybe we will never get rid of the OFA myth.
> 
> Just venting.
> 
> Tired of arguing in front of management with Oracle certified 
> DBAs that RAID 5 is not good, OFA is unnecessary, and uniform 
> extents is the only way to go.  Looking for a big stick to 
> catch their attention with.
> 
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Thomas Day
>   INET: tday6@csc.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@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).
> 

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Matthew Zito
  INET: mzito@gridapp.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@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).