Description

What servers, daemons, queues, etc., should be down when exporting/extracting Oracle data from Aleph?

Resolution

If this is a "for-real" export of Production data, then either Aleph should be in read-only mode (see the article Putting Aleph in Read-Only Mode during cutover to new instance ) or Aleph should be down entirely (that is:  run $alephe_root/aleph_shutdown prior to starting the export).

If this is a test run, you could leave things up.  The export utilities do not *require* that anything be down.  If updates are occurring while the export is running, there could be certain inconsistencies in the data.  For example, if, after the xxx01 bib data is extracted, a bib record with an attached ADM record and item is created, the bib record could be included in the xxx01 export while the ADM and item are not included in the (immediately following) xxx50 export.  Also, it could be that the export would take longer than it would if the system were down because, in exporting any one particular table, Oracle wants to create a consistent export, and will incorporate updates which occur during the export, adding extra time. 

   In any case, you should avoid running batch jobs which update records during such an export.  

In an "in-between" case -- where very minor inconsistencies in the export are OK, but anything more would be undesirable, you could toggle CAT,  QUEUE-BATCH, JOBD, and ALL-UE down (using util w/5), but leave other modules/functions up.  This will prevent GUI Cataloging updates and batch/background updates from occurring.   GUI Cataloging updates are the ones most likely to create inconsistencies between tables.  Circulation, including OPAC hold requests and renewals, could continue to occur.   

• Article last edited: 31-Oct-2016