Informix Error -169

Reasons / Common Causes

-169 is a brief, expected, and easily resolved restriction: when a chunk is added to extend storage for TEXT/BYTE data, new page allocation from that chunk can't happen until the log record documenting the chunk addition has actually been written. This exists to prevent recovery anomalies — if the engine crashed before that record was logged, recovery wouldn't correctly know about the new chunk, so allocating from it prematurely would be unsafe.

1. A chunk was just added to a blobspace or storage space, and the log record for that addition hasn't been written yet — it's pending until the current logical log fills and rolls over naturally, or is forced to.
2. An application inserting or updating BYTE/TEXT data immediately after a chunk was added to accommodate that growth, not realizing there's a brief, expected delay before the new capacity is actually usable.
3. Low logging activity elsewhere on the system, meaning the current logical log doesn't naturally fill and roll over quickly — extending how long this restriction stays in effect if left to resolve on its own.
4. Administrators unaware of the direct workaround, waiting unnecessarily for natural log rollover instead of forcing it immediately after adding the chunk.

Solutions / Resolution

1. Don't wait for natural log saturation. Per the official guidance, use onmode -l (or tbmode -l on older versions) to force the engine to move to the next logical log immediately — this writes the pending chunk-add log record right away and unblocks allocation without delay.
2. If capacity was just added specifically to relieve space pressure (following a -166 or -131 situation), follow the chunk addition immediately with onmode -l so the new capacity becomes usable without unnecessary delay.
3. Build this step into standard chunk-addition runbooks. Since this is expected and has a direct, immediate fix, document onmode -l as the standard follow-up step after adding a chunk, rather than leaving administrators to wait it out or treat it as an unexpected error.
4. If encountered unexpectedly (not immediately after a chunk addition), confirm whether a chunk was in fact recently added and correlate the timing before assuming something else is wrong.

Examples

The standard fix

onspaces -a dbspace1 -p /dev/newchunk -o 0 -s 1000000
-- chunk added successfully

onmode -l
-- forces immediate log rollover, writing the pending chunk-add
-- log record and unblocking new page allocation right away

Without the fix: waiting unnecessarily

onspaces -a dbspace1 -p /dev/newchunk -o 0 -s 1000000
-- chunk added

-- Application immediately attempts to insert new TEXT/BYTE data:
INSERT INTO documents (id, content) VALUES (1001, <large TEXT value>);
-- -169: allocation from the new chunk isn't available yet

-- Without forcing log rollover, this waits until the current
-- logical log fills naturally on its own — potentially a long time
-- on a system with low logging activity

Running onmode -l immediately after the chunk addition avoids this wait entirely.

Diagnostic Checks

1. Confirm whether a chunk was recently added to the storage space in question — this is the direct trigger for this condition.
2. Check logical log status and rollover history:

   onstat -l
   

3. Run onmode -l to force log progression if a recent chunk addition is confirmed as the cause.

Related Errors / Related Topics

• -166 — "ISAM error: Storage space is full." Often the reason a chunk was just added in the first place — worth reviewing together as part of the same capacity-management workflow.
• -168 — "ISAM error: archive is blocking storage space allocation." A different temporary restriction on the same general kind of allocation, tied to backup activity rather than chunk-addition logging.

Run onmode -l immediately after adding any chunk intended for TEXT/BYTE storage — it's the direct, documented fix, not something to wait out.