Informix Error -193

Reasons / Common Causes

-193 is a subtle recovery-consistency issue tied to reusing a physical chunk device too soon. When a chunk (or an entire storage space) is dropped and the same physical device/path is reused for a different storage space without a level-0 backup performed in between, logical recovery replaying logs from before the reuse still contains an "add chunk" record referencing that device — and finds it already exists, because it's now assigned to something else.

1. A chunk (or storage space) was dropped, and the same physical device was reused for a different storage space without an intervening level-0 backup. This is the exact condition the official text describes — the missing backup is what leaves a stale log reference that later recovery trips over.
2. Administrators recycling device paths quickly after decommissioning old storage, as a matter of storage-recycling habit, without realizing a level-0 backup must happen first to avoid orphaning old log records referencing the original assignment.
3. A disaster-recovery or logical-restore scenario replaying logs that span such a reuse, catching the recovery process at exactly this inconsistency.
4. Automated storage-provisioning scripts recycling device paths for new chunks without enforcing the required level-0 backup step between drop and reuse.

Solutions / Resolution

1. Always take a level-0 backup immediately after dropping a chunk or storage space and before reusing that physical device/path for a new one. Per the official guidance, this is exactly what prevents the inconsistency this error reports during future logical recovery.
2. If this occurs during recovery, review backup history to confirm whether a level-0 backup was actually performed between the drop and the reuse — if not, that gap is the root cause and needs procedural correction going forward, not just a one-time fix.
3. For storage-provisioning automation, build in an enforced level-0 backup step between dropping a chunk/space and reusing its device for something new.
4. Treat this seriously when it appears during active recovery — similar in urgency to -176/-177's restore-adjacent context — this may require administrator involvement to resolve the specific recovery inconsistency for the affected chunk and timeframe.

Examples

The missing backup that causes this later

-- Drop a chunk/storage space
onspaces -d old_dbspace

-- WITHOUT a level-0 backup here...

-- ...the same device is reused for a new storage space
onspaces -c -d new_dbspace -p /dev/reused_chunk -o 0 -s 1000000

-- Later, logical recovery replaying logs from before the reuse
-- encounters an "add chunk" record for /dev/reused_chunk and
-- finds it already in use — -193

The correct sequence

onspaces -d old_dbspace
ontape -s -L 0                    -- level-0 backup BEFORE reuse
onspaces -c -d new_dbspace -p /dev/reused_chunk -o 0 -s 1000000

Taking the level-0 backup between the drop and the reuse establishes a clean recovery boundary, so future logical recovery never needs to reconcile the old and new assignments for that device.

Diagnostic Checks

1. Review backup history for a level-0 archive between the original drop and the device's reuse.
2. Identify the specific chunk/device path involved and its assignment history — which storage space it belonged to before, and which it belongs to now.
3. Review the logical recovery or restore log for the specific point of conflict.

Related Errors / Related Topics

• -169 — "ISAM error: Pages for TEXT or BYTE data can't be allocated from a chunk until chunk add is logged." The closest sibling — both involve chunk-add mechanics interacting with the logging/recovery process.
• -191 — "ISAM error: No such chunk." The general chunk-lifecycle sibling.

Establish a level-0 backup as a mandatory step between dropping any chunk/storage space and reusing its physical device — this is a procedural discipline to build into runbooks, not something to fix reactively each time it's missed.