Informix Error -168

Reasons / Common Causes

-168 is a specific, temporary restriction during an online archive: allocation of new pages for TEXT/BYTE data in a storage space is frozen for the archive's duration. The official text draws an important distinction worth understanding clearly — this is not the same as ordinary row data being blocked during a backup.

1. An online archive is currently in progress, during which pages holding large-object data at the time the archive began must be preserved (not freed and overwritten) until they've been written to the archive — otherwise the archive couldn't guarantee a consistent copy of that data.
2. An application attempting to insert or update significant amounts of new BYTE/TEXT data during an active archive window, hitting this allocation freeze specifically.
3. A long-running archive extending the window during which this restriction is in effect, increasing the odds that a concurrently scheduled heavy BLOB-writing workload collides with it.
4. A misunderstanding of the asymmetry involved. The official text is explicit that ordinary row data can keep changing during the archive — changed dbspace pages can be written to the archive tape at any point. Only new page allocation for TEXT/BYTE data is restricted. Teams unaware of this distinction sometimes assume all writes are blocked during a backup, when in fact only new large-object page allocation is.
5. Heavy blob-ingestion workloads (bulk document loads, image imports) scheduled without coordinating against backup windows.

Solutions / Resolution

1. Wait until the archive completes. Allocation resumes automatically once all used pages in the chunk have been archived — no manual intervention is needed beyond that.
2. Coordinate scheduling of heavy BYTE/TEXT ingestion workloads with backup windows — the same general scheduling discipline as -147, but specifically important here because it affects BLOB allocation even though ordinary row writes continue unaffected.
3. If archives run long enough to regularly collide with BLOB-heavy workloads, consider whether archive scheduling, archive duration (investigate what's making it slow), or workload scheduling needs adjustment.
4. Communicate the asymmetry to development and operations teams: ordinary row data can keep changing during an archive; only new BYTE/TEXT page allocation in that storage space is frozen. This avoids unnecessary alarm or overly broad workarounds (like pausing all writes) when only BLOB allocation specifically needs to wait.
5. Consider dedicating separate maintenance windows for blob-heavy imports, away from backup schedules, if this is a frequent operational pain point.

Examples

A bulk document import colliding with an active archive

-- A nightly backup is running

-- Meanwhile, a batch job attempts to import several thousand new
-- documents into a TEXT column
-- -168: new BYTE/TEXT page allocation is frozen until the archive
-- finishes archiving the currently-used pages in that storage space

Waiting for the backup to complete, or scheduling the import outside the backup window, resolves this directly.

Clarifying what actually is and isn't blocked

-- During the same archive window:
UPDATE customer SET last_login = CURRENT WHERE id = 1;
-- succeeds normally — ordinary row data isn't blocked by the archive

INSERT INTO documents (id, content) VALUES (999, <new large TEXT value>);
-- -168 if this requires new BYTE/TEXT page allocation in a storage
-- space currently being archived

This distinction matters operationally — a team that assumes all writes are blocked during backups might unnecessarily pause an entire application, when only new large-object ingestion specifically needs to wait.

Diagnostic Checks

1. Check whether an archive is currently in progress:

   onstat -u
   

2. Review whether the failing operation specifically inserts or updates BYTE/TEXT data — ordinary row-data operations wouldn't hit this particular restriction.
3. Review archive duration and scheduling history if this recurs regularly, to understand whether the archive window or the BLOB-ingestion schedule needs adjusting.

Related Errors / Related Topics

• -147 — "ISAM error: archive in progress." The direct sibling — the general archive-blocks-certain-operations family, of which this is the BYTE/TEXT-specific case.
• -166 — "ISAM error: Storage space is full." Another blobspace-specific condition tied to the same underlying reclaim/allocation mechanics for large-object pages.

Remember the asymmetry: ordinary row data isn't blocked during an archive — only new BYTE/TEXT page allocation is. Don't over-scope a workaround to pause writes generally when only large-object ingestion specifically needs to wait.