The need for the use of RAID for IO throughput, as well as redundancy, in SQL Server storage systems, is well established. In most OLTP databases, using traditional magnetic drive hardware, one of the limiting factors for IO throughput is the disk head latency; the time it takes the head to physically move across the disk to find the data. Therefore, striping the data across a large number of smaller disks will generally lead to much better performance than using a few large disks.

There are many different possible RAID configurations but what has surprised me is the apparent difference in attitude towards RAID 5 in the SQL Server community, compared to Oracle. In my Oracle days, it was drummed into me hard that RAID 5 was simply no good for database work. The BAARF party, light-hearted in nature but serious in intent, offer some pretty damning indictments of the use of RAID 5 storage arrays for databases. The heavy write penalty, due to the need to maintain the parity data, is well known although the storage array manufacturers have supplied ways to compensate (mainly in the form of large caches). However, there are other problems too. For example, despite the greatly increased reliability of disk drives, sectors can still "go bad". When such sectors are written to, the 'garbage data' propagates into the parity data, thus destroying the integrity of the whole RAID array.

It is generally accepted, I think, in both communities, that RAID 10 (mirroring then striping) provides better redundancy, is more reliable, and leads to simpler storage architectures, with the downside being that storage capacity becomes much more expensive, since half the disk space is used to provide redundancy. Indeed, RAID 5 SANs gained in popularity as a viable 'compromise' between the need for a large number of disks, for IO throughput, whilst maintaining good storage capacity.

However, RAID 5's true viability for database systems, greatly challenged in the Oracle world, seems much more accepted in SQL Server. Books Online states that RAID 5 is "the most popular strategy for new designs". I've also read assertions to the effect that most SQL Server systems don't actually need RAID 10, as long as the SQL Server data files don't change more than 10% daily.

Do you agree? Given that disk storage has come down substantially in price over recent years, do you still think that RAID 5 is relevant as a storage configuration for databases? How many of you use RAID 5 for transaction log file storage, on OLTP systems? If you've had good – or bad – experiences with it, I'd like to hear about them.

Cheers,

Tony.

If you're interested in some in-depth coverage of hardware issues, check out Glen Berry's blog, and keep a look out for his new SQL Server Hardware book, which should be available in early March.