Okay, there's a variety of inaccuracies here. 1) "The (full cache), which is very expensive, is found on Symmetrix boxes only" - not true. In fact, just about every storage system today has some sort of protected write-back cache. This is true of hitachi, clariion, symmetrix, netapp, etc. EMC's implementation is a little different than some vendors' because it uses a lot of algorithms to determine where memory pressure exists within the cache and tweaks it accordingly. This can result in both better and worse performance under certain situations - your milage definitely varies in this case.
2) "These(write-back cache types) of RAID-5 implementation are usually referred to as RAID-6 or RAID-S" - I can't speak for what vendors say when they mean RAID-6, but RAID-S has nothing to do with cache strategies. RAID-S is a raid variant that is specific to EMC's strategy on disk layout. Basically, on a normal Symmetrix, you take a physical disk spindle: |-------------------| and split it up into one or more "splits": |----|----|----|----| and then you protect splits through mirroring them to splits on other disks, etc. With RAID-S you take 4 disks - its always 4 disks, you have no choice in the matter, and split them identically. You then take each positional split across all 4 disks, and one disk of splits becomes the parity and the rest become logical volumes. Sooo, it ends up looking like this: |--P1--|--P2--|--P3--|--P4--| |--D1--|--D4--|--D7--|--D10--| |--D2--|--D5--|--D8--|--D11--| |--D3--|--D6--|--D9--|--D12--| each one of these D-volumes becomes one logical volume that's exposed to the host, so you end up with 12 data volumes exposed to the host. So, its sort of an odd raid-4-ish - there's no striping per se - each split of the disks becomes a logical volume exposed to the host. When a write occurs to D2, let's say, the accompanying data block from D3 and D1 is fetched, and the XOR'ed parity result written to the P1 split. Horrifying? Yes, a little bit - but on non-cache-hungry workloads, it stands up pretty well even on older symmetrixes. On the new Symms, the claim is that RAID-S is just as fast as RAID-1 on everything but the most strenuous workloads - YMMV. There's also RAID-P, which is the exact same critter, only with 8 disks instead of 4. This actually brings up a worthwhile note - on any large-scale array that has "intelligence" in the caching and data management, you have to be very careful as to how you lay your storage out. Poor choice in software stripe size, volume layout, etc. can completely destroy the performance of an array. This can often explain why some people love large-scale array X while others decry its performance. Workload and design, workload and design. Also, the "non-volatile" cache generally means "battery-backed", which while almost as good as true non-volatile RAM, is not the same thing. Batteries die, power supplies get overstressed, and generally terrible things can happen to your storage arrays, and loss-of-power to the cache = loss of data in write-back environments. 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 Mladen Gogala > Sent: Sunday, June 15, 2003 2:24 PM > To: Multiple recipients of list ORACLE-L > Subject: Re: World premier performance of the BAARF party logo > > > Dennis, to tell the truth, writing in oracle is not a big > problem, as long as the redo files are not on RAID-5. > Everything else can reside on RAID-5 without a visible > performance impact. Second, RAID-5 vendors like EMC and > Hitachi usually offer two versions of non-volatile cache: > write-through one which essentially performs prefetch and a > genuine full cache which caches both read and write calls. > The latter type of cache, which is very expensive, is found > on Symmetrix boxes only and not on former DG-Clariion boxes > (talking EMC here). These types of RAID-5 implementation are > usually referred to as > RAID-6 or RAID-S. > How to benchmark those? Well, the trick in benchmarking those > systems is to do what one would never do with it's own > system: put redo logs on RAID-5(6,S?), launch several threads > of update intensive short transactions (OLTP mix) and count > "user commits" from v$sysstat. Prior to that, establish a > baseline with RAID 1+0 and see what is the difference. See > how many commits would RAID-5 box record during the same time > as RAID-1+0 box and you'll know the difference in speed. > Also, make sure to pull out one of the disks while system is > working and see what's the impact of resilvering. <RANT> As > for the entertainment value, I would hope that Julia Roberts > and Mel Gibson would consider making a movie about the RAID-5 > conspiracy. Julia would be a > DBA trying to purchase a RAID box and Mel Gibson would be a > honest RAID-5 > salesman which would uncover a nasty EMC, IBM and Hitachi > conspiracy. You can tell that it is a fiction because of the > phrase "honest RAID salesman". The only problem would be to > teach the two of them how not to sound "nucular". </RANT> > > -- 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).
