• Article Type: General
• Product: Aleph
• Product Version: 20

Problem Symptoms:
After running manage_01 (Words Index Build), manage_102 (Pre-Enrich Bibliographic Headings), and manage_02 (Update Headings Index), the util g/2 counters in the actual library (xxx01) were not updated with the values from the parallel library (xxx03), This seems to be resulting in "unique constraint violated" messages for the z01 (Headings index) in the ./xxx01/scratch/run_e_01 log.

Cause:
Failure to copy the updated util g/2 values from xxx03 to xxx01, as described in Step 10 of the Parallel Indexing document.

Resolution:
This could have resulted in the Headings or Words counters being off.

1. The critical values for these indexes are the last-acc-number (for Headings) and the last-word-number (for Words).

2. These values need to be higher then the highest value for the fields which they are controlling. In the case of the last-acc-number, this is the Z01_ACC_SEQUENCE; in the case of the last-word-number, the Z97-RECORD-NUMBER.

The following SQL can be used to obtain the relevant values:

SQL> select max (Z97_REC_NUMBER) from z97;

3. In this instance, the last-word-number is (correctly) >= than the max (Z97_REC_NUMBER);

Thus, the last-word-number is in synch with the max (Z97-RECORD-NUMBER) and the word-numbers being assigned are OK.

But

SQL> select max (Z01_ACC_SEQUENCE) from z01;

shows that last-acc-number is < than max (Z01_ACC_SEQUENCE).

4. Thus, the last-acc-number is *not* in synch with the max (Z01_ACC_SEQUENCE): it's lower. The effect of this is that new headings which have been added since the rebuilt z01/z02 was implemented have been assigned numbers already in use by other headings, which means that they overwrote those existing z01 (Headings) records.

This is confirmed by the following SQL which shows that newly-added headings have been given numbers in this lower range:

xxx03@ALEPH21> select Z01_ACC_SEQUENCE, Z01_OPEN_DATE from z01 where Z01_ACC_SEQUENCE < 'nnnnnn894' and Z01_ACC_SEQUENCE > 'nnnnn800' order by Z01_ACC_SEQUENCE desc;

5a. Correcting the last-acc-number in the xxx01 util g/2 to a value higher than the max (Z01_ACC_SEQUENCE) (-- which, of course, is changing all the time) will prevent further damage but will not correct the damage already done.

5b. The only way to correct this is to re-run manage-102 and manage-02. As described in Article 000022146 ("What library to use for indexing table already in parallel library?"), these should be run in the xxx02 library, so as to not interfere with the currently-in-use xxx03 Headings.