Tragically, no. Basically, though - the cache is just a big board with a pile of memory chips on them. Each chip in a region gets one bit of any word of data that is going to be stored in cache. Then, an extra set of parity bits is generated and distributed amongst additional chips. The result is that the symm can correct any single-bit error and detect any two-bit error (could also be correct two bits and detect three, but I'm pretty sure its one-and-two). So, the failure of any individual cache chip results in the loss of one bit of data from a bunch of different words, which is parity-correctable. Once a cache board detects any single-bit failure, it dials home. An emc tech then dials into the box and determines whether it was just a stray alpha particle or whether its indicative of an actual problem. If a cache board detects multiple single-bit failures in the same cache region, indicating the possible imminent failure of a cache chip or region, the cache board is failed out and all contents of that cache board destaged to disk - EMC is called at the same time.
Much ado is made by competitive vendors about EMC's lack of mirrored cache, and while there are some concerning aspects of it (someone could theoretically yank out a cache board, causing data loss), I would be absolutely comfortable putting my data on a symmetrix cache. (Full Disclosure: I used to work for EMC, though I was a customer long before I was an employee - I bought the kool-aid before I drank it. :) ). Talk to your EMC sales engineer chappie - he might be able to dig up better docs on the cache protection scheme than my memory. Thanks, Matt NB- I realized I wasn't specific in my previous post. I was referring specifically to the Symmetrix when talking about RAIDed cache. The Clariion, as I recall, uses mirrored cache (though that was never the core product I worked with, so I could easily be wrong). This is not an indication of EMC admitting RAIDed cache is a bad idea, but an artifact from the fact that Clariion as a product line was obtained through EMC's acquisition of Data General, and has stayed a fairly different animal from the Symmetrix ever since. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, August 14, 2003 7:19 PM > Hi! > > I wonder do you have a fast link to drop about RAIDedness of EMC storage > cache? > > Tanel. > > ----- Original Message ----- > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Thursday, August 14, 2003 7:29 PM > > > > > > As long as your cache is protected somehow, whether its RAIDed (a la EMC) > or > > mirrored (a la Hitachi), the vast majority of risk associated with > > write-back cache is mitigated. Even with protected cache, I know of a > > variety of failure scenarios that will result in loss of in-cache data, > but > > they definitely fall into the "cascading failure", aka "Act of God", > > category of outages. > > > > 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. :) > > > > 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 Jesse, Rich > > > Sent: Thursday, August 14, 2003 11:49 AM > > > To: Multiple recipients of list ORACLE-L > > > Subject: RE: Storage Cache - WriteThrough or WriteBack > > > > > > > > > Like any good DBA/SA should say "It depends." WriteBack > > > gives you better write performance since the IO only needs to > > > hit the cache to report back as being completed, whereas > > > WriteThru needs to verify the write hit the disk first. > > > Either should give the same performance on reads, provided > > > the cache isn't the point of contention because of heavy writes. > > > > > > For our SAN (if we ever get approval for it), we'll probably > > > go with WriteBack. The safety factor will be that the cache > > > will be mirrored and battery-backed, like you mentioned. > > > It's not failsafe (firmware error could conceivably corrupt > > > the mirror, too), but I feel that we'd be hitting major > > > diminishing returns by going farther than that. You'll have > > > to decide what's best for your situation. > > > > > > BTW, after having someone accidentally kick the power cord > > > out of our existing external storage during a server room > > > rehaul, I'm going to make sure that we have a copy of the > > > control files on a local drive! > > > > > > HTH! GL! :) > > > > > > > > > Rich > > > > > > Rich Jesse System/Database Administrator > > > [EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA > > > > > > > > > > -----Original Message----- > > > > From: Tanel Poder [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, August 14, 2003 3:54 AM > > > > To: Multiple recipients of list ORACLE-L > > > > Subject: Re: Storage Cache - WriteThrough or WriteBack > > > > > > > > > > > > Hi! > > > > > > > > I usually only tolerate write caching on storage subsystems > > > > when we are > > > > dealing with expensive boxes like EMCs Clariion or Symmetrix. > > > > I too have > > > > seen caches fail on entry level boxes like Sun A1000 etc... > > > > > > > > Tanel. > > > > > > > > ----- Original Message ----- > > > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > > > Sent: Thursday, August 14, 2003 8:39 AM > > > > > > > > > > > > > > > > > > I've begun a debate in my organisation about > > > > > caches on storage systems. > > > > > If an Oracle Database, including Redo Log files, > > > > > is on RAID1 or RAID1+0 or RAID5 on the storage/SAN > > > > > and the storage/SAN system provides a cache, should > > > > > the cache be WriteThrough or WriteBack ? > > > > > > > > > > I prefer WriteThrough -- particularly when the > > > > > Redo Log files are also on such external storage. > > > > > > > > > > The vendor talks of Mirrored-Caches and Battery-Backed Cache. > > > > > > > > > > In the past year, we've had one instance of the > > > > > Cache itself failing and the Controller stopping all > > > > > I/O to the storage and a couple of instances of > > > > > Cache batteries being low/dead. {Should I/O be > > > > > allowed to proceed if the Cache Batteries are dead > > > > > or should the storage automatically switch to WriteThrough ?} > > > > > > > > > > > > > > > Hemant K Chitale > > > > > http://hkchital.tripod.com > > > -- > > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > > -- > > > Author: Jesse, Rich > > > 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). > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Tanel Poder > 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).
