Managing Shared Transport Database Configuration Options
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
Topic Last Modified: 2016-11-10
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:
Message queue database A queue is a temporary holding location for messages that are waiting to enter the next stage of processing. Each queue represents a logical set of messages that a transport server processes in a specific order. For more information, see Managing Queues.
IP filter database The IP filter database stores the IP Allow lists and IP Block lists that are part of connection filtering. For more information, see Configuring Content Filtering.
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.
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.
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:
<gcServer enabled="true" />
<add key="Configuration Option
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.
The parameter names in the |
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
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.
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.
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.
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.
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.