- Article Type: General
- Product: Aleph
- Product Version: 20, 21, 22, 23
The following messages appear in the xxx01_p_manage_01 log (in the p_manage_01_e step) of a manage-01 run with 16 processes:
ORA-01034: ORACLE not available
ORA-27102: out of memory
The job is suspended and few or no z98 records are written. (Note: Oracle was *not* down during this time. The "Oracle not available" problem seems to be confined to this particular job.)
Note: The xxx01 bib file has 3.2 million records.
The p_manage_01_e step (the building of the z98) is the step which uses the most memory (and disk space). The more (concurrent) processes specified in the submission, the more memory it will require.
Reducing the number of processes from 16 to 8 let the job run to completion, but the log still had some "ORACLE not available" and "out of memory" messages, and testing showed that certain searches did not retrieve correct results.
When the number of processes was reduced to 4 manage-01 ran without error, and test searching showed the correct results being retrieved. The job ran in 12 hours -- the same time it took with 16 and 8 processes .
Note: This (Test) server had 8G of (real) memory. This should be OK for a Test server with this size database, but, as described in the following article, for a database this size, on a Production server, the SGA may need to be increased, which, in turn, may necessitate an increase in the (real) memory: Multi-process, I/O intensive jobs slow in Aleph 22/Oracle 11r2 .