p_union_04 running slow?
- Article Type: General
- Product: Aleph
- Product Version: 18.01
Description:
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 ****
COUNT(*)
----------
100391
Resolution:
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 ****
COUNT(*)
----------
438721
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 ****
SUBSTR(Z07_HIST COUNT(*)
--------------- ----------
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