Filter
Top Products
Product Environment 9-33
Heuristic Decisions: What and Why
Whenever a heuristic rollback occurs, the possibility exists that manual
recovery might be required. If manual recovery is required, you are advised
by messages in the OnLine message log. This possibility is described
completely in the discussion that begins on page 9-36.
Figure 9-8
Characteristics of Heuristic Rollback
Figure 9-9 on page 9-35 illustrates the characteristics of a heuristic end-trans-
action. The most important point to remember about the heuristic end-
transaction is that if you execute tbmode -Z at either the coordinator or at the
participant OnLine database server, you undermine the automatic recovery
and feedback mechanisms built into the two-phase commit protocol.
When it occurs: A heuristic rollback occurs after the participant OnLine
sends a “can commit” message for a piece of work.
Why it occurs: This piece of work initiated a long-transaction error, or
administrator executed tbmode -z process_id.
What occurs: This piece of work is rolled back at this OnLine,
independent of coordinator instructions.
Shared memory: Shared-memory resources are released. Transaction
entry remains in transaction table.
Logical log files: All files containing records associated with the piece of
work remain open. Long-transaction error is not
alleviated. It is possible for your logical log to fill.
Logical log: ROLLBACK and HEURTX logical log records are written.
Coordinator: Because a transaction entry exists in shared memory, the
coordinator knows the piece of work was rolled back and
needs to be ended.
OnLine messages: “Transaction completed abnormally (rollback)” is
written in the participant OnLine message log.