big problem.

good morning. excuse me for my poor english. i have informix rapid on sco unix, some days ago, a dat file was near of 2 gb and i deleted some records and after i alter table (a decimal (3,0) to (4,0) and after another time to (3,0)) to compact the dat file. that was right. when i was doing the alter table, i saw that the filesystem was near of 98% and i pass 3 dat files of the database directory to may computer and when the alter table was made i put the dat files in the database directoy. After that one of the tables (an important table) does not work well, there are records that the query instructions not found. i have made a bcheck -y but it doesnt work well. can anybody help me. thanks a lot.

Juanito wrote: > good morning. > excuse me for my poor english. > i have informix rapid on sco unix, some days ago, a dat file was near of 2 > gb and i deleted some records and after i alter table (a decimal (3,0) to > (4,0) and after another time to (3,0)) to compact the dat file. > that was right. > when i was doing the alter table, i saw that the filesystem was near of 98% > and i pass 3 dat files of the database directory to may computer and when > the alter table was made i put the dat files in the database directoy. > After that one of the tables (an important table) does not work well, there > are records that the query instructions not found. i have made a bcheck -y > but it doesnt work well. > can anybody help me. > thanks a lot. Interpreting a bit... You have an SCO system that is running Informix SE in some version older than 7.25, and you might also be using Informix-4GL Rapid Development System, I4GL-RDS. You had some data files that grew close to the old 2GB file size limit. So, to rebuild the table, you did a pair of ALTER TABLE operations. After doing this, you have some problems, and bcheck (predecessor to secheck - it sounds like a rather old version of SE) is not able to fix the issues. This is going to be painful to sort out. However, the first question is: do you have a good backup? If so, keep it carefully. If not, now is a good time to remind yourself why backups are recommended. How much space do you have on your disk? Make a copy of the database if you've got the space. Work on the copy - not the original. Or work on the original and not the copy. Don't work on both. When you say bcheck doesn't work well, what happens? Do you know if the index file is more or less OK, or is it corrupted? Do you have the database schema? How many indexes are on that table? If the index is corrupted, then the best thing may be to create a new table with the same structure as the old, then copy the new index file over the old. Then run bcheck on that. It will say there are a gazillion records not in the index - that's correct. But it might be able to rebuild the index(es). Is the data corrupted? We might need to analyze the data file, using the record size plus one, looking at the last byte. That should be either '\\n' for a current record, or '\\0' for a deleted record. If you see other values, your file is either corrupt or you've got the wrong record size. If you find the file is looking semi-decent, then the data can probably be recovered. If you find some inconsistency - the first half of the file is OK and the second is not, for example - then we probably need to go to the backup. If you don't have a backup, then we'll have to salvage what there is, piecemeal if necessary. You do have the schema - that should make it possible to resolve the issues, but it might take some inventiveness. It would be easier to go to the backup. And maybe upgrae to a platform that supports files bigger than 2 GB, so you can upgrade to a version of SE that supports files bigger than 2 GB, so you don't have to panic about it again. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-3781 whirlpool 2008-07-21 03:00:04 DEC8C3320912C407966BD402FCB444B762BD4A30D242434B6683A62ECBEB473903EB84 2F933D04D6D5A5CA6FC5272C7BB9477E2EF8248B9D76BD892FFBCA07D

i have the .dat file of a backup. can i do something with that? "Jonathan Leffler" <jleffler@earthlink.net> escribi' en el mensaje news:86OdnbRMGJFpvBnVnZ2dnUVZ_i2dnZ2d@earthlink.com... > Juanito wrote: >> good morning. >> excuse me for my poor english. >> i have informix rapid on sco unix, some days ago, a dat file was near of >> 2 gb and i deleted some records and after i alter table (a decimal (3,0) >> to (4,0) and after another time to (3,0)) to compact the dat file. >> that was right. >> when i was doing the alter table, i saw that the filesystem was near of >> 98% and i pass 3 dat files of the database directory to may computer and >> when the alter table was made i put the dat files in the database >> directoy. >> After that one of the tables (an important table) does not work well, >> there are records that the query instructions not found. i have made a >> bcheck -y but it doesnt work well. >> can anybody help me. >> thanks a lot. > > > Interpreting a bit... > > You have an SCO system that is running Informix SE in some version older > than 7.25, and you might also be using Informix-4GL Rapid Development > System, I4GL-RDS. > > You had some data files that grew close to the old 2GB file size limit. > So, to rebuild the table, you did a pair of ALTER TABLE operations. > > After doing this, you have some problems, and bcheck (predecessor to > secheck - it sounds like a rather old version of SE) is not able to fix > the issues. > > This is going to be painful to sort out. However, the first question is: > do you have a good backup? If so, keep it carefully. If not, now is a > good time to remind yourself why backups are recommended. > > How much space do you have on your disk? Make a copy of the database if > you've got the space. Work on the copy - not the original. Or work on > the original and not the copy. Don't work on both. > > When you say bcheck doesn't work well, what happens? Do you know if the > index file is more or less OK, or is it corrupted? Do you have the > database schema? How many indexes are on that table? > > If the index is corrupted, then the best thing may be to create a new > table with the same structure as the old, then copy the new index file > over the old. Then run bcheck on that. It will say there are a gazillion > records not in the index - that's correct. But it might be able to > rebuild the index(es). > > Is the data corrupted? We might need to analyze the data file, using the > record size plus one, looking at the last byte. That should be either > '\\n' for a current record, or '\\0' for a deleted record. If you see other > values, your file is either corrupt or you've got the wrong record size. > If you find the file is looking semi-decent, then the data can probably be > recovered. If you find some inconsistency - the first half of the file is > OK and the second is not, for example - then we probably need to go to the > backup. If you don't have a backup, then we'll have to salvage what there > is, piecemeal if necessary. You do have the schema - that should make it > possible to resolve the issues, but it might take some inventiveness. > > It would be easier to go to the backup. > > And maybe upgrae to a platform that supports files bigger than 2 GB, so > you can upgrade to a version of SE that supports files bigger than 2 GB, > so you don't have to panic about it again. > > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ > > publictimestamp.org/ptb/PTB-3781 whirlpool 2008-07-21 03:00:04 > DEC8C3320912C407966BD402FCB444B762BD4A30D242434B6683A62ECBEB473903EB84 > 2F933D04D6D5A5CA6FC5272C7BB9477E2EF8248B9D76BD892FFBCA07D