Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2009-01-16

Servers that have the Microsoft Exchange Server 2007 Hub Transport server role or the Edge Transport server role installed use Extensible Storage Engine (ESE) database technology for certain transport server components. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange 2007. ESE is used for the following transport components:

The message queue database and the IP filter database are separate ESE databases. These databases don't share any resources. However, you can configure ESE database configuration options on the Hub Transport server or Edge Transport server that apply to all the ESE databases that exist on the server.

An Overview of ESE Databases

ESE databases use log files to accept, track, and maintain data. To enhance performance, all transactions are written first to log files and memory, and then to the database file. The checkpoint file tracks the transaction log entries that have been committed to the database. During an ordinary shutdown of the Microsoft Exchange Transport service, uncommitted database changes that are found in the transaction logs are always committed to the database.

Circular logging is used for the message queue database and the IP filter database. This means that the history of committed transactions that are found in the transaction logs is not maintained. Any transaction logs that are older than the current checkpoint are immediately and automatically deleted. Therefore, the transaction logs cannot be replayed for message queue database recovery or IP filter database recovery from backup.

Configuring Shared ESE Database Options on Transport Servers

The shared ESE database configuration options are available in the EdgeTransport.exe.config application configuration file that is located in the C:\Program Files\Microsoft\Exchange Server\Bin directory. The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted. If a configuration option is missing or is present and contains the default value, the default value is enforced.

The following example shows the typical structure of the EdgeTransport.exe.config file:

<configuration>

<runtime>

<gcServer enabled="true" />

</runtime>

<appSettings>

<add key=" Configuration Option " value=" Value " />

...

</appSettings>

</configuration>

You can add new configuration options or modify existing configuration options in the <appSettings> section. Many configuration options available are completely unrelated to the shared ESE database options. Any configuration options that don't involve the shared ESE database options are outside the scope of this topic.

Note:
The parameter names in the <add key=../> section are case sensitive.

For information about the message queue database parameters that are available in the EdgeTransport.exe.config file, see Managing the Queue Database.

Table 1 shows the shared ESE database configuration options that are available in the EdgeTransport.exe.config file.

Table 1   Shared ESE database configuration options

Parameter name Description

DatabaseCacheFlushStart

This parameter enables the removal of cached database transactions from memory when the cache is overused. The value of this parameter represents the percentage of the cache that is unused. When the free database cache resources drop under the specified percentage, a background process writes the cached database transactions to the transaction log. The default value is 3.

DatabaseCacheFlushStop

This parameter suspends the removal of cached database transactions from memory when the cache utilization level returns to normal. The value of this parameter represents the percentage of the cache that is unused. When the free database cache resources increase to more than the specified percentage, the background process that writes the cached database transactions to the transaction log is suspended. The default value is 5.

DatabaseCheckPointDepthMax

This parameter controls the total allowed size of all uncommitted transaction logs that exist on the hard disk drive. The default value is 20971520 bytes. Setting the value of the DatabaseCheckPointDepthMax parameter too low can cause significant performance issues because uncommitted transactions are forcibly committed to the database instead of being written to transaction logs. We recommend that you do not modify the default value of the DatabaseCheckPointDepthMax parameter.

DatabaseMaxCacheSize

This parameter specifies the maximum size of the database cache in memory. The default value is 134217728 bytes.

To increase performance on computers that have 4 gigabytes (GB) or more of memory, set the value of the DatabaseMaxCacheSize value to 536870912 bytes.

For more information about how performance can be affected by changing the value of the DatabaseMaxCacheSize parameter, see the Exchange Server Team Blog article, New maximum database cache size guidance for Exchange 2007 Hub Transport Server role.

Note:
The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use

Remember that the message queue database and the IP filter database are completely isolated from one another. The ESE database files don't share database files, transaction logs, or caches. The shared configuration options apply to each database and its supporting infrastructure. For example, when you set the DatabaseMaxCacheSize parameter, you are at the same time setting the maximum cache size for the message queue database and the IP filter database.