Mmmm...I posted at some point with a description of EMC's write strategy - here it is:
"Some arrays actually don't even give you the option of write-through cache - on the symmetrix, for example, it is actually impossible for a write to go directly to disk. You have no choice but to cache writes. This is called, in EMC marketing parlance, a "Fast Write". When the cache is under pressure and the symm decides it needs to make more room in cache for an incoming write, it holds the write at the host port, flushes an in-cache write to disk, then places the incoming write in cache and acknowledges it to the host. This is a "Delayed Fast Write" - I love marketing talk. :)" Whether or not a write will hit spindles directly depends on a couple of factors: -Do you have write-back or write-through enabled? (write-back = cache writes and write-through=only cache reads) -How pressured is your cache? Some naive arrays won't throttle back active hosts and so if you're unfortunate enough to be sharing an array with a very write-heavy box, your writes could end up bypassing cache -how utilized are your disks? Some arrays will write directly to disk when the disks are very idle. The end result being, of course, it is completely dependent on your array. A quibbling little point - SAN is no different, from a what-is-cached standpoint, than NAS or direct-attached. It just happens that high-end arrays tend to have more intelligence internally and those tend to be the arrays that get hooked into SANs. As far as RAID-5 goes, some arrays are better than others. EMC happens to be particularly bad (at least on their last gen arrays - they claim huge performance increases on the new frames - ymmv), Hitachi tends to be pretty good. The bigger your write cache, the less the quality of the RAID-5 implementation matters. If you aren't pushing a whole lot of throughput, you'll never notice the difference between different RAID-5 implementations. 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 Craig Munday > Sent: Monday, September 22, 2003 6:40 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: OFA and Shared Storage > > > Hi, > > I've tended to have performance problems with RAID-5 (slow write > times). Does SAN make this any better, ie. with large disk > caches etc? > > With SAN, do the redo logs still hit the spindles when a > commit is issued > (for example)? I seem to recall that the EMC Symmetrix > considers the write > to be done when the write request is in its cache and not > necessarily on > the disk. > > Cheers, > Craig. > > > > At 10:54 AM 22/09/2003 -0800, Mladen Gogala wrote: > >Files are kept safe simply by RAID-5 mechanism. RAID-5 > protects against > >any single disk failure (double disk failure can wipe it all > out) and > >that is precisely why Mogens is such a zealous proponent of RAID-5 > >systems. > > > >-- > >Mladen Gogala > >Oracle DBA > > > > > > > > > -----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). > > > > > > > > > > > > >Note: > >This message is for the named person's use only. It may contain > >confidential, proprietary or legally privileged information. No > >confidentiality or privilege is waived or lost by any > mistransmission. If > >you receive this message in error, please immediately delete > it and all > >copies of it from your system, destroy any hard copies of it > and notify > >the sender. You must not, directly or indirectly, use, disclose, > >distribute, print, or copy any part of this message if you > are not the > >intended recipient. Wang Trading LLC and any of its > subsidiaries each > >reserve the right to monitor all e-mail communications > through its networks. > >Any views expressed in this message are those of the > individual sender, > >except where the message states otherwise and the sender is > authorized to > >state them to be the views of any such entity. > > > >-- > >Please see the official ORACLE-L FAQ: http://www.orafaq.net > >-- > >Author: Mladen Gogala > > 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: Craig Munday > 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).
