Informix Error -138

Reasons / Common Causes

-138 is the direct sibling of -137, at the dbspace level instead of the chunk level: the instance has reached its configured maximum number of dbspaces (DBSPACES in ONCONFIG) and can't add another. Same administrator-facing ceiling, same fix shape, different resource.

1. The instance-wide dbspace count has reached the configured DBSPACES limit.
2. A storage design that scales dbspace count directly with business growth — a dedicated dbspace per tenant, per large table, or per data tier grows the dbspace count as the business itself grows, eventually reaching a ceiling sized for an earlier scale.
3. An originally under-provisioned DBSPACES setting at initial configuration, never revisited as the system scaled.
4. Abandoned or temporary dbspaces from old migrations or one-off operations that were never cleaned up, silently consuming budget over time without providing ongoing value.

Solutions / Resolution

1. Increase the DBSPACES parameter in ONCONFIG.
2. Reinitialize shared memory for the change to take effect — the same required step as -137's fix; editing the configuration file alone isn't sufficient.
3. Review whether all existing dbspaces are still needed before simply raising the limit — clean up abandoned or temporary dbspaces from old migrations to free budget without a configuration change.
4. For multi-tenant or heavily-segmented storage designs, plan DBSPACES sizing proactively against expected future growth (projected tenant count, for example) rather than reacting to this ceiling after the fact.
5. Size DBSPACES generously at initial configuration for any system expected to grow substantially over its lifetime.

Examples

The fix

# ONCONFIG
DBSPACES  64

# Then reinitialize shared memory — e.g., a controlled restart

Cleanup before raising the limit

onstat -d
-- reveals several dbspaces from a migration completed over a year ago,
-- never dropped after the migration's source data was decommissioned

Dropping genuinely unused dbspaces can restore headroom without touching ONCONFIG at all — worth checking before assuming the limit itself needs to move.

Diagnostic Checks

1. Check the current DBSPACES setting:

   grep -i "^DBSPACES" $ONCONFIG
   

2. Count actual dbspaces in use:

   onstat -d
   

3. Review for abandoned or unused dbspaces from completed migrations or retired features before deciding whether cleanup or a configuration increase (or both) is the right response.

Related Errors / Related Topics

• -131 — "ISAM error: no free disk space." A different capacity dimension — space within existing dbspaces, rather than the count of dbspaces the instance can track.
• -137 — "ISAM error: chunk table overflow." The direct sibling of -138 — same administrator-facing configuration ceiling and fix pattern (raise the limit, reinitialize shared memory), applied to chunks instead of dbspaces.

Check for cleanup opportunities (unused, leftover dbspaces) before raising the configured limit — it's often the faster and more durable fix.