Buffer_pool keep

From oracle 10g we are using db_keep_cache, I am really interest to know on which condition I have to use buffer_pool keep while creating tables in database.

If your SGA is large enough to hold your table data, then you can use this.
ALTER TABLE EMPLOYEE CACHE;
would move the data to the keep pool.
Basically if the application runs multiple queries on a large single table, it would be better to keep the table in buffer cache (keep pool) thru which the quries can run faster multiple folds.
It can be used either on large or small data tables.

Similar Messages

How to revert back from storage(buffer_pool keep) clause

Hi,
We have fired "alter TABLE APPLSYS.FND_CONCURRENT_PROGRAMS storage (buffer_pool keep);"
But, now we dont want the specified table to be cached in keep pool. So, how to do the same ?
Could anybody please suggest ?

Like this.
SQL> select BUFFER_POOL from user_tables where table_name = 'T1';
BUFFER_
DEFAULT
SQL> alter table t1 storage(buffer_pool keep);
Table altered.
SQL> select BUFFER_POOL from user_tables where table_name = 'T1';
BUFFER_
KEEP
SQL> alter table t1 storage(buffer_pool default);
Table altered.
SQL> select BUFFER_POOL from user_tables where table_name = 'T1';
BUFFER_
DEFAULT
SQL>Asif Momen
http://momendba.blogspot.com

BUFFER_POOL KEEP问题

question from oracler:
SYS@orcl>select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
parameter set as :
SYS@orcl>sho parameter cache_size
NAME TYPE VALUE
client_result_cache_size big integer 0
db_16k_cache_size big integer 80M
db_2k_cache_size big integer 0
db_32k_cache_size big integer 0
db_4k_cache_size big integer 0
db_8k_cache_size big integer 0
db_cache_size big integer 160M
db_flash_cache_size big integer 0
db_keep_cache_size big integer 128M
db_recycle_cache_size big integer 0
SYS@orcl>create table dna.t2 storage(buffer_pool keep) as select level id ,rpad('*',4000,'*') data from dual connect by
level<=15000;
表已创建。
SYS@orcl>select count(*) from dna.t2;
COUNT(*)
15000
SYS@orcl>set autotrace traceonly
SYS@orcl>select count(*) from dna.t2;
执行计划
Plan hash value: 3321871023
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 4116 (1)| 00:00:50 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T2 | 16126 | 4116 (1)| 00:00:50 |
Note
- dynamic sampling used for this statement (level=2)
统计信息
0 recursive calls
0 db block gets
15004 consistent gets
15000 physical reads
0 redo size
528 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SYS@orcl>select count(*) from dna.t2;
执行计划
Plan hash value: 3321871023
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 4116 (1)| 00:00:50 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T2 | 16126 | 4116 (1)| 00:00:50 |
Note
- dynamic sampling used for this statement (level=2)
统计信息
0 recursive calls
0 db block gets
15004 consistent gets
15000 physical reads
0 redo size
528 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
为什么会出现大量的physical reads现象，难道此存在于The KEEP buffer pool中的表，应该不会出现此现象？

answered by maclean liu:
SQL>
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> show parameter db_keep
NAME                                 TYPE                             VALUE
db_keep_cache_size                   big integer                      128M
SQL> create table maclean_tan2 storage(buffer_pool keep) as select level id ,rpad('*',4000,'*') data from dual connect by
2 level<=15000;
Table created.
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
Execution Plan
Plan hash value: 1229461046
| Id | Operation          | Name         | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 | 4069   (1)| 00:00:49 |
|   1 | SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MACLEAN_TAN2 | 15476 | 4069   (1)| 00:00:49 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          4 recursive calls
          0 db block gets
      15081 consistent gets
      15000 physical reads
          0 redo size
        527 bytes sent via SQL*Net to client
        523 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
Execution Plan
Plan hash value: 1229461046
| Id | Operation          | Name         | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 | 4069   (1)| 00:00:49 |
|   1 | SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MACLEAN_TAN2 | 15476 | 4069   (1)| 00:00:49 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
      15004 consistent gets
      15000 physical reads
          0 redo size
        527 bytes sent via SQL*Net to client
        523 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> alter session set events '10046 trace name context forever,level 8';
Session altered.
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name
/s01/orabase/diag/rdbms/vprod/VPROD1/trace/VPROD1_ora_29876.trc
PARSING IN CURSOR #140118795641360 len=33 dep=0 uid=0 oct=3 lid=0 tim=1340511245212199 hv=486583032 ad='76883110' sqlid='drryzcwfh1ars'
select count(*) from maclean_tan2
END OF STMT
PARSE #140118795641360:c=6000,e=35195,p=0,cr=77,cu=0,mis=1,r=0,dep=0,og=1,plh=1229461046,tim=1340511245212192
EXEC #140118795641360:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1229461046,tim=1340511245212328
WAIT #140118795641360: nam='SQL*Net message to client' ela= 13 driver id=1650815232 #bytes=1 p3=0 obj#=79780 tim=1340511245212395
WAIT #140118795641360: nam='asynch descriptor resize' ela= 11 outstanding #aio=0 current aio limit=235 new aio limit=265 obj#=79780 tim=1340511245214369
WAIT #140118795641360: nam='direct path read' ela= 140 file number=1 first dba=200555 block cnt=1 obj#=79780 tim=1340511245276928
WAIT #140118795641360: nam='direct path read' ela= 124 file number=1 first dba=200683 block cnt=1 obj#=79780 tim=1340511245294008
WAIT #140118795641360: nam='direct path read' ela= 126 file number=1 first dba=201707 block cnt=1 obj#=79780 tim=1340511245425743
WAIT #140118795641360: nam='direct path read' ela= 170 file number=1 first dba=201835 block cnt=1 obj#=79780 tim=1340511245454308
WAIT #140118795641360: nam='direct path read' ela= 126 file number=1 first dba=201963 block cnt=1 obj#=79780 tim=1340511245472445
WAIT #140118795641360: nam='direct path read' ela= 113 file number=1 first dba=202091 block cnt=1 obj#=79780 tim=1340511245488926
WAIT #140118795641360: nam='direct path read' ela= 116 file number=1 first dba=202219 block cnt=1 obj#=79780 tim=1340511245505475
WAIT #140118795641360: nam='direct path read' ela= 116 file number=1 first dba=202475 block cnt=1 obj#=79780 tim=1340511245539057
WAIT #140118795641360: nam='direct path read' ela= 157 file number=1 first dba=202603 block cnt=1 obj#=79780 tim=1340511245556950
WAIT #140118795641360: nam='direct path read' ela= 31 file number=1 first dba=202987 block cnt=1 obj#=79780 tim=1340511245608673
WAIT #140118795641360: nam='direct path read' ela= 131 file number=1 first dba=203115 block cnt=1 obj#=79780 tim=1340511245624922
WAIT #140118795641360: nam='direct path read' ela= 113 file number=1 first dba=203755 block cnt=1 obj#=79780 tim=1340511245706298
WAIT #140118795641360: nam='direct path read' ela= 28 file number=1 first dba=203883 block cnt=1 obj#=79780 tim=1340511245722656
WAIT #140118795641360: nam='direct path read' ela= 13 file number=1 first dba=204011 block cnt=1 obj#=79780 tim=1340511245738218
WAIT #140118795641360: nam='direct path read' ela= 31 file number=1 first dba=204523 block cnt=1 obj#=79780 tim=1340511245801733
direct path read 而非 db file scattered read
11g new feature 对于大表的FULL SCAN 可以直接采用 direct path read   读入PGA 而不经过 buffer cache
ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT FOREVER';
10949 event 可以禁止 11g 的这种特性；
[oracle@vrh1 ~]$ oerr ora 10949
10949, 00000, "Disable autotune direct path read for full table scan"
// *Cause:
// *Action: Disable autotune direct path read for serial full table scan.
_small_table_threshold 设置为较大值避免 optimizer 将这个表视为大表 buffer 被flush
SQL>
SQL> alter session set "_small_table_threshold"=999999;
Session altered.
SQL> ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT FOREVER';
Session altered.
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
SQL> set autotrace on;
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
Execution Plan
Plan hash value: 1229461046
| Id | Operation          | Name         | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 | 4069   (1)| 00:00:49 |
|   1 | SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MACLEAN_TAN2 | 15476 | 4069   (1)| 00:00:49 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
      15011 consistent gets
          0 physical reads
          0 redo size
        527 bytes sent via SQL*Net to client
        523 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> select count(*) from maclean_tan2;
COUNT(*)
     15000
Execution Plan
Plan hash value: 1229461046
| Id | Operation          | Name         | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |     1 | 4069   (1)| 00:00:49 |
|   1 | SORT AGGREGATE    |              |     1 |            |          |
|   2 |   TABLE ACCESS FULL| MACLEAN_TAN2 | 15476 | 4069   (1)| 00:00:49 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
      15011 consistent gets
          0 physical reads
          0 redo size
        527 bytes sent via SQL*Net to client
        523 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
http://www.oracledatabase12g.com/archives/script-list-buffer-cache-details.html
参考以上网址的脚本
set pages 999
set lines 92
column c0 heading "Owner"                                    format a12
column c1 heading "Object|Name"                              format a30
column c2 heading "Object|Type"                              format a8
column c3 heading "Number of|Blocks in|Buffer|Cache"         format 99,999,999
column c4 heading "Percentage|of object|blocks in|Buffer"    format 999
column c5 heading "Buffer|Pool"                              format a7
column c6 heading "Block|Size"                               format 99,999
select
   buffer_map.owner                                          c0,
   object_name                                       c1,
   case when object_type = 'TABLE PARTITION' then 'TAB PART'
        when object_type = 'INDEX PARTITION' then 'IDX PART'
        else object_type end c2,
   sum(num_blocks)                                     c3,
   (sum(num_blocks)/greatest(sum(blocks), .001))*100 c4,
   buffer_pool                                       c5,
   sum(bytes)/sum(blocks)                            c6
from
   buffer_map,
   dba_segments s
where
   s.segment_name = buffer_map.object_name
and
   s.owner = buffer_map.owner
and
   s.segment_type = buffer_map.object_type
and
   nvl(s.partition_name,'-') = nvl(buffer_map.subobject_name,'-')
group by
   buffer_map.owner,
   object_name,
   object_type,
   buffer_pool
having
   sum(num_blocks) > 10
order by
   sum(num_blocks) desc
                                                       Number of Percentage
                                                       Blocks in of object
             Object                         Object        Buffer blocks in Buffer    Block
Owner        Name                           Type           Cache     Buffer Pool       Size
SYS          MACLEAN_TAN2                   TABLE         15,001         98 KEEP      8,192
SYS          C_TOID_VERSION#                CLUSTER        1,765         57 DEFAULT   8,192
SYS          C_OBJ#                         CLUSTER        1,428         93 DEFAULT   8,192
SYS          OBJ$                           TABLE            931         91 DEFAULT   8,192
SYS          I_OBJ2                         INDEX            760         99 DEFAULT   8,192
SYS          C_FILE#_BLOCK#                 CLUSTER          198         77 DEFAULT   8,192
SYS          I_FILE#_BLOCK#                 INDEX             40        100 DEFAULT   8,192
SYS          I_OBJ1                         INDEX             37         14 DEFAULT   8,192
SYS          INDPART$                       TABLE             16        100 DEFAULT   8,192
SYS          I_HH_OBJ#_INTCOL#              INDEX             15         12 DEFAULT   8,192
SYS          HIST_HEAD$                     TABLE             15          4 DEFAULT   8,192
SYS          AQ$_SYS$SERVICE_METRICS_TAB_S TABLE             14         88 DEFAULT   8,192
SYS          C_TS#                          CLUSTER           13         81 DEFAULT   8,192
SYS          I_DEPENDENCY1                  INDEX             13          2 DEFAULT   8,192
SYS          I_ACCESS1                      INDEX             12          2 DEFAULT   8,192
15 rows selected.
可以看到 MACLEAN_TAN2 表在 keep buffer pool中的详细信息， 15,001 blocks= 117MB

Dimensions with buffer_pool = keep

Hi,
We have a data warehouse built with WareHouse Builder more than 5 years ago. At that time, on a 8i database, it was suggested that we put our dimensions with buffer_pool = keep to get a faster response in Discoverer.
We have a fact table partitioned by month (3 years), with bitmap indexes + 4 dimensions without indexes.
My question : is it still valuable to set buffer_pool = keep with a 10G database for dimensions?
Would it be faster if we put the buffer_pool = default and add some indexes to the dimensions?
Thanks.

Fabrice, it would be very unusual to keep a 2G table and trying to do would be unlikely to aid performance in most environments I have every seen.
In fact unless you have a very strong knowledge of how the application works and the processing logic is fairly static the great majority of sites are better off to not use a keep or recycle buffer pools and to allow Oracle to manage the buffer pool based on demand.
You are probably trying to tune a specific query. You might want to look at the size of each table and the filter conditions available. Verify that the plain join order is correct. If not manipulate the plan to get what you believe should be the correct join order.
If you are just trying to improve performance against one table then check to make sure that the right indexes exist to support the most important quries. This would also be a step in the process above.
HTH -- Mark D Powell --

Buffer_pool keep vs cache

Hi,
i've a 11.2 database.
I want to reduce Logical Reads of a table that has only 300 records and 5 blocks.
This table is used many times in full scan.
I know that the keep is a defined pool and the cache use the buffer cache default pool.
It preferred to put it in buffer keep or use the table cache option?
tnx

In general, a small table that is used a lot will automagically be kept in the buffer cache, so you don't have to do anything.
When you might consider doing something is if you have lots of thrashing in the buffer, so things are getting kicked out and having to be read back in, and you already have a large buffer. But even there, simply reducing logical reads may have a consequent effect of reducing the thrashing, even if it is simply because of fewer read consistent copies being created in the buffer. So in nearly all cases with SGA size at least in the ballpark, tune the sql first. The small table is likely to be the least of your worries. In general, better to let Oracle work out what's going on in the default buffer, rather than taking away some and giving to the keep buffer.
If you see this table being read into PGA (like a lot of direct reads), that might be a different issue.

KEEP BUFFER_POOL

I want to know what exactly happens when we try to put a segment in Buffer using KEEP claause.
I have default DB_BUFFER_CACHE and have not created KEEP POOLs
NAME                                 TYPE        VALUE
db_cache_size                        big integer 1504M
NAME                                 TYPE        VALUE
db_keep_cache_size                   big integer 0and ran the following command
ALTER INDEX TEST_SCHEMA.PK_INDEX STORAGE (BUFFER_POOL KEEP);
After running the following SQL, I found that this Index is in KEEP
set linesize 132
SELECT ds.buffer_pool, do.owner, SUBSTR(do.object_name,1,9) OBJECT_NAME,
ds.blocks OBJECT_BLOCKS, COUNT(*) CACHED_BLOCKS
FROM dba_objects do, dba_segments ds, v$bh v
WHERE do.data_object_id=V.OBJD
AND do.owner=ds.owner(+)
AND do.object_name=ds.segment_name(+)
AND DO.OBJECT_TYPE=DS.SEGMENT_TYPE(+)
AND ds.buffer_pool ='KEEP'
GROUP BY ds.buffer_pool, do.owner, do.object_name, ds.blocks
ORDER BY do.owner, do.object_name, ds.buffer_pool;
BUFFER_ OWNER                          OBJECT_NAME                          OBJECT_BLOCKS CACHED_BLOCKS
KEEP    TEST_SCHEMA                    PK_INDEX                                    24064         10854Question -
1. Is this index really in KEEP status under default BUFFER POOL?
2. If this index is in KEEP, does it mean that it will "always" be in buffer?
3. If not, then what should we do so that a segment remains in the buffer cache all the time.
Thanks!
Edited by: user608897 on Mar 2, 2011 9:45 AM
Edited by: user608897 on Mar 2, 2011 9:46 AM
Edited by: user608897 on Mar 2, 2011 9:49 AM

Hello,
Here are the steps I followed for pinning this Index on memory.
alter system set db_keep_cache_size=2000M scope=both;
SQL> sho parameter db_keep_cache_size
NAME                                 TYPE        VALUE
db_keep_cache_size                   big integer 2016M
ALTER INDEX [SCHEMA].[INDEX] STORAGE (BUFFER_POOL KEEP);
SELECT /*+ INDEX ([SCHEMA].[INDEX]) */
FROM [SCHEMA].[TABLE];
set linesize 132
COL OBJECT_NAME FORMAT A30
SELECT ds.buffer_pool, do.owner, do.object_name OBJECT_NAME,
ds.blocks OBJECT_BLOCKS, COUNT(*) CACHED_BLOCKS
FROM dba_objects do, dba_segments ds, v$bh v
WHERE do.data_object_id=V.OBJD
AND do.owner=ds.owner(+)
AND do.object_name=ds.segment_name(+)
AND DO.OBJECT_TYPE=DS.SEGMENT_TYPE(+)
AND ds.buffer_pool ='KEEP'
GROUP BY ds.buffer_pool, do.owner, do.object_name, ds.blocks
ORDER BY do.owner, do.object_name, ds.buffer_pool;
BUFFER_ OWNER                          OBJECT_NAME                    OBJECT_BLOCKS CACHED_BLOCKS
KEEP    [SCHEMA]                [INDEX]                      234496          7313
As the "SELECT" statements are running, I can see the buffer cache being populated with the blocks from this index using the following query:
--- QUERY1
select
b.object_name,b.subobject_name,count(*)
from
v$bh a,dba_objects b
where
b.object_name = '[INDEX]'
and
b.owner = '[SCHEMA]'
and
b.object_id = a.objd and a.status != 'free'
group by
b.object_name,b.subobject_name
order by 3
desc;
I'm using the following query to determine when my db_keep_cache_size is approaching capacity:
--- QUERY2
select
(sum(count(*))*8192)/1024/1024 BUFFER_KEEP_USED_IN_MB
from
v$bh a,
dba_objects b
where
b.object_name = '[INDEX]'
and
b.owner = '[SCHEMA]'
and
b.object_id = a.objd and a.status != 'free'
group by
b.object_name,b.subobject_name;Following issue has been seen by another forum member also but there is no explanation to that. Since my problem is also same, I am putting same questions here -
What I've noticed is that as the blocks are being cached, the index that were cached first are being aged out.
I know this is normal behavior if you reach the capacity of your buffer keep pool size but according to QUERY2 above I am not even close to reaching 2G.
Why aren't the blocks remaining in the buffer cache? Is QUERY2 accurately depicting the usage of my buffer keep pool?
Secondly, If this index is of 1.5GB and KEEP_POOL size is 2GB then will the following sql make sure that the whole index will be avaliable in in buffer "all the time" as there is no other segment in the KEEP BUFFER POOL
ALTER INDEX [SCHEMA].[INDEX] STORAGE (BUFFER_POOL KEEP);
Thanks!

Table size exceeds Keep Pool Size (db_keep_cache_size)

Hello,
We have a situation where one of our applications started performing bad since last week.
After some analysis, it was found this was due to data increase in a table that was stored in KEEP POOL.
After the data increase, the table size exceeded db_keep_cache_size.
I was of the opinion that in such cases KEEP POOL will still be used but the remaining data will be brought in as needed from the table.
But, I ran some tests and found it is not the case. If the table size exceeds db_keep_cache_size, then KEEP POOL is not used at all.
Is my inference correct here ?
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - ProductionSetup
SQL> show parameter keep
NAME                                 TYPE        VALUE
buffer_pool_keep                     string
control_file_record_keep_time        integer     7
db_keep_cache_size                   big integer 4M
SQL>
SQL>
SQL> create table t1 storage (buffer_pool keep) as select * from all_objects union all select * from all_objects;
Table created.
SQL> set autotrace on
SQL>
SQL> exec print_table('select * from user_segments where segment_name = ''T1''');
PL/SQL procedure successfully completed.
SQL> set serveroutput on
SQL> exec print_table('select * from user_segments where segment_name = ''T1''');
SEGMENT_NAME                  : T1
PARTITION_NAME                :
SEGMENT_TYPE                  : TABLE
SEGMENT_SUBTYPE               : ASSM
TABLESPACE_NAME               : HR_TBS
BYTES                         : 16777216
BLOCKS                        : 2048
EXTENTS                       : 31
INITIAL_EXTENT                : 65536
NEXT_EXTENT                   : 1048576
MIN_EXTENTS                   : 1
MAX_EXTENTS                   : 2147483645
MAX_SIZE                      : 2147483645
RETENTION                     :
MINRETENTION                  :
PCT_INCREASE                  :
FREELISTS                     :
FREELIST_GROUPS               :
BUFFER_POOL                   : KEEP
FLASH_CACHE                   : DEFAULT
CELL_FLASH_CACHE              : DEFAULT
PL/SQL procedure successfully completed.DB_KEEP_CACHE_SIZE=4M
SQL> select count(*) from t1;
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          9 recursive calls
          0 db block gets
       2006 consistent gets
       2218 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> /
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
       1940 consistent gets
       1937 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processedDB_KEEP_CACHE_SIZE=10M
SQL> connect / as sysdba
Connected.
SQL>
SQL> alter system set db_keep_cache_size=10M scope=both;
System altered.
SQL>
SQL> connect hr/hr@orcl
Connected.
SQL>
SQL> show parameter keep
NAME                                 TYPE        VALUE
buffer_pool_keep                     string
control_file_record_keep_time        integer     7
db_keep_cache_size                   big integer 12M
SQL>
SQL> set autotrace on
SQL>
SQL> select count(*) from t1;
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
       1940 consistent gets
       1937 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> /
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
       1940 consistent gets
       1937 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processedDB_KEEP_CACHE_SIZE=20M
SQL> connect / as sysdba
Connected.
SQL>
SQL> alter system set db_keep_cache_size=20M scope=both;
System altered.
SQL>
SQL> connect hr/hr@orcl
Connected.
SQL>
SQL> show parameter keep
NAME                                 TYPE        VALUE
buffer_pool_keep                     string
control_file_record_keep_time        integer     7
db_keep_cache_size                   big integer 20M
SQL> set autotrace on
SQL> select count(*) from t1;
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
       1943 consistent gets
       1656 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> /
COUNT(*)
    135496
Execution Plan
Plan hash value: 3724264953
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   538   (1)| 00:00:07 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   |   126K|   538   (1)| 00:00:07 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
          0 recursive calls
          0 db block gets
       1943 consistent gets
          0 physical reads
          0 redo size
        424 bytes sent via SQL*Net to client
        419 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processedOnly with 20M db_keep_cache_size I see no physical reads.
Does it mean that if the db_keep_cache_size < table size, there is no caching for that table ?
Or am I missing something ?
Rgds,
Gokul

Hello Jonathan,
Many thanks for your response.
Here is the test I ran;
SQL> select buffer_pool,blocks from dba_tables where owner = 'HR' and table_name = 'T1';
BUFFER_     BLOCKS
KEEP          1977
SQL> select count(*) from v$bh where objd = (select data_object_id from dba_objects where owner = 'HR' and object_name = 'T1');
COUNT(*)
      1939
SQL> show parameter db_keep_cache_size
NAME                                 TYPE        VALUE
db_keep_cache_size                   big integer 20M
SQL>
SQL> alter system set db_keep_cache_size = 5M scope=both;
System altered.
SQL> select count(*) from hr.t1;
COUNT(*)
    135496
SQL> select count(*) from v$bh where objd = (select data_object_id from dba_objects where owner = 'HR' and object_name = 'T1');
COUNT(*)
       992I think my inference is wrong and as you said I am indeed seeing the effect of tail end flushing the start of the table.
Rgds,
Gokul

Cannot Load Index Into Keep Pool

I've sucessfully loaded my ctxsys.context index into the keep pool (works great) using the web page: http://www.oracle.com/technology/products/text/htdocs/mem_load.html .
I'm now trying the techniques to load a regular index (that joins to my text index).
I've executed:
alter index PROD_SVC_NDX storage (buffer_pool keep);
Then I tried the hint INDEX_FFS on the base table:
select /*+ INDEX_FFS ( INDEXDATA , PROD_SVC_NDX ) */ count(svc_code) FROM INDEXDATA ;
The optimizer shows a ffs in the algorithm:
INDEX FAST FULL SCAN| PROD_SVC_NDX |524K| 2047K|251 (2)| 0:00:04
WHEN I QUERY THE BUFFER CACHE, only 9% of the index is in the keep pool..
Owner............. Name...........................Type...........Cache....... %BLOCKS........POOL........BSize
SYSTEM.......PROD_SVC_NDX...........INDEX..........1,248.................9..............KEEP.........8,192.
How do you load regular index blocks into keep pool?
What would be the best Oracle forum for this question?
Joe

I think the optimizer will always use a full scan for such a query, regardless of hints. What you need to do is fetch all rows individually. This can be done in a PL/SQL block with an outer loop which fetches all the indexed values, and an inner select that performs an indexed lookup with each value. For example:
Given a table with a primary key index:
create table foo (pk number primary key, bar varchar2);
Populated:
insert into foo values (1, 'aa');
insert into foo values (2, 'ab');
insert into foo values (3, 'ac');
We could do this:
declare
v_bar varchar2(2);
begin
for q in (select pk from foo) loop
select bar into v_bar from foo where pk = q.pk;
end loop;
end;
It may well not be necessary to fetch every row - you should experiment and see whether maybe fetching every 10th row - or even every 100th row - is sufficient to fetch all index blocks into the SGA.
- Roger

ODI 10g - session keep a table locked

Hi,
We have a random issue, with ODI session that keep a lock on a table, even replication is finished and session becomes inactive
It generated dead locks as a trigger has to update the target table.
what happened :
- user application create rows (13)
- ODI scenario replicate the rows (contract table)
- 2nd scenario based on same source with another sunscriber run a stored procedure to create records in another table (around 30, positions table)
this 2nd locked the target table, and when the run of the procedure finished, and commited, the lock was not released
- ODI replicate another table (price) 30mn later, a trigger on target update position table with new values
---> trigger failed with deadlock (ora 60)
---> ODI failed as the trigger raised back the error
this issue happened after 10 hours of same activity without issue, chained lot of time, but suddenly the lock become persistent (more than 4 hours)
what can I do?
use ODI 10g 10.1.3.5.0 - RDBMS 10.2.0.4

Hi !
For small tables wich are mostly accessed with full table scan you can use
ALTER TABLE <table_name> STORAGE (BUFFER_POOL KEEP);KEEP pool should be properly sized , setting will cause once the table is read oracle will avoid flushing it out from pool.
T

Db_keep_cache_size shows 0 when i keep object in KEEP buffer pool !

Dear Frineds ,
I use Oracle 10g . Form the oracle 10g documentaiton, I get the following information regarding ASMM (Automatic Shared Memory Management) :
The following pools are manually sized components and are not affected by Automatic Shared Memory Management:
Log buffer
Other buffer caches (such as KEEP, RECYCLE, and other non-default block size)
Fixed SGA and other internal allocations
Now plz see the following examle :
1) SQL> select sum(bytes)/1024/1024 " SGA size used in MB" from v$sgastat where name!='free memory';
SGA size used in MB
247.09124
2) SQL> show parameter keep_
NAME TYPE VALUE
db_keep_cache_size big integer 0 (Here db_keep_cache_size is 0 )
3) Now I keep the scott's dept table to KEEP cache :
SQL> select owner,segment_type,segment_name,buffer_pool from dba_segments where buffer_pool != 'DEFAULT';
no rows selected
SQL> alter table scott.dept storage(BUFFER_POOL KEEP);
Table altered.
SQL> select owner,segment_type,segment_name,buffer_pool from dba_segments where buffer_pool != 'DEFAULT';
OWNER SEGMENT_TYPE SEGMENT_NAME
SCOTT TABLE DEPT
4)
After doing this , I have to see the following parameter :
SQL> show parameter keep
NAME TYPE VALUE
db_keep_cache_size big integer 0
SQL> select sum(bytes)/1024/1024 " SGA size used in MB" from v$sgastat where name!='free memory';
SGA size used in MB
246.76825
Here I see that my sga is used but "db_keep_cache_size" still shows the '0' .
Can u plz explain why this parameter value shows '0' now ?
Thx in advance ... ...

Hi,
I am not sure I have understood the question fully but if you are trying to monitor usage of the buffer pools you should use some of the dynamic views like in the example query below. If this is not what you are interested in let me know.
SELECT NAME, BLOCK_SIZE, SUM(BUFFERS)
FROM V$BUFFER_POOL
GROUP BY NAME, BLOCK_SIZE
HAVING SUM(BUFFERS) > 0;

KEEP POOL and count(*)

Hello,
I resized db_keep_cache_size and altered tables and indexes -> storage (buffer_pool keep).
Now, I think, I have to select * from tables.
Is command select count(*) from table an equivalent please ?
If I run select count(*), Disk activity is on 100% and it takes 2minutes. But when I run script, where is
set termout off
select * from table;
set termout on
It takes very very long time and activity is maybe on 5%. Could you help me with this please ?
Thank you very much! :)

Ondrej T. wrote:
I'm creating application, only for one user. Data from tablespace are static - writing is not possible. Only reading.
There are 4 tables ( 7+7+3+18 ) GB.
I want to put them into keep pool. ( allocated 40GB)
I altered tables and indexes. But the data will be in pull after execution
select * from tables
When I run this command, execution is very slow. Disk usage - 5%.
1) Why? Termout is off...
When I run app, there will be checkout if the tables are in pool, if not(server restart), it will execute select * from tables.
So, why is it too slow?
( When I run select count(*) from table , disk usage is 100% )Reading 40G data from disk will take a while. Btw, do you have enough RAM to keep indexes of these tables?
Have you waited until your first select complete? What about second run?
Why don't you use an in-memory database solution such as TimesTen?
Regards
Gokhan

Buffer_pool & db_keep_cache_size

Our database is 10.2.0.3 with 2 nodes RAC. The database servers are window 2003.
I ran the query “select * from dba_tables where buffer_pool = 'KEEP'” and get 6 records come back. Some tables are pretty big.
I ran “select sum(blocks) * 8192 from dba_tables where buffer_pool = 'KEEP'” and get:
5489451008
The parameter for db_keep_cache_size is 1073741824 for both instances.
My question is: How Oracle handles this if Oracle allocated memory is smaller than the requested space? What are the impacts on the performance?
Thanks,
Shirley

Yes, a buffer pool is a buffer pool and is managed as such. Each type of pool may have has some unique logic especially for how data is selected to go into the pool (keep, recycle, 16K block size, 2K block size) but when all else is said and done the end product is a buffer cache that has to be managed.
Personally, I am not a fan of using multiple buffer pools. For most situations Oracle can probably do a better job of deciding what blocks to keep and purge from one large buffer cache than most DBA's can do by using the normal buffer cache, a keep, and a recycle pool. Over time the application data and usage changes. The pool configuration probably is not checked regularly enough to keep it properly aligned.
Besides Oracle really uses a modified for touch count algorithm to manage the buffer cache instead of the documented LRU. Call it a modified LRU algorithm so the need to use a keep and/or recycle really isn’t there for most shops.
IMHO -- Mark D Powell --

How to keep a table in memory in Oracle 10g

How to keep a table in memory in Oracle 10g

Hi !
For small tables wich are mostly accessed with full table scan you can use
ALTER TABLE <table_name> STORAGE (BUFFER_POOL KEEP);KEEP pool should be properly sized , setting will cause once the table is read oracle will avoid flushing it out from pool.
T

FTS on small Materialized View, should I cache it in the KEEP Pool ?

Hi all,
I have a small MV (1773 rows) that is used in a Query JOIN (the query & the explain plan is attached below). Although I already create index for the MV, it is always FTS in the query.
I read a Tuning tips, that FTS on small table should be cached in the KEEP POOL, with this command :
ALTER TABLE ITT.MV_CONVERT_UOM STORAGE (BUFFER_POOL KEEP);
Should I do this ?
Thank you for your help,
xtanto.
Query & explain PLAN :
SELECT so_id_hdr, product_ord, qty_ord, UOM, MV.UOM_B, MV.UOM_K
FROM SALESORDER_D SOD
JOIN MV_CONVERT_UOM MV ON MV.PRODUCT = SOD.PRODUCT_ORD
WHERE SO_id_hdr = 31944
Plan hash value: 1323612888
| Id | Operation                         | Name             | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                  |                  |     5 |   225 |     5 (20)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR                   |                  |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)             | :TQ10001         |     5 |   225 |     5 (20)| 00:00:01 | Q1,01 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                      |                  |     5 |   225 |     5 (20)| 00:00:01 | Q1,01 | PCWP |            |
|   4 |     BUFFER SORT                   |                  |       |       |            |          | Q1,01 | PCWC |            |
|   5 |      PX RECEIVE                   |                  |     5 |   135 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
|   6 |       PX SEND BROADCAST           | :TQ10000         |     5 |   135 |     2   (0)| 00:00:01 |        | S->P | BROADCAST |
|   7 |        TABLE ACCESS BY INDEX ROWID| SALESORDER_D     |     5 |   135 |     2   (0)| 00:00:01 |        |      |            |
|* 8 |         INDEX RANGE SCAN          | SALESORDER_D_FKH |     5 |       |     1   (0)| 00:00:01 |        |      |            |
|   9 |     PX BLOCK ITERATOR             |                  | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWC |            |
| 10 |      MAT_VIEW ACCESS FULL         | MV_CONVERT_UOM   | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
Predicate Information (identified by operation id):
   3 - access("MV"."PRODUCT"="SOD"."PRODUCT_ORD")
   8 - access("SOD"."SO_ID_HDR"=31944)

Hi Leo, below is execution plan for the query you gave :
Plan hash value: 1323612888
| Id | Operation                         | Name             | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                  |                  |     5 |   200 |     5 (20)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR                   |                  |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)             | :TQ10001         |     5 |   200 |     5 (20)| 00:00:01 | Q1,01 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                      |                  |     5 |   200 |     5 (20)| 00:00:01 | Q1,01 | PCWP |            |
|   4 |     BUFFER SORT                   |                  |       |       |            |          | Q1,01 | PCWC |            |
|   5 |      PX RECEIVE                   |                  |     5 |   110 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
|   6 |       PX SEND BROADCAST           | :TQ10000         |     5 |   110 |     2   (0)| 00:00:01 |        | S->P | BROADCAST |
|   7 |        TABLE ACCESS BY INDEX ROWID| SALESORDER_D     |     5 |   110 |     2   (0)| 00:00:01 |        |      |            |
|* 8 |         INDEX RANGE SCAN          | SALESORDER_D_FKH |     5 |       |     1   (0)| 00:00:01 |        |      |            |
|   9 |     PX BLOCK ITERATOR             |                  | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWC |            |
| 10 |      MAT_VIEW ACCESS FULL         | MV_CONVERT_UOM   | 1773 | 31914 |     2   (0)| 00:00:01 | Q1,01 | PCWP |            |
------------I have tried using index hints like below, but it stil FTS.
EXPLAIN PLAN FOR
SELECT /*+ INDEX(MV_CONVERT_UOM MV_CONVERT_UOM_IDX1) */sod.so_id_hdr ,sod.product_ord ,
     sod.qty_ord ,sod.uom ,mv.uom_b ,
     mv.uom_k FROM SALESORDER_D sod ,
     MV_CONVERT_UOM mv WHERE mv.product = sod.product_ord AND
     sod.so_id_hdr = 31944
what to do now ?
Thank you,
xtanto

KEEP and RECYCLE buffer pools question...

About the DB buffer cache's two optional buffer pools: KEEP and RECYCLE pools.
If i want a table to be kept in KEEP buffer pool, can i specify that in CREATE TABLE or ALTER TABLE syntax? Or is it possible only at tablespace level?

HI,
You can keep tables at keep pool by specifying storage (buffer_pool keep) parameter.

Buffer_pool keep

Similar Messages

Maybe you are looking for