Listener unable to allocate memory
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 8 of 8

Thread: Listener unable to allocate memory

  1. #1
    Join Date
    Feb 2006
    Posts
    6

    Listener unable to allocate memory

    Hello,
    I am having a problem where the listener log eventually gives me an error stating that listener is unable to allocate memory.
    Originally I thought the problem was with the shared pool. The free space in the memory would eventually dwindle down to nothing. I have since increased the shared pool size and changed some other initialization parameters, and have pinned the large oracle packages. There is currently no problem with shared pool available, but his error is occuring frequently (once a week, or so). It is usually cleared up by bringing down listener and restarting. As a note, sometimes listener will not come down through lsnrctl, and the process itself must be stopped. I am using an 8.1.6 instance of Oracle, running on an Alpha Open VMS 7-2 Operating system. The other thing that we noticed is that near the end of listeners week long life is that its' paging quota becomes 98%. The reason we don't think this is the core reason is that it doesn't seem to matter how large of a quota we give, it just prolongs the life a little longer. I noticed another error that comes up often in the listener.log:

    22-MAR-2006 08:18:51 * 12502

    TNS-12502: TNS:listener received no CONNECT_DATA from client

    This happens very regularly, and when I looked on metalink, a couple of articles said to ignore the error because it was something monitoring the listener port, but we don't have anything monitoring this port.

    The following are the parameters in the init.ora file:

    db_files = 1500 # LARGE


    db_file_multiblock_read_count = 32 # LARGE

    db_block_buffers = 70000 # INITIAL


    shared_pool_size = 83886080 # INITIAL


    large_pool_size = 614400 # INITIAL
    java_pool_size = 100000 # INITIAL

    log_checkpoint_interval = 10000

    processes = 300 # LARGE

    log_buffer = 163840 # INITIAL


    timed_statistics = true # if you want timed statistics
    max_dump_file_size = 10240 # limit trace file size to 5 Meg each


    rollback_segments = (ROLLBACK, ROLLBACK_2, ROLLBACK_3, ROLLBACK_4, ROLLBACK_5, R
    OLLBACK_6, ROLLBACK_7, ROLLBACK_8, ROLLBACK_9, ROLLBACK_10, ROLLBACK_11, ROLLBAC
    K_12, ROLLBACK_13, ROLLBACK_14, ROLLBACK_15)


    transactions = 40
    transactions_per_rollback_segment = 5


    global_names = TRUE


    control_files = ($5$dka0:[000000]ora_control1.con,$5$dka0:[000000]ora_control2.c
    on)


    compatible = 8.1.6

    #
    remote_login_passwordfile = shared


    #Enabled job queue processes
    job_queue_processes = 10

    #Sort area size added 03/7/2006
    sort_area_size = 102400

    #Shared_pool_reserved_size added 03/07/2006
    shared_pool_reserved_size = 20971520

    #open_cursors added 03/07/2006
    open_cursors = 70
    # alert log file location
    USER_DUMP_DEST=ORADISK1:[ORACLE8.DB_DBA.TRACE]
    BACKGROUND_DUMP_DEST=ORADISK1:[ORACLE8.DB_DBA.TRACE]



    I am not sure if this is even an Oracle issue, my systems Admin is looking into it on his side. This seemed to happen a couple of months ago, for the first time, and has been decreasing in time since last event ever since.

    Thanks in advance for your help,
    Mike

  2. #2
    Join Date
    Mar 2004
    Location
    DC,USA
    Posts
    650
    Check your TNSnames.ora file for the CONNECT_DATA component for the service name you are using.
    "What is past is PROLOGUE"

  3. #3
    Join Date
    Feb 2006
    Posts
    6
    The service names look correct, on thing i did notice though is that the tnsnames.ora file has two databases listed, one for the production system, and one for our long term database, both on the default port of 1521, could this be the issue with the errors, and could this solve the entire issue of listener eventually crashing?

    Thanks,
    Mike

  4. #4
    Join Date
    Aug 2000
    Location
    Singapore
    Posts
    323
    What is the status of LISTENER when you receive TNS-12502?
    Nagesh

  5. #5
    Join Date
    Feb 2006
    Posts
    6
    Up and running, I have checked it, and it still runs even though there are hundreds of these in the log. The strange thing is that I have no problem connecting in any sort of way. It just eventually stops accepting incoming connections, and finally dies with the unable to allocate memory error, i will look up the exact code.

    Mike

  6. #6
    Join Date
    Mar 2004
    Location
    DC,USA
    Posts
    650
    Did you had a look at this doc 205603.1, possibility of bugs?

    Otherwise, Log SR with Oracle.
    "What is past is PROLOGUE"

  7. #7
    Join Date
    Feb 2006
    Posts
    6
    Thanks, I will read the document and go from there.

    Mike

  8. #8
    Join Date
    Feb 2006
    Posts
    6
    I found something today that may be of interest:

    Q: What can customers do to tune for performance?
    A: Please consult MetaLink as your starting point for researching tuning tips for Oracle8i. Oracle also recommends that customers stay current with all software maintenance, both from Compaq and from Oracle, to ensure that your applications continue to run smoothly.
    Oracle Worldwide Support maintains a document, accessible from MetaLink, which lists all Oracle patches and Compaq ECOs (please see Note 154427.1 - List of patches for Oracle 8.1.7.1.0/8.1.7.1b on Alpha OpenVMS, Note 174247.1 - List of patches for Oracle 8.1.7.3, and Note162502.1 - List of patches for Oracle 9.0.1.0.0 on Alpha OpenVMS).

    Also, there are some basic tuning steps known to benefit overall OpenVMS system and Oracle performance:

    Distribute Oracle datafiles and redolog files across all available disks; the document at http://technet.oracle.com/deploy/ava...w2000_sane.pdf contains useful tips and guidelines.
    Ensure those files are not fragmented.
    Ensure tables and indexes have as few extents as possible.
    Ensure table rows have no or little block chaining.
    Ensure proper Working Set quota settings for both the Bequeath and the TNS listener slave processes. Files are BEQLSNR.COM and TNSLNR.COM, both residing in ORA_ROOT:[NETWORK]. We suggest ORA_LSNR_WSDEFAULT be set to 4096 and ORA_LSNR_WSQUOTA and ORA_LSNR_WSEXTENT each be set to 102400.
    Ensure Automatic Working Set Adjustment is enabled.
    Ensure proper tuning of the various components within the SGA, keeping in mind that "bigger = better" is not true per definition. Too large can in fact have an adverse effect on overall performance! For example, having a buffer cache that is too large incurs overhead that can be more than the benefits of having more data blocks in memory. Similarly, a SQL pool that is larger than the sum of all unique statements is a waste of memory that is better used elsewhere.

    This was found on HP's site under open VMS. I am going to attempt to make the changes on the BEQLSNR.COM file.


    Thanks,
    Mike

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width