Informix Error -155

Reasons / Common Causes

-155 is among the most severe conditions in this range: both the primary chunk and its mirror — the redundancy that was specifically supposed to prevent exactly this — are unusable at the same time. The official guidance doesn't offer a repair path; it states plainly that new chunks must be defined and the system restored. Understanding why mirroring failed to protect against this matters as much as the immediate recovery.

1. A genuine, simultaneous failure of both the primary and mirror devices — rare, but real: both disks in a mirror pair failing close together, or a shared underlying failure point (a controller, a shared power or cooling issue) taking out both physical disks even though they were nominally independent.
2. A shared point of failure that defeated the redundancy mirroring was meant to provide. If the primary and mirror chunks physically reside on the same underlying storage array, controller, or host, they were never actually independent failure domains — a mirroring architecture mistake that only becomes visible when that shared component fails.
3. Corruption affecting both copies independently, from a layer above the physical disks. Mirroring protects against disk-level hardware failure, not against writing bad data to both copies in the first place — a software bug, in-memory corruption before the write, or a corrupting filesystem/volume layer shared by both copies can leave both the primary and its mirror holding the same corrupted data.
4. A severe I/O subsystem failure (a RAID controller failure, a SAN fabric issue) affecting the storage paths for both primary and mirror simultaneously.
5. Human error affecting both chunks at once — a scripting mistake that wiped or reformatted both devices, or a decommissioning process that removed both without realizing they were still a needed mirror pair.

Solutions / Resolution

Follow the official guidance's sequence directly, given the severity:

1. Roll back the current transaction and terminate the application immediately.
2. Contact the database server administrator immediately — this is not a condition for the application or a single session to work through.
3. Define new disk chunks, and restore the system. The official text is explicit that restoration is required here, not an optional fallback after attempted repair — treat backup restoration as the expected path forward from the start.
4. After recovery, conduct a serious root-cause investigation. Given the severity, determine specifically why redundancy failed to protect against this event: a true double-disk failure, a shared failure-domain design flaw, or corruption that defeated mirroring's protection model entirely (each has a different implication for what needs to change).
5. Review mirroring architecture to confirm primary and mirror chunks genuinely reside on independent failure domains — different physical disks, different controllers, ideally different arrays or hosts. If the investigation reveals a shared failure point, treat fixing that as part of recovery, not something to restore back into place unchanged.
6. Confirm backup currency and integrity as part of the incident response. This is exactly the scenario where mirroring's protection failed and a verified, tested backup is the only remaining recovery path — don't discover a stale or untested backup during the incident.
7. If corruption (not physical failure) affected both copies, investigate the layer above the physical disks — application, filesystem, memory — for the actual source of bad data. Restoring without finding that cause risks writing the same corruption back into the restored system.

Examples

The immediate response

ROLLBACK WORK;

-- Terminate the application, then escalate immediately to the
-- database server administrator — this is a "restore the system"
-- situation from the start, not a "try to repair" one.

Investigating a shared failure domain after recovery

-- Check: did the primary and mirror chunks share a controller,
-- array, or host that failed as a single point, defeating the
-- redundancy mirroring was meant to provide?

If the post-incident investigation confirms a shared failure domain, the restored system's mirroring architecture needs to change — placing primary and mirror on genuinely independent storage — not just recreating the same layout that just failed.

Diagnostic Checks

1. Confirm the actual failure mode reported by the storage layer for both the primary and mirror chunks — hardware failure versus checksum/corruption detection calls for different root-cause investigation.
2. Review the physical and logical placement of the primary and mirror chunks to check for a shared failure domain.
3. Check for recent operator or scripting activity that might have inadvertently affected both chunks at once.
4. Confirm backup currency and integrity before and during the restoration process.

Related Errors / Related Topics

• -146 — "ISAM error: the other copy of this disk is currently disabled or non-existent." The less severe mirroring-related sibling — -146 is a protective sequencing check preventing this exact outcome (both copies unavailable at once) during planned maintenance; -155 is what it looks like when both copies actually do become unavailable simultaneously.
• -105 — "ISAM error: bad ISAM file format." Similar severity and diagnostic posture — both call for a serious root-cause investigation as part of recovery, not just a restore-and-move-on response.

This is a restore-from-backup situation from the start, per the official guidance — the real work is the root-cause investigation into why redundancy failed, so it doesn't happen again.