Informix Error -141

Reasons / Common Causes

-141 is different in character from -137/-138/-139: those are ceilings on how many chunks, dbspaces, or logical logs can exist in total; -141 is a ceiling on how many tblspaces (approximately, tables) can be open concurrently at a given moment. It's a live concurrency condition, not a permanent storage-object count — which is exactly why the official guidance offers a short-term retry option alongside the long-term configuration fix.

1. Many concurrent sessions or queries each having multiple tables open at once, collectively exceeding the configured TBLSPACES limit during a moment of unusually high concurrency, rather than any single session doing something wrong.
2. Queries touching a large number of tables simultaneously — wide joins, or views built on many base tables — each contributing to the currently-open count for the query's duration.
3. Heavy table fragmentation, echoing the same mechanism as -104: a table split into many fragments can count multiple times toward the open-tblspace total for what's logically one table.
4. TBLSPACES sized for typical concurrency, not peak concurrency — a burst of unusually high activity (month-end reporting overlapping normal OLTP traffic, for example) can exceed a limit that comfortably covers ordinary load.
5. PDQ (parallel database query) amplifying the instantaneous open-tblspace count for a single complex query — the same mechanism -104 describes for file handles, applied here to concurrently open tblspaces.

Solutions / Resolution

1. Short-term: roll back the current transaction and re-execute it when fewer concurrent operations are happening. Per the official guidance, this is a legitimate response to an occasional concurrency spike, not just a stopgap — many occurrences of -141 are exactly that: a transient peak, not a durable problem.
2. Long-term: increase the TBLSPACES parameter in ONCONFIG if this recurs regularly rather than as an occasional spike — an administrator task, typically requiring the same reinitialization discipline as other ONCONFIG capacity parameters.
3. Monitor the ovrtable count (via ON-Monitor/ON-Monitor Profile, or the current equivalent monitoring mechanism) — the official guidance highlights this metric specifically because it tracks how often this condition actually occurs, which is the right basis for deciding whether TBLSPACES genuinely needs raising versus this being a rare, acceptable occurrence.
4. Consolidate fragments for tables that don't need many, if heavy fragmentation is contributing to the count, similar to -104's guidance.
5. Adjust PDQPRIORITY for specific heavy queries during periods when open-tblspace pressure is already elevated, if PDQ amplification is a major contributor.
6. Stagger high-concurrency batch or reporting workloads away from other equally demanding activity where possible, to reduce peak simultaneous open-tblspace counts.

Examples

The month-end reporting spike

-- Normal OLTP traffic, plus month-end reporting queries touching
-- many tables each, all running concurrently for a few hours

If ovrtable shows this happening only during predictable, bounded windows like month-end, the short-term retry approach — or scheduling reports to avoid overlapping peak OLTP hours — may be more appropriate than permanently raising TBLSPACES.

PDQ amplifying a single query's open-tblspace footprint

A single complex report, run with PDQ enabled, opens many of its underlying tables' tblspaces in parallel rather than sequentially — during exactly the moment several other sessions are also active, the combined instantaneous count exceeds TBLSPACES even though none of the individual queries look unreasonable.

Monitoring before deciding

-- Check the ovrtable count over time before increasing TBLSPACES
-- A rare, occasional count suggests retry-on-conflict is sufficient;
-- a steadily climbing or frequent count suggests raising the limit

Diagnostic Checks

1. Check the ovrtable count to see how often this condition actually occurs — the official guidance's own recommended metric for deciding whether configuration change is warranted.
2. Check the current TBLSPACES configuration value:

   grep -i "^TBLSPACES" $ONCONFIG
   

3. Review concurrent activity and timing around failures — does this correlate with a known batch/reporting window overlapping normal traffic?
4. Check for heavy fragmentation on tables involved in the failing queries, if fragment count might be inflating the open-tblspace total.

Related Errors / Related Topics

• -104 — "ISAM error: too many files open." The closest conceptual sibling — both are concurrency-driven "too many storage objects open at once" conditions, with the same PDQ- and fragmentation-amplification mechanisms.
• -137 — "ISAM error: chunk table overflow." Same general ONCONFIG capacity-ceiling family as the long-term fix for -141, though -137 is a permanent storage-object count rather than a live concurrency measure.

Check the ovrtable count before deciding whether this needs a configuration change or is simply an occasional, retry-worthy concurrency spike — the two call for very different responses.