Informix Error -118

Reasons / Common Causes

-118 happens during the exact moment the engine most needs its transaction log to be reliable — rolling back a transaction or recovering a file — and it can't read a log record it needs. Like -105, this is a storage-integrity condition more than a coding issue, but with an added dimension specific to logging: the record needed might be gone, not just corrupted.

1. The logical log wrapped and overwrote the record before rollback/recovery could read it. A long-running transaction, combined with an undersized logical log or infrequent log backup, can mean the log space a rollback needs has already been recycled for other purposes by the time the rollback actually runs. This is the classic "long transaction" failure mode for logging.
2. Physical corruption or damage to the log files themselves — disk failure, bad sectors, or an incomplete write leaves a specific log record unreadable exactly where recovery needs it.
3. An abrupt engine crash mid-write to the logical log, leaving a partially written record at the position recovery needs to read.
4. Logical log files or chunks deleted, moved, or otherwise altered outside the engine's own management — manual intervention with dbspace or log chunk files that the engine didn't coordinate.
5. Continuous log backup falling behind or misconfigured, allowing the log to wrap and overwrite records still needed for an in-progress or crashed transaction's potential rollback.
6. Storage-level I/O errors — transient or persistent disk, SAN, or filesystem problems corrupting or making inaccessible the specific log page needed at the moment it's read.
7. Running out of logical log space during a long transaction, putting the engine into a recovery/rollback path under exactly the conditions (log pressure, possible partial writes) most likely to also surface a read failure.

Solutions / Resolution

1. Check the accompanying OS-level error message first, per the official guidance — it usually identifies whether this is a storage/hardware problem versus a logical (log-wrapped) one.
2. Use dblog and onstat/selog (the official text's own recommended tools) to get detailed diagnostic information about exactly which log record or position failed and why.
3. If the file/table cannot be recovered through the engine's own recovery, re-create it or restore from the most recent known-good backup — the official guidance's own documented fallback when recovery itself can't complete.
4. Review transaction duration patterns if log-wrapping is implicated — is a batch job leaving transactions open far longer than necessary, and would breaking it into smaller committed units prevent the log pressure that led here?
5. Size the logical log appropriately for actual workload — increase log space or log file count if long transactions or high write volume routinely strain retention.
6. Ensure continuous log backup runs reliably and doesn't fall behind — this is what keeps the engine from ever needing to reuse log space still required by an active or crashed transaction.
7. Investigate underlying storage health if OS-level errors suggest hardware or I/O trouble — the same diagnostic posture as -105: don't just recover and move on without understanding whether the disk itself is failing.
8. Treat root-cause investigation as equally important as recovery. A rollback/recovery path failing outright is a serious enough condition that resuming normal operation without understanding why risks recurrence — this mirrors -105's own guidance directly.

Examples

The long transaction outliving the log

-- A batch job holds one enormous transaction open for hours
BEGIN WORK;
-- ... thousands of inserts/updates over several hours ...
-- meanwhile, continuous log backup runs on its normal schedule and
-- the logical log wraps, reusing space this transaction's eventual
-- rollback would have needed
ROLLBACK WORK;
-- -118: the log records needed to undo this transaction are gone

The fix isn't retrying the rollback — it's restructuring the batch job into smaller, more frequently committed units so no single transaction can outlive the log's retention.

Diagnosing with dblog

dblog

Review the logical log's current status and recent history — this is the first tool to reach for, per the official guidance, before assuming either a hardware or a workload-pattern cause.

Diagnostic Checks

1. Check logical log status directly:

   dblog
   onstat -l
   

2. Check the message log for surrounding detail:

   selog | tail -100
   

3. Check OS/storage logs for I/O errors around the failure time:

   dmesg -T | grep -iE "error|i/o"
   

4. Review whether a long-running transaction was active around the time of failure — job schedules, application logs, or transaction history if still available.
5. Review logical log configuration (log size, number of logical logs, backup frequency) against the workload's actual transaction duration and volume, if log-wrapping is suspected as the root cause rather than a storage fault.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -105 — "ISAM error: bad ISAM file format." The closest sibling in spirit — both are storage-integrity conditions where the check-first, restore-if-needed, investigate-root-cause posture matters more than searching for an application-level bug.

If recovery or rollback itself is failing, don't treat this as routine — confirm whether the cause is storage-level corruption or a log-retention/long-transaction problem before deciding whether restoring from backup is actually necessary, per Solutions above.