Enlist of MSDTC transaction failed: %hs.

Details
Product: SQL Server
Event ID: 8510
Source: MSSQLServer
Version: 8.0
Component: SQL Engine
Message: Enlist of MSDTC transaction failed: %hs.
   
Explanation
This message occurs when an attempt is made to enlist a new or existing Microsoft Distributed Transaction Coordinator (MS DTC) transaction and that attempt fails.

The cause of the failure to enlist varies. The state of the error, the specific result code returned with the error, as well as any other errors that occurred around the same time can help to determine why the enlistment failed in your environment. The failure to enlist is often a sign of a communications problem such as failed name resolution. It can also be the result of the way the calling application is coded or a result of blocking or performance issues on the SQL Server side.

Under certain very specific conditions, when a second server process ID (SPID) attempts a new enlistment or makes a call to the sp_reset_connection stored procedure while the Microsoft Distributed Transaction Coordinator (MS DTC) transaction is being successfully interrupted or committed, the second SPID encounters a changing MS DTC transaction and generates the 8510 error message. The 8510 error message is considered unnecessary in these circumstances because the state of the transaction is already resolved before the error message occurs. For more information about this particular set of circumstances, see Microsoft Knowledge Base article 307802.

   
User Action
  • Check that the MS DTC is started on both machines involved in the MS DTC transaction. If the MS DTC service is clustered, verify that it is online in Cluster Administrator.
  • Review the event logs for the servers involved in the MS DTC transaction to see if there are other errors at the same time as this message. If there are other errors, troubleshoot them first, because this error is often a side effect of other errors.
  • By default, network MS DTC access is disabled on Windows Server 2003. If any computer involved is running Windows 2003, verify that MS DTC has been enabled. For more information about how to enable network MS DTC access in Windows 2003, see Microsoft Knowledge Base article 817064.
  • Verify that RPC communications between the servers involved is working correctly.
  • Reboot the servers involved in the MS DTC transaction to flush all IP address information.
  • Verify that the transaction timeout settings for the calling COM+ component are long enough to avoid a timeout that results in a separate component trying to enlist in a transaction that has already timed out.
  • If you have turned on the SQL Server configuration option “lightweight pooling” (also known as “fiber mode”) turn it back off. Test whether the error still occurs.
  • If you have turned on the SQL Server configuration option “priority boost,” turn it back off. Test whether the error still occurs.
  • Review the Microsoft Knowledge Base article 307802 to see if your environment is an exact match for the environment in the article. If it is an exact match, test changing one of the environmental factors to see if the message stops occurring. If it stops once the environment no longer matches the article, you know the message can be safely ignored.

Related:

Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Details
Product: SQL Server
Event ID: 1205
Source: MSSQLServer
Version: 9.00.1281.60
Symbolic Name: LK_VICTIM
Message: Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
   
Explanation

Resources are accessed in conflicting order on separate transactions, causing a deadlock. For example:

  • Transaction1 updates Table1.Row1, while Transaction2 updates Table2.Row2.

  • Transaction1 attempts to update Table2.Row2 but is blocked because Transaction2 has not yet committed.

  • Transaction2 now attempts to update Table1.Row1 but is blocked because Transaction1 has not committed.

  • A deadlock occurs because Transaction1 is waiting for Transaction2 to complete, but Transaction2 is waiting for Transaction1 to complete.

The system will detect this deadlock and will choose one of the transactions involved as a ‘victim’ and will issue this message, rolling back the victim’s transaction. For more information about deadlocks, see Deadlocking in SQL Server 2005 Books Online.

   
User Action

Execute the transaction again. You can also revise the application to avoid deadlocks. The transaction that was chosen as a victim can be retried and will likely succeed, depending on what operations are being executed simultaneously.

To prevent or avoid deadlocks from occurring, consider having all transactions access rows in the same order (Table1, then Table2); this way, although blocking may occur, a deadlock will not occur. For more information about actions to take see “Detecting and Ending Deadlocks” in SQL Server 2005 Books Online.

Related:

process name (process id) file nameUnable to read the header of logfile error code. Error %5.

Details
Product: Exchange
Event ID: 412
Source: ESE
Version: 6.5.0000.0
Message: process name (process id) file nameUnable to read the header of logfile error code. Error %5.
   
Explanation

Unable to read the header of the log file named in the Event ID 412

message. This may be due to a mismatching log signature, a corrupt log

file, or a corrupt log header.

The cause depends on the Jet (ESE) Error code in the Description section of

the event. The most common causes are listed below.

  • Error -530 =

    JET_errBadLogSignature= Bad signature for a log file. A signature for

    log files is used only to ensure that we are replaying the “right” set of log

    files. For example, if Log 45 from another storage group ended up in the set of log files of another storage group, then ESE will detect a signature

    mismatch and not replay this log file. A portion of each database header

    includes the signature of the current log file generation; if they do not

    match, then we error out indicating a mismatch.

  • Error -501 =

    JET_errLogFileCorrupt = Log file corrupt. Error-1022 is

    returned from corrupting the header of a log file. Corrupting other areas of

    the log file returns -501 JET_errLogFileCorrupt.

  • Error -1022 = JET_errDiskIO =

    Disk IO error. The -1022 error is a generic error that appears whenever

    a disk input/output (I/O) problem prevents Exchange from gaining access to a

    requested page in the database or to a transaction log. The most common reason for a -1022 error is a

    database file that was severely damaged or truncated. If this issue occurs,
    Exchange requests a page number that is larger than the number of pages in the

    database file, and a -1022 error results. This issue can occur because of

    issues in the file system or because of improper transaction log replay. In

    the case of a log file, Error-1022 is returned from corrupting the header of a

    log file.

   
User Action
  • Restore from online backup.
  • If there is no valid backup,

    repair the database by running the eseutil /p command,

    and then run the isinteg -fix command on the affected store repeatedly until

    you receive 0 fixes or the same result for fixes twice. CAUTION: After you

    repair the database by using the eseutil /p switch and isinteg -fix,

    the database may not be stable and reliable. Because the repair process

    deletes database pages, data loss is likely. NOTE: If you have to run a hard

    repair on your production database, Microsoft recommends that you move the

    data out of the repaired database to a new database or rebuild the database

    using Move Mailbox or ExMerge.

Related:

%1 (%2) %3Unable to read the header of logfile %4. Error %5.

Details
Product: Exchange
Event ID: 412
Source: ESE
Version: 8.0
Symbolic Name: LOG_HEADER_READ_ERROR_ID
Message: %1 (%2) %3Unable to read the header of logfile %4. Error %5.
   
Explanation

This Warning event indicates that the database engine is unable to read the log file header specified in the event description. This may be because of a mismatching log signature, a corrupted log file, or a corrupted log header.

The cause depends on the ESE error code in the Description section of the event. The most common causes are in the following list.

  • Error 530 = Jet_errBadLogSignature = Bad signature for a log file. A signature for log files is used only to make sure that we are replaying the “right” set of log files. For example, if Log 45 from another storage group ended up in the set of log files of another storage group, then ESE will detect a signature mismatch and not replay this log file. A part of each database header includes the signature of the current log file generation; if they do not match, then we error out indicating a mismatch.

  • Error 501 = Jet_errLog fileCorrupt = Log file corrupt. Error 1022 is returned from corrupting the header of a log file. Corrupting other areas of the log file returns 501 Jet_errLog fileCorrupt errors.

  • Error 1022 = Jet_errDiskIO = disk I/O error. The 1022 error is a generic error that appears whenever a disk I/O problem prevents Exchange from gaining access to a requested page in the database or to a transaction log. The most common reason for a 1022 error is a database file that was severely damaged or truncated. If this issue occurs, Exchange requests a page number that is larger than the number of pages in the database file, and a 1022 error results. This issue can occur because of issues in the file system or because of incorrect transaction log replay. In a log file, error 1022 is returned from corrupting the header of a log file.

   
User Action

To resolve the warning, use one of the following procedures:

  • Restore data from online backup.

  • If there is no valid backup, repair the database by running the Eseutil /p command, and then run the isinteg -fix command on the affected store repeatedly until you receive 0 fixes or the same result for fixes two times. After you repair the database by using the Eseutil /p command and isinteg -fix, the database may not be stable and reliable. Because the repair process deletes database pages, data loss is likely. If you have to run a hard repair on your production database, we recommend that you move the data out of the repaired database to a new database or rebuild the database using the Move Mailbox command.

For information about ESE error codes other than the ones explained in this topic, see the following Microsoft Knowledge Base articles:

For more information about ESE error 1022, see 314917, Understanding and Analyzing -1018, -1019, and -1022 Exchange database errors.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related:

Transform your business in the cloud with Business Operations Connect

With business processes and business rules, you can transform your
operations by gaining efficiency and insight. By exposing these enterprise
assets as reusable APIs and managing the APIs in an easily accessed catalog,
your mobile and web-based apps can be more easily discovered, tried, and
integrated for innovative new applications. This tutorial shows how to create
a business process using IBM Business Process Manager (BPM) on Cloud and a
decision service using IBM Operational Decision Manager (ODM) on Cloud and
then how to manage those assets as APIs in IBM API Connect.

Related:

Handle distributed transactions with federated two-phase commit in WebSphere Federation Server Version 9.1

So, what’s new in the distributed transaction processing area? Federated two-phase commit, a new feature in WebSphere Federation Server Version 9.1 that enables multi-site updates in a distributed transaction environment. Learn how this feature provides location transparency, transaction coordination, error recovery during two-phase commit, resynchronization, and performs indoubt transaction resolution manually.

Related: