Share via

Restoring Damaged DTC Log Files

  • Article

 

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

If the DTC log file is damaged or lost, it cannot be restored, copied from another system, or reinitialized without causing potentially serious data corruption. The DTC log file contains critical information regarding transaction outcomes. The information in the DTC log is extremely volatile—information that, even when only a few seconds old, is almost certainly out of date and largely useless for recovery purposes. Because of this, it makes no sense to back up and restore the DTC log file.

The preferred option is to place the DTC log file on a failsafe disk device such as a RAID array. If the log file is lost despite this precaution, the only alternative is to reinitialize the DTC log file through the Component Services administrative tool, after copying this file from the CD, which brings the unavoidable risk of compromising the consistency of the underlying transactional resource managers.

Such a consistency problem can occur if the DTC log file is reinitialized 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 under DTC transaction control and 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 receiving the commit notification during phase two. In this case, the first resource manager commits the transaction while the second resource manager remains in doubt about the transaction outcome. If the DTC log file is lost before the second resource manager can perform recovery, all record of the committed but in-doubt transaction is lost.

When the second resource manager is restarted, it inquires about the in-doubt transaction. The DTC assumes that the transaction aborted because there is no record of the transaction in the newly initialized log file. The 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 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 the DTC log file is lost or damaged, you should perform the following steps:

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

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

    Note

    Determining transaction outcomes may be difficult without the DTC log file. You should resolve all in-doubt transactions before reinitializing the DTC log file and restarting the DTC. Any in-doubt transactions you do not resolve are aborted when the DTC is restarted and recovery is performed.

  3. In the Component Services administrative tool, click Reset log on the MSDTC tab of the My Computer Properties page to reinitialize the log file. If a log file already exists in the location specified by the drive and directory, clicking Reset log deletes the current log file.

  4. Click Start to restart the DTC.

Note

If automated system recovery is initiated the DTC log can no longer be considered valid. Therefore the CID (GUID that identifies the DTC instance) is changed, and the log is re-initialized. While this may leave some resource data locked until it can be manually taken care of, it ensures the integrity of the data.

See Also

Choosing the DTC Log File Location
DTC Log File Management
Resetting the DTC Log File (Component PSDK)