Ok, it is not what you think it to be, its about R.A.I.D. Technology as in redundant array of independent (or inexpensive) disks.
I am providing a generalized view of how i worked with the SQL Server and related Storage Environment(s), i am not a Storage expert or do not have hands on Enterprise Storage system at my leisure (But limited access to EMC ClarionCX4-480),  to try out various performance configurations and enhancements. I Just have one shot of getting the configuration right and better get them done right that time. I am discussing the generalized benefits of SQL Server Performance on RAID 5 vs RAID 10 systems. People have done a lot more research to prove some technologies that work and some don’t. So Following the guidelines, i present some meaningful overview of SQL Server and Storage concepts.

RAID is the technique used where data can be written to Multiple Hard Drives to provide redundancy, where if one hard disk failure in the array of disks, still preserves the data across several other and thus providing fault tolerance.

I have seen most DBA’s have little or no Knowledge of RAID Technologies OR are not interested in getting themselves engaged in the Database file management/architecture scenarios and let the system admins or Managers handle it as it is. Also many don’t even know, how their RAID environment is configured, which is a SAD scenario.

DBA’s need to understand, how important it is to know these aspects of technology and the benefits and cons associated with it.  I would promote the DBA’s to learn about Tiered Storage and DISK Speeds / RAID controllers / SAN Vendors / Strip sizes. There are many Whitepapers on the VENDOR Sites (EMC/DELL/HP/IBM to name a few), which are really helpful in understanding the SERVERS as well as performance benefits of various technologies.

NOTE: Microsoft recommends not to put the page file on the RAID-5 Volume, because it degrades the performance and to use a mirrored (RAID 1) volume instead. Because re-generating a RAID 5 Orphaned disk takes some work, where the network connection to the volume are lost and the volume has to be locked.

RAID is a part and parcel of every MID to HIGH END server and (now gaming and other desktops too) and has been a very hot Topic. A DBA, should be aware of the concepts as this encapsulates the performance enhancement strategies. I will be referring to SQL Server RAID configurations practices and the ones i have worked across.

RAID technologies have various forms as we will take a look. MID  and SMALL companies are heavily relying on the default RAID 5 configuration, because of the cost associated with it and the maximum space availability associated with it. Many Database Shops are still relying on the Out of Box RAID 5 configuration for all of their requirements.(which is not a bad bet, but when it comes to database servers with high Random IO, we have to re-think our strategies).

Consider for example a single hard disk. when you start windows/outlook/SQL Server/3d Studio Max, There are certain factors that come into play. The hard disk works with the CPU and Memory to Produce (OPEN) the programs as quickly as possible. This heads have to do all the work of reads and writes before data is fetched from HDD into memory. It will first bring up windows, then outlook, then SQL Server and 3DStudio. HDD will keep on reading the blocks as and when available. So you see the half the program load before the other program loads half way and then the previous one finishes loading. There are many disadvantages of using the single disks or JBOD for IO intensive applications. Disk Subsystems come in all flavors of SPEED (10K RPM to 15K RPM for servers) and (5400 RPM to 7200 RPM and now sometime at 10000 RPM for special gaming desktops) Another HDD are Solid State, which absolutely require 1/4th the time compared to regular disks to fetch data.

With one of my clients, I was given SQL Server 2000 and 2005 systems with 1 LUN based on RAID-5 and another volume a RAID-1 for binaries. This kind of configuration has some performance constraints and issues. and on top of it if your data files(.mdf and .ldf) and system databases all reside on the same LUN from same RAID system, they do not provide any performance benefits. There is definitely going to be a write as well as read overhead associated with this design, where your disk avg. queue length will top it all. All your Files are still on the SAME SET and are getting Sequentially Read.(Specially Log Files IO are Sequential)

Many forms of RAID-5 can have data loss after a system failure. Data loss occurs because a system failure causes the data and parity in the RAID-5 volume to become unsynchronized. If an attempt is made to read data contained on a stale subdisk, the data is reconstructed from data on all other stripe units in the stripe. This operation is called a reconstructing-read. This is a more expensive operation than simply reading the data and can result in degraded read performance. When a RAID-5 volume has stale subdisks, it is considered to be in degraded mode. If the HOT-SPARE is available and enabled, it is automatically triggered by the failure and Data can be re-generated using the parity.

RAID-5 is less expensive than RAID-10, also write performance has a better advantage on RAID-10 over Raid-5, because of the overhead of writing parity information in RAID 5. (Which is negligible if not HIGH Random I/O’s are generated).

The most common RAID types used in production IT environments are RAID-1, RAID-5, and RAID-10

When i talk about high end and low end disk subsystems, i mean a 7.2K vs 10K vs 15K disk-subsystems under the RAID-5 systems. so these variations makes a lot of difference in performance as well. STRIP SIZE is another factor which should be taken into consideration:

Strip Size defines the block size defined while the disk is prepared as LUN.

The default block size used by most vendors is 64K. Generally it depends upon your environment requirements.

Do not take my word for it. Here are some more references that are a great READ.

Start by reading this paper on http://technet.microsoft.com/en-us/library/cc966414.aspx
http://blogs.msdn.com/jimmymay/ http://blogs.msdn.com/jimmymay/archive/tags/Disk+Partition+Alignment/default.aspx
http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-series.html
http://blogs.msdn.com/sqlcat/archive/2005/11/21/495440.aspx

Remember RAID 0+1(Disks are Striped together then Mirrored) is different than RAID 1+0 (Disks Groups  are Mirrored then Stripped)

Spreading your SQL Server Databases across separate LUNS from separate disks (RAID Groups) can benefit you in getting rid of many(not all) Performance issues resolved with slowness and locking and several other disk related IO will be minimized.

In case of a RANDOM IO Type environment or even close or if you are have somehow figured the issues is with the IO, then try the following for performance benefits. This depends on the type of luxury you have with storage and $$ to spend. But consider the Performance (benefit) enhancements that come along and how some of the generalized issues of slowness will go away.

As an example: A SQL 2000 Server and a Database size of 180 GB, used to take 70 min’s on a RAID 5 system(Data Files / Log Files / TempDB / Indexes / Backups are all stored on SAME LUN with strip size of 8K), Which was a havoc. The system Manager was in disagreement regarding any performance issues on this box.
I had to challenge him to provide extra space in form of additional dedicated LUN with STRIP size to 64KB from separate physical disks for Log Files and TEMPDB. Which he did and immediately saw the dramatic change, in performance of backups and Other database tasks. (15K RPM disks with RAID 5 (4+1 disks) and block size of 64K). The backup were down to under 50 min’s and rest of the Disk Queue Length (Just one the primary measures i use) on both of these Logical Drives under acceptable limits. It was no longer that we moved to IBM DS8000 Ent. SAN with configurations to RAID 10 and our problems started to fade away for slowness and Backup interfering with Daily Jobs and on top of it blocking scenarios due to Slow IO. The backups went down to 10 min’s.. I have everything separated out as a SQL Server best practice. Same benefits i got from another SQL Server 2005 with Db size of 90 GB and now the files are on separate RAID 10 volumes, with the exception of binaries.

ok how do you find you current strip size / block size.

In windows cmd type fsutil fsinfo ntfsinfo <drive letter:>
then check the Bytes Per Cluster.

Transaction Log Files = RAID 10 (There is always another option as described below…)
Data and index Files = RAID 10 Or  RAID 5
Tempdb (Depend on Load) = RAID 10 (RAID 5 will do if not Heavy Write intensive LOAD)
Binaries and OS = RAID 1

Or Assign a Database log File to a Separate LUN with dedicated Physical disks with nothing else on it. Also Tempdb to a Separate LUN with dedicated Physical Disks with nothing else on it.
If you are a active DBA with Enterprise SAN at your Leisure, then work with it dedicatedly, defining your Database File storage structures and location.

Many will disagree, but the lessons i have learnt with hands burnt down, provide me solid proof for perusing the best practices.