- Article Type: General
- Product: Aleph
- Product Version: 16.02
We are experiencing problems with our directory filling up due to archive oracle files.
I eliminated some of the archive files and restarted. This morning, the directory is nearly filled again. What can we do to correct this problem? We have not had these kinds of incidents in the past.
First, an examination of the directory shows that about the only thing on this disk is the oradata/aleph0/arch archive logs.
Large archive logs are most often produced by batch index jobs or ue_01 indexing activity. An examination of $alephe_scratch shows that the last batch index job was run on Sept. 3.
This grep in the sys01 $data_scratch directory shows that a large number of Z07s have been written (and needed to be processed by ue_01, resulting in many Oracle updates):
>>grep -c HANDLING *e_01*
There are three main sources of large numbers of Z07s:
the p_manage_21 global change job;
the p_manage_40 index-update-request generation job; and
the ue_08 "Update BIB Acc from Aut" daemon.
I don't see any recent p_manage_21 or p_manage_40 logs, but I do see this large ue_08 log (in the sys01 $data_scratch):
We can see that the ue_08 was running ( run_e_08.12762)
This grep shows that this ue_08 generated 1,920,712 doc updates (each of which also generates a z07):
>>grep -c 'Update doc' run_e_08.12762
This SQL shows that there are 98,000 Z07s waiting to be processed:
SQL-SYS01> select count(*) from z07;
**** Hit return to continue ****
The sys01 ue_01 is processing these at a rate of 1 every 2 seconds, so they should all be processed in about 2 days.
Assuming that whatever generated the Z01 "-NEW-" changes which resulted in the large ue_08 activity is a one-time event, then once these z07s are processed you should see lower archive log activity.
oracle. ue_08. z07
- Article last edited: 10/8/2013