Informix Error -163

Reasons / Common Causes

-163 is a direct, mechanical corruption detection: disk pages carry a stamp at both the beginning and end, meant to match as a sanity check that the entire page was written as one atomic unit. When they don't match, it means the page was only partially written or partially overwritten — this is genuine storage-integrity corruption, in the same severity class as -105 and -135.

1. A torn or incomplete page write — a crash or power loss interrupting a write partway through a page, leaving the two stamps inconsistent with each other. This is the classic root cause behind most torn-write corruption in this range, detected here through a specific, mechanical check rather than a general "bad format" signal.
2. A partial overwrite from a different layer — a faulty driver, faulty memory, or a storage controller issue writing only part of a page's data, distinct from an application-level crash.
3. Hardware failure — a failing disk with sector-level issues corrupting part of a page while leaving the rest intact, producing a real, detectable mismatch.
4. An unclean shutdown occurring during a page write — the same underlying event that can produce -105, -118, or -119, but caught here through this page's own internal consistency check.
5. Storage or filesystem write-caching acknowledging a write before it's actually persisted, turning an ordinary crash into a torn page at the storage layer even though the application believed the write had completed.
6. An improperly taken "hot" copy of underlying files while writes were in progress — the same cause -105 describes, capturing a page mid-write inconsistently.

Solutions / Resolution

Follow the same severity-appropriate sequence as -105/-135/-155:

1. Roll back the current transaction and terminate the application, per the official guidance.
2. Have the database administrator run tbcheck, oncheck, or onutil to investigate and attempt repair.
3. If repair isn't possible, or the utility confirms serious damage, restore from backup.
4. After recovery, investigate root cause — check for an unclean shutdown or crash, hardware issues on the underlying storage, or an improperly taken hot copy around the time the corruption likely occurred, mirroring -105's own root-cause investigation.
5. Confirm regular, verified backups exist going forward, given the severity of this failure class.
6. If storage or filesystem write-caching is implicated (acknowledging writes before they're actually persisted), review and correct that configuration to prevent recurrence — this is a durability-guarantee problem, not just a one-time incident to recover from.

Examples

The immediate response

ROLLBACK WORK;

-- Terminate the application, then have the administrator run:
oncheck -cc     -- or tbcheck / onutil, per the version in use

Investigating after recovery

grep -iE "abort|panic|shutdown" $INFORMIXDIR/online.log
dmesg -T | grep -iE "error|i/o|reset"

As with -105, correlating the timing against a crash or a disk/I-O error is what determines whether this is likely to recur — don't close the incident without this step.

Diagnostic Checks

1. Run the version-appropriate check/repair utility:

   oncheck -cc
   tbcheck -y
   onutil
   

2. Check the message log for related events around when this first appeared:

   grep -iE "abort|panic|shutdown|assert" $INFORMIXDIR/online.log
   

3. Check OS/storage logs for hardware or I/O errors affecting the underlying storage.
4. Review recent operational history — crashes, restores, or any external tooling that might have caused a torn write.

Related Errors / Related Topics

• -105 — "ISAM error: bad ISAM file format." The closest sibling in cause and severity — both point at genuine storage corruption requiring a check/repair utility and, potentially, a restore from backup.
• -135 — "ISAM error: tblspace does not exist." Similar severity, applied to the engine's central bookkeeping rather than an individual page.

Don't spend time searching for an application-level explanation — this is a mechanical, page-level integrity check failing, and the response is the same regardless of what specific application code was running at the time.