Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Is Raid 5 really that bad for Oracle?

Re: Is Raid 5 really that bad for Oracle?

From: omlet <notrolls_at_notrolls.omlet.org.notrolls>
Date: Tue, 03 Aug 2004 15:57:39 -0400
Message-ID: <c1298bcca272850daa05252529d5fd7d@localhost.talkaboutdatabases.com>


My argument is this:

  1. Mirroring is excellent for resilience. So is snapshots implementation
    (less than 1.4MB). Combining any two technologies
    makes for excellent resilience and excellent performance. Add to it, clustering and you get true %99.99999.

Check the Saber/USAirways infamous crash: RAID 10 corruption lasted for three full days!

2. But mirroring is expensive per byte of storage. Hence RAID levels 2, 3,
4, 5, and 6 were proposed. Their design goals were to lessen the expense-per-byte of storage of RAID level 1 (mirroring). For example, with
G=5 RAID level 5, the price of resilience per byte of storage is 5/4 of a 4-disk array instead of 8/4.

Why waste the shelve space and disks for a false sense of added resilience?! A disk array with 60 disks would shake worse than Daniel Morgan's Mama.

3. But the additional parity operations required to run RAID [23456] produce
a performance penalty. The performance penalty is so bad (4:1 for many common Oracle operations) that it begged for a solution: namely, the introduction of non-volatile cache

Where did you get this crap from? A simple cache would do? A disk is prune to crash; and Oracle treats it as such. Simply have your redo logs elsewhere. Actually a post "NO REDO LOGS ALLOWED" should be posted on every disk array.

Now the archived logs are another story; again checked for corruption by the archiver they would be best suited for tapes and MOST IMPORTANTLY SNAPSHOTS. why waste disks and shelve space!

and a complicated kernel (more lines of
source code than Oracle7.1) to run it all.

Dead wrong!

So, as long as the cache is big
enough to stay ahead of your sustained throughput, a RAID level 5 array can
perform almost as well as a well-configured array that uses levels 0 and 1
combined.

The goal is not RAID 0 and 1 combined: it is raid 0 level of performance. Easily attained with large cache and some added magic you missed all along: PREFETCHING. Check EMC's prefetching algorithms and utilization using a utility like OMLET or Spotlight and see for yourself.

4. But the RAID level 5 array is deficient in a number of important ways
(performance degradation during partial outage as Howard mentioned,

Dead wrong! all the rebuilding done in the background using SMP and tons of cache reserved for this -- by the way SCRUBBING is done all the time in all major arrays; and during partial outage is not degrading more than Daniel Morgan.

worse availability performance,

Dead wrong! Parity disks are cached entirely in cache and recomputed; in fact many situations of double disk crash is hot swap-able.

worse read performance [contrary to popular belief],

Now where the hell did you get this?! I have spent more than 6 years benchmarking and running tpcc code on Storageworks, Symmertix and Filers: the magic word you missed here is prefetching. Actually you yourself published the sequence of blocks Oracle data files are accessed; and prefetching breaks only for random access patterns; so simply use index only tables with contigeous overflow storage and you get a perfect match!

inability to take online backups with a simple re-silver operation,

Again Snapshots with require no operation at all! no need to silver and re-silver

etc.). And the cache and microcode make the RAID level 5 array more expensive than the 0+1 or 1+0 array,

Any good techology is expensive. So what you do suggest?: buy StoreEdge disk shelves and buy cheap software and crash yourself (and you would have David Fitzjarrell picture engraved in your mind for the rest of your life"? Received on Tue Aug 03 2004 - 14:57:39 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US