Informix Error -166

Reasons / Common Causes

-166 is the blobspace-specific counterpart to -131, but with a crucial mechanism worth understanding before assuming genuine exhaustion: pages occupied by deleted or replaced BYTE/TEXT values don't become reusable immediately. They stay unavailable until the logical log containing that transaction is freed — which itself requires the log to be backed up and all related transactions to be closed. A blobspace can report itself full even when a large share of its "used" space is actually deleted data simply waiting to be reclaimed.

1. Genuine blobspace exhaustion — not enough space allocated for the actual volume of BYTE/TEXT data being stored, the straightforward case.
2. Continuous log backup not running, or falling behind. This is the mechanism the official text specifically calls out: without regular log backups, deleted/replaced large-object pages never actually get freed, so a blobspace fills up with what is logically dead data that simply hasn't been reclaimed yet.
3. Long-running transactions holding onto the "not yet freed" state for their touched BYTE/TEXT pages, delaying reclaim further even when log backups are otherwise current.
4. Growth in actual large-object data volume outpacing the blobspace's original capacity planning — genuine growth, distinct from the reclaim-lag mechanism above.
5. No backup/logging strategy in place at all for a blobspace-heavy workload, meaning deleted BYTE/TEXT space effectively never gets reclaimed until this is addressed.

Solutions / Resolution

1. Roll back the transaction and terminate the application, per the official guidance.
2. Request that the database administrator allocate additional disk space to the affected storage area — the direct official fix for genuine exhaustion.
3. Confirm continuous log backup is actually running and current. This is the single highest- value check before assuming more space is needed: if backups are lagging, freeing up the backlog can reclaim substantial space without adding any capacity at all.
4. Close out or commit long-running transactions promptly so their touched BYTE/TEXT pages become eligible for reclaim sooner, rather than holding space hostage for longer than necessary.
5. Monitor blobspace usage over time, distinguishing genuine growth from reclaim-pending space, so capacity planning is based on the right signal rather than raw "used space" alone.
6. For workloads with heavy BYTE/TEXT churn (frequent deletion or replacement of large objects), consider more frequent log backups specifically to speed up the page-reclaim turnaround.

Examples

The reclaim-lag trap

onstat -d
-- blobspace1 reports 95% used

-- But: application logs show large-object rows were deleted heavily
-- over the past week, and log backups haven't run in that time

Running the overdue log backups, rather than immediately adding disk space, may resolve this entirely — the "used" space includes a large amount of already-deleted data still waiting to be reclaimed.

Genuine growth requiring more space

onstat -d
-- blobspace1 reports 95% used

-- Log backups are current and frequent; application logs show
-- steadily growing large-object data volume with minimal deletion

Here, the official fix — allocating additional disk space — is the right response, since the reclaim mechanism isn't the bottleneck.

Diagnostic Checks

1. Check blobspace free space and usage:

   onstat -d
   

2. Check logical log backup schedule and history, and confirm it's current — this is the check that distinguishes reclaim-lag from genuine exhaustion.
3. Check for long-running transactions holding onto not-yet-freed BYTE/TEXT pages.
4. Compare actual logical data volume (rows not yet deleted) against blobspace used-space to gauge how much of the reported usage is reclaim-pending versus genuine.

Related Errors / Related Topics

• -131 — "ISAM error: no free disk space." The general dbspace-level sibling — the same space-exhaustion concern, without the specific BYTE/TEXT-page-reclaim mechanism this error introduces.
• -162 — "ISAM error: Storage space does not exist." The other blobspace-specific error in this range — a naming/existence problem rather than a capacity one.

Check log backup currency before adding disk space — a lagging backup schedule is a very common, easily fixed cause of an apparently full blobspace that doesn't actually need more capacity.