ue_01 running wild!

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
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?

Resolution:
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
3481918
ajax1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.25019
589929
ajax1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.28851
1559369

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

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

COUNT(*)
----------
964829

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 ****

COUNT(*)
----------
0

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