Re: bfcheck: bad page

In article <23sdifINNm35@emory.mathcs.emory.edu> atina!lucas.MREC.AR!alex@uunet.UU.NET (Maria Alejandra Perez Weiss) writes: > >I need suggestions on what to do with a Fail Consistency Check error > >This is the message I received > >Date: 05/08/93 Time: 10:51:15 >Program error at "rec_conj.4gl", line number 768. >SQL statement error number -242. >Could not open database table (sic.auxitem). >SYSTEM error number -105. >ISAM error: bad isam file format. Oh, voila, there it is again. that's it, friends, that's what I was trying to tell you, that was the error I got, too. And I think, I solved it in-between, it costet me a full week (with days + nights), but I have cut down the program and cut it down more and isolated the error more and more and now it _seems_ to be trapped. Isolating the error has been very hard for me: 1.) it always killed a table which didn't participate in the transaction, so looking up all pieces where your auxitem needn't be successful. 2.) The error didn't show up until the next checkpoint was reached, and after the checkpoint there had to be there a select on the vanishing table 3.) The SE Version works without problems 4.) The whole database is not operable afterwards, because the vanished table is still there, in systables, and thus can't be dropped separately. It also can't be renamed, but it is gone, so you have to reinstall the database. The dropping of the tablespace can be redone by rolling forward the database, so be aware of the log tapes you are giving it. I almost lost my mind about it and all people told me they didn't have that problem, although many of them helped me by showing sympathy... The error doesn't show up, if you make a complete redesign of your transaction and cursor strategy: Say BEGIN WORK only very short before you enter your UPDATE/DELETE/INSERT-Statement, and then immediately COMMIT or ROLLBACK. Open all non-update-CURSORs outside of your transactions. That's what I did, and it crashed three times a day before and didn't crash for two full days since the change. And those are the only things I had to change to make the error go away (two fingers crossed, of course, but I'm not superstitious ;-) >The weird thing here is that sic.auxitem is the name of a temp table >which is created and dropped by the 4gl process. No, it isn't dropped any more, see above. It can't be dropped and thus can't be a normal temp table thus. >It'd happened once, 3 months ago but now it's appeared 3 times during >last week. >bfcheck: bad page: pg_flags 0 != type 2, userp = 80401bf4, pid = 11953, uid = 2240 >buffer header: >8043b2bc: 00000000 00000000 bc7b4380 bc7b4380 ........ .{C..{C. >8043b2cc: dc034080 3cba4380 02000000 090c0000 ..@.<.C. ........ Can you read that? I can't. >-- Fail Consistency Check -- pthdrpage:ptalloc:bad partn page -- pid=11953 user=2240 us=80401bf4 that's the interesting line, same with me. To me it says, I'm innocent, that's what the server did to the tablespace, not me. And there is no SQL-Command "RUIN TABLE" ;-)) There has to be a dangling pointer in the shared memory area. >Any ideas welcomed. >Please contact me by e-mail, I'm not reading the list by now. I'll send it to you by e-Mail, but I'll also post that spooky thing to the list, because there have been so many nice people trying to help me, I feel the need to say thank you all, especially to Garrett Sienkiewicz <garrett@data-design.com> Graeme Sargent <graeme@pyra.co.uk> inf_bb@hermes1.sps.mot.com (Bob Baskett) Sandor.Szabo@mch.sni.de adkins@tfs.COM (Kerry Adkins) porter@vincere.muc.de (Brian Porter) Regards, svb. -- Sebastian v. Bomhard, +49-89-298934, +49-89-296629 <svb@muc.de> St.-Anna-Str. 13, D-80538 Muenchen (Lehel) >>>>>>>>>>> The early bird catches the EARLY worm. <<<<<<<<<<<<