I'm planning to implement some SSD drives for my Exchange 2003 server. My single MDB for all mailboxes is 114GB with some user mailboxes as large as 8.4GB. I planned to do a RAID 10 array of 4 SSD drives, but the total capacity with that config will too quickly fill up with the log files between backups. I speculate that Exchange, by its nature, is far more read intensive than write intensive with the possible exception of the log files. And it's a known fact that SSDs have a limited write lifespan. Based on these premises, my theory is that if I have a fast set of drives with limit write life and a slow set of drives, and the fast set can not hold the MDB along with the logs, the best strategy is to use the SSD for the MDB and use the slower spinning drives for the log files. Are these reasonable and sound practices? MDB and logs on separate drives? Ultra fast drives for the MDB and mediocre speed drives for the logs? With SSDs, especially in a RAID 10 array, IOPS should be easily satisfied if the IOPS relate to the MDB. But, will the log file creation on the separate and slower array negate the gains?

You should change this post to a "question" not a comment. This is the "definitive" article on Exchange 2003 disk i/o planning: What Causes Exchange Disk I/O http://technet.microsoft.com/en-us/library/aa996376(EXCHG.65).aspxHonestly, I'm not sure I'd be spending money on SSD hardware at this late in the 2003 game with Exchange 2010 out now... But Yes, random I/O for MDB and sequential for Transaction logs. -Mike

Thanks for the article. It IS very useful and I'll spend more time reading up on it. One thing it seems to suggest to me is that I need to have the EDB (I mistakenly used MDB) and the logs on separate SSD RAIDs. Because all activity seems to take place in the logs before it goes to the in-RAM and EDB database, and "activity" includes "any time a user sends or [EVEN] reads a message", having smoking fast writes speeds on the drive for the logs is very important. To maximize write performance for the log files, a RAID 10 array of the more expensive, but smaller, SLC drives should be used for the log files. So would you agree that: 1. for the EDB, more reading takes place and capacity is more important than the log files, thus the shorter-write-lifespan, larger capacity, slower write, but equally fast reads of MLC SSD is probably the best compromise. 2. for the log files, the vast majority of the IOPS are writes but the capacity requirement is lower than the EDB, and since the in-RAM database waits for the successful log write, smoking fast sequential write speed means that the SLC SSD is probably the best fit. Will this remain the case with Exchange 2010? At this time, I have no plans to upgrade to 2010 and I think I wring out some significant speed by making this architectural change will make life better. My current system is using a slow RAID5 array using 7200RPM SATA drives for EDB and the logs. So separating the EDB from the logs and having such a huge increase in IOPS and throughput should make nearly a night and day difference.

1. Very important for both databases and logs. If your database LUN runs out of space, it gets dismounted. If your log LUN runs out of space, dismounted. 2. Yes, majority of IOPs are write and the logs are generally 10% the size of the database. Don't use 10% as a a definitive figure for planning though. In Exchange 2010, databases are sequentalish. They still have random IO and are to be planned as random IO and is still recommended to place them on separate spindles. As for the 10% number for Exchange 2010, all I'll say is that the general number is different. The statistics I have seen is preliminary data from Microsoft so I won't show the preliminary numbers they have stated.MVP | MCSE:M | MCITP: Enterprise Messaging Administrator | MCTS: OCS + Voice Specialization | http://www.shudnow.net