Re: Strange buffer resizing in 10gR2

Also,

a simple show parameter spfile in sqlplus will reveal if the instance has been started using an spfile (and which one).

Stefan

On 11/28/06, Jesse, Rich <Rich.Jesse_at_qg.com> wrote:
>
> 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_at_qg.com> 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
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Charles Schultz
>

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