Re: DB block buffers and Shared Pool Size on Oracle 7.3 Windows NT 4.0

On Fri, 30 Oct 1998 10:11:29 -0000, "Dean Cunningham" <drcunningham_at_bewiseltd.demon.co.uk> wrote:

>I am currently running Oracle 7.3 on a dedicated AlphaServer 4100 with 1.5GB
>of memory.
>This machine has only one instance and the physical database is around 30 GB
>with over 60 users and large batch runs.
>The DB block size was set to 4k and the number of block buffers is set to
>24000 resulting in a cache size of around 90 Mbytes.
>The shared pool size is set to 250 Mbytes. When using NT to monitor the free
>memory at the operating system level it reports that around 1.1 GB is free
>which you would expect. The data dictionary caches are still 100% full and
>there are still misses. There is still over 140 Mbytes of free memory in the
>SGA area so why is this database trying to conserve memory when the
>dictionary cache needs more memory. Is there something in oracle that will
>not allow
>the dictonary caches to use say more than 10% of the SGA.
>
>We have been told by the suppliers of the oracle database that we shouldn't
>change the number of buffers or the shared pool size as they are considered
>massive already considering the size of the database.
>
>Ideally I would like to change the number of block buffers to 80,000 and the
>shared pool size to at least 512 Mbytes to at least use some more memory and
>hopefully achieve a bit more perfromance.
>Is there some internal limits in oracle or N.T. that would damage the
>database if these changes were made.
>
>I have heard of some companies running oracle on Windows N.T. with 4 GB
>memory. Surely they cannot be having the same problems and only using 300
>Mbytes.
>
>Any feedback on the above would be greatly appreciated.
>
>
>
>

Are you sure that you are not observing inevitable misses which occur after an instance startup?

Ensure that you use the BSTAT/ESTAT reports after a settling down period so that you don't get skewed results.

Cheers.
--
Clive Bostock Received on Sun Nov 01 1998 - 13:22:49 CST