RE: Strange buffer resizing in 10gR2
- From: "Jesse, Rich" <Rich.Jesse@xxxxxx>
- Date: Tue, 28 Nov 2006 15:46:55 -0600
Bingo! It shows that streams_pool_size was increased from 0 to the
amount that db_buffer_size was decreased. Funny, but the entry for the
increase comes logically in the view before the decrease, but I won't
pick nits. :)
I don't think this would have been done manually, but I should be able
to find something related to this behavior. Not used to this fun
self-managing stuff just yet...
In the meantime, I have other fires to put out now...
Thanks, Charles!
Rich
________________________________
From: Charles Schultz
Sent: Tuesday, November 28, 2006 3:07 PM
To: Jesse, Rich
Subject: Re: Strange buffer resizing in 10gR2
What does v$SGA_RESIZE_OPS show? If your SGA is resizing itself (due to
sga_target = 0), the pools will show multiple dynamic entries. If the
sizes are static, then they were set once the database started and have
not resized dynamically. Does your spfile parameter show a value, or is
it blank?
On 11/28/06, Jesse, Rich <Rich.Jesse@xxxxxx> wrote:
So, here I am sitting in a developer's class for our new ERP
package,
and I decided to monitor the 10.2.0.2.0 DB on AIX 5.3 that all
the dev's
individual JBoss servers are hammering. The first thing I
noticed is
that the buffer cache appears to be a whopping 16MB. Hmmm...I
could
have sworn that I set that higher. And I did.
The init.ora shows db_cache_size to be "50MB" and log_buffer to
be
"524288". sga_target is unset and is "0" according to
V$PARAMETER. The
init.ora file is dated November 5th, and V$INSTANCE shows that
it's been
up and running since the 9th. There is no spfile (on purpose).
Attempts to increase db_cache_size fail, like one would expect
with the
default sga_max_size.
Confucious. There's some things in this database that are out
of my
control (despite my protests), but I don't see how this scenario
could
happen from within the DB. The only thing I can think of is
that the
instance was started with an SPFILE and that file has since been
deleted, but I'm not sure how to prove this.
Thoughts?
Rich
--
//www.freelists.org/webpage/oracle-l
--
Charles Schultz
Other related posts:
