Why Exchange 2013 asks you to restart the Information Store after creating a new database

If you have deployed Exchange 2013 CU1, you might have noticed that every time you add a new database using either the Exchange Administration Center (EAC) or the Exchange Management Shell (EMS), you are prompted to restart the Information Store service. The requirement to restart the Information Store service after adding a new database also exists in Exchange 2013 RTM but the management tools do not issue the "need to restart" message in that version.

Exchange 2013 rewrote the old monolithic Store process to produce the "Managed Store", which uses a very different memory management model to that which you might have been accustomed to in Exchange 2007 or Exchange 2010. On an Exchange 2013 mailbox server, you’ll see an Information Store control process and one Store worker process for each database (active or passive) that is mounted on the server.

Forcing the restart of a critical service is a side effect of the new memory management model. It is seems like a strange requirement until you know that the Store only determines the amount of memory that it will use to manage all of the databases on a server (the maximum ESE cache size) when it starts up. This happens when the server starts or if you force a restart of the Information Store service.

The old scheme is called Dynamic Buffer Allocation (DBA) and it seizes as much memory as is available on a server and uses the memory to cache Store data. The scheme is dynamic in that the Store releases memory back to other processes as they need memory, but it does create an impression that Exchange is a memory hog and that, in particular, the Store uses masses of memory. In fact, DBA has worked pretty well since its introduction in Exchange 2003. 

The decomposition of the monolithic Store into the control-and-worker processes used by Exchange 2013 means that the old approach had to be revised. Exchange 2013 figures out how much memory it should use for the ESE cache (usually 25% of available RAM) and then parcels this memory out to worker processes. Logically, because they have more work to do, active databases are assigned more memory than passive databases.

Of course, the new memory management scheme depends on knowing how many worker processes are in use. When you alter the situation by creating a new database, the Store does not attempt to recalculate its ESE cache or reassign memory to databases. This does not mean that you cannot the new database as it will be managed by its worker process. However, caching won’t be as efficient as it should be until the next time the Store process restarts and memory use is adjusted.

It would be better if memory allocation was managed dynamically but given that a) adding or removing a database is probably not going to happen often in the lifetime of a sever and b) the memory management scheme used by Exchange 2013 is still relatively new, it is possible that this is an area that might be automated in future versions. Interestingly, the same prompt to restart the Information Store service doesn’t show up after a database is removed, possibly because the databases that remain in use on a server have been allocated an appropriate cache and the memory previously used by the now-deleted database will be reallocated by Windows to other processes.

Another way to think about the situation is that whe next action after adding a new database is invariably to redistribute workload by moving some mailboxes to the database. If this is true, then assigning an appropriate cache to the new database is important and the administrator should be informed of this fact and asked to restart the Store. By comparison, it is not so important to recalculate the cache after removing a database because all mailboxes have to be moved out of a database before it can be removed. In either case, adding or removing a database is not going to be a common situation once a server has reached full operational status so there's no real need to worry.

Getting used to new software behaviour is part and parcel of learning how to exploit applications. The advent of the managed Store in Exchange 2013 is a big change. Being forced to change operational procedures (which you might decide to do after creating new databases) to optimize memory management is just one part of the big picture.

Follow Tony @12Knocksinna