Index Corruption

Posted by byoung2735 on 29-Oct-2014 10:25

Progress 10.2b08 AIX

Occasionally receiving this error in the DB log -

IDXCHEC26: (8783)  SYSTEM ERROR: Index 1103 (PUB.address, third-ndx): couldn't find key <DIVISION><GOVERNMENT><16622733> recid 96823872

Any ideas on how to prevent it from occurring?

Thanks.

OpenEdge RDBMS - Forum

All Replies

Posted by James Palmer on 29-Oct-2014 10:35

Can't say for certain if it will fix your issue, but you may wish to look at an idxbuild on that table.

PROUTIL <dbname> -C idxbuild table address

There are other parameters to speed this up, but unfortunately I'm not 100% sure if they are available in 10.2b.

Posted by TheMadDBA on 29-Oct-2014 12:14

James: 10.2B08 does have the new multi-threaded idxbuild (think that started working in 10.2B07)

But... You might want to take a look at this KB first knowledgebase.progress.com/.../P150819

It will be much much faster than an idxbuild.

If this is happening frequently I would be worried about disk/memory issues on your AIX host.

Posted by George Potemkin on 27-Nov-2014 12:12

If the following is true:

1) Record with the specified recid does not have the keys for all indexes except for unique one (run idxfix/point 1 and scan by recid).

2) Idfxi/point 2 (with record's validation) does not find any "wrong" keys.

then it's a known bug that is NOT fixed in V10.2B08.

Workaround: use the -nosavepoint parameter to start the client's sessions.

Upd: Scenario that produces the index corruption. Application creates new record and assigns the values to the fields of an unique index. Then inside a sub-transaction it updates the database (it can be the changes in tables that are not related to the new record. Then it undoes the sub-transaction and commits the transaction. Now you have the record without index keys.

Posted by Stefan Marquardt on 28-Nov-2014 04:21

"then it's a known bug that is NOT fixed in V10.2B08 "

Shall any 10.2B08 user use option -nosavepoint by default to deactivate this new "feature" and prevent index corruption?

Posted by George Potemkin on 28-Nov-2014 06:06

If you see the 1422's in db log under V10.2B08 then I would suggest to use the -nosavepoint.

BTW, the bug is not new to SP08: the index corruptions with the same symptoms happened under V10.2B07 at least.

Bug PSC00248436 (65536: maximum number of sub-transactions) fixed in V10.2B07 also created the "corrupted" indexes but in this case idxfix/point 2 returned the errors.

This thread is closed