MSExchangeTransport 17009

Последнее изменение раздела: 2011-03-19

В этой статье приводится объяснение и возможные варианты устранения неполадок, связанных с определенными событиями Exchange. Если вам не удалось найти ответ на свой вопрос, используйте поиск по Справке Exchange 2010.

Details

Explanation

This Information event is logged after the Microsoft Exchange Transport service starts. This event indicates that the Microsoft Exchange Transport service has finished parsing the Transport database to process any queued messages. This event may be logged after a planned restart of the service or after the service experiences a database error and restarts.

Starting with Microsoft Exchange Server 2007, the Microsoft Exchange Transport service uses an Extensible Storage Engine (ESE) database for mail queue storage. This design change improves read and write performance with respect to messaging queues and also allows for the messaging queues to be backed up. The message queue database and the Content Filtering database use circular logging. Therefore, you can't use the transaction logs for data recovery. Additionally, the transaction logs are re-created automatically during the startup of the Microsoft Exchange Transport service if they are missing. By default, the Microsoft Exchange Server 2010 Transport database files are located in the following directory:

%ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\data\Queue

The Transport database consists of the following files:

• Mail.que: The ESE database

• Tmp.edb: The temporary workspace for processing transactions

• Trn.log: The current transaction log file

• Trntmp.log: The temporary transaction log file

• Trn.chk: The database checkpoint file

• Trnres00001.jrs: The first transaction reserve file

• Trnres00002.jrs: The second transaction reserve file

When a message is received in the Transport pipeline, the page that requires updating is read into memory and the changes are recorded in the ESE cache. The version store component tracks the uncommitted changes. This operation is then recorded in a transaction log file on the hard disk, and when the log file becomes full, a new log file is created. Finally, the page is committed to the mail.que file and the checkpoint is advanced to record the committed transaction.

If these files become damaged or if the Microsoft Exchange Transport service is unable to access them, the Microsoft Exchange Transport service shuts down.

Because of this, the Microsoft Exchange Transport service includes a "self healing" feature that is designed to enable Exchange to recover from most of the issues that could cause the Transport database to fail. These include the following issues:

• Logical database corruption: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies database corruption, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.

• File(s) not available: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies missing or locked database files, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.

• Insufficient disk space: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies insufficient disk space, the service does not perform any recovery actions. For example, the error might specify that the database cannot be extended or that a log file cannot be created. In this scenario, the service shuts down.

• Database upgrade: When the Microsoft Exchange Transport service experiences a database version error, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.

• Failed server disk replaced: When the Microsoft Exchange Transport service first starts after a failed hard disk has been replaced, the service detects a "JET permanent exception" error that specifies physical database corruption. In this scenario, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.

The recovery actions may be modified by changing the value of the following key in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config file:

<add key="QueueDatabaseRecoveryAction" value="<action>" />

The following action values are available:

• None: When this action is specified, the Microsoft Exchange Transport service does not try to recover. The service logs the database exception to the Application log and remains stopped until the Transport database is either repaired or deleted and the service restarted.

• Delete: When this action is specified, the Microsoft Exchange Transport service deletes the existing mail.que database and associated log files. Then, when the Microsoft Exchange Transport service starts, it creates new database and transaction log files.

Примечание.
With this action, any messages that are stuck in the messaging queues are lost.

• Move: When this action is specified, the Microsoft Exchange Transport service moves the existing transport database and log files to a directory named %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\Queue\Queue.old. Then, when the Microsoft Exchange Transport service starts, it creates new database and transaction log files.

• For more information, see Общие сведения об очередях транспорта.

User Action

No user action is required. However, you may want to obtain more information about the cause of the Transport restart issue that occurred or modify the recovery action. Additionally, you may want to recover any queued messages that may be stored in a moved Transport database. To do this, do one or more of the following:

• Проверьте наличие соответствующих событий в журналах приложений и системных журналах серверов Exchange 2010. Например, события, которые происходят непосредственно до и после этого события, могут предоставить дополнительные сведения об основной причине ошибки.

• Review the Application log to help locate the issue that caused the resource usage issue.

• Examine the System event log to determine whether any hard disk drive or subsystem issues exist which may cause the storage issue.

• Examine memory-related performance counters or memory-related logged events to determine whether the Microsoft Exchange Transport service experienced an out-of-memory condition.

• Use the Queue Viewer tool in the Exchange 2010 Toolbox to verify that the queued messages are being delivered.

• You may want to review the back pressure configuration settings in the EdgeTransport.exe.config file. The file is located in the following folder on the Transport server:

  %ProgramFiles%\Microsoft\Exchange Server\V14\Bin

  Note   We recommend that you do not modify the back pressure settings.

  For more information about the back pressure settings, see the "Back Pressure Configuration Options in the EdgeTransport.exe.config File" section in Общие сведения об обратном давлении.

• You may want to increase diagnostics logging to log the components in the transport pipeline. To increase diagnostics logging for the Transport components, follow these steps:

  1. In the Exchange Server 2010 Management Console, expand Server Configuration, and then click Hub Transport.

     Note   For an Edge Transport server, click Edge Transport.

  2. In the Actions pane, click Manage Diagnostic Logging Properties for the appropriate server.

  3. Expand MSExchangeTransport.

  4. Click the following components, and then click Expert, then click Configure for each component:

  • Smtpreceive

  • Smtpsend

  • DSN

  • Components

  • Remote Delivery

  • Categorizer

• If a file-level antivirus scanner is running, verify that antivirus exclusions are configured appropriately. For more information, see Поиск вирусов на файловом уровне в Exchange 2010.

• Determine whether the transport database is corrupted. To do this, follow these steps:

  1. Stop the Microsoft Exchange Transport service.

  2. Remove the transport database. To do this, rename the following folder:

     %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\data\Queue

  3. Start the Microsoft Exchange Transport service to determine whether mail flow is restored.

• Edit the EdgeTransportConfig.exe.config file to modify the recovery action. To do this, follow these steps:

  1. Start Windows Explorer, and then browse to the following folder:

     %ProgramFiles%\Microsoft\Exchange Server\V14\Bin

  2. Open the EdgeTransport.exe.config file by using any text editor such as Notepad.

  3. Search for QueueDatabaseRecoveryAction. If this key does not exist, add the following entry in the <appSettings> tag after the other QueueDatabase-related entries:

     <add key="QueueDatabaseRecoveryAction" value="<action>" />

     For example:

     <add key="QueueDatabaseRecoveryAction" value="move" />

  4. Save the changes to the file, and then restart the Microsoft Exchange Transport service.

• If the Microsoft Exchange Transport service moved the Transport database to the Queue.old directory, try to repair the damaged Transport database to recover any queued messages. For more information, see Working with the Queue Database on Transport Servers. Specifically, move the Transport database files from the Queue.old directory to a working location, and use the Eseutil tool to perform the following actions against the original Transport database files:

  1. Run the following command to dump the database headers. Then, view the results to determine whether the Mail.que database is in a dirty shutdown state.

     Eseutil /mh mail.que

  2. If the database is in a dirty shutdown state, run the following command to replay any outstanding transaction logs:

     Eseutil /r trn

  3. If MsExchangeTransport Event ID 17011 is logged to indicate that the checkpoint file is damaged, remove the .chk file, and then run the Eseutil /r trn command to replay the transaction log files.

  4. Run the following command to defragment the database:

     Eseutil /d mail.que

  5. Restore the database files to their original location. Use the steps in the Working with the Queue Database on Transport Servers topic to do this. For example:

  • Pause the Microsoft Exchange Transport service.

  • Use the Queue Viewer tool to verify that all Transport queues have emptied or export any messages that have not emptied.

  • Stop the Microsoft Exchange Transport service.

  • Replace the new database files with the original files, and then start the Microsoft Exchange Transport service.

• Для решения проблемы обратитесь в службу технической поддержки, используйте средства для самостоятельного устранения неполадок или другие ресурсы. Эти дополнительные ресурсы доступны в Техническом центре Exchange Server. В области навигации на этой странице щелкните Самостоятельная поддержка и выберите один из предлагаемых вариантов. Для самостоятельного устранения неполадок можно выполнить поиск по базе знаний Майкрософт, опубликовать свой вопрос на форуме Exchange Server и воспользоваться другими способами. Можно также обратиться к специалисту службы технической поддержки Майкрософт, щелкнув в области навигации Варианты технической поддержки. Поскольку для прямого обращения в службу технической поддержки Майкрософт в вашей организации может использоваться определенная процедура, необходимо сначала ознакомиться с инструкциями организации.

For more information about the transport pipeline in Exchange 2010, see Общие сведения о конвейере транспорта and also the Exchange Server Team blog article,

Exchange 2010 Transport Architecture Diagrams Available for Download

Содержимое и URL-адрес любого блога могут быть изменены без предварительного уведомления. Содержимое каждого блога предоставляется «как есть», без каких-либо гарантий и передачи каких-либо прав. На предлагаемые примеры сценариев и коды распространяются условия использования продуктов корпорации Майкрософт.