Informix Error -137

Reasons / Common Causes

-137 is a pure administrator-configuration ceiling, not an application or data-design issue — the official text says explicitly that this is what the database system administrator sees, and names the exact fix. The engine tracks a fixed maximum number of disk chunks it can manage, set by the CHUNKS parameter in the ONCONFIG file, and that limit has been reached.

1. The instance-wide chunk count has grown to the configured CHUNKS limit — this is a single, shared budget across the entire instance, not per dbspace, so it's the sum of every chunk across every dbspace that matters.
2. Storage provisioned as many smaller chunks over time, whether for incremental growth or to spread I/O across more devices/LUNs, consuming the chunk-count budget faster than raw data volume alone would suggest.
3. An originally under-provisioned CHUNKS setting relative to how much the deployment eventually grew — a value that made sense at initial sizing but was never revisited as the system scaled.
4. Multiple dbspaces each accumulating chunks independently, none individually alarming, but collectively reaching the shared instance-wide ceiling.

Solutions / Resolution

1. Increase the CHUNKS parameter in the ONCONFIG file — the official guidance's direct fix.
2. Initialize shared memory after changing the parameter — per the official text, this is a required step, not optional; editing the config file alone doesn't take effect until the engine's shared memory is reinitialized (a restart or the equivalent re-initialization procedure for the version in use).
3. Consider consolidating existing chunks into fewer, larger ones, for dbspaces provisioned with many small chunks, if reducing chunk-count pressure independent of raising the ceiling is worthwhile — this requires more involved reorganization than simply raising CHUNKS, but reduces how quickly the limit is approached again in the future.
4. Size CHUNKS generously relative to anticipated long-term growth when initially configuring a new instance, rather than a value that only comfortably covers current needs.
5. Balance storage provisioning strategy against the chunk-count budget — spreading I/O across many small chunks consumes the same limited instance-wide resource as fewer large ones, so that trade-off is worth making deliberately rather than by accident.

Examples

Reaching the limit after years of incremental growth

# ONCONFIG
CHUNKS  32

A system that started small and grew by adding a few chunks at a time, across several dbspaces, over several years, can reach even a moderate CHUNKS value like this without anyone individually add a large number at once — the ceiling is reached cumulatively.

The fix: raise the limit and reinitialize

# ONCONFIG
CHUNKS  128

# Then, per the official guidance, initialize shared memory —
# e.g., a controlled restart of the database server

Editing the file alone is not sufficient — the new value needs the engine's shared memory reinitialized to take effect.

Diagnostic Checks

1. Check the current CHUNKS setting:

   grep -i "^CHUNKS" $ONCONFIG
   

2. Count actual chunks in use across all dbspaces and compare against the configured limit:

   onstat -d
   

3. Review chunk-addition history across dbspaces if the goal is understanding whether a many-small-chunks provisioning pattern is what drove this, separate from simply raising the limit.

Related Errors / Related Topics

• -131 — "ISAM error: no free disk space." A different kind of capacity ceiling — -131 is about space within existing chunks; -137 is about the number of chunks the instance can track at all, regardless of how much space each one holds.
• -136 — "ISAM error: no more extents." Another administrator-facing capacity limit in the same general family, though at the table/extent level rather than the instance/chunk level.

This is a configuration change, not a data or application problem — raise CHUNKS and reinitialize shared memory, and confirm the new count is actually in effect afterward.