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

    p_union_04 running slow?

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

    There are 100391 z120 records that need to be processed by p_union_04; this is up 30,000 from yesterday at around the same time. The p_union_04 job is kicked off at 11:45 at night and we usually let it run till about 12 noon the next day. Our IT staff believe it is running slow though there is no proof of this, as I don't know a way to see how many records its processing an hour. Nor do I know how many records are being inputed. Is there a way? Is it running slow? do we have to just let this run?

    Below is the SQL output.

    abc01@ABCU16> select count (*) from z120 where z120_update_flag = 'N';
    **** Hit return to continue ****


    p_union_04 processes the z120's with an z120_update_status of "N", checking to see if the z120_rec_key_1 (preferred_doc_number) needs to be updated.

    As noted in KB 5335, the z120_update_flag is changed to "N" by ue_01. This SQL shows a large number of z07's waiting to be processed by ue_01:

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


    The sources of z07's are discussed in KB 4093. Running the SQL from that KB we see:

    abc01@ABCU16> select substr (z07_history, 1,5), count(*) from z07 group by substr (z07_history, 1,5);
    **** Hit return to continue ****

    --------------- ----------
    ABC01 187661
    ABC50 248379
    ABC60 2152

    Checking $alephe_scratch, I see numerous p_manage_18, p_manage_50, p_manage_37, and p_manage_33 jobs -- all of which generate z07's (and z120 updates).

    I find that ue_01 is processing the z07's at the (good) rate of 1/second. This is 86,000 per day. If the aforementioned batch jobs were to stop writing z07's, the queue of 438,000 would be processed in 5 days.

    • Article last edited: 10/8/2013