Informix Error -145

Reasons / Common Causes

-145 is an administrator-facing prerequisite error: disk mirroring is an instance-wide capability that must be established when the database server is initialized, not something enabled on-the-fly per dbspace afterward. Attempting to add a mirror chunk to a server that was never set up for mirroring fails here, every time, regardless of the specific chunk or dbspace involved.

1. The server instance was never initialized with mirroring support enabled, and someone is now attempting to add a mirror chunk (via onspaces -m or the equivalent for the version in use) as though it were a per-dbspace setting.
2. Mirroring wasn't planned for at initial provisioning, with the intention to "add it later" without realizing that retrofitting requires reconfiguring and reinitializing the server itself, not a lightweight follow-up command.
3. Confusing storage-level redundancy with Informix's own mirroring feature. RAID, a SAN's own replication, or similar storage-level protection is a different mechanism entirely from Informix's application-level disk mirroring — existing storage redundancy doesn't satisfy this prerequisite, and a team assuming it does is surprised when the Informix-level command still requires its own configuration.
4. A migrated or restored instance that didn't carry over mirroring configuration — if the source instance was mirrored, that setting doesn't automatically transfer to a differently initialized target instance.

Solutions / Resolution

1. Reconfigure and reinitialize the database server to support mirroring before attempting to add a mirror chunk. This is an instance-level change, not a per-dbspace toggle — plan for the associated downtime/maintenance window accordingly.
2. Plan for mirroring needs during initial server provisioning whenever there's a realistic chance it will be needed — retrofitting later requires this more involved reconfiguration step, so deciding upfront avoids it.
3. If storage-level protection (RAID, SAN replication) already exists, confirm explicitly with whoever owns the architecture decision whether Informix-level mirroring is still actually required for this environment — this is a real decision to make deliberately, not something to assume either way.
4. For migrated or restored instances, explicitly verify whether mirroring configuration needs to be re-established on the new instance, rather than assuming it carried over from the source.

Examples

Attempting to add a mirror chunk on an unmirrored server

onspaces -m dbspace1 -p /dev/mirror_device -o 0
-- -145: this server was never initialized with mirroring support

The fix isn't a different command or flag — the server itself needs reconfiguration and reinitialization for mirroring before any mirror chunk can be added.

RAID isn't a substitute

A team assumes existing RAID1 storage means Informix-level mirroring is redundant and skips configuring it, then later needs to add a mirror chunk for a specific dbspace and discovers this error — the two protection mechanisms operate independently, and having one doesn't configure the other.

Diagnostic Checks

1. Check the server's current mirroring configuration status using the appropriate check for the version in use.
2. Review server initialization/ONCONFIG history for whether mirroring was ever enabled at setup time.
3. Confirm architecture requirements around mirroring versus existing storage-level protection, if the need for Informix-level mirroring is in question at all.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -137 — "ISAM error: chunk table overflow." A different administrator-facing infrastructure prerequisite in the same general category — both require a deliberate server-level configuration step rather than anything fixable from the application side.

This isn't a condition with a quick workaround — mirroring genuinely needs to be configured at the server level before any mirror chunk can be added.