Informix Error -105

Reasons / Common Causes

-105 is different in kind from the rest of the -100-series: it isn't a call-argument or file-lifecycle mistake in the calling program — it's a report that the contents of an ISAM file (a table or an index) are corrupted. The official text splits recovery by product (C-ISAM's isrecover, or SQL's oncheck/bcheck/secheck), but the causes worth understanding are what put the file in that state to begin with:

1. An unclean shutdown mid-write. A hard crash, an OS panic, a kill -9 against the engine, or a power loss while a table or index page was partially written leaves that structure internally inconsistent. This is by far the most common path to -105 in practice.
2. Storage hardware failure — failing disk sectors, a botched RAID rebuild, or a controller fault corrupting the bytes that make up the file, independent of anything the database engine did.
3. A storage or filesystem layer that lied about durability. Write-back caching (in a controller, a SAN, or a virtualization layer) that acknowledges a write before it's actually persisted turns an otherwise-ordinary crash into data loss the engine had no way to anticipate.
4. An improperly taken "hot" copy. Copying a raw dbspace chunk file with a generic file-copy or backup tool while the engine is actively writing to it — rather than using the engine's own backup mechanism or quiescing writes first — can capture an internally inconsistent snapshot that looks like corruption the moment it's used.
5. External tooling writing to ISAM structures outside the engine's control. Legacy or third-party tools that use the ISAM API directly against files the SQL engine also manages can leave the two layers' internal bookkeeping disagreeing with each other.
6. An incomplete operation from a mid-build disk-space shortage. An index build or similar structural change that runs out of disk space partway through can leave a file structurally incomplete rather than cleanly failed.
7. A version mismatch during an in-place upgrade — running against on-disk structures without the correct conversion/migration step for that specific version jump.
8. Silent bit-level corruption ("bit rot") on aging storage without active integrity checking — rare on well-maintained hardware, but a real long-tail cause on older or unreliable disks.

Solutions / Resolution

1. If C-ISAM with transaction logging was enabled, attempt automated recovery first:

   isrecover <file>
   

   This is the fastest, least lossy path when it's available — try it before anything more invasive.
2. Without logging, or if isrecover can't fully repair the file, restore from the most recent known-good backup rather than attempting to hand-patch a corrupted structure.
3. For SQL products, run the appropriate check utility to get a specific damage report and attempt repair:

   oncheck -pt <database>:<table>      -- table pages
   oncheck -pe                         -- extents
   oncheck -cI <database>:<table>      -- indexes
   

   (bcheck/secheck, or tbcheck on IBM Informix OnLine 6.0 and earlier, for those specific older structures.)
4. If the check utility reports it cannot recover the object, re-create the table or index from a known-good source — DDL plus a reload from backup, a replica, or another consistent copy — rather than continuing to attempt manual repair on a structure the tooling itself has given up on.
5. Investigate root cause before just restoring and moving on. A restore without understanding why the file corrupted risks the same failure recurring:
   • Check for an unclean engine shutdown around the estimated corruption onset (online.log, OS logs, whether the process was killed rather than shut down cleanly).
   • Check storage hardware health directly rather than assuming the database layer is at fault.
   • Review whether any external backup/replication/copy tool touched the raw dbspace chunk files outside the engine's own mechanisms.
6. If hardware is implicated, run vendor disk diagnostics and consider moving the affected dbspace to different physical storage.
7. Confirm transaction logging is actually enabled and working for the affected database going forward — it directly determines what recovery options exist the next time this happens, and it's worth verifying rather than assuming.
8. If disk space exhaustion coincided with the corruption, add monitoring/alerting on free space for the dbspaces involved, since a repeat shortage during another structural operation will produce the same failure again.
9. For a suspected version-mismatch cause, follow the documented upgrade path exactly, including any required conversion utility, rather than skipping steps on the assumption an in-place jump is safe.

Examples

Diagnosing before restoring

oncheck -pt mydb:customer

Run this first, even when a backup is available and restoring feels like the fast path — the check utility's output tells you whether this is a page-level issue oncheck can repair in place, sparing a full restore, or genuine structural damage that confirms a restore is actually necessary.

Correlating with an unclean shutdown

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

If an unclean shutdown or a storage I/O error shows up around the time the corrupted table was last written, that's the root cause — not a mystery to keep investigating after the restore.

The improperly taken hot copy

# Wrong: copying a live chunk file while the engine is writing to it
cp /informix/chunks/chunk03.dat /backup/chunk03.dat

# Right: use the engine's own backup mechanism (ontape, onbar, or an
# equivalent that coordinates with the engine), or quiesce writes first
ontape -s -L 0

A raw file copy has no way to know it captured a page mid-write — the corruption this produces often isn't discovered until the copy is actually used, which can be long after the copy was taken.

Diagnostic Checks

1. Run the appropriate check utility first, before any restore, to get a specific damage report rather than guessing at scope:

   oncheck -pt <database>:<table>
   oncheck -cI <database>:<table>
   

2. Check for an unclean shutdown around the estimated onset:

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

3. Check OS/storage logs for hardware or I/O errors in the same window:

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

4. Confirm whether transaction logging was enabled for the affected database — this determines whether isrecover is even a viable option:

   SELECT logged FROM sysdatabases WHERE name = 'mydb';
   

5. Check disk space history for the dbspace around the time of the failure, if monitoring data is available — a shortage during a structural operation (index build, extent allocation) is a common, checkable cause.
6. Review external tooling — backup scripts, replication agents, or anything else that touches dbspace chunk files directly — for recent changes or runs that coincide with the corruption's onset.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family, though unrelated in cause — grouped here as background on how this error class is organized.

Unlike most errors in this range, -105 is rarely something application code can prevent or work around — it's a storage-integrity problem. Treat the check-utility output as the actual diagnosis, and treat root-cause investigation (Solutions #5) as equally important to the recovery itself, so the same corruption doesn't recur.