Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Hi I'm trying to impress upon a group of administrators as to why the extra money should be spent on raid 10 vs say raid 5. Other then just pointing at MS Best Practices does anyone know of any good testing documentation to illustrate the point ?

share|improve this question

closed as primarily opinion-based by Max Vernon, Mark Storey-Smith, Jon Seigel, Paul White, Mike Walsh Nov 3 '13 at 13:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Have you done a search? For instance turns up lots of gold. – Max Vernon Oct 31 '13 at 17:39
Not a SQL Server person, just MySQL. I wrote this RAID5 post a while back : – RolandoMySQLDBA Oct 31 '13 at 19:24
For RAID decisions the core considerations are pretty much the same for any DMBS, Rolando's answer in that link is just as relevant for MSSQL. There are extra considerations of course such as the benefits of splitting load around spindles, but these apply equally to noon-RAID setups too. – David Spillett Oct 31 '13 at 20:37
up vote 2 down vote accepted

This is just a reference. A great session recording at SQL PASS Summit 2011 by Wesley Brown on this subject. It is an hour and 15 minutes of just storage talk. He goes over RAID configurations and then how they pertain to SQL Server and the pros and cons of each:
Understanding Storage Systems and SQL Server

You will need to register with SQL PASS in order to view it but it is well worth it. To find the recording go to this link and look for course "DBA-103". I don't think the same slide deck he uses is available for download but he posted the deck used at a few SQL Saturday events here.

share|improve this answer

The RAID5 write performance penalties are well documented (a simple search finds many reasonable looking references so if you have any write heavy access patterns finding a good page/paper documenting why R5 can be slower than R10 for writes may be enough to convince.

Also you could arrange a small set of benchmarks, preferably based on the IO load patterns of your application in production (the results will be far more convincing that way as they will be more specific to your use case), on a small machine with a bunch of disks in RAID 5 for one set of tests and rebuild to RAID10 for the second set. As well as testing performance on an array in good working order, test how long it takes to bring each array back to 100% when a drive is replaced and what affect this has on your benchmarks.

Also show them a breakdown of the redundancy offered. RAID5 over 3 drives can survive 3 of the 7 drive failure combinations (42%) where RAID10 over four drives can survive 8 of the 15 failure combinations (53%). RAID5 over four drives with all active, though I assume as you are concerned with cost you are not comparing like-for-like on the number of drives but instead comparing on the array size once constructde, is worse as it can survive just 4 of the 15 drive failure combos (27%). Of course for redundancy RAID6 will be better (it can survive any two-drive failure scenario so 8/15 or 67% but you still have the write performance matter and longer rebuild times as with RAID5).

Of course if your application is not write-heavy at all then normal application performance is not going to be affected significantly, but you still need to consider the redundancy offered and the rebuild time once a degraded array gets replacement drive(s).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.