Informix Error -131: ISAM error: no free disk space.

Reasons / Common Causes

-131 is specifically about contiguous free space, not just total free space — that word in the official text matters. A dbspace can report plenty of free space in aggregate while still failing this way, if that space is scattered across many small fragments rather than available as one block large enough for the operation being attempted.

1. A dbspace or chunk that's genuinely full — the straightforward case, no free space left at all.
2. Free space fragmented across many small pieces within a dbspace. Extents from different tables interspersed with each other over time can leave a dbspace with adequate total free space that's nowhere available as one usable contiguous block — this is the case the official wording specifically calls out and the one most likely to surprise someone checking only aggregate free-space numbers.
3. A table's extent sizes growing over time — as a table's next-extent-size policy increases with growth, each subsequent extent demands a larger contiguous allocation, which a moderately fragmented dbspace can satisfy for small extents but not for large ones.
4. Rapid, unplanned data growth outpacing the capacity planning done for a specific dbspace.
5. Multiple tables competing for space within the same dbspace, with one growing much faster than anticipated and squeezing out room others need.
6. A single large operation — a bulk load, a big index build — requiring a large contiguous extent all at once, which even a dbspace that isn't "full" in aggregate can fail to provide if fragmented.
7. Undersized or fragmented temp dbspaces relative to the workload's actual sort, hash, or temp-table needs.

Solutions / Resolution

1. For C-ISAM programs, roll back the current transaction (if transaction logging is in use), free up disk space, and retry — per the official guidance.
2. For SQL products, roll back the current transaction if possible, then contact the system administrator about acquiring more disk space for the affected database.
3. Add more chunks/space to the affected dbspace to relieve immediate pressure.
4. If fragmentation, not raw exhaustion, is the actual issue, reorganize to consolidate free space into usable contiguous extents — an unload/reload of a badly fragmented table, or the equivalent reorganization mechanism for the version in use.
5. Review and adjust extent-sizing policy for tables prone to this, so future growth doesn't demand progressively larger contiguous allocations that fragmented free space can't satisfy.
6. Move large, fast-growing tables into their own dedicated dbspace so they don't compete with, or fragment space for, unrelated objects.
7. Size temp dbspaces appropriately for the actual sort/hash/temp-table workload, and monitor their usage rather than assuming the original sizing still fits current load.
8. Monitor dbspace free-space and fragmentation trends proactively — catching this before it blocks an operation is much cheaper than an emergency response after a bulk load or index build fails mid-run.

Examples

Adequate total space, no usable contiguous block

onstat -d
-- dbspace shows 500MB free in aggregate

oncheck -pe mydb:dbspace1
-- reveals that free space is scattered across dozens of small gaps,
-- none larger than a few MB, interspersed between other tables' extents

A load or index build needing a single 100MB contiguous extent fails here even though the dbspace is nowhere near "full" by total free space alone — the fix is reorganization, not simply adding a little more space.

Extent-size growth outpacing available contiguous space

-- A growing table's next-extent-size increases with each allocation:
-- extent 1: 10MB, extent 2: 20MB, extent 3: 40MB, extent 4: 80MB...
-- Eventually the required contiguous block exceeds what a
-- moderately fragmented dbspace can provide, even if total free
-- space would have been sufficient for several smaller extents

A big bulk load hitting fragmented space

LOAD FROM 'large_export.unl' INSERT INTO archive_table;
-- -131: the load needs a large contiguous extent; the target
-- dbspace has enough total free space but not one block that big

Splitting the load into smaller batches, or moving archive_table to its own dedicated, unfragmented dbspace, both address this more directly than simply adding more total space to a dbspace that's already fragmented.

Diagnostic Checks

1. Check dbspace/chunk free space at the aggregate level:

   onstat -d
   

2. Check extent-level fragmentation detail — this is the check that actually distinguishes "genuinely full" from "fragmented":

   oncheck -pe <database>:<dbspace>
   

3. Compare the size of the failing operation (the load, the index build) against the largest available contiguous block, not just total free space.
4. Review recent growth trends for the specific dbspace and the tables within it, to understand whether this is a one-time spike or an ongoing capacity issue.

Related Errors / Related Topics

• -130 — "ISAM error: no such dbspace." The naming-mismatch sibling — -130 is about a dbspace that doesn't exist by the name given; -131 is about one that exists but has run out of usable space.
• -116 — "ISAM error: cannot allocate memory." The other resource-exhaustion error in this range — -116 is memory, -131 is disk, but both call for the same kind of investigation: genuine exhaustion versus fragmentation, and whether a single oversized operation or accumulated growth is the trigger.

Check for fragmentation, not just raw free space, before concluding a dbspace simply needs more room — the official wording's emphasis on "contiguous" is the clue that this distinction matters.