Skip to main content
ExLibris

Knowledge Assistant

BETA
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. BIB z07 filling up and parallel indexing

    BIB z07 filling up and parallel indexing

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    No headers
    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    In our prod region we have the problem where the z07 is filling up with records to process. I followed through KB 4093 and none of the causes mentioned are in place here. BUT I did rebuild the direct index (z11) today via parallel indexing in the ABC02 library. I have run manage_05 in ABC02 after setting LS's for z00 and z103 in ABC02. I haven't done anything to ABC01 yet.

    Could it be the cause of all the z07 entries? That doesn't seem logical since it defeats the purpose of parallel indexing. Is there a table setting that I messed that could be causing this?

    Resolution:
    I see that the current ue_08 log (run_e_08.18695) in abc01 $data_scratch is large.

    Each processing of a z01 heading by ue_08 can generate up to 10 z07 records. The following grep shows that the current ue_08 generated 455,480 z07's:

    aleph1-18(1) ABC01-ALEPH>>grep -c 'Update doc' run_e_08.18695
    455480

    I see in the run_e_08.18695 that ue_08 was started with "CHECK-OPTION: C". That's good; that's what it should be.

    ue_08 processes z01 records which have a z01_rec_key_4 value of "-NEW-000000000".


    This is similar to KB 8192-10426, but I don't see any run of p_manage_02 which could have triggered all the z01_rec_key_4 "-NEW-"s . p_manage_05 does not update the z01 and, I believe, has nothing whatsoever to do with this problem.

    At the moment, each z07 which is being processed is being written to the z07h for re-processing in the later parallel indexing step. This means that the 184,421 z07's will be written there, if given the chance.

    I suggest preventing this by either:

    (1) completing the parallel indexing steps in the near future; or
    (2) halting the parallel indexing at this point ( -- including doing the SQL "drop table z07h"--) and then starting it over again from the beginning.


    • Article last edited: 10/8/2013
    View article in the Exlibris Knowledge Center
    1. Back to top
      • BIB Subfield Punctuation Added, Then Lost
      • Bib z07 records when running p_manage_18 on Authorities
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 18.01
      2. contype:kba
      3. Prod:Aleph
      4. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved