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

    ue_01 running wild!

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

    We re-indexed over Thanksgiving Holiday. Now the ue_01 abc01 background process is continually running creating numerous ORACLE archive log files daily, clogging our "normal" RMAN ORACLE backups and is usually taking up about 10% of the CPU processing.

    We thought that if we let it run for a while it would catch up, but it is going on a week and a half. Please check to see if this is "normal".

    What is causing this? Is it a serious problem? How can we fix it?

    ue_01 processes z07 records. Large amounts of ue_01 activity are the result of large numbers of z07's.

    KB's 4093 and 8192-6521 describe reasons for large numbers of z07's.

    In this case, I see some very large abc01 $data_scratch ue_08 logs from Nov. 27 and 28:

    -rw-rw-r-- 1 aleph exlibris 500132763 Nov 27 03:01 run_e_08.16461
    -rw-r--r-- 1 aleph exlibris 153543558 Nov 27 10:21 run_e_08.25019
    -rw-rw-r-- 1 aleph exlibris 211298858 Nov 28 03:01 run_e_08.28851

    These ue_08's produced a total of 5.6 million z07's:

    ajax1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.16461
    ajax1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.25019
    ajax1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.28851

    We see that all but 964,829 of these have been processed:

    abc01@ALEPH1> select count(*) from z07;
    **** Hit return to continue ****


    Using the SQL in KB 8192-6521, we find that *all* of the current z07's were created by ue_08 (that is, there are no Z07s back-dated to 199n, indicating processing by GUI Cataloging, oclc_server, etc.):

    abc01@ALEPH1> select count(*) from z07 where substr (z07_sequence,1,4) < '2007';
    **** Hit return to continue ****


    Thus, you should feel free to drop/create the abc01 z07, as suggested in KB 8192-6521.

    What caused all the ue_08 activity? One possibility is starting ue_08 with CHECK-OPTION "N" or "R" -- which you should never do without consulting Ex Libris Support. But this grep shows that *that* is not the case:

    >>grep CHECK-OPTION *e_08*
    run_e_08.10005:CHECK-OPTION: C
    run_e_08.11419:CHECK-OPTION: C
    run_e_08.11952:CHECK-OPTION: C
    run_e_08.12717:CHECK-OPTION: C
    run_e_08.14168:CHECK-OPTION: C
    run_e_08.15278:CHECK-OPTION: C
    run_e_08.15506:CHECK-OPTION: C
    run_e_08.16461:CHECK-OPTION: C

    One trigger for bib ue_08 activity is updating of bib z01 records to "z01_rec_key_4 -NEW-..." by ue_11 (resulting from authority record updates). But the abc50 $z105_library ue_11 logs don't show any large activity.

    I see (in $alephe_scratch) that a bib p_manage_02 was run on Nov. 24. Though it was preceded by p_manage_102, I see from setenv's at the beginning of the log that p_force_chk is set to "N".

    The effect of this is that *all* of the headings created by p_manage_02 will have "z01_rec_key_4 -NEW-...", which means that they *all* will need to be processed by ue_08.

    When p_manage_02 is preceded by p_manage_102, you should specify "Y" for Force Check. (Note: The p_duplicate_mode, in contrast, should always be "N".) These settings are described in section 2.3 of the "How To Run Index Jobs".

    • Article last edited: 10/8/2013