Kbase 17995: SYSTEM ERROR: Index Add returned with error in idxfix (5154)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/06/1998 |
|
SYSTEM ERROR: Index Add returned with error in idxfix (5154)
The idxfix utility can be used to build indexes from existing ones. We
can achieve this by activating a nonword index with option 2 for each
of the tables we are working on, and then using option 5 in the
idxfix option menu to build the remaining indexes in the table from
the index we had activated earlier. This option prompts you for the
table name and the index (the primary, for example) from which you
want to build the remaining indexes in the table. This can be done on
several tables online simultaneously so it provides a method for
building indexes with a multithreaded process. This luxury was never
available to us with the traditional proutil idxbuild.
Idxfix uses ixgen to generate a new entry to an index. Throughout
this process we have to format and build index keys which contain the
fields for the index. We are also checking the index for consistency
with the index anchor table, and we do this comparison every time an
action takes place on the index. The keys in the indexes are compared
with the keys in the records, and this explains the comment on page
5-129 of the Sytem Administration Reference for Version 8.2. At the
conclusion of number 5 we mention that the source index for building
the others cannot be a word index, and this is because word indexes
allow duplicate keys. Basically, if we find an index key that does not
exist in the record, then we delete the entry from the index. That is
the real "fixing" that we are doing here.
The rest of this process involves the retrieval of records and the
validation of their keys with the index. If during the search for a
key within the index we find a duplicate key, we see the following
message:
SYSTEM ERROR: Index Add returned with error <error number> in the
index fix utility. (5154)
NOTE: In the past the workaround for a duplicate key was to modify the
record, however since we get no specific information about where the
duplicate key is in this instance we are unable to modify it. It would
be a good idea to either bite the bullet here and do the index rebuild
for this table or run the idxcheck utility with the hope of getting
more specific information about the location of the duplicate key.
Although this is a great tool for building indexes from others and
can be run as a multithreaded process, it is not useful in compressing
them so you will not see any improvements in your % utilization
numbers for index blocks. This utility WILL find corruption within the
indexes it is run against and delete any bogus entries as it finds
them.
NOTE: When performed online idxfix will not activate the indexes that
it builds from the source index. A full database scan with the idxfix
utility (option 2) will reactivate all the indexes it scans and this
must be run OFFLINE to reactivate them.
REFERENCES TO WRITTEN DOCUMENTATION:
System Administration Reference 5-128 through 5-130
SDA 6/3/98