Oninit
Talk to an expert →

Informix Error -698

-698 Inconsistent transaction. Number and names of servers rolled

back - servers.

This message is returned if an Informix STAR two-phase commit or a distributed transaction is implemented with a mixed result. That is, some database servers participating in the transaction rolled back their parts of the global transaction, but other database servers committed their parts of the global transaction. The number of database servers that rolled back work is always accurate, but the list of server names (specified by DBSERVERNAME values) can be incomplete. If a large number of servers rolled back work, the list might be truncated to save space. Refer to the message log of the coordinator database server for a complete list of server names. If this error message is returned, you must determine whether your networked database system is in an inconsistent state. This procedure is described in detail in your Administrator's Guide.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-698 signals a genuinely serious condition, distinct from the rest of the -627..-630 Informix STAR two-phase-commit family: a distributed transaction ended with a mixed result — some participant servers rolled back their part of the global transaction while others committed theirs. Per the official guidance, this means the networked database system may be in an inconsistent state, and determining whether it actually is requires investigation, not automatic resolution.

  1. A network partition or communication failure during the commit phase, isolating some participants from the coordinator's final commit instruction after they'd already prepared, while others received it.
  2. A participant server crash or restart during the commit phase, between preparing and receiving the coordinator's final instruction.
  3. A heuristic decision by one or more participants (as in -629) that happened to diverge from what the coordinator ultimately decided for the transaction as a whole.
Solutions / Resolution
  1. Check the message log of the coordinator database server for the complete list of server names, per the official guidance — the error message itself may truncate the list if many servers were involved, but the reported count of rolled-back servers is always accurate.
  2. Determine whether the networked database system is actually in an inconsistent state, per the official guidance — this requires reviewing what each participant's committed vs. rolled-back state actually was for this specific transaction, not assuming either outcome.
  3. Reconcile data manually across the affected servers if an actual inconsistency is confirmed — the specific reconciliation steps depend entirely on what the transaction was doing and which servers ended up in which state; there's no generic automated fix for this.
  4. Investigate the root cause (network partition, server crash, heuristic timeout) to prevent recurrence, once the immediate data-consistency question is resolved.
Examples
Checking the coordinator's message log for the full server list
$ tail -200 /path/to/coordinator/online.log

Review around the time of the -698 error for the complete list of participant server names and their individual commit/rollback outcomes.

Diagnostic Checks
  1. Review the coordinator's message log for the complete, untruncated list of affected servers.
  2. Check each affected server's actual outcome for this transaction (committed vs. rolled back) to determine whether the data is genuinely inconsistent.
  3. This is not a "no administrative intervention required" condition, unlike -627/-628/-629 — treat it as requiring active investigation.
Related Errors / Related Topics
  • -627 — "Cannot prepare coordinator for two-phase commit." Part of the same Informix STAR two-phase-commit family, but resolved automatically (all participants roll back) — unlike -698's mixed, potentially inconsistent outcome.
  • -628 — "Cannot end two-phase commit transaction at coordinator." Same family, also self-resolving via automatic recovery.
  • -629 — "Cannot end heuristically rolled back transaction." Same family; a heuristic rollback decision by one participant is one plausible contributor to -698's mixed outcome.
  • -630 — "Cannot prepare database server server-name for commit." Same family, participant- side prepare failure.

Unlike the rest of the STAR two-phase-commit family, this genuinely needs administrative investigation — check the coordinator's message log and determine each participant's actual outcome before assuming the data is fine.