-
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|