Authors : Levon Kohoutek (for the question) and Nagesh Mahadev (for the answer)
Exchange 2007 SP3 RU6 - Server 2008 SP2 environment.
Quite frequently we’re receiving ExchangeIS Event 9786’s potentially followed by ESE Event ID: 623 “The version store for this instance (x) has reached its maximum size of xxxMb.” errors. At this point we’re unsure as to what action is precipitating this (e.g. performing a search in Outlook). Also we may have high item counts, and we know we have to do a procdump of Store.
The question is as follows:
When viewing the 623 Event in Event Viewer, we can see that it cites a possible long-running transaction as the cause. It identifies this possible transaction by a SessionID, Session-context, and Session-context ThreadID.
What the SessionID is referring to ? Is there a way to derive anything identifiable (user/mailbox/etc…) from that number and if so, how?
The SessionID represents a particular connection between the store process and ESE. It has no bearing on the client at the other end of the request. It is only helpful when looking at dump of store process. While ESE.DLL is tightly coupled with the Store.exe, ESE is a database engine and serves clients. Similar to how SQL would handle multiple clients issuing requests against a server, except in this case, the clients are different threads within the store. Within a procdump, you *may* be able to locate a session (represented by a JSES object) and tie it back to a particular user depending upon context – again typically within a procdump only.
About event 9786 :
Event Type: Warning
Event Source: MSExchangeIS
Event Category: Database Storage Engine
Event ID: 9786
Time: 1:34:04 PM
The database engine has consumed 90% of the "b-trees" resource (60820 used out of a maximum of 67096) for storage group 'GLDSTORE1'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
0000: 46 43 42 FCB
==> This can indicate that we have a user that sends a huge attachment to a large amount of people for example, or there is a large message that is looping between two servers, anyways, there may be a leak in the ESE process due to an other database usage pattern.
- To see what happens exactly, we have to get a dump and use the userdmp3.pl script on the Dump to see if there was a message leak and or if someone send a large message to a ton of people.