Indexing issue in the Cataloging module

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

Description:
Since Thursday of last week it appears that the indexing of cataloging records has slowed down considerably. Staff are no longer querying by alpha characters to verify data loads as it takes too long to return records. Numerical queries do not seem to be affected and is the workaround solution at the moment. Of note, another analyst did a query against the Z07 table in MGU01 on Monday and I repeated that query today and our numbers have not gone down, they've actually increased.

Resolution:
I used the SQL in KB 4093 to analyze this:

mgu01@PALEPH1> select substr (z07_history, 1,5), count(*) from z07 group by substr (z07_history, 1,5);
**** Hit return to continue ****

SUBSTR(Z07_HIST COUNT(*)
--------------- ----------
MGU01 58949
MGU60 108
MGU50 1379


The following SQL shows that most of the current unprocessed z07's have been written with a backdate of 2009:

mgu01@PALEPH1> select substr(z07_sequence,1,6), count(*) from z07 group by substr(z07_sequence,1,6) order by substr(z07_sequence,1,6);
**** Hit return to continue ****

SUBSTR(Z07_SEQUENC COUNT(*)
------------------ ----------
199807 2388
200506 43
200507 121
200906 666
200907 46715
201106 926
201107 9362

and will not interfere with the current Cataloging, which, as described in KB 8192-7463, are being backdated to 1990.

This line in $alephe_scratch/mgu01_p_manage_18.01888 shows p_manage_18 loading 46,000 records:

46390 END READING AT 04:23:47

I find that the count of z07's decreased from 60,567 to 59,172 in the half hour that I was examining this incident.

mgu01 ue_01 is processing more than one z07 each second. The "1998" z07's have been cut in half.

If new z07's are not being written, these should all be processed by tomorrow morning.

• Article last edited: 10/8/2013