Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    xxx01 util g/ counters not updated after parallel indexing

    • 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.

    Additional Information

    Data for this sample case:

    xxx03 util g/2::
    2. last-acc-number 158437529
    11. last-word-number 54338235

    xxx01 util g/2:
    2. last-acc-number 111964894
    11. last-word-number 61846123

    xxx03@ALEPH21> select max (Z01_ACC_SEQUENCE) from z01;
    MAX(Z01_A
    ---------
    158437529

    xxx03@ALEPH21> select max (Z97_REC_NUMBER) from z97;
    MAX(Z97_R
    ---------
    061846123
    ...
    ...

    This is confirmed by the following SQL which shows that headings added today (2014-03-18) have been given numbers in this lower range:

    xxx01@ALEPH21> select Z01_ACC_SEQUENCE, Z01_OPEN_DATE from z01 where Z01_ACC_SEQUENCE < '111964894' and Z01_ACC_SEQUENCE > '111964800' order by Z01_ACC_SEQUENCE desc;

    Z01_ACC_S Z01_OPEN_DATE
    --------- -------------
    111964893 20140318
    111964892 20140318
    111964891 20140318
    111964890 20140318
    111964889 20140318
    111964888 20140318
    111964887 20140318
    111964886 20140318
    111964885 20140318
    111964884 20140318
    111964883 20140318
    <etc.>


    • Article last edited: 3/26/2014