p_manage_01: based on p_manage_01_a.cycles will take 50+ hours to run

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

Description
The p_manage_01 (Word indexing) service is extremely slow (-- 10 times slower than it should be).

1. The most common cause of extreme slowness in Aleph is Oracle indexes missing for tables being read by the Aleph programs. (In the case of an indexing job, the Oracle indexes on the tables being *written* to are often dropped by the job and rebuilt only after the job has finished. That is normal.)

The SQL in Article 000043308 ("*How to tell if Oracle indexes for a particular library are present & VALID?*") (see link below) searches for missing Oracle indexes missing with a single query.

Note that in building the Word indexes manage-01 reads not only bib library tables, but also ADM and HOL library tables. Those libraries need to be checked for missing Oracle indexes as well.

After building the missing index(es), the job *may* need to be killed and restarted for them to be in effect.

2. In some cases an increase in Oracle memory size (SGA) has been found to improve performance of various jobs, including bib-indexing jobs. (See link below.)

3. In another case, though the site had only 1.4 million bib records, the xxx01 last-doc-number (as seen in util g/2) was greater than 30 million and 600 cycles (30,000,000 / 50,000) had been generated in the p_manage_01_a.cycles file, making it seem as though the job would run for several days. Since many of these record ranges were in fact empty, the job ran for only 10 hours. See link to Article 000045655 ("Increasing bib library last-doc-number") below in this regard.