Re: Jonathan Leffler/Informix HELP!

Well, you've probably already fixed this (probably by restoring an archive), but just in case I can still help... David Williams (djw@smooth1.demon.co.uk) wrote: : tbcheck -cr find no errors. Well, this means that the first 12 pages of your root chunk 1 are okay, but that's all it means. : 16:57:46 bfcheck: bad page: pg_addr 0 != bp->bf_pagenum 300004, userp = Try this: tbcheck -pP 3 4 If it returns a page header that is all 0's (address 0, timestamp 0, etc) then you are really in trouble (someone has written 0's or garbage over all your nice clean Informix data). That's what the error is saying. I only say to run the tbcheck in case there is some weird Informix or OS bug that is causing your page to be trashed in memory, but it's still okay on disk. I have to say this is somewhat of a longshot. Chances are that you'll get output something like pg_addr timestamp nslots flags 0 0 0 0 which means someone dumped a bunch of zero's where you used to have data. : Informix Tech. Support just said restore from backup and move the root : dbspace somewhere else - onto a cooked filesystem. Actually, this looks like it's dbspace 3 that's corrupt, not root dbspace. Is your database yyyy (the one you couldn't open) in dbspace 3? If so, then that's your problem dbspace, not root. That's the one you should move. : If I restore then I risk corrupting other applications which are not my : companies. Hmmm. Well, that seems quite possible, since it would appear that they wrote all over your disk space. You could try dumping out some of the data on the device and see what's there. Find out what device dbspace 3 is on. If you don't remember, tbstat -d might still work, or try tbcheck -pr, which will print info on your dbspaces and chunks from the reserved pages, which appear to be unaffected. Then, given the pathname, dd if=<pathname> of=/tmp/fubar bs=2k count=100 will dump out 100 pages (or 200k) of the dbspace. (You did say you were on Solaris, didn't you? I deleted it... Anyway, this will work on any 2k buffsize machine -- if you have a 4k buffsize, change bs to 4k.) Run strings or od -c on the /tmp/fubar file, and see if you can figure out what it is. : Surely there must be a way to find out what is overlapping? The engineer : was not surprised that tbcheck seg faulted! Surely this is a bug in : tbcheck??? Well, no. tbcheck is meant to read OnLine pages. It really doesn't know what to do with all the garbage it's finding in your disk pages. : All chunks are flags as PO i.e. online surely this is wrong if dbspace : 3 cannot be opened?? OnLine marks a dbspace as "Off-line" if it returns an I/O error. In this case, you aren't getting an I/O error, it's just finding a lot of stuff it doesn't recognize. I guess it doesn't consider that a reason to mark your chunk off-line. Sorry I don't have any better news for you. June ---- June Tong Informix Software ---- ---- Senior Consultant (415) 926-6140 ---- ---- International Support junet@informix.com ---- ---- Location-du-jour: Oakland ---- * * Standard disclaimers apply * - Please do not send me requests/questions by mail. When I have the knowledge - and time permits, I try to answer questions on comp.databases.informix, but - travel schedule, time, and volume make responding to personal requests - difficult and often slow. Please call your local Informix Technical Support - organization for assistance with technical issues.