Because the version store requires contiguous virtual address space, it has a size limit. The repository that holds these temporary copies is called the version store. This copy must remain as long as any two transactions in the process have different views of the object. The cost of providing these views is that any object that is modified in a transaction has to be temporarily copied so that two views of the object can be provided: one to the thread inside that transaction and one to threads in other transactions. “ESE provides transactional views of the database. All applications and services that utilize an ESE database use version store to some extent. This allows the database to roll back transactions in case it can’t commit them, and it allows other threads to read from a copy of the data while it’s in the process of being modified. It’s an area of temporary storage in memory that holds copies of objects that are in the process of being modified, for the sake of providing atomic transactions. While the job security for us is nice, knowing this stuff ahead of time can save you from having to call us and spend lots of costly support hours.Īs mentioned earlier, the version store is an integral part of the ESE database engine. There has been quite an uptick lately in the number of cases we’re seeing here in Support that center around version store exhaustion. I can also offer more practical examples than you would probably get from straight technical documentation. (as of the year 2016) information and guidance on the version store, and to do it in a format that may be more palatable to many readers than sifting through reams of old MSDN and TechNet documentation that may or may not be accurate or up to date. The purpose of this blog post is to provide And quite suddenly too, as replication throughout your environment grinds to a halt because of version store exhaustion and you scramble to figure out why. But for that 1% out there with exceptionally large and/or busy Active Directory deployments, (or for those who make “interesting” administrative choices,) the monitoring and tuning of the version store can become a very important topic. The stock configuration of the version store for Active Directory will be sufficient to handle any situation encountered by 99% of AD administrators. The version store is one of those details that the majority of customers will never need to think about.
Sometimes old codenames are so catchy that they just won’t die.) Therefore, the following information should be relevant to any application or service that uses an ESE database (such as Exchange,) but today I’m specifically focused on its usage as it pertains to Active Directory.
(ESE is sometimes referred to as Jet Blue.
The version store is an inherent mechanism of the Extensible Storage Engine and a commonly seen concept among databases in general. I think we need to have another little chat about something called the version store. First published on TechNet on Jun 14, 2016īack at it again with another exciting installment of esoteric Active Directory and ESE database details!