Two paths to the same parsed page. oncheck goes through a running engine and prints its view of the page; ondebug reads the chunk file offline and produces the same view without the engine. The example throughout is the second extent page of test_enc in the encryptdbs dbspace — chunk 4, page 54, holding two rows whose values are 'Informix is pure dead brill' and 'Informix runs on scotch' (both CHAR(100), so the engine pads each payload with spaces to 100 bytes).
ondebug needs the per-dbspace key to read a chunk file. Two operator-facing options:
The two flows produce identical decrypted output; the difference is purely where the key material lives at the moment ondebug runs. See ondebug CLI for the full flag set. The examples below assume one of the two options is in place.
| Task | Command |
|---|---|
| Locate table extents | oncheck -pT testdb:test_enc |
| Dump a data page | oncheck -pP 4 54 |
| Dump rows by table | oncheck -pD testdb:test_enc |
| Verify chunk consistency | oncheck -ce |
| Show dbspace properties | onstat -d |
Requires: a running engine and informix group
membership.
Produces: the engine's parsed view of the page
— header fields decoded into named columns, slot table laid
out, row payloads in their (ptr, len) extents.
| Task | Command |
|---|---|
| Locate table extents | (addressing supplied by oncheck -pT captured ahead of time, or by sysmaster query) |
| Dump a data page (oncheck-format) | ondebug -P 54 -C 4 -O \
/home/informix/data/encryptdbs |
| Save the page bytes to a file | ondebug -P 54 -C 4 \
-o page54.bin \
/home/informix/data/encryptdbs |
| Patch one byte (offline) | (see Patching examples for the full round trip) |
The engine may be down. Page size auto-detects from the chunk file
when -p is absent.
Produces: the parsed page — hex dump on stdout
(default) or the bare page bytes written to a file with -o.
The same logical page (chunk 4, page 54 of encryptdbs) seen through the engine and through ondebug. Both tools render the parsed page with the same column conventions; an operator familiar with one reads the other without translation. Detailed page-header column layouts and the slot-table byte positions are documented in the engagement-internal reference (internal).
Page 4:54 — DATA, 2 slots, free=1804
(parsed-header column layout omitted — see internal reference)
slot ptr len flg
1 <…> 104 0
2 <…> 104 0
slot 1:
… 49 6e 66 6f 72 6d 69 78 20 69 73 20 ....Informix is
… 70 75 72 65 20 64 65 61 64 20 62 72 69 6c 6c 20 pure dead brill
…
slot 2:
… 49 6e 66 6f 72 6d 69 78 20 72 75 6e ....Informix run
… 73 20 6f 6e 20 73 63 6f 74 63 68 20 20 20 20 20 s on scotch
…
The engine's view. Page header decoded into named columns and each slot's body laid out at its (ptr, len) extent. Requires the engine to be running.
Page 4:54 — DATA, 2 slots, free=1804
(parsed-header column layout omitted — see internal reference)
slot ptr len flg
1 <…> 104 0
2 <…> 104 0
slot 1:
… 49 6e 66 6f 72 6d 69 78 20 69 73 20 ....Informix is
… 70 75 72 65 20 64 65 61 64 20 62 72 69 6c 6c 20 pure dead brill
…
slot 2:
… 49 6e 66 6f 72 6d 69 78 20 72 75 6e ....Informix run
… 73 20 6f 6e 20 73 63 6f 74 63 68 20 20 20 20 20 s on scotch
…
The same page rendered in oncheck -pP's format. The parsed-header fields drift between snapshots (the engine rewrites some of them at every checkpoint); the row payloads are stable. Runs from the chunk file alone — the engine may be down.
The length-prefixed 0 0 0 1 'Informix is pure dead brill' payload at the engine's slot 1 body matches ondebug's slot 1 output. The slot table sits at the page tail and grows toward the middle as rows are added.
The same row layout in a 16-KB dbspace (test_enc_16 in encryptdbs16, chunk 7, page_size = 16 KB). The two tools use different page-numbering conventions for larger-page dbspaces: oncheck uses its own internal page index and addresses the row-holding page as 7:432; ondebug uses the dbspace's logical page number and addresses the same content as page 54. Both tools read the same bytes; they just label the page differently.
TBLspace Report for testdb:informix.test_enc_16
Pagesize (k) 16
First extent size 4
Number of pages allocated 4
Number of pages used 2
Number of data pages 1
Number of rows 2
Partition partnum 7340034
Extents
Logical Page Physical Page Size Physical Pages
0 7:424 4 32
The extent map shows the table's first physical page as 7:424; the row-holding page is the next logical 16-KB page, addressed as 7:432 by oncheck.
Page 7:432 — DATA, 2 slots (16-KB page)
(parsed-header column layout omitted — see internal reference)
slot ptr len flg
1 <…> 104 0
2 <…> 104 0
slot 1:
… 49 6e 66 6f 72 6d 69 78 20 69 73 20 ....Informix is
… 70 75 72 65 20 64 65 61 64 20 42 72 69 6c 6c 20 pure dead Brill
…
The engine's view at the engine's own page index. Calling oncheck -pP 7 54 would land on unallocated space — the engine prints "Page does not appear sane". For 16-KB dbspaces the right index to pass to oncheck is the one shown by oncheck -pT.
ondebug: auto-detected page_size=16384
Page 7:54 — DATA, 2 slots (16-KB page)
(parsed-header column layout omitted — see internal reference)
slot ptr len flg
1 <…> 104 0
2 <…> 104 0
slot 1:
… 49 6e 66 6f 72 6d 69 78 20 69 73 20 ....Informix is
… 70 75 72 65 20 64 65 61 64 20 42 72 69 6c 6c 20 pure dead Brill
…
ondebug uses the dbspace-page abstraction throughout. The -P 54 flag is the operator's mental-model page number — the 54th 16-KB block of the chunk. Auto-detect reports the recovered page size on stderr; the parsed content matches oncheck's output column-for-column.
The two tools label the address differently (7:432 vs 7:54), but the slot table and row payloads line up exactly. Same page, two labelling conventions.
For modifying a page (ondebug -w) and the round-trip back through the engine, see Patching examples.
To discuss how Oninit ® can assist please call on +1-913-732-8892 or alternatively just send an email specifying your requirements.
You get all this for free.. think about what you get if you pay us