In a DRDA environment, resynchronization occurs if two-phase commit processing is interrupted by a resource failure. However, the decision to commit or roll back an in-doubt LUW by any way other than the normal resynchronization process is a heuristic decision. If you commit or roll back a unit of work and your decision is different from the other system's decision, data inconsistency occurs. This type of damage is called heuristic damage.
An example of heuristic damage would be if the operator performed a heuristic commit and then the transaction manager requested that the unit of work be rolled back. If this situation occurs, and your system then updates any data involved with the previous unit of work, your data is corrupted and is difficult to correct.
The only way to correct heuristic damage is to restore the database from an archive by manually correcting the data based on knowledge from the application. This damage correction must be coordinated with all of the participating application servers to ensure that the data is consistent in each individual application server and between all of the participating application servers.
You can perform heuristic actions on in-doubt transactions that are not involved in a distributed unit of work. The heuristic actions performed are not logged and therefore are also not displayed by the SHOW INDOUBT operator command. (Note that heuristic damage is still possible on these transactions.) See the DB2 Server for VSE & VM Operation manual for more information on the SHOW INDOUBT command.
Performing heuristic actions on distributed unit of work transactions must be done with caution. You can use the FORCE command to perform heuristic functions on distributed unit of work in-doubt LUWs when the resource owner cannot wait for the sync point manager to perform the resynchronization action. See the DB2 Server for VSE & VM Operation manual for more information on the FORCE command.