From: fitzjarrell on
On Oct 24, 12:07 pm, Frank van Bortel <frank.van.bor...(a)gmail.com>
wrote:
> joel garry wrote:
> > Maybe I'm unimaginative, but I can't even imagine an SGA that small in
> > any modern production system.
>
> It is not the SGA - there's 4GB on the machine.
>
> --
> Regards,
> Frank van Bortel
>
> Top-posting is one way to shut me up...

And less than 23 MB allocated for the shared pool. I'm curious as to
what V$SHARED_POOL_ADVICE reports.


David Fitzjarrell

From: joel garry on
On Oct 24, 10:07 am, Frank van Bortel <frank.van.bor...(a)gmail.com>
wrote:
> joel garry wrote:
> > Maybe I'm unimaginative, but I can't even imagine an SGA that small in
> > any modern production system.
>
> It is not the SGA - there's 4GB on the machine.
>

Well, that's fine if nothing you are doing bothers with cached
buffers.

Another issue might be, is there really 4GB on the machine, available
to users? Earlier versions of hp-ux might be easier to misconfigure,
but it is still easy to not give enough to users. With such a
db_block_buffers, I'd be wondering if it was set down that small
because too much was given to OS buffers. I'd also be wondering what
db_cache_size is! Perhaps the OP (or someone before him) got confused
between db_block_buffers and db_block_size.

"For backward compatibility the DB_BLOCK_BUFFERS parameter will still
work, but it remains a static parameter and cannot be combined with
any of the dynamic sizing parameters."

I guess the real red flag should be the possibility that the init.ora
was for a different version. Maybe no one has complained because no
one has ever seen it work right.

jg
--
@home.com is bogus.
http://news.zdnet.com/2100-9595_22-6214764.html