Re: sga_max_size discrepancy

Raj,

Thanks. You put me on the right track but the granule size is actually 4M and...

NAME TYPE VALUE

------------------ ----------- ------------------------------
cpu_count          integer     64

Here's the deal. These are the Sun "cool thread" servers and while our zone only has 1 real CPU, each CPU has 64 threads of execution and to Oracle that looks like 64 CPUs.

We moved the zone from an older server (32 threads per CPU) to a newer server (64 threads per CPU) and the buffer cache doubled in size.

I don't know what if anything I can do about this. Need to research further.

Here's another calculated value that is way too high.

NAME                    TYPE        VALUE
----------------------- ----------- ------------------------------
parallel_max_servers    integer     185

BTW, on CPU intensive tasks these servers are about 25% the speed of other Sun processors. I've heard they are equivalent to a 300 MHz processor. They are best suited to applications like web servers where there are many processes but each request is small. OLTP databases might be another good use.

I'm not sure our development environment with a few users is the right application. On the other hand we are running 20 databases on a relatively cheap server. Either way, I wasn't consulted.

Keith

> Keith,
>
> do you have 4 CPUs? then it might make sense because in absence of
> sga_target setting, db_cache_size will default to 4mb * #cpus * granule
> size.
>
> I am guessing granule size as 16M so, if you have 4cpus, the min
> db_cache_size will be 256m (or 8 cpus if granule size is 8m).
>
> Raj
>

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