Exchange 2013 reduces number of mounted databases to 50

I must have been asleep during Ross Smith IV’s Technical Keynote at the Microsoft Exchange Conference when the topic was apparently covered, but I certainly wasn’t asleep at The Experts Conference (TEC) in Barcelona this week when Greg Taylor mentioned the fact that Exchange 2013 Enterprise Edition reduces the number of databases that can be mounted on a mailbox server from 100 to 50. Exchange 2013 Standard Edition maintains its ability to mount up to five databases.

Cutting the number of mountable databases in half is clearly a pretty fundamental change that will affect the way in which some organizations have deployed Database Availability Groups (DAGs). For example, if you depend on mounting 60 or 70 databases on each DAG member in order to have three or four copies of each database, then your plans will have to change for Exchange 2013.

But why has Microsoft taken such a step? On the surface, it would seem that this hamstrings the DAG a tad, but when you poke at the topic further you find that some reasonable logic has driven the decision.

Although they share many aspects of the product architecture, Exchange 2013 is different to Exchange 2010. Take search for instance. Exchange 2010 uses the MSSearch component to create the content indexes of mailbox databases. Exchange 2013 uses the Search Foundation instead in order to share a common search infrastructure with other products, SharePoint being the most important because of the need to provide discovery searches across email and documents. Search Foundation is fond of memory and the current indications are that it can easily take between 10 to 15% of available memory on a mailbox server. Another big change in the transfer of protocol handling from CAS to mailbox server. The advantage gained is to help make the CAS more of a stateless server and to enable client connections to “survive” the loss of a CAS. All of this is good stuff, but the upshot is that an Exchange 2013 mailbox server uses more memory than its Exchange 2010 counterpart.

Each database that is mounted on a server incurs an overhead as the database structures are mapped into memory. Remember that Exchange has long been in the business of trading memory for I/O to drive down the overall I/O profile of the server and enable the use of lower-cost storage solutions. So if memory is being assigned to new processes, it is reasonable to conclude that less memory is available to mount databases and that’s exactly the position reached in Exchange 2013. The performance data from internal Microsoft tests and early customer deployments (using beta code) reveal that mailbox servers have no problems in terms I/O but they can become memory-constrained and CPU-bound as the number of mounted databases grew.

The decision was therefore reached to limit Exchange 2013 Enterprise Edition to 50 mounted databases. Put this fact into context with the other fact that Exchange 2013 maintains the limit of sixteen mailbox servers that can be deployed in a DAG and you understand that any DAG that currently supports more than 800 mounted databases has to make an adjustment as Exchange 2013 is deployed. However, it's a fair point that relatively few DAGs support more than 800 databases today so only a small number of customers are affected.

It’s possible that other advances in Exchange 2013 (such as database autoseed after failure) might let system designers reduce the number of copies maintained for each database and so shrink the total number of databases supported by the DAG. It’s also possible that you might feel that it’s possible to grow databases to a larger size because Exchange 2013 uses the second generation of the DAG. Thus, you could combine some current databases into larger databases and so reduce the number of databases within the DAG.

The news of the 50-database limit will cause some furrowed brows as designers and administrators figure out what to do. Whatever path you choose to take, it’s important to realize that all software evolves over time and limitations and restrictions change. In this case, Exchange 2013 introduces a new limitation while addressing some of the other constraints that might have driven design decisions in the past. I’m looking forward to the debate – and a brand new Exchange storage calculator that builds the new constraint into its models!

Follow Tony @12Knocksinna