Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Authority record load creates indexing loop; fix_doc_aut_duplicate

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

    Description:
    We have had two separate incidents within the last 2 weeks of records which were brought in from Marcive during a regular Authorities update which have created a "loop" with indexing .

    We receive records from Marcive and load them using a combination of p_file_01, p_file_02, p_manage_36, and p_manage_18. We received the record friedrich_new.mrc and loaded it into production on 07/15/2010. This record was loaded as a new record (001053253), but is basically a duplicate of our record 000308724 (attached as friedrich_orig.mrc). The result is that a back and forth gets created, in which each of these records evidently changes the other, sending it back through the indexing process. The result can be seen in the ABC10 indexing logs:

    HANDLING DOC NO. - ABC10.001053253 14:21:52
    HANDLING DOC NO. - ABC10.000308724 14:21:52
    HANDLING DOC NO. - ABC10.001053253 14:21:52
    HANDLING DOC NO. - ABC10.000308724 14:21:52
    HANDLING DOC NO. - ABC10.001053253 14:21:52
    <hundreds more lines of the same>

    util f/4 shows that these two AUT records have hundreds of CAT fields with today's date (added by ue_01).

    This back and forth fills up Oracle off-line redo logs to the point where all available space is used up.

    As mentioned, this has now happened twice over the past 2.5 weeks, whereas it never happened in the 2.5 years we have been using this loading process (with v18).

    Resolution:
    ue_01 processing of authority record 1 updates authority record 2 and then ue_01 processing of authority record 2 updates authority record 1, etc.

    We found that changing the following line in abc10 tab_fix from:
    UE-01 fix_doc_aut_duplicate
    to:
    MNG18 fix_doc_aut_duplicate
    <where "MNG18" is the p_fix_type specified in the p_manage_18 submission>

    and restarting ue_01 corrects the problem.

    In addition to adding the fix_doc_aut_duplicate to the fix_doc section specified as the p_manage_18 p_fix_type, as described above, you should also include it in the INS section, if you are not already doing so:
    INS fix_doc_aut_duplicate

    KB 16384-5281 talks about also including it in the INS2 section.

    The problem occurred in v19 as a result of rep_change #613 (and v20, as a result of rep_change #2). These rep_change's required updating of a second record. The tab_fix UE_01 section can *not* have a fix routine which updates a second record.


    • Article last edited: 10/8/2013
    //Feedback