Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: SOS!!!....Process running out of memory.

RE: SOS!!!....Process running out of memory.

From: Vinod Gopinath BMMI IS <vinodg_at_BMMI.com.bh>
Date: Mon, 1 Nov 2004 14:39:19 +0300
Message-ID: <C9239A40098E1B47815F48965A7D0BF1266141@BMMIXCH.BMMIHQ.Root.AD>


Thanks Terry/Biti/PVN and to every one.=20 Thanks for your kind help.=20
Hve bounced the DB after changg the Shared_pool and log_buffer. Need to wait and c for any other surprises. /- Vin

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Terry Sutton Sent: Sunday, October 03, 2004 9:08 PM
To: oracle-l_at_freelists.org
Subject: Re: SOS!!!....Process running out of memory.

Without knowing a lot more about how your database is used, I can't tell you
what your settings should be.

I can tell you that whoever set up your init params doesn't seem to know what the params do (open_cursors =3D 1000000?). And I can tell you that I've
never seen a database which needs a log_buffer greater than 1MB (I'm not saying they don't exist, but they are very, very rare). Do you use java in
the database? If not, then java_pool_size should be 0.

As I asked before, is there a reason your shared pool is 1GB? Do your app
use bind variables? Is SQL reused?

Someone seems to have made random settings to parameters; it looks like their approach was "if in doubt, make it really big". The proper way to determine the settings is to see what your application needs and then set
parameters accordingly. If you're unwilling to do that, you can use trial
and error. Make your shared pool 100MB and see if parsing increases (after
the initial startup period). If it does, gradually work up to larger sizes.

But hit or miss is not the best approach to take to dealing with the needs
of your database. If you take it, you're just going to be putting out fires; changing parameters without knowing what they do and investigating
the consequences of the changes will just cause the fires to be in different
places.

--Terry

Appreciate your reply terry. Can you give me some good suggestion. This problem started recently when internet based application started accessing this db. For one of the user the session gets created and remains their inactive (when checked thru OEM) even if the user logs out, but with others its not so.

Having said so what do you suggest. I would opt to reduce the SGA. Send me you opinion.

/- Vin

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Terry Sutton Sent: Sunday, October 03, 2004 8:09 PM
To: oracle-l_at_freelists.org
Subject: Re: SOS!!!....Process running out of memory.

You're out of process memory, so you need to reduce memory areas so you either (1)need less or (2)have more available. One way to do #1 is reduce
sort_area_size. One way to do #2 is reduce the SGA.

Not sure what "tuned the db correctly" means, but why on earth do you have a
52MB log buffer (#2)?

Do you really need a 10MB sort_area_size (#1)? If you don't have many concurrent sessions sorting it won't matter, but if you have a lot of sessions sorting it could be a problem.

Is there a reason that your shared_pool is 1GB (#2)?

Do your large pool and java pool need to be as big as they are (#2)?

--Terry

--

http://www.freelists.org/webpage/oracle-l
--

http://www.freelists.org/webpage/oracle-l Received on Mon Nov 01 2004 - 05:30:55 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US