Oninit® Forensic Tools — Offline dbspace removal

Surgical removal of a single dbspace from an Informix® rootdbs chunk file, performed offline against a disk image of the chunk — no onspaces -d, no sysmaster cooperation, no running engine required. The operation is part of the Oninit® forensic services portfolio; it lives alongside the offline patching recipe and shares the same operational posture (engine quiesced, chunk file in hand, edit, verify on next startup).

For a concrete step-by-step run-through, see Examples — dropping a dbspace.

When you'd need this

The common case is recovery from an engine that won't come up because one dbspace is unhealthy — underlying chunk file missing, storage pulled, dbspace marked invalid in a partial backup restore, test dbspace left behind that prevents production startup, or any state that makes the engine fail initialisation. The engine's own onspaces -d needs a running instance; if the instance can't start, the standard remediation path is closed and a forensic edit becomes the alternative.

Less common but legitimate: a captured chunk-image dataset where the analyst wants to walk the post-removal state of the dbspace catalog without affecting production. The offline edit produces a verifiable image that an analyst host can mount and inspect.

What the operation does

At a high level, the operation amends rootdbs so the engine no longer believes the target dbspace exists. After the edit:

• The target dbspace is absent from onstat -d on next engine startup.
• The chunks that were owned by the dbspace are also absent from onstat -d's chunk listing.
• All other dbspaces retain their original dbspace numbers and chunk assignments — the operation removes, it does not renumber.
• The engine starts cleanly and proceeds with the remaining dbspaces.

Verification is unambiguous: bring the engine up against the edited rootdbs and read onstat -d. If the target dbsnum is no longer listed and the remaining dbspaces are intact, the operation succeeded; if startup fails, the edited image is discarded and the pre-edit backup is restored.

Constraints

• The engine must be offline. Editing rootdbs while the engine has it open invites torn writes and is unsupported. Standard practice is to take an image of rootdbs with the engine stopped, edit the image, then put the edited image back in place before restarting.
• rootdbs itself cannot be removed. The engine has no concept of an instance without rootdbs; the operation refuses to target it.
• The physical-log dbspace cannot be removed. The physical log is part of the engine's crash-recovery substrate; removing it would break recovery on next checkpoint. The operation refuses to target a dbspace carrying the physical-log marker.
• Mandatory pre-edit backup. The image of rootdbs being edited is copied to a timestamped backup before any bytes are written. The rollback path is a straight file copy from the backup; the offline edit has no engine-side transactional undo.
• Engagement-scoped. Offline modification of rootdbs is invasive and irreversible at the engine layer once the engine has restarted on the edited image. We perform this operation as part of a recovery engagement with explicit sign-off, not as a self-service customer-side script.

What this operation does not do

• It does not delete chunk files. The chunk files on disk that backed the removed dbspace are left in place. Deletion is a separate decision once the engine is confirmed running without the dbspace; the operation leaves the files alone so the operator retains a recovery image if the removal needs to be reconsidered.
• It does not touch sysmaster. The sysmaster:sysdbspaces / syschunks views are engine-managed; they reflect post-startup state. After the engine starts with the dbspace absent, these catalogs will already not list it.
• It does not reclaim space. The pages formerly backing the removed dbspace's chunks remain marked as belonging to those chunks at the bitmap layer; the byte ranges become "abandoned" from the engine's point of view. Returning those pages to the free pool is a separate follow-on operation.
• It does not migrate or preserve data. Any rows or indexes that lived in the removed dbspace are gone. If preserving the contents matters, run onunload or a row-level export before the removal — once the dbspace is absent from the catalog, the rows are unreachable.

Talk to us

This operation is engagement-only. If you have an engine that won't come up because of a damaged or undesired dbspace and you need it amputated cleanly, get in touch — we'll take a quiesced rootdbs image, do the surgery, verify the post-edit image against the engine, and hand you back a startable instance. The operation is reversible up to the moment the engine starts on the edited image; after that point, the rollback path is restoring the pre-edit backup before the engine writes new state.