ue_01_z0102 index process very slow

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

Description:
Looking at the abc01 $data_scratch run_e_01_z0102.6420 log, we see that from 10 am to 5 pm ue_01_z0102 processed only 400 records.

This is way too slow and there's a big backlog. What can be done to speed this up?

Resolution:
Do util c/1 in abc01 to verify that the ue_01_z0102 process is running. If not, consult Article 000042834 ("ue_01_z0102 process stops after 2000 records; account is locked; CTXSYS") as to why it may have stopped, and do util e/2 / util e/1 to restart it. If it *is* running....

Slowness in processing is often due to missing Oracle indexes. I did util a/17/14 to check on the xxx01 z0102 indexes. It showed that the z0102_id was "defined in file list", but does not "Exist in the Database":

Enter Table Name : z0102

Defined in file_list:
__________________________________________________________
IND z0102_id 1M OK ts3x
IND z0102_id1 2M 0K ts3x
__________________________________________________________


Exist in the Database:

INDEX_NAME STATUS INDEX_TYPE UNIQUENESS COLUMN_NAME
--------------- ------- ---------- ----------- --------------------
Z0102_ID1 VALID NORMAL NONUNIQUE Z0102_REC_KEY_1

Enter CR to continue...



I tried to do util a/17/2 to build the lnl01 z0102_id but it got the following error:

aleph_admin@ALEPH0> 07:57:30 aleph_admin@ALEPH0> STORAGE (INITIAL 1M NEXT OK MINEXTENTS 1 PCTINCREASE 0)
*
ERROR at line 2:
ORA-02219: invalid NEXT storage option value


The value of the NEXT storage option is defined in the fourth value in the $data_root file_list:

IND z0102_id 1M OK ts3x

This is "OK" (the letter "O"). It *should* be "0K" (the number zero).

You should make this correction to the file_list and then do util a/17/2 to build the z0102_id index.