- Article Type: General
- Product: Aleph
- Product Version: 20
One of our consortial partners reported a Course Reserves item that wasn't in Primo yesterday. While investigating the problem, I found that ue_21 has not been running on production in ABC30 since 3/16. The end of the last ue_21 log in abc30/scratch is below.
Any idea why this may have crashed? Also, is there any recommended practice for ensuring that a crash like this is reported out somewhere? It's unfortunate that this went unnoticed for so long, and resulted in a backlog of over 2200 Z07P records in the ABC30 processing queue.
I've since restarted the process, Z07P is now empty, and presumably tonight publish_04 job will pick up all affected records.
Looking at the abc30 $data_scratch/run_e_21.3794, I see this:
HANDLING DOC NO. - NYU30.000081285 19:13:54
HANDLING DOC NO. - NYU30.000079716 19:17:24
EXITING - 19:20:10
This is the result of the p_publish_04 which (as seen in the $alephe_scratch/abc30_p_publish_04.00155 log) was started at 19:20:05.
p_publish_04 doesn't want ue_21 running.
The $aleph_proc/p_publish_04 has these lines:
at the end.
But this second line doesn't cause ue_21 to be restarted. It just *allows* it to be restarted.
Normally p_publish_04 is a one-time job. Once the initial run is done, ue_21 takes over and creates the Z00Ps.
For now: If you need to run p_publish_04, you should restart ue_21 when it is done.
As described in KB 16384-21105 we recommend stopping/starting Aleph weekly -- even if you aren't stopping Oracle.
If something should fall through the cracks like this, it will at least be covered by this restart....
- Article last edited: 10/8/2013