Re: message log question
Posted in 1994
In article <2nsb6g$me5@emory.mathcs.emory.edu>, inf_bb@hermes1.sps.mot.com (Bob Baskett) says:
>
>netters,
>
>im running a 4gl program that reads from db1:tab1 and inserts data into
>db2:tab1,...,db2:tab4. the program is not reporting any errors on the
>inserts,fetches,etc. but the logfile is recording the following:
>
>10:56:06 On-Line Mode
>11:04:35 bfcheck: bad page: pg_addr 0 != bp->bf_pagenum 120adea, userp = 100022a8, pid = 14118, uid = 1060
>11:04:35 buffer header:
>11:04:35 10926334: 00000000 00000000 09600000 108f843c ........ .`.....<
>11:04:35 10926344: 108f843c 100003d0 10926974 00020000 ...<.... ..it....
>11:04:35 10926354: 010a0000 0120adea 10cbd800 00000000 ..... .. ........
>11:04:35 10926364: 00000000 00010000 109b0f44 01000000 ........ ...D....
>11:04:35 page header:
>11:04:35 10cbd800: 00000000 00000000 00000000 00000000 ........ ........
>11:04:35 10cbd810: 00000000 00000000 ........
>11:04:35 slot table and stamp:
>11:04:35 10cbdffc: 00000000 ....
>11:04:35 -- Fail Consistency Check -- btsearch:bad btree node -- pid=14118 user=1060 us=100022a8>
>im was the only one using this instance at the time. the dba manul states:
>
>"These messages have meaning to Informix technical support personnel. Please
>contact Informix Tech Support for additional assistance resolving this
>situation."
>
>anyone from informix want to comment before i make a call?
>
I'm not from Informix, but I'll give it a crack...
The last line, including "bad btree node", indicates that the problem is in an index.
The hex zeroes under page header: are what was read from disk.
In the second line, bf_pagenum 0x120adea, decodes, I believe to
chunk 18 decimal, page 44522 decimal. This conversion involves taking the
lower order 5 hex digits as the page offset within the chunk, and the 3 high
order hex digits as the chunk number. Use tbcheck -pe to see what table
occupies that page offset within that chunk.
Try tbcheck -pP 18 44522 and see what happens.
Problem diagnosis:
If the problem is NOT repeatable, then you have
bad hardware or OS software. (Note: We've seen similar on Pyramid,
that was not repeatable, but would go away completely after a
reboot).
If the problem IS repeatable, then you have a page that has been zeroed.
Either way, Informix will tell you to reload the last known good archive.
If you want to make it go away, merely dropping and rebuilding all
indexes on the table will rewrite the page.
Please let us know here what Informix says, and what you finally
determine the problem is.
Jim Burks jburks@promus.com
Database Administrator
The Promus Companies
Memphis, TN USA