Archive detects that page x:xxxxx is corrupt

Hi!, I have detected the next errors in my online.log --- 12:08:10 Archive detects that page 6:6278896 is corrupt. 12:08:10 invoke_alarm(): /bin/sh -c '/opt/informix/etc/alarmprogram.sh 5 6 "Internal Subsystem failure: 'MT'" "Archive detects that page 6:6278896 is corrupt." ' --- Then, after a lot of those lines the backup finish with: 12:11:17 Archive on rootdbs, datadbs, physdbs, datadbs2, datadbs1 Completed with 137 corrupted pages detected Like I see in the logs i have some wrong data in my chunk 6 in page 6278896. I have check and I have one Table in that chunk. If I do a select count(*) from table I get like the half of the rows I SHOULD have. I restore that backup in my development server and run oncheck -cID database:informix.table, it took like 20 minutes but no luck. I have some questions about this issue. 1) If I restore that backup in another server. Can I try fixing in that server before try in production? Or the backup is restore *without* corrupted pages? 2) Is there another way to deal with this problem? Thanks in advice and sorry about my really bad English. -- Emiliano Romero Proyect Leader IT Sitrack.com This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.

I run oncheck -cID in the production enviroment and get the following: Validating indexes for db:informix.table... Index 146_117 Index fragment partition datadbs1 in DBspace datadbs1 Could not bfget pagenum 0x138374, iserrno 105 ISAM error: bad isam file format. ERROR: Index 146_117 for db:informix.table is bad. Index idx_chst Index fragment partition datadbs1 in DBspace datadbs1 Is that error being fixed with oncheck utility? Regards Emiliano Romero wrote: > Hi!, I have detected the next errors in my online.log > --- > 12:08:10 Archive detects that page 6:6278896 is corrupt. > 12:08:10 invoke_alarm(): /bin/sh -c '/opt/informix/etc/alarmprogram.sh > 5 6 "Internal Subsystem failure: 'MT'" "Archive detects that page > 6:6278896 is corrupt." ' > --- > Then, after a lot of those lines the backup finish with: > 12:11:17 Archive on rootdbs, datadbs, physdbs, datadbs2, datadbs1 > Completed with 137 corrupted pages detected > > Like I see in the logs i have some wrong data in my chunk 6 in page > 6278896. I have check and I have one Table in that chunk. If I do a > select count(*) from table I get like the half of the rows I SHOULD have.> > I restore that backup in my development server and run oncheck -cID > database:informix.table, it took like 20 minutes but no luck. > > I have some questions about this issue. > 1) If I restore that backup in another server. Can I try fixing in that > server before try in production? Or the backup is restore *without* > corrupted pages? > 2) Is there another way to deal with this problem? > > Thanks in advice and sorry about my really bad English. > > This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.

Emiliano Romero wrote: > I run oncheck -cID in the production enviroment and get the following: > Validating indexes for db:informix.table... > > Index 146_117 > > Index fragment partition datadbs1 in DBspace datadbs1 > Could not bfget pagenum 0x138374, iserrno 105 > ISAM error: bad isam file format. > ERROR: Index 146_117 for db:informix.table is bad.> > Index idx_chst > > Index fragment partition datadbs1 in DBspace datadbs1 > > Is that error being fixed with oncheck utility? oncheck should as you something liek 'Ok to repair?' if it did and you answered yes , it will have dropped and recreated the index, the corruption will be gone then. However, if you di not answer y or yes, it is probably still bad. In that case I suggest to not use oncheck to repair the corrupt index but to drop it and recreate it maually (with PDQPRIORITY set to 100 and loads od DS_TOTAL_MEMORY configured (up 90 % of SHMVIRTSIZE) ... >> Then, after a lot of those lines the backup finish with: >> 12:11:17 Archive on rootdbs, datadbs, physdbs, datadbs2, datadbs1 >> Completed with 137 corrupted pages detected >> >> Like I see in the logs i have some wrong data in my chunk 6 in page >> 6278896. I have check and I have one Table in that chunk. If I do a >> select count(*) from table I get like the half of the rows I SHOULD have.>> >> I restore that backup in my development server and run oncheck -cID >> database:informix.table, it took like 20 minutes but no luck. What you mean No luck : oncheckk did not finish or not reprot any errors? >> >> I have some questions about this issue. >> 1) If I restore that backup in another server. Can I try fixing in that >> server before try in production? Or the backup is restore *without* >> corrupted pages? >> 2) Is there another way to deal with this problem? I'd try and drop the bad index of the table - it seems to be bad. Afterwards run oncheck -cD <database>:<table> Doe it still report errors ? if not , go recreate the index (i hope you saved the schema beforehand with dbschema -d <db> -ss -t <table> If yes - try to find the nature AND root cause of the corruption . IBM Informix Tech support can help. Also hae a look at the af-files in case any got generate dduring archive or when accessing the bad pages. >> >> Thanks in advice and sorry about my really bad English. >> >>

Thanks!, I have remove the index with: alter table <table> DROP CONSTRAINT <uxxx_xxx> and then just recreate with: alter table <table> ADD CONSTRAINT PRIMARY KEY (<tableid>) It took like 1 hour to recreate the index, but now it works perfect. I just have to add more space for physical logs because my DB is "NO LOGGING". Thanks for your help. Regards Emiliano Romero tilleul17@web.de wrote: > Emiliano Romero wrote: > >> I run oncheck -cID in the production enviroment and get the following: >> Validating indexes for db:informix.table... >> >> Index 146_117 >> >> Index fragment partition datadbs1 in DBspace datadbs1 >> Could not bfget pagenum 0x138374, iserrno 105 >> ISAM error: bad isam file format. >> ERROR: Index 146_117 for db:informix.table is bad.>> >> Index idx_chst >> >> Index fragment partition datadbs1 in DBspace datadbs1 >> >> Is that error being fixed with oncheck utility? >> > > oncheck should as you something liek 'Ok to repair?' > if it did and you answered yes , it will have dropped and recreated the > index, the corruption will be gone then. > However, if you di not answer y or yes, it is probably still bad. In > that case I suggest to not use oncheck to repair the corrupt index but > to drop it and recreate it maually (with PDQPRIORITY set to 100 and > loads od DS_TOTAL_MEMORY configured (up 90 % of SHMVIRTSIZE) > > .... > > >>> Then, after a lot of those lines the backup finish with: >>> 12:11:17 Archive on rootdbs, datadbs, physdbs, datadbs2, datadbs1 >>> Completed with 137 corrupted pages detected >>> >>> Like I see in the logs i have some wrong data in my chunk 6 in page >>> 6278896. I have check and I have one Table in that chunk. If I do a >>> select count(*) from table I get like the half of the rows I SHOULD have.>>> >>> I restore that backup in my development server and run oncheck -cID >>> database:informix.table, it took like 20 minutes but no luck. >>> > > What you mean No luck : oncheckk did not finish or not reprot any errors? > >>> I have some questions about this issue. >>> 1) If I restore that backup in another server. Can I try fixing in that >>> server before try in production? Or the backup is restore *without* >>> corrupted pages? >>> > > >>> 2) Is there another way to deal with this problem? >>> > > I'd try and drop the bad index of the table - it seems to be bad. > Afterwards run oncheck -cD <database>:<table> > Doe it still report errors ? > if not , go recreate the index (i hope you saved the schema beforehand > with dbschema -d <db> -ss -t <table> > > If yes - try to find the nature AND root cause of the corruption . > IBM Informix Tech support can help. > Also hae a look at the af-files in case any got generate dduring archive > or when accessing the bad pages. > > >>> Thanks in advice and sorry about my really bad English. >>> >>> >>> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > This email and any attachments thereof may contain confidential, privileged, proprietary, or otherwise private information. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of the email and its attachments please inform the sender immediately and do not disclose the contents to any other person, use it for any purpose or store or copy the information in any way and delete this e-mail and its attachments from your system. Any views or opinions expressed are solely those of the author.