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

Description:
df -k" shows that the /exlibris filesystem is at 97% and a new 500 meg ./arch_aleph20_n_nnn_nnnnnnnnnn.dbf file is being written every 10 minutes. What is causing all this archiving activity? Our staff is not doing anything special.

Resolution:
Doing "ps -ef | grep ue_", I see that the abc01 ue_01 has a high CPU time.

I find that almost all the records in the database were updated today by the abc01_p_manage_21.00125 which used the file list909qrs as its input and deleted the 996 tag from the bib records. Each update generated a z07 indexing request record and the following grep shows that 285,074 z07's were processed today:

ABC01> grep -c HANDLING run_e_01.22751
285074

Every abc01 record that I've looked at has the following CAT fields:

CAT L $$aBATCH-UPD$$b00$$c20110920$$lABC01$$h1441
CAT L $$aBATCH-UPD$$b00$$c20110920$$lABC01$$h1542


Today's archive log activity was generated primarily by ue_01 processing the z07 records generated by the abc01_p_manage_21.00125.

Since df -k /exlibris had reached a state of 97% full, I stopped the abc01 ue_01 to prevent it from generating more /arch activity and filling up the disk.

Two things need to happen:

1) a cold Oracle backup which will allow the removal of the /arch files; this should free up 94 gig of disk space

2) restart the abc01 ue_01 (which will then process the 121,826 remaining z07 indexing requests). My guess is that this will generate a maximum of 20 gig of archive logs.

• Article last edited: 10/8/2013