Re: Database and RAID
> ---- Original Msg from: Syed <sas@mastic.gov.my> At: 6/20 0:16 > > I am not sure what RAID level, we were given the option between RAID > level 3 and 5. I was told RAID level 3 need only two hard disk while > RAID level 5 need 3 harddisk. What i am more interested is if we use > RAID system and if one of the chunk within a dbspace is down can the > RAID system switch to the mirrored harddisk immediately and > automatically? secondly if we were to use RAID system, is it possible to > separate OS into another harddisk, for example i have 2 harddisk > mirrored 9G+9G while my O/S is in another 2G harddisk? Your advice on > this matter much appreciated. Your second question first. Of course you can, and MUST, keep your OS and database on separate disks. To your first question, simply yes data will be provided immediately and automatically in the event of a drive failure for either RAID, however, it is not that simple. There IS NO MIRROR drive in the sense that you seem to mean it. Let me explain these two RAID technologies. RAID 3 uses a parity/ECC disk, one or more data disks with one extra disk containing all of the parity/Error Correction information for the data drives. RAID 5 spreads the parity/ECC information out over the drives in the RAID set rotating which drive contains the parity block for a particular stripe of data among the drives in the set. If you have either of these schemes there is no "mirror" persay. That said let me address the issue of configuring drives for databases and for maximum performance and reliability. RAID 5 is very slow for writes and inherently unreliable (yes I know it is the most popular RAID type) suffering from what is know as "Transient disk error" problems (I've been bitten by this myself but I only learned what it is called today). Basically because RAID5 does not reread the data it writes to verify that the data and ECC blocks were written correctly, and since one of the primary read performance features of RAID 5 is that drives in the set that do not contain data that is needed for a particular read are not accessed, the ECC is not verified for every data read. It is possible for RAID 5 to write and retrieve bad data, garbage, without noticing or reporting. RAID 5 is basically only effective for recovery from the catastrophic loss of a single drive! It is ineffective to protect against the much more common fading drive, or transient disk error problem. Several RAID vendors have implemented a Write Verify strategy to help solve this problem but that only further degrades RAID 5's write performance. During recover, all remaining drives will be busy reading data to rebuild the new drive. Also, 1/N reads (where N is the number of drives in the complete RAID set) will be reconstructed from ECC during the recovery further reducing performance at this critical time. RAID 3 does not suffer from this problem since all data drives in the set plus the parity drive are always read together so that the ECC can be checked and applied for EVERY read. This of course degrades RAID 3's read performance (unless the ECC check is performed in hardware) and prevents the parallelization that RAID 5 provides further reducing both read and write performance. If a drive does fail all access during recovery is reconstructed on the fly using the ECC drive (unless of course it is the ECC drive that crashed). This present reduced performance during drive recovery beyond what would be expected, and beyond that needed to recover RAID 5, because the drives are busy trying to rebuild. Also all drives will be busy rebuilding. As you can see I do not like RAID 3 or 5 for databases AT ALL! I, rather, recommend what is commonly called either RAID 10 or RAID 1+0 which is stripping (RAID 0) of mirrored (RAID 1) drives. While more expensive that RAID 3 or RAID 5 it presents the best performance and is absolutely reliable. Like RAID 5 you asynchronously access only those drive that you need. Bad data on one drive CANNOT propagate to the mirror which is written independently in parallel so that it does not slow write performance. Like both RAID 3 & 5 you get read performance N times (actually N-1 for RAID 3 & 5) that of a singleton drive (for sequential reads - including Informix ReadAhead and sequential scans). Many RAID 1 implementations can read both sides of the mirror in parallel to satisfy two otherwise competing requests simultaneously. Recovery slows only one drive of the stripe set not the entire set so that only 1/N reads is slowed at all (unlike RAID3 where all reads are slow during recovery but 1/N reads are SLOWER still). BTW don't fall into the trap of implementing RAID 0+1 which is mirrored stripe sets which has all of the disadvantages, during recovery, that RAID 3 & 5 have plus ALL N drives need to be recovered when ANY drive fails. Bottom line, if you have a choice and the currency choose RAID 10 for best performance, safety, and reliability. If not favor RAID 3 over RAID 5. It will be only slightly slower that RAID 5 for reads (and I think that Informix's buffers/readahead/optimizations will gloss the difference over anyway) but it will be much faster for writes and much more reliable than RAID 5. > Art S. Kagel wrote: > > > > > > See my response from yesterday. What RAID level? From your discussion > > I assume RAID 1 (mirroring). This is fine. For performance, Informix > > benchmarked its own mirror -vs- OS and Firmware/hardware mirroring > > systems several years ago under 5.0x. They found firmware mirroring to > > be fastest by a safe margin and OS level mirror and Informix mirror to > > be equivalent with OS mirror the slight favorite. Informix mirror is > > by far the easiest to maintain though. Also 7.2x+ knows about the > > Informix mirror and can take advantage of it to improve performance so > > the results under 7.2x+ may be better than under 5.0x were. Art S. Kagel, kagel@bloomberg.com