With the release of Exchange 2000 came the ability to create multiple storage groups, which could contain multiple mailboxes or public folder stores. Unfortunately, because of memory fragmentation issues, the longstanding best practice for Exchange 2000 is to use the fewest possible number of those storage groups.
In Exchange 2000, most Exchange experts agree that you should completely fill up a storage group before creating any additional ones. Obviously, if you're using 20 different stores, you have no choice but to either use multiple storage groups or move the contents of some stores to a different server. If your Exchange 2000 server only has a few stores, though, you are generally much better off placing them into a common storage group.
On the surface, storage groups appear to work the same way in Exchange 2003 -- but there is quite a bit that is different behind the scenes. Placing all your stores in a single storage group -- as recommended for Exchange 2000 -- is not the best course of action. For example, if you have four stores in Exchange 2003, it would be better to place each in its own storage group, rather than all in one storage group.
Microsoft has taken care of the memory fragmentation issue for the most part in Exchange 2003. They have also taken steps to reduce the strain on system memory.
In Exchange 2000 (pre-SP3), each storage group is statically allocated 250 MB of memory. This allocated memory has to be used for the version store, the schema cache, and various Jet database functions. In Exchange 2000 SP3, Microsoft made store memory allocation dynamic.
Post-SP3 versions of Exchange 2000 may still be susceptible to memory fragmentation issues, but store memory shouldn't run low as long as the server has the resources to provide Exchange with what it asks for.
Shared transaction logs
Microsoft fixing a few fragmentation and memory consumption issues in Exchange 2003 isn't sufficient reason to put your stores in separate storage groups, though. The main rationale is the fact that the stores themselves are not completely independent.
In Exchange 2003, all stores within a storage group share a common set of transaction logs. This has some negative implications on the way Exchange operates. For starters, disk I/O suffers.
Microsoft has always recommended placing transaction logs on a high performance disk or disk array -- away from the database itself. The more quickly Exchange can read and write transaction logs, the better the server will perform.
Imagine that you have four Exchange 2003 databases; each receives the exact same amount of utilization. If these databases were lumped into the same storage group, the hard disk with the transaction logs would have to work four times harder to deliver the same level of performance. If the disk didn't have the capacity to work that hard, performance would suffer.
Sharing transaction logs has a negative impact on disaster recovery as well. When you restore an Exchange 2003 database, part of the process is replaying the transaction logs to make the database current. If multiple databases are using the transaction logs, it takes a lot longer for the restore to complete than it would if the database being restored had its own transaction logs.
There is also the issue of putting all of your Exchange 2003 eggs in one basket. If the drive with the shared transaction logs failed, multiple stores would be affected. If the stores were separated into multiple storage groups though (and each storage group used a dedicated drive for transaction logs), a failure of a partition containing transaction logs would only affect a single store. The other stores would remain functional.
As you can see, there are many different factors to consider when organizing stores into storage groups in Exchange 2000 versus Exchange 2003. For more information, I recommend reading Microsoft's Knowledge Base article 890699, How to configure storage groups in Exchange Server 2003..
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.