Results 1 to 6 of 6
  1. #1
    Join Date
    Jan 2011
    Posts
    32

    Talking Unanswered: Response Time worst after upgrade to 11g

    Hi All ,

    My Oracle database size is =921 GB
    Physical Ram=132 GB

    Recently the DB is been upgraded to 11g, From 10
    Then Started experiencing the performance worst(Response Time) by 30%
    Then our colleagues have enabled the Parameter Filesystemio=ASYSNCH
    The original value was SETALL

    Now how to get the normal response time from the database base
    without parameter filesystemio=ASYNCH,

    The application Running on the database is SAP ,

    Please advise on this

    Which are the Memory Consuming parameters in oracle i e

    also , is there a way to find out , determine the should be values for

    different oracle crucial parameters based on Physical Ram and Database size


    Thanks in advance

  2. #2
    Join Date
    Jan 2011
    Posts
    32
    Hi All

    Did i post in incorrect category of ORACLE Related Threads

    Regards

  3. #3
    Join Date
    Dec 2011
    Posts
    2

    Oracle memory 11G

    Hi,

    This is my first post on here, but I may be able to help. In 11G the Oracle memory parameters have changed you now have:

    Memory Target
    Max Memory

    You will still have the previous memory parameters such as drilling down to the sga and all of the areas that make up the SGA. It is often recommended though that during the testing stages that you just set the memory max and memory targets as the upper limit of Memory that you wish to allocate to Oracle, then allow the database to resize all of the other areas such as the SGA, shared pool, log buffer etc automatically.

    Of course for this to take effect you will need to ensure all other memory parameters such as those mentioned are set to zero.

    I assume that you've ran the production workload through on a test system using Database replay beforehand?

    Thanks

    Dale

  4. #4
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    Also have up to date statistics been gathered on the new database?
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  5. #5
    Join Date
    Jan 2011
    Posts
    32
    Hi Daley B and beilstwh

    Thanks For the response

    Is there a Formula or a way or a calculation place(site)

    Where I can feed physical memory of the system and Database size

    The result would give me , whether Physical memory is apt for the size of the database


    also For physical memory size of 132 GB and database size of 921 GB , whether can i know the should be values for Following parameters

    DB_CACHE_SIZE JAVA_POOL_SIZE LARGE_POOL LOG_BUFFER SHARED_POOL_SIZE LOG_BUFFER PGA_AGGREGATE_TARGET

    memory_max_target


    Thanks in advance
    Regards

    Presently my system carries the Following parameters

    PARAMETER OPER_TYPE INITIAL_SIZE TARGET_SIZE FINAL_SIZE
    ------------------------------ ------------- ------------ ----------- ----------
    STATUS
    ---------
    shared_pool_size STATIC 0 1409286144 1409286144
    COMPLETE

    pga_aggregate_target STATIC 0 1509949440 1509949440
    COMPLETE

    java_pool_size STATIC 0 67108864 67108864
    COMPLETE

    streams_pool_size STATIC 0 0 0
    COMPLETE

    sga_target STATIC 0 0 0
    COMPLETE

    db_cache_size INITIALIZING 1.0033E+10 1.0033E+10 1.0033E+10
    COMPLETE

    db_cache_size STATIC 0 1.0033E+10 1.0033E+10
    COMPLETE

    db_cache_size STATIC 0 0 0
    COMPLETE

    db_2k_cache_size STATIC 0 0 0
    COMPLETE

    db_4k_cache_size STATIC 0 0 0
    COMPLETE

    db_8k_cache_size STATIC 0 0 0
    COMPLETE

    db_16k_cache_size STATIC 0 0 0
    COMPLETE

    db_32k_cache_size STATIC 0 0 0
    COMPLETE

    db_keep_cache_size STATIC 0 0 0
    COMPLETE

    db_recycle_cache_size STATIC 0 0 0
    COMPLETE

  6. #6
    Join Date
    Dec 2011
    Posts
    2
    What you will need to look at is some of the performance views based on what you have set.

    For example:

    v$memory_target_advice - this will show you whether the memory allocated is ok or whether you can benefit from adding more.

    Likewise with:

    v$db_cache_size_advice.

    Remember though that there will be a point where just chucking more and more memory at the instance won't make an improvement in performance and in fact could go the other way. The process will spend more time scanning the shared pool for a free block than actually doing work for example

    You can also use the advisors in OEM and you should generate statistics as mentioned previously. I tend to invalidate any previous cursors.

    Cheers

    Dale

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •