I often come across environments where databases perform poorly. When I do analyses of those environments (one needs to analyze an entire E2E chain instead of just one component before drawing any conclusions), I often run into poorly configured systems. These systems can host SQL, Oracle, DB2 or any other RDBMS. When I’m lucky people took the effort to split up database and transaction log files, that is, they partitioned the disk in several partitions and assigned the basic concept of splitting database transaction log files from database files. At least they figured out they had to do it… But, instead of creating separate disk arrays, one disk array with one logical driver was created which was partitioned under Windows. Or creating small Logical Units Numbers (LUN) on a Storage Area Network (SAN, effecient in terms of not waisting any disk space on a SAN), then people use volume management software to combine them into one Windows volume, which is partitioned again to separate database file from database transaction log files. Yes, I know, a normal person won't even consider doing that, let alone carry it out. But guess what, they do... I will talk about sizing, configuring a disk sub system and the importance of doing it right in a future blog.
In this blog I talk a bit about the myths surrounding the all holy RAID-5. Yes, also the first RAID level I heard and learned about during my Windows NT 3.5 Server training… ;-) Oh and I am not going to explain the differences in RAID levels, you can read all about that here.

One can use the following RAID Ratio of performance for comparing RAID strategies:
%Reads * (Physical Read Ops) + %Writes * (Physical Write Ops)

RAID-10, RAID-1, RAID 0+1, RAID 1+0:
Two physical disk writes per logical write request are required
I/O Performance = % Read * (1) + % Write * (2)

RAID-5:
Four physical disk I/O operations per logical random write request are required (two reads and two writes)
I/O Performance = % Read * (1) + % Write * (4)

Since mirroring technologies need to copy the data to an alternate location, it makes sense that every application generated I/O needs to be mirrored to another disk. Therefore write operations on RAID-1x configurations require 2 physical I/O's per application generated I/O. 

But then why are there 4 physical I/O’s needed for RAID-5 when performing an application write request? Well, most modern RAID controllers use a XOR algorithm for RAID-5 arrays with 3 disks and a read/modify write algorithm for RAID-5 arrays with 4 or more disks to write/change data. The read/modify write algorithm is more effecient for RAID-5 arrays with 4 or more disks then the XOR algorithm. It uses the following sequence to write/change blocks of data:

1. Read old data in stripe (can be any block)
2. Read old checksum in stripe
3. Calculate the new checksum from old data, new data and old checksum
4. Write new data in stripe (can be any block, depends on one to be modified)
5. Write new checksum in stripe

So, if for every requested write action, 4 physical I/O operations are required, why would one use RAID-5 everywhere? Because, very little people know how the various RAID levels really work and what their impact is on system performance.

What about Write Back (WB) cache? With cache the controller can do step 1 to 5 in memory and doesn't need to wait for for the actual disks to complete the I/O operations, so it can send an I/O completion to the requesting host almost immediately. However, this is only true when:

1. Cache is not satured.
2. Data is to be found in cache.

In short, when the demand for I/O is higher than the efficiency of the cache, the cache becomes a bottleneck. This is a reason why modern cached controllers use mechanisms like fly-by-cache. This actually disables the caching fuctions when a certain type of data stream is detected by the controller logic. This is especially true for streaming write operations, where the amount of data being generated is simply to large to be effeciently processed by the controller logic.

So, is RAID-5 bad? Yes and no. Yes it is, when the data stream to be served (mostly) consists of write requests, like database transaction logging. No, when the type of data stream to be served is (mostly) read. It doesn't matter whether it's sequential read or random read, because all RAID levels do one I/O for single block read operations.

Can RAID-5 serve high performance transaction logging databases? Yes, just keep in mind you need twice as many I/O's to be performed as with RAID-1x solutions, so double the amount of disks to equal the performance.

Did you know there is a community against using RAID-5 in production environments? It's called: Battle Against Any Raid Five.