RE: SOS!!!....Process running out of memory.
- From: "Vinod Gopinath BMMI IS" <vinodg@xxxxxxxxxxx>
- To: <terrysutton@xxxxxxx>, <oracle-l@xxxxxxxxxxxxx>, <biti_rainy@xxxxxxxxx>
- Date: Mon, 1 Nov 2004 14:39:19 +0300
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Terry Sutton
Sent: Sunday, October 03, 2004 9:08 PM
To: oracle-l@xxxxxxxxxxxxx
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
----- Original Message -----=20
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Terry Sutton
Sent: Sunday, October 03, 2004 8:09 PM
To: oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
