FAQ
Hello to you all,

I've a mobile application that uses Oracle Lite 10g ( 10.2.0.2) as mobile
server and Oracle Database Server 10g release 1 (10.1.0.2) as the repository
database. Both of these components are installed on servers with Microsoft
Windows 2000 Advanced Server.

My question is related with the repository database:

We use Automatic Shared Memory Management and have a SGA target = to the SGA
Max Size = 1336Mb. ASMM always gave a bigger slice of memory to the Buffer
Cache (about 70%), but in the last 2 weeks I noticed that the value of the
Shared Pool started to increase and now it's bigger than Buffer Cache (a
slice of 49,7%).

Here's my current situation:

*Shared Pool 664* Mb

*Buffer Cache 648* Mb

Large Pool 8 Mb

Java Pool 8 Mb

Other 8 Mb

I have some knowledge of Oracle Database Server Architecture, but I'm being
able to interpret this behavior or why this is happening. Can anyone give me
some help or some ideas ?

It's also important to say that we have been experiencing some performance
problems in the last two weeks. We are also having a bigger volume of data.

Thanks for all your attention.

Best Regards,

Ricardo Santos
PL/SQL Analyst/Developer

Search Discussions

  • Fairlie rego at Jul 6, 2007 at 11:47 am
    Hi,


    The default algorithm of ASSM is that memory is stolen from the buffer cache if the shared pool is stressed.
    However this default behaviour can be changed by setting _memory_broker_shrink_heaps=30
    The default value for the above parameter is 0


    If you want to continue using this feature you might want to set a minimum value for your buffer cache so that memory does not shrink to below this value.


    HTH,

    Fairlie

    Richard Saints wrote:


    Hello to you all,
    I've a mobile application that uses Oracle Lite 10g ( 10.2.0.2) as mobile server and Oracle Database Server 10g release 1 (10.1.0.2) as the repository database. Both of these components are installed on servers with Microsoft Windows 2000 Advanced Server.


    My question is related with the repository database:
    We use Automatic Shared Memory Management and have a SGA target = to the SGA Max Size = 1336Mb. ASMM always gave a bigger slice of memory to the Buffer Cache (about 70%), but in the last 2 weeks I noticed that the value of the Shared Pool started to increase and now it's bigger than Buffer Cache (a slice of 49,7%).
    Here's my current situation:
    Shared Pool 664 Mb
    Buffer Cache 648 Mb
    Large Pool 8 Mb
    Java Pool 8 Mb
    Other 8 Mb


    I have some knowledge of Oracle Database Server Architecture, but I'm being able to interpret this behavior or why this is happening. Can anyone give me some help or some ideas ?


    It's also important to say that we have been experiencing some performance problems in the last two weeks. We are also having a bigger volume of data.



    Thanks for all your attention.


    Best Regards,
    Ricardo Santos
    PL/SQL Analyst/Developer


    Fairlie Rego
    Senior Oracle Consultant
    http://el-caro.blogspot.com/
    M: +61 402 792 405




    Luggage? GPS? Comic books?
    Check out fitting gifts for grads at Yahoo! Search.
  • Alexander Fatkulin at Jul 6, 2007 at 1:12 pm
    Richard,

    What are taking space in the shared pool?

    Look at v$sql for queues without binds, many child cursors, etc...
    On 7/6/07, Richard Saints wrote:

    Hello to you all,


    We use Automatic Shared Memory Management and have a SGA target = to the SGA
    Max Size = 1336Mb. ASMM always gave a bigger slice of memory to the Buffer
    Cache (about 70%), but in the last 2 weeks I noticed that the value of the
    Shared Pool started to increase and now it's bigger than Buffer Cache (a
    slice of 49,7%).
    --
    Alex Fatkulin, The Pythian Group
    http://www.pythian.com/blogs/author/alexf/
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJul 6, '07 at 10:26a
activeJul 6, '07 at 1:12p
posts3
users3
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase