Re: general informix wierdness

Richard (R.) Bown (rbown@bnr.co.uk) wrote: [snip] > So, in an attempt to locate the problem we start afresh with a new > table. Fresh. Add a hundred rows at a time and perform a > tbcheck inbetween. Leave this to run for a bit. Everything is > fine and then suddenly the table develops errors as above. > WARNING: Bit-Map has wrong bits set for page 1a7 (bitmap c should be 8) > BAD PAGE 1095c0: pg_stamp 1273428 != PG_STAMP2 100008446 > BAD PAGE 0: pg_addr 0 != bp->bf_pagenum 1095c1 > We wonder whether we have a configuration problem, are we set up right? > Informix don't think so; we don't. We can see ALL of our data fine from > all of the tables in the Database. The whole thing is at a maximum size > of 200MB. Not a large DB. Latest installment. This morning, just before I call Informix again, I have a look at the database we'd created on Friday. This was giving all the errors shown above. I 'tbcheck' the whole database and it doesn't return a SINGLE error. So then I try to UNLOAD two tables that have been giving us problems and it works. Harumph. I 'tbcheck' again, and it shows a few page errors as above. Try the UNLOAD once more and this time it fails with the previous error ("Unknown Error Code 0"). I checked for cron jobs to see if any magical fixer had been at work over the weekend. All I could find was a script that ran a tape backup ONLY if a tape was in the drive. There was no tape so this would have failed. Looks like it's fixed itself. As Bob Hoskins once said in 'Brazil': "Machines don't fix themselves, sir. He's TAMPERED with it, that's what he's done." I only wish. Needless to say this has confused us all even more. Now we ARE able to UNLOAD the tables, but only before the pages corrupt themselves again. When they corrupt/uncorrupt is a mystery. I have checked kernel parameters to ensure that the system has been set-up OK and to my mind everything LOOKS fine. *sigh* Rich.