- Article Type: General
- Product: Aleph
- Product Version: 20, 21, 22, 23
We are finding cases where a single update to a bib record (loaded, for instance, by manage-18) generates four, or even eight, z07a records (for word and z0102 indexing), and these records have the highest priority year ("1990"), which is equal in priority to GUI-cataloged records. Thus, they are preventing GUI-cataloged records from being word-indexed in a timely fashion.
After a set of 120,000 bib records was loaded five days ago ...
1. ue_01 has been processing the set continuously -- and filling up our archive logs;
2. a grep on record number shows that the same records being processed over and over: grep XXX01.003808388 retrieves four entries from run_e_01_word.nnnnn and four from run_e_z0102.nnnnn.
With these entries in aleph_start:
setenv z07_p_manage_21 1999
setenv z07_p_manage_18 2000
setenv z07_p_manage_40 2019
setenv z07_p_manage_33 2021
setenv z07_p_manage_37 2021
setenv z07_p_manage_50 2021
setenv z07_p_manage_55 2021
the site ran this sequence of jobs:
manage-18 (for approximately 5,000 bib records)
manage-50 (xxx01), 4 times, to create the hol and item for 4 xxx50 ADMs.
manage-55 (xxx01) + manage 18 (xxx60), to load the bib 856 into each hol.
manage-37 (xxx60), to add the proxy to each 856
manage-21 (xxx01), 2 times, to delete 852 in 856 in the bib.
For those 5k input records, 18,664 z07a's were generated, most with the year 1990.
Updates to the record after the original load cause additional z07 and z07a records to be created.
If there's an existing, unprocessed z07 for a particular record, a second z07 will not be written for that record. See the article Overwriting of existing z07's by new ones in this regard.
But, while there can't be more than one z07 record at a time for a particular doc record, there can be any number of z07a records.
Stop ue_01 before running the first job, and start it only after the last job has finished. Thus, only one z07 and one z07a will be written for each input record.
As described in the article Order of Z07A processing , the z07a's priority is generally the same as the z07 it is derived from -- but see the last paragraph in the article for an exception to this.
This SQL showed 134,944 z07a records (waiting to be processed by ue_01_word and/or ue_01_z0102):
xxx01@LIBP> select count(*) from z07a;
util f/4 for XXX01.003808388 showed there have been various updates to XXX01.003808388:
CAT L $$aCBUEBSCO$$b$$c20130217 $$lXXX01$$h1154
CAT L $$aBATCH$$b00$$c20130217 $$lXXX01$$h1249
CAT L $$aBATCH$$b00$$c20130219 $$lXXX01$$h0555
CAT L $$aBATCH$$b00$$c20130219 $$lXXX01$$h0957
CAT L $$a035OCLC$$b$$c20130223 $$lXXX01$$h0753
The following SQL shows that there are currently no z07a's waiting to be processed for XXX01.003808388:
xxx01@LIBP> select z07a_rec_key from z07a where z07a_rec_key like '%003808388';
no rows selected
XXX01.003808388 will appear in the log again *only* if another update is made to it. There is no evidence that records will be processed multiple times by ue_01 without multiple updates occurring.
Former title: "ue_01 continuously processing same records - huge archive redo logs"
- Article last edited: 15-Dec-2016