How to update/delete large numbers of bib records without filling up ./arch disk

Description

Updating or deleting bib records causes large numbers of updates to be written to the Oracle archive directory (./oradata/.../arch), which causes the disk it resides on to fill up.  How can this be avoided?

Resolution

The update/deletion of a bib record requires that all of the indexes the record is included in be updated.  There can be *thousands* of Word index entries for a particular bib record. The Oracle archive logs are temporary files which are used by Oracle/RMAN when a problem occurs to restore the data to its state immediately preceding the problem.  When a complete/cold backup is done, the files become obsolete and Oracle/RMAN removes them.  

You should never manually remove ./oradata/.../arch files.  

It typically takes 1 - 5 days from the time a particular archive log file is written for Oracle to remove it.

Thus, there are two possibilities:

1.  Limit the updates/deletions to a number which doesn't fill up the ./arch directory and the disk; or

2.  If the deletions/updates can be clustered into a time period when user-update via the OPAC or GUI is prevented, turn off archiving while the deletions or updates are running.  This requires:

   a. Do util o/7/2 to turn Oracle archiving off.  (This will run aleph_shutdown  and aleph_startup as part of its processing.)  Then. immediately....

   b. In util w/5, toggle CIRC, ACQ, ILL, and JOBD  DOWN, while leaving the following UP:  
       * SYSTEM, 
       * WWW-SERVER, 
       * ALL-UE (so index updates will be processed),
       * CAT** (so you can submit batch update/delete jobs via the GUI), and
       * QUEUE-BATCH** (so GUI-submitted batch jobs will run). 
   Run aleph_shutdown / aleph_startup to make the Toggles take effect.  See the article " Putting Aleph in Read-Only Mode during cutover to new instance " for more in this regard.   

    ** This presumes that catalogers are instructed to not perform updates or (other) job submissions in this time period. If you are unable to control this, then you could (1) stop the xxx01 batch queue, (2) create a command to submit the job from the command line as described in the article Creating commands for submitting jobs from command line or including in job_list, and (3) stop the pc_server(s) once the command has been created.

   c. Run update/deletion job(s).  Wait until the following shows a count of zero:  
      > s+ xxx01
      SQL> select count(*) from z07a;   
    Then .... 

   d. Do a complete cold Oracle backup or data-pump backup of the Oracle tables, as described in the article " Refreshing Test server data Using Oracle Data Pump " 

   e. Do util o/7/1 to turn Oracle archiving on.  (This will run aleph_shutdown  and aleph_startup as part of its processing.)

   f.  In util w/5, toggle everything back up, then run aleph_shutdown / aleph_startup again (to make the Toggles take effect).
 

• Article last edited: 25-Sep-2018