Informix Error -119

Reasons / Common Causes

-119 is the sibling of -118, and the distinction between them matters for diagnosis: -118 is "I couldn't read the log record" (an access/I-O problem); -119 is "I read the log record, and its contents are invalid" (a data-integrity problem). Both surface during rollback or recovery, and both point at the transaction log rather than application code, but the specific cause is different enough to investigate separately.

1. A torn or partial write to the log from an earlier abrupt crash — the record was successfully written far enough to be readable, but not completely or correctly enough to be structurally valid. This is the most common practical cause: a crash or power loss during a log write leaves data that a later read can retrieve but not make sense of.
2. Bit-level corruption after the record was written correctly — a memory error or storage bit-rot event altering the record's bytes sometime between a correct write and a later read.
3. A version mismatch reading a log record written by an incompatible server version — during a migration or a failed/partial upgrade, log records written under one version's binary layout being interpreted by different, incompatible reading code.
4. External tooling manipulating log files directly, outside the engine's own management, leaving structurally invalid data even though the file itself remains readable.
5. A genuine software defect in an older engine version that wrote a malformed record in the first place — rare, but real, and part of why the official guidance treats an unexplained recurrence as worth escalating rather than self-diagnosing indefinitely.

Solutions / Resolution

1. Use dblog/selog to get detail about which specific log record is bad and its surrounding context — the same first step as -118, and for the same reason: these tools identify exactly where and when the problem is, rather than leaving it to guesswork.
2. If the object cannot be recovered, re-create it or restore from the most recent known-good backup — the same documented fallback as -118.
3. Check for a crash or abrupt shutdown around the time the bad record would have been written — a torn-write scenario from an earlier incident is the most common explanation, and confirming it (rather than assuming ongoing corruption) changes what needs fixing going forward.
4. Check hardware health — memory diagnostics and disk health checks — if no crash or version mismatch explains it, since bit-level corruption after a correct write is a real, if less common, cause.
5. Confirm engine version consistency across any recent migration or upgrade activity if the timing lines up — verify the log is being read by tooling that actually matches the version that wrote it.
6. Investigate any external tooling touching log files directly, and stop that practice if found — log files are meant to be managed exclusively by the engine.
7. If none of the above explains it, treat this as a genuine anomaly and escalate to IBM Informix Technical Support with full diagnostic detail (dblog/selog output, version, timeline) rather than continuing to search for a self-service fix.

Examples

The torn write from an earlier crash

# Server crashed (power loss) at 03:14 while writing to the logical log
# Days later, a rollback needs to read a record from around that time
ROLLBACK WORK;
-- -119: the record from the crash window is readable but malformed

The record's window in time — not anything about the current rollback — is the actual clue: a bad record from exactly when an earlier crash occurred is the torn-write signature, not an ongoing or worsening problem.

Diagnosing with dblog and selog together

dblog
selog | grep -i "bad log record"

Run both — dblog for the logical log's own status, selog for surrounding message-log context — before deciding whether this looks like a one-time torn write or something requiring deeper investigation (hardware, version mismatch).

Diagnostic Checks

1. Check the specific bad record's context:

   dblog
   selog | tail -100
   

2. Correlate against crash/shutdown history — does the bad record's position or timestamp line up with a known abrupt termination?
3. Check hardware health if no crash explanation fits:

   dmesg -T | grep -iE "ecc|memory|error"
   

   and disk health via vendor tools or smartctl.
4. Confirm version consistency if a migration or upgrade happened recently — verify the version reading the log matches (or is properly compatible with) the version that wrote it.
5. Check for any external process touching log files directly — anything outside the engine's own log management that might explain structurally invalid data in an otherwise accessible file.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -118 — "ISAM error: cannot read log record." The closest sibling — the two are distinguished by how the log record failed: unreadable (-118) versus readable but invalid (-119). Both call for the same first diagnostic step (dblog/selog) and the same fallback (re-create or restore) if recovery can't complete.

Correlating the bad record's timing against crash/shutdown history is the single most useful first check — a torn write from a known earlier incident is a very different situation from ongoing, unexplained corruption.