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

    ORA-04031 heap dump / unable to allocate ... shared memory

     

    • Product: Aleph
    • Product Version: 20, 21, 22, 23
    • Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care

     

    Description

    Various server and ue_nn daemon logs have errors such as this:

    Oracle error: update_cursor13 z30
    ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool"

    over a period of 20 minutes.

    Looking at the /exlibris/app/oracle/diag/rdbms/aleph22/aleph22/trace/alert_aleph22.log file, we see an occurrence of the "ORA-04031 heap dump being written to trace file" error message, followed by a 20-minute period in which about 100 "unable to allocate 32 bytes of shared memory" messages are written. 

    These are some excerpts from the log:
    Sat Nov 29 15:16:34 2014
    ORA-04031 heap dump being written to trace file /exlibris/app/oracle/diag/rdbms/aleph22/aleph22/trace/aleph22_ora_9052.trc
    Errors in file /exlibris/app/oracle/diag/rdbms/aleph22/aleph22/trace/aleph22_ora_9052.trc (incident=150473):
    ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","select /*+ index(z410 z410_i...","SQLA","tmp")
    ...

    [about 100 occurrences of "unable to allocate 32 bytes"]
    ...
    ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","select f.file#, f.block#, f....","SQLA","tmp")
    Sat Nov 29 15:35:10 2014

    <that's the last ORA-04031 error message>

    Resolution

    As shown in the analysis in Additional Information below, it seems that the updates which showed errors in the batch job logs and the ue_nn daemons *were* eventually successful.

     

    This is a known Oracle bug.  It's described at https://support.oracle.com/epmos/fac...ylh6jwz_73#REF .

    The workaround is setting "_enable_shared_pool_durations = false" in the init file and restarting Oracle.

     

    Additional Information

     

    Looking at the odn01 run_e_21.29644 log, we see that all of the error messages occurred during the processing of two doc records: 
    HANDLING DOC NO. - SYS01.007587357 2017-03-14 14:59:01 
    ... 
    HANDLING DOC NO. - SYS01.007861825 2017-03-14 15:02:41 

    The above are the only HANDLING occurrences for these bib records on 2017-03-14. 

    Checking the sys00 z00p with util f/4 I see this: 
    Doc Number : 007587357 
    Timestamp : 201703141959074 
    Status : UPDATED 

    and 
    Doc Number : 007861825 
    Timestamp : 201703142002425 
    Status : UPDATED 

    This indicates to me that these updates of the z00p by ue_21 *were* eventually successful. 
     


    • Article last edited: 12-Mar-2017
    • Was this article helpful?