Well, its beyond no "need" to multiplex - it rolls right into "might not be possible" (though that's an extreme case). Basically, since today's large arrays have several layers of abstraction between the storage consumer and the physical spindles, it can be difficult to determine what physical spindles data is living on.
>From a reliability standpoint, its always worthwhile to have extra copies of things you need floating around, though in the case of a large array a fault that is severe enough to cause data loss at an array level is probably catastrophic enough to cause data loss on the copy(ies) as well. The more likely scenario is filesystem corruption when a server goes down. Ask your storage administrator to work with you to put redolog copies on different RAID sets. If they look at you like you're crazy, get another storage administrator :) Or set up a meeting with your Large Storage Vendor - they have people on staff to help with things like that. Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, September 22, 2003 2:05 PM > To: Multiple recipients of list ORACLE-L > Subject: OFA and Shared Storage > > > I read some posts on here with shared storage such as SAN and > Network Appliances its no longer necessary to multiplex > datafiles on different disks, since the storage array handles > that for you. > > How do you ensure that control files and redo log files are > kept safely apart so that no one disk failure in the shared > storage can take them all out? > > According to the OFA(well the abbreviated version I have in > front of me) 4-5 disks is optimal for multiplexing. Does this > no longer apply with shared storage? How do you ensure > database available with shared storage? if your not > multiplexing datafiles? > > I may have read some peoples posts incorrectly. Im just > digging into backup and recovery. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: <[EMAIL PROTECTED] > INET: [EMAIL PROTECTED] > > 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: [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.net -- Author: Matthew Zito INET: [EMAIL PROTECTED] 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: [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).
