Oninit
Talk to an expert →

Informix Error -458

-458 Long transaction aborted.

The database server ran out of log space in which to record this transaction. A transaction that is not fully recorded cannot be rolled back. To preserve database integrity, the operating system ended the transaction and rolled it back automatically. All changes made since the start of the transaction have been removed. Terminate the application, and replan it so that it modifies fewer rows per transaction. Alternatively, contact the database server administrator to discuss increasing the number or the size of the logical logs. Be prepared to talk about the number of rows being updated or inserted and the size of each row.

This error can also occur when a DBA has used FORCE_DDL_EXEC environment variable in another session and executes the ALTER FRAGMENT ON TABLE statement. In this situation, the ALTER FRAGMENT ON TABLE statement rolls back any transactions that opened or have locks on the tables on which ALTER FRAGMENT is issued.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-458 fires when a transaction exhausts available logical log space needed to record its changes. Since an incompletely recorded transaction can't be rolled back safely from a partial log record, the server automatically terminates and rolls back the entire transaction to protect database integrity — every change since the transaction began is undone.

  1. A transaction modifying an unusually large number of rows, generating more log records than the configured logical log space can hold.
  2. A batch operation (bulk update/delete/insert) run as a single transaction, rather than broken into smaller committed chunks.
  3. Logical log capacity configured too small for the application's normal transaction sizes, even for operations that aren't unusually large by the application's own standards.
  4. A DBA using the FORCE_DDL_EXEC environment variable to execute ALTER FRAGMENT ON TABLE — per the official guidance, this specifically rolls back any open transactions on the affected tables, which can surface as this same error for sessions with open transactions on those tables at that moment.
Solutions / Resolution
  1. Redesign the application to modify fewer rows per transaction, per the official guidance — break large batch operations into smaller, separately committed chunks.
  2. Contact the database administrator about increasing logical log capacity, per the official guidance, if the transaction sizes are genuinely appropriate for the application's needs.
  3. If this coincides with a DBA running ALTER FRAGMENT ON TABLE with FORCE_DDL_EXEC, recognize this as an expected side effect of that specific administrative action, not an application bug — coordinate timing with the DBA if this disrupts normal operations.
Examples
Breaking a large batch operation into smaller transactions
-- Instead of one huge transaction:
BEGIN WORK;
UPDATE orders SET archived = 1 WHERE order_date < '2020-01-01';
-- (potentially millions of rows)
COMMIT WORK;

-- Break into smaller committed batches:
BEGIN WORK;
UPDATE orders SET archived = 1
    WHERE order_date < '2020-01-01' AND order_id BETWEEN 1 AND 100000;
COMMIT WORK;
-- repeat for subsequent ranges
Diagnostic Checks
  1. Check how many rows the failing transaction was modifying relative to normal application patterns.
  2. Check the server's configured logical log capacity against typical and peak transaction sizes.
  3. Check whether a DBA recently ran ALTER FRAGMENT ON TABLE with FORCE_DDL_EXEC on the affected tables around the same time.
Related Errors / Related Topics
  • -377 — "Must terminate transaction before closing database." A related transaction-state restriction, though about sequencing rather than log-space exhaustion.
  • -347 — "Could not open table for exclusive access." Another resource-constraint-related error, in this case about the lock table rather than logical log space.

Break large batch operations into smaller, separately committed transactions — this is usually a better fix than repeatedly raising logical log capacity to accommodate ever-larger transactions.