oncheck -cI

In my weekely oncheck -cI I am getting the following errors and not sure how to fix as is on a pseudo table (systabauth). Validating indexes for cars:informix.systabauth... Index tabgtor ERROR: The btree item points to a wrong rowid. Btree item contains rowid 0x17780c, key value: Key: 12731:"informix ":"chfoster ": Rowid 0x17780c contains key value: Key: 12510:"informix ":"jquinn ": Index tabgtee ERROR: The btree item points to a wrong rowid. Btree item contains rowid 0x17780c, key value: Key: 12731:"chfoster ": Rowid 0x17780c contains key value: Key: 12510:"jquinn ": Does anyone know how to resolve these errors?

jda wrote: > In my weekely oncheck -cI I am getting the following errors and not > sure how to fix as is on a pseudo table (systabauth). systabauth is not a pseudo-table; it is a real table, but it is part of the system catalog and does therefore present some potential problems. > Validating indexes for cars:informix.systabauth... > Index tabgtor > ERROR: The btree item points to a wrong rowid. > Btree item contains rowid 0x17780c, key value: > Key: 12731:"informix ":"chfoster > ": > Rowid 0x17780c contains key value: > Key: 12510:"informix ":"jquinn > ": > Index tabgtee > ERROR: The btree item points to a wrong rowid. > Btree item contains rowid 0x17780c, key value: > Key: 12731:"chfoster ": > Rowid 0x17780c contains key value: > Key: 12510:"jquinn ": So, that index on grantor is corrupted - and the one on grantee. Did you run 'oncheck' in repair mode (onmode -cI -y)? > Does anyone know how to resolve these errors? RTFM - Admin's Ref? Please include platform and version information if the problem needs to be revisited. If the repair mode can't fix it (highly unlikely given the details in the problem report), you may need to go to Tech Support for advice. Is there anything screwball in the online log file that might hint about how the mistake happened? Does either tabid 12731 or tabid 12510 contain exceptionally sensitive data? Did someone need to add 'jquinn' or 'chfoster' recently as a user - or remove one of them? Does 'informix' normally give permissions away? If so, you have a role separation problem; user informix should normally be reserved for the DB system administration functions (DBSA role), leaving a normal user - possibly created specifically for the purpose - to be the DB administrator (DBA role). It is not, however, the end of the world. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

We are running on HPUX 11i (B.11.11) and IDS 9.4 9.40.HC3. Running the oncheck -cI -y on the database did not fix the indexes, so I have put in a call to our third party software provider so they can open a call to IBM. Thanks for the help. John

jda wrote: > We are running on HPUX 11i (B.11.11) and IDS 9.4 9.40.HC3. > > Running the oncheck -cI -y on the database did not fix the indexes, Generally I don't recommend to let oncheck repair indexes, at least not larger ones. I'd rather drop bad indices after saving their schema (use dbschema with -ss option ) , then set PDQPRIORITY and ensure PDQ resources have been set properly and then recreate the index. Regards Tilman