Re: bcheck Error: Bad B-Tree Node (####) Format???

JCHoffman wrote: > Both data file and index crash bcheck after showing the following > error > codes: > > ERROR: Bad B-Tree Node (####) Format (repeated many times before > Segmentation Fault haults the process. (####) are 4-digit numbers > (codes). > Appears only when I check one particular data/idx file. > > I've tried archiving older data from this file using SQL, but I > suspect the > corrupted index won't allow the deletion to finish. Any way to > rebuild this > index without having to roll-back the entire system? > > Appreciate any help from the Informix Gods on this one. > > Best regards, > John C. Hoffman > Taipei, Taiwan [\\] Although I've never experienced this exact problem I have run into the case where an index is so corrupted that bcheck cannot repair it. In these cases there is not much you can do except try lots of different things and pray. I've found the following things to work/help: 1) Make sure you have a good idea of how many records are in the table. Use select count(*) if you have no other way of knowing. This will be theeasiest way to see if you loose data while trying to fix the index problem. 2) Try unloading the table through isql without using the index(s). This can be done by giving no where clause or by using a field that is not in an index in the where clause. I suggest doing this first because my experience has been that when the index is so bad off that bcheck can't fix it, you usually can't drop/create it either. 3) Try unloading the data via an index to see if one of the indexes is ok. I had a case where one of my three indices on a table wash trashed and would read passed a certain point, but when I forced the select to use a different one, it read passed the point where the other index stopped. 4) Create a duplicate table as the one that's corrupt, but with a different table name. This will give a two new files in the dbname.dbs directory (ie: newfile.dat and newfile.idx). Copy badfile.dat to newfile.dat (make sure and get the tabid number correct) and then try a bcheck on it and see if you can see your data. 5) If you have only tried to becheck the bad table and index try running becheck on *.dat. Sometimes (mainly on older versions of SE) bcheck would flake if you only ran it on a specific .dat or .idx. 6) You can try to drop your index(s) through isql, but my guess is they can't be dropped. If they can, then great... rebuild and hope you haven't lost any data. It's a good idea to have a correct record count so that you can tell if you've lost a big chunk of data. Hopefully one of the above steps helps you out. You don't necessarily need to do them in the order I gave, but that is how I usually approach this type of problem. -Rob Weight robw@datapac.com