DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE

The keep buffer pool retains the schema objects in the memory. and the recycle buffer pool eliminates the data blocks from the memory as soon as they are no longer needed.
Now i have a table shares with 230Mb of dataa (approx 34M rows).
i use the alter table shares cache; statement to indicate that the blocks of the segment shares have to be kept in the memory.
i use the alter table shares nocache; statement to indicate the blocks should be removed once the work is done.
1. am i correct for the above statements regarding using the cache and nocache option.
2. can any one tell me how to specify htat the blocks of a particular segment have to be in keep cache. if the above statement is false.
3. please guys, can any one explain me the details regarding how to cache. and how to use recycle cache size for segments.

Hi vishnusivathej ,
Default cache: blocks will be kept or remove from database buffer cache based on LRU (Least Recent Used).
Recycle cache: blocks will be removed from database buffer cache after being issued
Keep cache: : blocks will be remain in database buffer cache
You cannnot assign a db cache based on segment. This is a storage option for an entire object, unless you have a partitioned table (then you can define which cache to use on a partition level).
Syntax:
alter TABLE <schema>.<table_name> storage (buffer_pool keep);
alter INDEX <schema>.<index_name> storage (buffer_pool keep);
You can refer to the following discussions as well:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:23558719922648
http://www.dba-oracle.com/t_script_automate_keep_pool_tables_indexes.htm
HTH,
Thierry
Note: the use of the keep pool is intended for small / frenquently used tables (lookup tables). I implemented this some time ago, and acheived a substantial increase of performance.
Edited by: Urgent-IT on Feb 2, 2011 9:00 AM

Similar Messages

  • Questions about db_keep_cache_size and Automatic Shared Memory Management

    Hello all,
    I'm coming upon a server that I'm needing to pin a table and some objects in, per the recommendations of an application support call.
    Looking at the database, which is a 5 node RAC cluster (11gr2), I'm looking to see how things are laid out:
    SQL> select name, value, value/1024/1024 value_MB from v$parameter
    2 where name in ('db_cache_size','db_keep_cache_size','db_recycle_cache_size','shared_pool_size','sga_max_size');
    NAME VALUE VALUE_MB
    sga_max_size 1694498816 1616
    shared_pool_size 0 0
    db_cache_size 0 0
    db_keep_cache_size 0 0
    db_recycle_cache_siz 0 0
    e
    Looking at granularity level:
    SQL> select granule_size/value from v$sga_dynamic_components, v$parameter where name = 'db_block_size' and component like 'KEEP%';
    GRANULE_SIZE/VALUE
    2048
    Then....I looked, and I thought this instance was set up with Auto Shared Mem Mgmt....but I see that sga_target size is not set:
    SQL> show parameter sga
    NAME TYPE VALUE
    lock_sga boolean FALSE
    pre_page_sga boolean FALSE
    sga_max_size big integer 1616M
    sga_target big integer 0
    So, I'm wondering first of all...would it be a good idea to switch to Automatic Shared Memory Management? If so, is this as simple as altering system set sga_target =...? Again, this is on a RAC system, is there a different way to do this than on a single instance?
    If that isn't the way to go...let me continue with the table size, etc....
    The table I need to pin is:
    SQL> select sum (blocks) from all_tables where table_name = 'MYTABLE' and owner = 'MYOWNER';
    SUM(BLOCKS)
    4858
    And block size is:
    SQL> show parameter block_size
    NAME TYPE VALUE
    db_block_size integer 8192
    So, the space I'll need in memory for pinning this is:
    4858 * 8192 /1024/1024 = 37.95.......which is well below my granularity mark of 2048
    So, would this be as easy as setting db_keep_cache_size = 2048 with an alter system call? Do I need to set db_cache_size first? What do I set that to?
    Thanks in advance for any suggestions and links to info on this.
    cayenne
    Edited by: cayenne on Mar 27, 2013 10:14 AM
    Edited by: cayenne on Mar 27, 2013 10:15 AM

    JohnWatson wrote:
    This is what you need,alter system set db_keep_cache_size=40M;I do not understand the arithmetic you do here,select granule_size/value from v$sga_dynamic_components, v$parameter where name = 'db_block_size' and component like 'KEEP%';it shows you the number of buffers per granule, which I would not think has any meaning.I'd been looking at some different sites studying this, and what I got from that, was that this granularity gave you the minimum you could set the db_keep_cache_size, that if you tried setting it below this value, it would be bumped up to it, and also, that each bump you gave the keep_cache, would be in increments of the granularity number....?
    Thanks,
    cayenne

  • (9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE

    제품 : ORACLE SERVER
    작성날짜 : 2005-01-05
    (9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE
    ==================================================================
    PURPOSE
    Oracle 9i의 새 기능인 동적으로 SGA 파라미터들을 변경하는 방법에
    대하여 알아보기로 한다.
    Explanation
    Oracle 8i까지는 Buffer Cache, Shared Pool, Large Pool 등과 같은 SGA
    파라미터들에 대해 그 크기를 동적으로, db가 운영 중인 상태에서는 변경할
    수가 없었다.
    즉, 이러한 파라미터들을 변경하려면 db를 shutdown하고 initSID.ora 화일에
    서 그 크기를 다시 설정하고, 이 파라미터를 이용해서 db 인스턴스를 restart
    해야만 했었다.
    Oracle 9i에서는 DBA가 ALTER SYSTEM 명령을 이용해서 SGA 파라미터의 크기
    를 동적으로 변경할 수 있게 되었다. 이 특정을 'Dynamic SGA'라고 부른다.
    SGA 전체의 최대 크기(SGA_MAX_SIZE)를 정의하고 그 한도 내에서 파라미터의
    크기를 변경할 수 있는 것이다. 데이타베이스를 shutdown/startup 없이 작업
    이 가능하기 때문에 'Planned Downtime'을 줄이는 한 방법으로도 이해할 수
    있다.
    이 글에서는 SGA에 할당할 수 있는 최소 단위인 'Granule'의 개념을 살펴보
    고, 이 granule이 어떠한 방법에 의해 동적으로 할당되는지에 대해 알아보고
    자 한다.
    또한 Buffer Cache 파라미터 중 새로운 것과 이전 버전에 비해 달라진 내용
    을 소개하기로 한다.
    1. Granule
    Granule은 가상 메모리 상의 연속된 공간으로, dynamic SGA 모델에서 할당할
    수 있는 최소 단위이다. 이 granule의 크기는 SGA 전체의 추정값
    (SGA_MAX_SIZE)에 따라 다음과 같이 구분된다.
    4MB if estimated SGA size is < 128M
    16MB otherwise
    SGA의 Buffer Cache, Shared Pool, Large Pool 등의 파라미터는 이 granule
    단위로 늘어나거나 줄어들 수 있다. (현재 dynamic SGA를 사용할 수 있는
    SGA 관련 파라미터는 Buffer Cache, Shared Pool, Large Pool 세 가지이다.)
    2. Dynamic SGA(DB_CACHE_SIZE, SHARED_POOL_SIZE)
    DBA는 ALTER SYSTEM 명령을 통해 initSID.ora 화일에 정의된 SGA 관련 파라미
    터 값을 동적으로 변경할 수 있다. SGA 파라미터의 크기를 늘려주기 위해서
    는 필요한 만큼의 free granule이 존재해야만 하며, 현재 사용하고 있는 SGA
    의 크기가 SGA_MAX_SIZE보다 작아야 한다. Free granule이 없다고 해서 다른
    파라미터로부터 granule을 free시켜서 그 granule을 이용할 수 있는 것은 아
    니다.
    반드시 DBA가 명시적으로 free/allocate해야 한다.
    다음의 예를 살펴보자. 설명을 단순화하기 위해 이 경우는 SGA가 Buffer
    Cache와 Shared Pool로만 구성되었다고만 하자.
    예) initSID.ora
    SGA_MAX_SIZE = 128M
    DB_CACHE_SIZE = 96M
    SHARED_POOL_SIZE = 32M
    Note : DB_CACHE_SIZE는 Oracle 9i에 새롭게 도입된 파라미터이다.
    위와 같은 상태일 때 동적으로 SHARED_POOL_SIZE를 64M로 늘리면 에러가 발생
    한다.
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    (insufficient memory error message)
    이 에러는 SHARED_POOL_SIZE를 늘림으로써 전체 SGA의 크기가 SGA_MAX_SIZE
    보다 커지기 때문에 발생한다. (96M + 64M > 128M)
    이를 해결하기 위해서는 DB_CACHE_SIZE를 줄인 후, SHARED_POOL_SIZE를 늘린다.
    SQL> ALTER SYSTEM SET DB_CACHE_SIZE=64M;
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    Note : DB_CACHE_SIZE가 shrink되는 동안에
    ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    를 하면 insufficient error가 발생할 수도 있다.
    이 경우는 DB_CACHE_SIZE가 shrink된 후 다시 수행하면 정상적으로
    수행이 된다.
    Note : 위 예제의 경우 estimated SGA 크기가 128M 이상이므로, granule의
    단위는 16M이다. 따라서 SGA 파라미터의 크기를 16M의 정수배로 했다.
    16M의 정수배가 아닌 경우는 지정한 값보다 큰 값에 대해 16M의
    정수배 중 가장 가까운 값을 택하게 된다.
    즉, 아래 두 문장의 결과는 똑같다.
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=49M;
    Note : LARGE_POOL_SIZE 와 JAVA_POOL_SIZE 파라미터는 동적으로 변경하는
    것이 불가능하다.
    1) Dynamic Shared Pool
    인스턴스 start 후, Shared Pool의 크기는 다음과 같은 명령에 의해 동적으
    로 변경(grow or shrink)될 수 있다.
    ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    다음과 같은 제약 사항이 있다.
    - 실제 할당되는 크기는 16M의 정수배가 된다.
    - 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
    2) Dynamic Buffer Cache
    인스턴스 start 후, Buffer Cache의 크기는 다음과 같은 명령에 의해 동적으
    로 변경(grow or shrink)될 수 있다.
    ALTER SYSTEM SET DB_CACHE_SIZE=96M;
    다음과 같은 제약 사항이 있다.
    - 실제 할당되는 크기는 16M의 정수배가 된다.
    - 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
    - DB_CACHE_SIZE는 0이 될 수 없다.
    3. Buffer Cache 파라미터의 변경된 내용
    여기서는 Buffer Cache 파라미터와 관련하여 Oracle 9i에 의미가 없어진 파라
    미터와 새롭게 추가된 파라미터, 그리고 dynamic SGA 중 Buffer Cache와 관련
    이 있는 부분에 대해 기술하고자 한다.
    1) Deprecated Buffer Cache Parameters
    다음의 세 가지 파라미터는 backward compatibility를 위해 존재하는 것으
    로, 차후 의미가 없어진다.
    - DB_BLOCK_BUFFERS
    - BUFFER_POOL_KEEP
    - BUFFER_POOL_RECYCLE
    위의 파라미터들이 정의되어 있으면 이 값들을 사용하게 될 것이다. 하지만,
    다음에 나올 새로운 파라미터들을 사용하는 것이 좋으며, 만일 위 파라미터
    (DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE) 값들을 사용
    한다면 이 글에서 설명한 dynamic SGA 특징을 사용할 수는 없다. 또한
    initSID.ora 화일에 위 파라미터들과 새로운 파라미터를 동시에 기술한다면
    에러가 발생한다.
    2) New Buffer Cache Sizing Parameters
    다음의 세 파라미터가 추가되었다. 이 파라미터들은 primary block size에
    대한 buffer cache 정보를 다루고 있다.
    - DB_CACHE_SIZE
    - DB_KEEP_CACHE_SIZE
    - DB_RECYCLE_CACHE_SIZE
    DB_CACHE_SIZE 파라미터에 지정된 값은 primary block size에 대한 default
    Buffer Pool의 크기를 의미한다. 또한 이전 버전과 마찬가지로 KEEP과
    RECYCLE buffer pool을 둘 수 있는데, 이는 DB_KEEP_CACHE_SIZE,
    DB_RECYCLE_CACHE_SIZE 라는 파라미터를 이용한다.
    이전 버전과 다른 점은 이전 버전의 경우 각각의 파라미터
    (DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP,BUFFER_POOL_RECYCLE)에 정의된 값들
    이 buffer 갯수(즉, 실제 메모리 크기를 구하려면 db_block_size를 곱했어야
    했다. )였는데 반해 이제는 구체적인 메모리 크기이다.
    또한 이전에는 DB_BLOCK_BUFFERS가 BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE
    의 값을 포함하고 있었지만, 이제는 DB_CACHE_SIZE가 DB_KEEP_CACHE_SIZE,
    DB_RECYCLE_CACHE_SIZE를 포함하고 있지 않다.
    즉, 각각의 파라미터들은 독립적이다.
    Note : Oracle 9i부터는 multiple block size(2K, 4K, 8K, 16K, 32K)를 지원한다.
    위에서 언급한 primary block size는 DB_BLOCK_SIZE에 의해 정해진 block
    size를 의미한다. (SYSTEM tablespace는 이 block size를 이용한다.)
    3) Dynamic Buffer Cache Size Parameters
    바로 위에서 언급한 세 파라미터는 아래와 같이 ALTER SYSTEM 명령에 의해
    동적으로 변경 가능하다.
    SQL> ALTER SYSTEM SET DB_CACHE_SIZE=96M;
    SQL> ALTER SYSTEM SET DB_KEEP_CACHE_SIZE=16M;
    SQL> ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE=16M;
    Example
    none
    Reference Documents
    <Note:148495.1>

    Hello Martin,
    Can I execute by ORA-27102 the following commandos in order to set and use the values of sga_max_size immediately?
    Variant 1)
    >sqlplus /nolog
    >connect / as sysdba
    > startup nomout
    > ALTER SYSTEM SET SGA_MAX_SIZE= ’value’ SCOPE=pfile;
    > shutdown immediate
    > startup
    Variant 2)
    Changing the values of sga_max_size, etc. in init<DBSID>.ora
    >sqlplus /nolog
    >connect / as sysdba
    > startup from pfile = /oracle/<SID>/dbs/ init<DBSID>.ora;
    Thank you very much!
    regards
    Thom

  • How to Increase the SGA Size.

    Hi Guru's
    I want to Know
    How to Increase the SGA Size in Database 8.1.7.4.1
    My Ram Size is 6 GB
    When I query the Below Script
    select name, value
    from v$parameter
    where name in ('shared_pool_size', 'java_pool_size', 'streams_pool_size',
    'log_buffer', 'db_cache_size', 'db_2k_cache_size', 'db_4k_cache_size',
    'db_8k_cache_size', 'db_16k_cache_size', 'db_32k_cache_size',
    'db_keep_cache_size', 'db_recycle_cache_size', 'large_pool_size');
    Result
    shared_pool_size     300000000
    large_pool_size     0
    java_pool_size     50000000
    log_buffer     10485760
    Please Suggest Me the How Much Value also to increase the SGA
    My RAM SIZE is 6 GB
    Regards
    ***SBJ***

    SGA size on 8i is static , and for increasing the size you have to make the changes in the pfile and bounce the database
    First thumb rule is that your SGA should not exceed more than 40% of your PHYSICAL RAM in oracle <= 8i version. You can go around 80% from oracle 9i onwards
    http://mohamedazar.wordpress.com/2010/08/30/can-i-increase-sga-target-size-greater-than-sga-max-size/
    Edited by: Amigo on Dec 18, 2010 1:31 AM

  • 10 new features to the oracle dataabse 10g

    Hi all.
    Recently, I have been interivewed and I have been asked to list 10 new features of Oracle 10g.
    I told him about:
    1) Here, stats have been collected automatically, in oracle 9i it was manual
    2) AWR
    3) RULE based optimizer is not there only in oracle 9i
    4) ASM
    Anything else which you want to mentioned:

    The Automatic Database Diagnostic Monitor (ADDM) analyzes data in the Automatic Workload Repository (AWR) to identify potential performance bottlenecks. For each of the identified issues it locates the root cause and provides recommendations for correcting the problem. An ADDM analysis task is performed and its findings and recommendations stored in the database every time an AWR snapshot is taken provided the STATISTICS_LEVEL parameter is set to TYPICAL or ALL. The ADDM analysis includes:
    •     CPU load
    •     Memory usage
    •     I/O usage
    •     Resource intensive SQL
    •     Resource intensive PL/SQL and Java
    •     RAC issues
    •     Application issues
    •     Database configuration issues
    •     Concurrency issues
    •     Object contention
    ASM
    Automatic Storage Management (ASM) simplifies administration of Oracle related files by allowing the administrator to reference disk groups rather than individual disks and files, which are managed by ASM
    DBMS_FILE_TRANSFER Package in Oracle Database 10g•     Common Usage Notes
    •     COPY_FILE
    •     GET_FILE
    •     PUT_FILE
    Flashback New Features and Enhancements in Oracle Database 10g•     Flashback Query
    •     Flashback Version Query
    •     Flashback Transaction Query
    •     Flashback Table
    •     Flashback Drop (Recycle Bin)
    •     Flashback Database
    •     Flashback Query Functions
    Oracle Data Pump
    STARTUP UPGRADE
    The is a new startup mode associated with the upgrade procedure in Oracle 10g.
    SQL> STARTUP UPGRADE
    Automatic Shared Memory ManagementAutomatic Shared Memory Management puts Oracle in control of allocating memory within the SGA. The SGA_TARGET parameter sets the amount of memory available to the SGA. This parameter can be altered dynamically up to a maximum of the SGA_MAX_SIZE parameter value. Provided the STATISTICS_LEVEL is set to TYPICAL or ALL and the SGA_TARGET is set to a value other than "0" Oracle will control the memory pools which would otherwise be controlled by the following parameters:
    •     DB_CACHE_SIZE (default block size)
    •     SHARED_POOL_SIZE
    •     LARGE_POOL_SIZE
    •     JAVA_POOL_SIZE
    If these parameters are set to a non-zero value they represent the minimum size for the pool. These minimum values may be necessary if you experience application errors when certain pool sizes drop below a specific threshold.
    The following parameters must be set manually and take memory from the quota allocated by the SGA_TARGET parameter:
    •     DB_KEEP_CACHE_SIZE
    •     DB_RECYCLE_CACHE_SIZE
    •     DB_nK_CACHE_SIZE (non-default block size)
    •     STREAMS_POOL_SIZE
    •     LOG_BUFFER

  • Slow query - db_cache_size ?

    Hi,
    Oracle 9.2.0.5.0 ( solaris )
    I've got a query which when run on a production machine runs very slow ( 10 hours ), but on a preproduction machine ( with same data ) takes about a 10th of the time. I have confirmed that on both machines we are getting the same plan.
    The only thing I can nail it down to, is that in production I'm seeing lots more "db file sequential read" wait events. Can I assume this is due to the blocks not being in/staying in the cache?
    When running on preprod, the hit ratio for the query is .90 + , on production it drops down to .70 - .80 ( as per query below )
    I have plenty of memory available on the machine, would it be wise to size up the caches? db_cache_size, db_keep_cache_size, db_recycle_cache_size ?
       SELECT (P1.value + P2.value - P3.value) / (P1.value + P2.value)
         FROM   v$sesstat P1, v$statname N1, v$sesstat P2, v$statname N2,
                v$sesstat P3, v$statname N3
         WHERE  N1.name = 'db block gets'
         AND    P1.statistic# = N1.statistic#
         AND    P1.sid = &sid
         AND    N2.name = 'consistent gets'
         AND    P2.statistic# = N2.statistic#
         AND    P2.sid = P1.sid
         AND    N3.name = 'physical reads'
         AND    P3.statistic# = N3.statistic#
         AND    P3.sid = P1.sid
    PRE-PRODUCTION
      call     count       cpu    elapsed       disk      query    current        rows   
      Parse        1      0.64       0.64          0          0          0           0      
      Execute      1      0.00       0.00          0          0          0           0      
      Fetch        2    186.92     329.88     162174    5144281          5           1      
      total        4    187.56     330.53     162174    5144281          5           1      
      Elapsed times include waiting on following events:
        Event waited on                             Times   Max. Wait  Total Waited
        ----------------------------------------   Waited  ----------  ------------
        SQL*Net message to client                       2        0.00          0.00
        db file sequential read                    160098        1.44        162.52
        db file scattered read                          1        0.00          0.00
        direct path write                              27        0.66          3.36
        direct path read                               97        0.00          0.02
        SQL*Net message from client                     2      985.79        985.79
    PRODUCTION
      call     count       cpu    elapsed       disk      query    current        rows
      Parse        1      2.41       2.34         79         16          0           0  
      Execute      1      0.00       0.00          0          0          0           0  
      Fetch        2    844.76   12305.06    1507519    5226663          0           1  
      total        4    847.17   12307.41    1507598    5226679          0           1  
      Elapsed times include waiting on following events:
        Event waited on                             Times   Max. Wait  Total Waited
        ----------------------------------------   Waited  ----------  ------------
        SQL*Net message to client                       2        0.00          0.00
        db file sequential read                   1502104        4.40      11849.13
        direct path write                             361        0.57          3.06
        direct path read                              361        0.05          0.88
        buffer busy waits                              36        0.02          0.17
        latch free                                      5        0.01          0.01
        log buffer space                                2        1.00          1.37
        SQL*Net message from client                     2      687.95        687.95
      Suggestions for further investigation more than welcome.

    user12044475 wrote:
    Hi,
    Oracle 9.2.0.5.0 ( solaris )
    I've got a query which when run on a production machine runs very slow ( 10 hours ), but on a preproduction machine ( with same data ) takes about a 10th of the time. I have confirmed that on both machines we are getting the same plan.
    The only thing I can nail it down to, is that in production I'm seeing lots more "db file sequential read" wait events. Can I assume this is due to the blocks not being in/staying in the cache?
    There are more physical reads, and the average read time is longer. This may simply be a reflection of the fact that other people are working on the production database at the same time and (a) kicking your data out of the cache and (b) causing you to queue at the disc as they do their I/O. A larger cache MIGHT protect your data a little longer, and MAY reduce their I/O at the same time so that the I/Os are faster - but we have no idea what side effects might then appear.
    It's also worth considering whether you did something as you tranferred the data from production to pre-production that helped to improve query performance. (As a simple example, an export/import could have eliminated a lot of row migration - and the nature of your plan means you MIGHT be suffering a lot of excess I/O from "table fetch continued row"). So, how did you get the data from production to test, how long ago, what's happened to it since, and do you have any session statistics taken as you ran the two queries ?
    Since your execution plan (prediction) is a long way off the actual run time, though, (even on the pre-production system), it's probably more important to work out whether you can make your query much more efficient before you make any dramatic changes to the system. I notice that you have three existences subqueries that appear at the end of the plan - such subqueries wreck the optimizer's arithmetic in your version of Oracle and can make it do very silly things. (See for example this blog note: http://jonathanlewis.wordpress.com/2006/11/08/subquery-selectivity )
    The effect of the subqueries may (for example) be why you have a full tablescan on the second table in a nested loop join at one point in your query. The expectation of a vastly reduced number of rows may be why you are seeing nested loops all over the place when (possibly) a couple of hash joins would be more appropriate.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
    Isaac Asimov                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Buffer Pool Question regarding db_nk_cache_size parameter

    If I set db_nk_cache_size parameter to db_16k_cache_size=50M then I create a tablespace using blocksize=16k, will all block objects in the tablespace be automatically pooled in my 16k cache?
    Matt

    Hi..
    The values of db_keep_cache_size and db_recycle_cache_size are by default 0.You can create the RECYCLE and KEEP pools by specifying the following init.ora parameters:
    DB_KEEP_CACHE_SIZE = <size of KEEP pool>
    DB_RECYCLE_CACHE_SIZE = < size of RECYCLE pool>
    When you use the above parameters, the total memory allocated to the block buffers is the sum of DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE, and DB_CACHE_SIZE.
    Regards,
    Anand

  • Database cache

    HI all,
    i read many documents about the database cache, but i still have a confusion about the
    db_keep_cache_size, db_recycle_cache_size, db_nk_block_size.
    kindly tell me, what is the use of this parameter, when will we use this parameter, how we assign the parameter to the database.
    Regards
    S.Senthil Kumar

    If you really read those documents, 'kindly' explain what you don't understand, instead of just requesting to abstract those very documents.
    You can read up on the difference between the parameters you mention in the Oracle reference manual easily.
    Sybrand Bakker
    Senior Oracle DBA

  • Buffer Cache Sizing

    I'm using 9i Release 7 on Microsoft Windows Server 2003.
    I have searched on metalink but I'm going around in circles confusing myself.
    I have 4GB Physical RAM
    SGA MAX SIZE = 2600 MB
    BUFFER CACHE = 2048 MB
    SHARED POOL = 256 MB
    JAVA POOL = 152 MB
    LARGE POOL = 16MB
    Aggreagte PGA Target = 768 MB
    Currently, the parameters DB_KEEP_CACHE_SIZE & DB_RECYCLE_CACHE_SIZE is 0MB
    If I wish to take advantage of the DB_KEEP_CACHE_SIZE Parameter so that I can retain frequently queried data in the Buffer Cache, what would be the optimal size I can allocate for this Parameter given the SGA Size I have mentioned above.

    Can I ask the reason which forced you to tune DB_KEEP_CACHE_SIZE & DB_RECYCLE_CACHE_SIZE . Is your DB not performing well , Is there any
    issue raised by your users ? Is there any responce time issue ? or throughput issue ? If your DB is working fine , then there is no need to try such stuffs , you wish to use this settings , just because you read somewhere or people useally
    do it, som forum user suggested me to do this.
    hare krishna
    Alok

  • Components of SGA?

    I'm aware of
    1) sga_max_size should be >= Total SGA.
    2) Size of the Total SGA = (shared_pool_size+large_pool_size+java_pool_size+db_keep_cache_size+db_recycle_cache_size+db_2k_cache_size+db_4k_cache_size+db_8k_cache_size+db_16k_cache_size+db_32k_cache_size+db_cache_size)
    Whether size of the PGA and/or size of the log_buffer have to account for Size of the Total SGA?
    Is there any thumb rule for sizing the PGA?
    Thanks in advance.

    Your main link is
    http://tahiti.oracle.com
    which is a searchable interface to all documentation.
    Kindly do not ask anyone to do something you can easily do yourself.
    Sybrand Bakker
    Senior Oracle DBA

  • Corba Client inside the DB

    Hello all
    I tried to deploy the HelloWoworld Corba example into DB (Corba server inside the DB, Oracle 8.1.6). All works fine while client is outside of DB... Then I tried to load the client into the DB and created related stored procedure to call the "HellWorld" method, but got the exception: ORA-29532: Java call terminated by uncaught Java exception:<b>
    org.omg.CORBA.OBJ_ADAPTER: Could not instantiate adapter:
    java.lang.NullPointerException minor code: 0 completed: No
    </b> So, is it possible to call the DB Corba object from within the same DB? What I should do to perform this?
    Thank you,
    Andrew

    The 'Keep Pool' is part of the Shared Pool and is used to keep executable objects (procedures, functions, and packages) in memory. This can speed up loading and reduce parsing of these objects.
    In the DBBlock Buffer Cache, you can have several areas. The size of these is determined by
    DB_CACHE_SIZE and DB_nK_CACHE_SIZE
    DB_KEEP_CACHE_SIZE
    DB_RECYCLE_CACHE_SIZE
    Which segments go into the various cache pools are determined by the 'STORAGE (BUFFER_POOL {DEFAULT | KEEP | RECYCLE } ) clause of the table or index create/alter statement.
    The purpose of the KEEP pool seems to be to keep the table blocks in memory as much as possible (eg: frequently used lookup tables), whereas the RECYCLE pool is to flush it from the cache as quickly as possible (typically large, always scanned tables)
    For more info, look for BUFFER_POOL in the SQL Reference at http://docs.oracle.com (not http://www.docs.oracle.com as someone suggested)
    I reserve the right to change my mind on anything. Especially when confronted with facts that are better than the ones I use right now.

  • QueryByExamplePolicy inside the DB Adapter

    I'm using the DB-Adapter inside the ESB creating a DB Read Service with a query by example.
    {color:#008000}&lt;binding name="BPELInstance_TAS_Read_binding" type="tns:BPELInstance_TAS_Read_ptt"&gt;
    &lt;jca:binding /&gt;
    &lt;operation name="BPELInstance_TAS_ReadSelect"&gt;
    &lt;jca:operation
    InteractionSpec="oracle.tip.adapter.db.DBReadInteractionSpec"
    IsQueryByExample="true"
    DescriptorName="BPELInstanceTASRead.CubeInstance"
    QueryName="BPELInstance_TAS_ReadSelect"
    ReturnSingleResultSet="false"
    MappingsMetaDataURL="BPELInstanceTASRead_toplink_mappings.xml" /&gt;
    &lt;input&gt;
    &lt;jca:header message="hdr:OutboundHeader_msg" part="outboundHeader"/&gt;
    &lt;/input&gt;
    &lt;/operation&gt;
    &lt;/binding&gt;{color}
    The implementation of the DB Adatper uses an "EQUALS" operator for the where clause.
    *{color:#ff0000}Does the DB Adapter support the QueryByExamplePolicy for setting a "LIKE" operator?{color}*
    Example of the QueryByExamplePolicy in Java:
    {color:#008000}ReadAllQuery query = new ReadAllQuery();
    Employee employee = new Employee();
    employee.setFirstName("B%");
    employee.setLastName("S%");
    employee.setSalary(0);
    query.setExampleObject(employee);
    /* Query by example policy section adds like and greaterThan */
    QueryByExamplePolicy policy = new QueryByExamplePolicy();
    policy.addSpecialOperation(String.class, "like");
    policy.addSpecialOperation(Integer.class, "greaterThan");
    policy.alwaysIncludeAttribute(Employee.class, "salary");
    query.setQueryByExamplePolicy(policy);
    Vector results = (Vector) session.executeQuery(query);{color}

    The 'Keep Pool' is part of the Shared Pool and is used to keep executable objects (procedures, functions, and packages) in memory. This can speed up loading and reduce parsing of these objects.
    In the DBBlock Buffer Cache, you can have several areas. The size of these is determined by
    DB_CACHE_SIZE and DB_nK_CACHE_SIZE
    DB_KEEP_CACHE_SIZE
    DB_RECYCLE_CACHE_SIZE
    Which segments go into the various cache pools are determined by the 'STORAGE (BUFFER_POOL {DEFAULT | KEEP | RECYCLE } ) clause of the table or index create/alter statement.
    The purpose of the KEEP pool seems to be to keep the table blocks in memory as much as possible (eg: frequently used lookup tables), whereas the RECYCLE pool is to flush it from the cache as quickly as possible (typically large, always scanned tables)
    For more info, look for BUFFER_POOL in the SQL Reference at http://docs.oracle.com (not http://www.docs.oracle.com as someone suggested)
    I reserve the right to change my mind on anything. Especially when confronted with facts that are better than the ones I use right now.

  • DB_KEEP_CACHE_SIZE  and  DB_RECYCLE_CACHE_SIZE  -- -- question

    db version = 10.2
    db block size = 8k
    I just added followiong two parameters to my init.ora:
    DB_KEEP_CACHE_SIZE=8k
    DB_RECYCLE_CACHE_SIZE=8k
    Question: I want to keep few lookup tables in 'KEEP' and 'RECYCLE'. Am I configuring the above two parameters correctly? Any inputs will be appreciated.
    regards,
    Lily.

    Sorry not mean how many rows in the tables rather the actual size like how many blocks.
    Check this from Performance Tuning Guide
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref540
    You can compute an approximate size for the KEEP buffer pool by adding together the blocks used by all objects assigned to this pool. If you gather statistics on the segments, you can query DBA_TABLES.BLOCKS and DBA_TABLES.EMPTY_BLOCKS to determine the number of blocks used.

  • Db_keep_cache_size

    Hi All,
    What is the functionality of db_keep_cache_size & db_recycle_size & how can i set it at my database.

    Dear 788442,
    Please see the following online documentations;
    DB_KEEP_CACHE_SIZE;
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/initparams059.htm#REFRN10040
    DB_KEEP_CACHE_SIZE specifies the size of the KEEP buffer pool. The size of the buffers in the KEEP buffer pool is the primary block size (the block size defined by the DB_BLOCK_SIZE initialization parameter).DB_RECYCLE_CACHE_SIZE;
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/initparams064.htm#REFRN10042
    DB_RECYCLE_CACHE_SIZE specifies the size of the RECYCLE buffer pool. The size of the buffers in the RECYCLE pool is the primary block size (the block size defined by the DB_BLOCK_SIZE initialization parameter).Hope That Helps.
    Ogan

  • Buffer_pool and db_keep_cache_size

    hi all,
    i want to change the buffer_pool of one table to KEEP and my parameter settings are
    sga_target big integer 7516192768
    buffer_pool_recycle string
    db_recycle_cache_size big integer 0
    db_keep_cache_size big integer 0
    if i change the buffer_pool it KEEP for table, will it be cached or not with above settings.
    do i have to first set db_keep_cache_size to non-zero to make it effective.
    regards
    Mir

    user11972299 wrote:
    hi all,
    i want to change the buffer_pool of one table to KEEP and my parameter settings are
    sga_target big integer 7516192768
    buffer_pool_recycle string
    db_recycle_cache_size big integer 0
    db_keep_cache_size big integer 0
    if i change the buffer_pool it KEEP for table, will it be cached or not with above settings.
    do i have to first set db_keep_cache_size to non-zero to make it effective.
    buffer_pool_recycle is an old parameter. Why you want to combine with the new ASMM parameter? If you want to use Keep pool for your table, in the table, change the Storage's option BUFFER_POOL to Keep with the alter table option.
    Don't touch the db_cache_size . Let ASMM handle it.
    HTH
    Aman....

Maybe you are looking for