p_manage_34 executing for a long time

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

Description:
The p_manage_34 job which was submitted Monday night is still running as of this morning (Mar. 10, 2004). We had the same problem as describe in incident 6264. Today, I did the recommend changes according to this problem report. We don't understand what causes the p_manage_34 to run for such a long time. Could the cause be the loading of bib. or authority records? If so, these loads do not contain, at most, a couple hundred records. How can we tell when p_manage_34 will execute so long? Is there any possibility of having multipe processes for this job? Our apps domain has 8 cpu's.

Resolution:
p_manage_34 checks for Z01 records whose z01_update_z0102 field is set to "Y". The z01_update_z0102 is set to "Y" when a new Z01 record is created. {Note: Z01 records are not updated when a change occurs to the heading: a new z01 is created and the z02s (listing the doc numbers which contain the heading) are moved from the old to the new.} The time required for p_manage_34 to process a heading depends on how many logical bases there are: your site has 21, a bit above average, but not *so* many. Last night, p_manage_34 was processing 100 records every 15 seconds or so. But by morning (when there was more competition?) had slowed down to 100 every 40 seconds. (Note that this is much faster than the "5 minutes per record" described in 2707 --where an Oracle index was missing-- and may be about as fast as we can expect.) We see that 55,000 doc records were processed by ue_01 on March 9: grep -c HANDLING run_e_01* And there was also the ue_08 activity. So I believe that the answer is that because of ue_01 and ue_08 indexing activity there were many new/changed headings in this time period and that was why p_manage_34 took so long. Since p_manage_34 no longer exists with version 15.2 (updating of the z0102 is done by ue_08 instead), it is extremely unlikely that any such change will be made to p_manage_34. This SQL query shows that there is a backlog of 366,273 headings waiting to be processed: SQL-CUN01> select count(*) from z01 where z01_update_z0102 = 'Y'; Figuring an average rate of 300/minute this would be 12 hours. I would think that, if nothing else, there would be a chance for it to catch up over the weekend. I see that you have temporarily swapped in an "empty" version of tab_base_z0102 which will prevent the OPAC from using the outdated z0102 -- that's a good idea....