From: fitzjarrell on 24 Oct 2007 13:20 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 24 Oct 2007 14:41
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 |