Informix Error -116

Reasons / Common Causes

-116 means the ISAM processor asked the operating system for memory and didn't get it. The official text specifically calls out large BYTE/TEXT columns and BLOB values as common triggers — buffering that kind of data wholesale in memory is a very different load than ordinary row processing, and it's where this error tends to show up first.

1. Selecting rows with large BYTE/TEXT columns into a temporary table, or otherwise buffering large object data wholesale rather than streaming it — exactly the case the official text names. A query that seems ordinary in row count can still demand enormous memory if the rows carry large object columns.
2. Buffering an entire row containing BLOB values in memory during processing that doesn't need to hold the whole thing at once — building a full in-memory result set (for a report, a form, or an export) instead of processing row-by-row.
3. A memory leak in a long-running C-ISAM program, accumulating allocations over the process's lifetime until even a modest new request fails — the failure can appear long after, and far from, the code that's actually leaking.
4. Insufficient physical memory and swap configured for the actual workload — the engine's real working-set requirements (sort space, temp space, buffer pools) can exceed what's provisioned even without any single query being unusually large.
5. Memory fragmentation, particularly in older or 32-bit environments — enough total free memory can exist while no single contiguous block is large enough for one big allocation request, which large object buffers are especially prone to triggering.
6. Process- or container-level memory limits (ulimit -v/-m, cgroup/container memory caps) constraining the process well below the physical machine's total, causing failures under load that wouldn't occur unconstrained.
7. Collective memory pressure from multiple concurrent sessions — several large sorts or temp-table builds running at once can exhaust a shared, finite total even though any one of them in isolation would have succeeded.

Solutions / Resolution

1. Avoid buffering large object columns wholesale. Select only the columns actually needed; defer fetching BYTE/TEXT/BLOB data until it's genuinely required, rather than pulling it into a temporary table or an in-memory structure as a matter of course.
2. For C-ISAM programs, review memory usage directly — release buffers as soon as they're no longer needed, and check for leaks in long-running processes rather than assuming memory pressure is always external.
3. Simplify overly complex SQL, forms, or reports, per the official guidance — break a large operation into smaller pieces that each hold less in memory at once, rather than one operation that tries to do everything together.
4. Check and raise process/container memory limits if they're constraining the process below what the actual workload legitimately needs:

   ulimit -a
   

5. Size physical memory and swap appropriately for the real workload rather than assuming defaults are adequate, especially on systems that regularly handle large object data.
6. Move off a 32-bit environment if still running one — address-space fragmentation is a far smaller concern on 64-bit builds, and large-object allocations are exactly the kind most affected by it.
7. Stagger or limit concurrent large operations (big sorts, big temp-table builds) if collective memory pressure from simultaneous sessions is the cause, rather than assuming any single session's usage in isolation must be the culprit.
8. Monitor memory usage over the life of long-running processes to catch a leak early, rather than discovering it only once -116 finally occurs.

Examples

The BLOB-buffering query

SELECT customer_id, contract_document
INTO TEMP tmp_contracts
FROM contracts
WHERE status = 'active';
-- contract_document is a large BYTE/TEXT column; buffering it into a
-- temp table for every active contract can demand far more memory
-- than the row count alone would suggest

Better: select the large column only for the specific rows actually needed, or process contracts one at a time rather than materializing all of them into a temp table together.

The slow leak in a long-running program

while (has_more_work()) {
    buf = malloc(BUFSIZE);
    process(buf);
    /* free(buf) missing — leaks BUFSIZE bytes every iteration */
}
/* -116 eventually, once accumulated leaked memory exhausts what's available */

The failure point (wherever -116 is finally reported) is unrelated to where the actual bug is — the leak has been accumulating since the loop started.

Concurrent large sorts exhausting shared memory

-- Several sessions, at the same time
SELECT * FROM large_table ORDER BY unindexed_column;
-- each sort needs significant memory; several running concurrently
-- can collectively exhaust what's available even though any single
-- one would have succeeded in isolation

Diagnostic Checks

1. Check system memory and swap usage at or around the failure time:

   free -h
   

2. Check process/container memory limits:

   ulimit -a
   

   and, if running in a container, the configured cgroup memory limit.
3. Review the specific query/report/form for large object columns being selected or buffered unnecessarily — this is the first thing to check given how directly the official text points at it.
4. For a suspected C-ISAM leak, use a memory-profiling or leak-detection tool against the long-running process rather than guessing at the source from the failure point alone.
5. Check for concurrent large operations around the failure time:

   onstat -g mem
   

   or review other active sessions for large sorts or temp-table builds happening simultaneously.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -104 — "ISAM error: too many files open." The other resource-exhaustion error in this range — -104 is about file descriptors, -116 is about memory, but both call for the same kind of investigation: is this a leak, a genuinely oversized single operation, or collective pressure from concurrent activity?

Check for large object columns first (Reasons #1/#2) before assuming a leak or a systemic memory-sizing problem — it's the cause the official text itself calls out, and the easiest to confirm or rule out directly.