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 --

Similar Messages

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....

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

Db_keep_cache_size aging

Database Version: 10.2.0.4
OS: RHEL 4
SGA_MAX_SIZE=25G
SGA_TARGET=10G
Database block size=8K
I am trying to cache the most recent 20 or so partitions of an index.
No objects in my database were using the buffer keep pool before now.
I did the following to accomplish this:
alter system set sga_target=20G scope=both;
alter system set db_keep_cache_size = 10G scope=both;
ALTER INDEX [INDEX_NAME] modify PARTITION PART1 storage (buffer_pool keep);
ALTER INDEX [INDEX_NAME] modify PARTITION PART2 storage (buffer_pool keep);
ALTER INDEX [INDEX_NAME] modify PARTITION PART3 storage (buffer_pool keep);
SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR1);
SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR2);
SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR3);
As the "SELECT" statements are running, I can see the buffer cache being populated with the blocks from this index's partitions 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_NAME]'+
+     and+
+     b.owner = '[OWNER]'+
+     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_NAME]'+
+     and+
+     b.owner = '[OWNER]'+
+     and+
+     b.object_id = a.objd and a.status != 'free'+
group by
+     b.object_name,b.subobject_name;+
My Problems/Questions:
What I've noticed is that as the blocks are being cached, the index partitions 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 10G.
Why aren't the blocks remaining in the buffer cache? Is QUERY2 accurately depicting the usage of my buffer keep pool?
I have already verified that this index's partitions are the only objects setup for my keep cache. (SELECT * fROM DBA_OBJECTS WHERE BUFFER_POOL <> 'DEFAULT')

SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR1);
SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR2);
SELECT /*+ INDEX ([INDEX_NAME]) */ ... FROM [TABLE_NAME] partition (PAR3);Just to clarify.
Do above queries follow index scan?
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
http://dioncho.blogspot.com (japanese)
http://ask.ex-em.com (q&a)
================================

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 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!

Three questions regarding DB_KEEP_CACHE_SIZE and caching tables.

Folks,
In my Oracle 10g db, which I got in legacy. It has the init.ora parameter DB_KEEP_CACHE_SIZE parameter configured to 4GB in size.
Also there are bunch of tables that were created with CACHE turned on for them.
By querying dba_tables table , with CACHE='Y', I can see the name of these tables.
With time, some of these tables have grown in size (no. of rows) and also some of these tables are not required to be cached any longer.
So here is my first question
1) Is there a query I can run , to find out , what tables are currently in the DB_KEEP_CACHE_SIZE.
2) Also how can I find out if my DB_KEEP_CACHE_SIZE is adqueataly sized or needs to be increased in size,as some of these
tables have grown in size.
Third question
I know for fact, that there are 2 tables that do not need to be cached any longer.
So how do I make sure they do not occupy space in the DB_KEEP_CACHE_POOL.
I tried, alter table <table_name> nocache; statement
Now the cache column value for these in dba_tables is 'N', but if I query the dba_segments tables, the BUFFER_POOL column for them still has value of 'KEEP'.
After altering these tables to nocache, I did bounce my database.
Again, So how do I make sure these tables which are not required to be cached any longer, do not occupy space in the DB_KEEP_CACHE_SIZE.
Would very much appreciate your help.
Regards
Ashish

Hello,
1) Is there a query I can run , to find out , what tables are currently in the DB_KEEP_CACHE_SIZE:You may try this query:
select owner, segment_name, segment_type, buffer_pool
from dba_segments
where buffer_pool = 'KEEP'
order by owner, segment_name;
2) Also how can I find out if my DB_KEEP_CACHE_SIZE is adqueataly sized or needs to be increased in size,as some of these tables have grown in size.You may try to get the total size of the Segments using the KEEP BUFFER:
select sum(bytes)/(1024*10124) "Mo"
from dba_segments
where buffer_pool = 'KEEP';To be sure that all the blocks of these segments (Table / Index) won't be often aged out from the KEEP BUFFER, the total size given by the above query should be less than the size of your KEEP BUFFER.
I know for fact, that there are 2 tables that do not need to be cached any longer.
So how do I make sure they do not occupy space in the DB_KEEP_CACHE_POOL.You just have to execute the following statement:
ALTER TABLE <owner>.<table> STORAGE(BUFFER_POOL DEFAULT);Hope this help.
Best regards,
Jean-Valentin

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

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

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

Db_keep_cache_size and cache in dba_tables

Hello All:
I have recently alter a table to cache it in db_keep_cache pool however i do not see the change reflected in dba_tables in cache column. Is this expected behaviour?
Thanks
S~

The CACHE clause is specified when you create the table. It indicates how the blocks of this table handled in regular buffer cache. It's separate setting from keep cache.
CACHE
For data that is accessed frequently, this clause indicates that the blocks retrieved for this table are placed at the most recently used end of the least recently used (LRU) list in the buffer cache when a full table scan is performed. This attribute is useful for small lookup tables.
Once you put your table in keep pool, the BUFFER_POOL should indicate which pool this object belong to.
select buffer_pool from dba_tables
2 where table_name='TEST1'
3 /
BUFFER_
KEEP

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, 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

(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

ASMM - DB_KEEP_CACHE_SIZE

Hello colleagues
10.2.0.2 - MS2003 SP2
I'm using ASMM and I like to pin a frequently scanned table to the KEEP buffer. The parameter DB_KEEP_CACHE_SIZE is per default 0. Do I have to change this parameter to the size of the object (at least) I like to pin?
If I set a fixed size of e.g. 200M - is this space allocated as one piece and not used anymore by other SGA components or is the "unused" space still available?
How can I prove that my object is located in the KEEP cache?
Thx for your hints.
TonyDBA

Hello colleagues
10.2.0.2 - MS2003 SP2
I'm using ASMM and I like to pin a frequently scanned table to the KEEP buffer. The parameter DB_KEEP_CACHE_SIZE is per default 0. Do I have to change this parameter to the size of the object (at least) I like to pin?
If I set a fixed size of e.g. 200M - is this space allocated as one piece and not used anymore by other SGA components or is the "unused" space still available?
How can I prove that my object is located in the KEEP cache?
Thx for your hints.
TonyDBA
Keep buffer usually to keep small, almost never updated table which used as look up table.
Set DB_KEEP_CACHE_SIZE size big enough to keep the table. Memory allocated for DB_KEEP_CACHE_SIZE will not be used by other component of SGA.
Use below query to check the tables that sitting on buffer cache:
select
object_name c1,
object_type c2,
num_blocks c3,
(num_blocks/decode(sum(blocks), 0, .001, sum(blocks)))*100 c4
from
(select
o.object_name object_name,
o.object_type object_type,
count(1) num_blocks
from
dba_objects o,
v$bh bh
where
o.object_id = bh.objd
and
o.owner not in ('SYS','SYSTEM')
group by
o.object_name,
o.object_type)
t1,
dba_segments s
where
s.segment_name = t1.object_name
and
num_blocks > 10
group by
object_name,
object_type,
num_blocks
order by
num_blocks desc
regards
AM

Buffer_pool & db_keep_cache_size

Similar Messages

Maybe you are looking for