Informix Error -146

Reasons / Common Causes

-146 is a protective sequencing check: the engine refuses to take one side of a mirror pair offline while the other side is already disabled or missing, because doing so would mean both copies become unavailable at once — exactly what mirroring exists to prevent.

1. Attempting maintenance on one chunk while its mirror partner is already offline, from an earlier, possibly unrelated incident (a disk failure, a prior maintenance action) that was never fully resolved before this second action was attempted.
2. A sequencing mistake in a maintenance runbook or script — intending to perform maintenance on one side of a mirror pair without first checking the current online status of the other side.
3. The partner chunk's device path is genuinely gone ("non-existent," not just administratively disabled) — the physical device or path was removed, renamed, or is otherwise unrecognized by the engine, a more serious underlying infrastructure issue than a routine administrative disable.
4. Automated rolling maintenance across multiple mirrored chunks without verifying each pair's current health before acting on it — a script that assumes all mirror pairs are healthy and processes them uniformly can hit this the moment one pair already has an issue.

Solutions / Resolution

1. Bring the other (partner) chunk of the mirror pair back online first, before attempting to take the current chunk offline. This is the only path forward per the official guidance — not a check to work around, but the actual required sequence.
2. If the partner chunk is offline due to an underlying disk failure, resolve that failure first — replace or repair the disk, reattach the device — and bring it back online before proceeding with whatever maintenance was originally intended on the other side.
3. Add an explicit pre-check to maintenance runbooks and scripts operating on mirrored storage: confirm both sides of a mirror pair are online before ever taking either side offline for planned maintenance.
4. If the partner chunk's device path is genuinely gone, treat this as a device-level infrastructure issue requiring investigation or replacement before mirroring health can be restored at all — this is a different, more serious situation than an administratively disabled chunk.
5. Never schedule simultaneous or overlapping maintenance windows for both sides of the same mirror pair — stagger maintenance so one side is always confirmed online before touching the other.

Examples

The sequencing mistake

onspaces -s dbspace1 -p /dev/chunk1_primary -o 0 -O
-- -146: /dev/chunk1_mirror (the partner) is already offline
-- from an unrelated disk issue last week that was never resolved

The fix is bringing /dev/chunk1_mirror back online first — attempting to force the primary offline anyway would leave the dbspace with zero available copies, which the engine refuses to allow.

A runbook missing a pre-check

A rolling maintenance script iterates through several mirrored chunks, taking each briefly offline for a routine check. One pair already has its mirror side down from an earlier incident; the script, having no pre-check, attempts the same operation uniformly and hits -146 on that pair specifically — the fix is adding a status check before the offline attempt, not special-casing this one pair after the fact.

Diagnostic Checks

1. Check mirror pair status directly:

   onstat -d
   

   Review the chunk status flags for both sides of the pair in question.
2. Determine whether the partner chunk is administratively disabled or genuinely non-existent at the device level — these call for different responses (bringing it back online administratively, versus a device-level infrastructure fix).
3. Review recent maintenance or incident history for the mirror pair, to understand how and when the partner chunk went offline in the first place.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -145 — "ISAM error: system does not have disk mirroring." The prerequisite sibling — -145 is about mirroring not being configured at all; -146 is a sequencing protection on an already-mirrored system, encountered during maintenance on a pair that isn't currently healthy on both sides.

Resolve the partner chunk's status first — there's no way to proceed with taking the other side offline until it is.