February 10, 2004 at 9:00 am
Hi,
I'm changing the the DB server configuration to maximize performance. I've read that transaction logs should NOT be RAID 5? Why? I'm also curious as to how other DB servers are configured ie: # of disks; type of RAID; grouping of files on disks ie: use C: for OS files only. Any suggestions or comments on this are greatly appreciated.
THanks. Jeff
Many thanks. Jeff
February 11, 2004 at 6:03 am
In my experience I would not use RAID 5 for anything unless I had to (ie couldn't get the head guys to fork out the dollars).
It's somewhat more costly but I would go with RAID 1 for the OS drive, also make a seperate Pagefile Drive also RAID 1.
Then splash the bucks and go with RAID 10 (or RAID 0+1 as it's otherwise known). It's mirrored striping and gives the best performance.
If you don't want to go with the big bucks go with RAID 5 for the mdf's and RAID 1 for the LDF's (you could actually look at yesterday QOD for more on this).
February 11, 2004 at 10:17 am
The page http://www.acnc.com/04_01_01.html shows comparisons between the various RAID levels. Searching google for RAID will turn up more explanations if you're interested.
To address your question, RAID 5 is fast for reading, medium fast for sequential writes, and not all that fast for random writes because it has to do extra reads to get all the information it needs to compute parity information. Since the transaction logs are sequential, you could argue that it would be ok to use RAID 5 for log files, but iffy to use RAID 5 for data files. One other thing about RAID 5 is that if a disk fails, performance for both reading and writing will be mediocre until the failed disk is replaced and rebuilt.
We just use RAID 1 for both the databases and the logs. It suits what we do. In the last analysis, the right answer for you depends on what you need to do. Testing with your workload is the only way to really know the right answer.
Regards,
Peter
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply