Compartir a través de

Restoring Lost or Damaged MS DTC Log Files

  • Artículo

Applies To: Windows Server 2008

The Microsoft Distributed Transaction Coordinator (MS DTC) log file contains critical data regarding transaction outcomes. If the MS DTC log file is lost or damaged, you cannot copy it from another computer or reinitialize it without causing potentially serious data corruption. The data in the MS DTC log is extremely volatile. Even if the data is only a few seconds old, it is probably out of date and largely useless for recovery purposes. Because of this volatility, it makes no sense to back up and restore the MS DTC log file.

The preferred alternative is to keep the MS DTC log file on a fail-safe disk, such as a RAID array. If you lose the log file despite this precaution, the only alternative is to use the Component Services administrative tool to reinitialize the MS DTC log file. When you copy the file, you risk compromising the consistency of the underlying transactional resource managers. Inconsistency can occur if you reinitialize the MS DTC log file while committed transactions remain in doubt. In this case, a resource manager that is in doubt may erroneously abort the transaction when it eventually performs recovery. Consider the following example.

Suppose an application updates two resource managers and then commits the transaction. Suppose both resource managers successfully complete phase one of the two-phase commit protocol, but one of the resource managers fails before it receives the commit notification during phase two. In this case, the first resource manager commits the transaction, but the transaction outcome of the second resource manager remains in doubt. If you lose the MS DTC log file before the second resource manager can perform recovery, the record of the committed, but in-doubt, transaction is lost.

When you restart the second resource manager, it inquires about the in-doubt transaction. The MS DTC assumes that the transaction aborted because there is no record of the transaction in the newly initialized log file. The MS DTC informs the second resource manager that it could find no record of the transaction and that the resource manager should assume that the transaction is aborted. This is a natural consequence of the Presumed Abort logging protocol that modern transaction managers rely on. As a result, the first resource manager commits the transaction while the second resource manager aborts the transaction.

If you have a lost or damaged MS DTC log file, we recommend that you perform the following steps:

  1. Use your resource manager administrative tools to determine whether your resource manager is in doubt about any MS DTC transaction outcome.

  2. Use your resource manager administrative tools to manually force any unresolved transactions to commit or abort.

    Determining transaction outcomes may be difficult without the MS DTC log file. Before you reinitialize the MS DTC log file and restart the MS DTC, resolve all in-doubt transactions. Any in-doubt transactions that you do not resolve are aborted when you restart the MS DTC and perform recovery operations.

  3. Reset the log file.

    For more information, see Resetting the MS DTC Log File.

  4. Restart the MS DTC.

    For more information, see Start and Stop MS DTC.

Note

If system recovery happens automatically, the MS DTC log is no longer valid. Therefore, the compatible ID (CID) is changed, and the log is initialized again. Although this may leave some resource data locked until you can lock it manually, it ensures the integrity of the data. A CID is a globally unique identifier (GUID) that identifies the MS DTC instance.