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. p_manage_07 process unexpectedly filling up archive logs; NOLOGGING doesn't help

    p_manage_07 process unexpectedly filling up archive logs; NOLOGGING doesn't help

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

    Description:
    We are attempting to run p_manage_07 on our production environment, Dewey, to build the z00r records for our holdings library. The z00r records will be created in a parallel library (PAR60) and then linked to the holdings library (ABC60) via a synonym once p_manage_07 is complete. We have turned archive logging OFF for the tablespaces that hold the z00r table and associated indexes, but have noticed that the archive logs are filling at a rapid rate regardless of this precaution. The University is closed this week and so there is minimal activity in the system, other than this p_manage_07 process. For example, less than 150 holdings records have been sent through indexing today (we typically see close to 30,000 holdings records indexed in a given day.) We find the archive log activity to be very unusual in this context.

    We have been assuming that the p_manage_07 process does the inserts into z00r via direct load (as is done for the Aleph indexing jobs), which will respect the NOLOGGING setting on the tablespace and tables/indexes, and this is why I am finding the behavior surprising. Can you confirm whether or not this assumption is true?

    Resolution:
    The load_mode (DIRECT / INDIRECT) is set in the $aleph_proc/aleph_load and ./aleph_load_z9 procs. Jobs which call aleph_load or aleph_load_z9 invoke the SQL*Loader and have the load_mode set. Other jobs do not.

    Indexing jobs which have a separate Load step {such as

    p_manage_01 (p_manage_01_c, p_manage_01_d1, p_manage_01_e),
    p_manage_02 (p_manage_02_c, p_manage_02_d1),
    p_manage_05 (p_manage_05_c)
    etc.}

    invoke aleph_load. Other jobs do not.

    By doing

    > grep aleph_load *

    in the $aleph_proc directory, you can see the jobs which execute aleph_load.

    p_manage_07 is not one of them. The b_manage_07_a program does 'CALL "update_z00r"' and 'CALL "io_z13"', which update the z00r and z13 without using SQL*Loader.

    KB 3945 says "Oracle never lets you really, completely turn off logging. It only lets you disable it for certain kinds of logging -- such as SQL Loader direct loads,..."




    This issue is still open and was escalated to Development for further investigation <2010-01-17 01:00:00>.


    • Article last edited: 10/8/2013
    View article in the Exlibris Knowledge Center
    1. Back to top
      • p_manage_07 fails if z13u is not in use; empty z13u records
      • p_manage_07: how long for both z13's and z00r's?
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 19.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