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. Resource busy and acquire with NOWAIT specified" **MASTER RECORD**

    Resource busy and acquire with NOWAIT specified" **MASTER RECORD**

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    1. Additional Information
    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    In doing util a/17/2, or util a/17/3, or in running an Indexing job or other batch job which DROPs /recreates an Oracle table (or index), you get the message:

    ORA-00054: resource busy and acquire with NOWAIT specified

    Resolution:
    This message indicates that another process is using this table.

    If the pc_server or the www_server is running, then it may be that someone has initiated a request which reads or updates this table.

    Try (or re-try) building the index with util a/17/2 or util a/17/3: the "resource busy" can sometimes be temporary and a subsequent attempt will sometimes succeed.

    If the job continues to get the error, then try it at a time when such activity is not occurring and when the www_server and pc_server are down.

    Or, it may be that another batch process is using this resource. This can happen when, for instance, you kill a job but don't kill all the processes associated with the job and then restart this job or another job which uses the same tables.

    There are some p_manage processes and some b_manage processes. To get both you need to do, for p_manage_07, for example:

    ps -ef |grep manage_07

    That is, you omit the "p_".

    In one recent case a manage_32 job was killed but the process associated with the last step, the step which builds the z0102_id1, which looks like this:

    aleph 23138 1 0 10:15:53 ? 0:00 /bin/csh -f util_a_17_b index z0102_id1

    was not killed. Note that this process won't be found by a "grep manage_32".

    The moral: If a job is an index-building step, then your "ps -ef | grep" needs to be done not just on the job name but also the table for which the index is being built.

    In the case of p_manage_nn indexing jobs, the problem could be that, though the job attempts to stop the ue_nn processes which update the index it is rebuilding this stop have failed and certain ue_nn indexing daemons are still running in this library. Do util c/1 to check. In this case, do this: kill all ue_nn processes in this library, do util c/1 to confirm that they are no longer present, and resubmit the indexing job.

    If you find that no matter what you do you continue to get the "resource busy", consult KB 8192-7896.

    Additional Information

    faq


    • Article last edited: 12/31/2014
    View article in the Exlibris Knowledge Center
    1. Back to top
      • Reshelving status -- how does Aleph know?
      • Resource busy and acquire with NOWAIT specified" -- can't make it stop
    • Was this article helpful?

    Recommended articles

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