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?
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.
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.
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.
"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?
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.