Diagnosing slow bib record indexing; ue_01 stages **MASTER RECORD**

• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23

Desired Outcome Goal:
Determine why indexing of bib (/authority) records is taking so long.

Procedure:
First, determine where in the indexing process a particular record (which is not retrievable in the OPAC/GUI searching) is. There are three stages to the ue_01 indexing:
(1) processing of the z07 by ue_01_a;
(2) processing of z07a for word indexing; and
(3) processing of the z07a for logical base indexing.

> s+ xxx01
SQL> select * from z07 where z07_rec_key = 'nnnnnnnnn'; <where nnnnnnnnn is the bib record number>

If found, that indicates that the ue_01 processing is still in stage 1. See Additional Information below.**
If not found, then:

SQL> select * from z07a where z07a_rec_key like '%nnnnnnnnn%';

If the result is "1nnnnnnnnn...", then the record is waiting for word indexing. Consult Article 000003443 ("ue_01 Word indexing extremely slow").
If the result is "2nnnnnnnnn...", then the record is waiting for logical base indexing. Consult Article 000018203 ("ue_01_z0102 index process very slow").

If "No rows found", that indicates that the record *has* been indexed. In that case, check for the record# in the ue_01 logs: "cd $data_scratch" and grep for the number in the current run_e_01.nnnnn, run_e_01_word.nnnnn, and run_e_01_z0102.nnnnn logs.

If found in the logs, that confirms that the record has been indexed. If, despite being in the logs and being indexed, the record is not retrievable in the OPAC or GUI search, try searching in a different base or in the xxx01 physical base (which should include *all* records).

If not found (and there's no z07 or z07a), try resending the record to the server again and start over at the beginning above.