Pinning blocks to the Buffer Cache

Does any one remember how you can pin data buffers to the buffer cache so they don't get cycled out ? The shared pool has dbms_shared_pool.KEEP for library caches. I thought there was something like this for the buffer cache as well ? Can't find it.
thx,
RP. Use ALTER TABLE <table_name> CACHE;
and that will cache the table in the buffer pool. Or in the future (or if you recreate the table as CREATE TABLE . . . AS SELECT) the CACHE argument can be added to the CREATE TABLE statement;

Similar Messages

Understanding the buffer cache architecture

1st Question :
When we want to modify a single record in block ( which has multiple records), does the oracle process reads that particular record into the buffer cache or it will read the entire block into the buffer cache?
2nd Question : Metalink note 62172.1 says --- The cache may hold more than one copy of a block from different points in time . Can some one explain me why it is architected in this manner.
3rd Question : By increasing the pctfree , how can we over come the 'cache buffers chains' latch . How the less rows per block will reduce the contention to 'cache buffers chains' latch .
Thanks
Naveen
Edited by: Naveen Sangam on Jul 15, 2009 8:07 AM

Naveen Sangam wrote:
1st Question :
When we want to modify a single record in block ( which has multiple records), does the oracle process reads that particular record into the buffer cache or it will read the entire block into the buffer cache?It will be always a block by block access. That's why it is suggested that choose your block size properly so that you wont' waste the memory of the cache. Oh god, what did I just write :-) ?
>
2nd Question : Metalink note 62172.1 says --- The cache may hold more than one copy of a block from different points in time . Can some one explain me why it is architected in this manner.Yes, that's correct. This is the concept that makes Oracle, well Oracle. In Oracle. the isolation level is set to Read Committed which means, any dirty read wont' be allowed within oracle. So when you change a buffer and its still haven't got a commit, oracle would not let anyone else read the same buffer in its current state. This buffer's old image would be used by oracle to satisfy the read request of the user. For this, the concept of Multiversoning or Read Consitancy comes into the picture. For an dirty buffer, oralce prepares a Snapshot/Consistent Read(CR) buffer in the same hash bucket. This buffer is given to the user. That's why there can be more than one copy of the changed buffer be there in the cache , depending on the requests issued by the users.
3rd Question : By increasing the pctfree , how can we over come the 'cache buffers chains' latch . How the less rows per block will reduce the contention to 'cache buffers chains' latch .I am not sure how did you make up this link? The only thing that ML note is saying that there should be less number of rows within a block so that a single block doesn't become a "hot spot" . The less number of rows, the less contention would be there over it. How did you link up this with the CBC Chain lathc?
HTH
Aman....

10G NEW FEATURE-HOW TO FLUSH THE BUFFER CACHE

제품 : ORACLE SERVER
작성날짜 : 2004-05-25
10G NEW FEATURE-HOW TO FLUSH THE BUFFER CACHE
===============================================
PURPOSE
이 자료는 Oracle 10g new feature 로 manual 하게
buffer cache 를 flush 할 수 있는 기능에 대하여 알아보도록 한다.
Explanation
Oracle 10g 에서 new feature 로 소개된 내용으로 SGA 내 buffer cache 의
모든 data 를 command 수행으로 clear 할 수 있다.
이 작업을 위해서는 "alter system" privileges 가 있어야 한다.
Buffer cache flush 를 위한 command 는 다음과 같다.
주의) 이 작업은 database performance 에 영향을 줄 수 있으므로 주의하여 사용하여야 한다.
SQL > alter system flush buffer_cache;
Example
x$bh 를 query 하여 buffer cache 내 존재하는 정보를 확인한다.
x$bh view 는 buffer cache headers 정보를 확인할 수 있는 view 이다.
우선 test 로 table 을 생성하고 insert 를 수행하고
x$bh 에서 barfil column(Relative file number of block) 과 file# 를 조회한다.
1) Test table 생성
SQL> Create table Test_buffer (a number)
2 tablespace USERS;
Table created.
2) Test table 에 insert
SQL> begin
2 for i in 1..1000
3 loop
4 insert into test_buffer values (i);
5 end loop;
6 commit;
7 end;
8 /
PL/SQL procedure successfully completed.
3) Object_id 확인
SQL> select OBJECT_id from dba_objects
2 where object_name='TEST_BUFFER';
OBJECT_ID
42817
4) x$bh 에서 buffer cache 내에 올라와 있는 DBARFIL(file number of block) 를 조회한다.
SQL> select ts#,file#,dbarfil,dbablk,class,state,mode_held,obj
2 from x$bh where obj= 42817;
TS# FILE# DBARFIL DBABLK CLASS STATE MODE_HELD J
9 23 23 1297 8 1 0 7
9 23 23 1298 9 1 0 7
9 23 23 1299 4 1 0 7
9 23 23 1300 1 1 0 7
9 23 23 1301 1 1 0 7
9 23 23 1302 1 1 0 7
9 23 23 1303 1 1 0 7
9 23 23 1304 1 1 0 7
8 rows selected.
5) 다음과 같이 buffer cache 를 flush 하고 위 query 를 재수행한다.
SQL > alter system flush buffer_cache ;
SQL> select ts#,file#,dbarfil,dbablk,class,state,mode_held,obj
2 from x$bh where obj= 42817;
6) x$bh 에서 state column 이 0 인지 확인한다.
0 은 free buffer 를 의미한다. flush 이후에 state 가 0 인지 확인함으로써
flushing 이 command 를 통해 manual 하게 수행되었음을 확인할 수 있다.
Reference Documents
<NOTE. 251326.1>

I am also having the same issue. Can this be addressed or does BEA provide 'almost'
working code for the bargin price of $80k/cpu?
"Prashanth " <[email protected]> wrote:
>
Hi ALL,
I am using wl:cache tag for caching purpose. My reqmnt is such that I
have to
flush the cache based on user activity.
I have tried all the combinations, but could not achieve the desired
result.
Can somebody guide me on how can we flush the cache??
TIA, Prashanth Bhat.

" unable to allocate space from the buffer cache" Message

Hi
I am trying to delete a large volume or records from a BTREE database. I have used the DB_SET_RANGE with a cursor to locate the desired records. After that the Dbc::get() with DB_NEXT is called. After deleting a considerable amount of records I am receiving a message in the error callback function as "unable to allocate space from the buffer cache".
What might be the reason for such a message.
Regards
Nisam

Nisam,
This means that the cache is full and there are no pages that BDB can evict to make space. Are you running with the default cache size? You can increase the cache size by calling: dbenv->set_cachesize or db->set_cachesize.
Related docs:
Selecting a cache size: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/cachesize.html
Bogdan Coman

Unused tables in the buffer cache

I have a program that queries the V$BH view every hour and stores the name of every table in the buffer cache. There is a set of tables that are never used which are appearing in the buffer cache every hour. I did a case insensitive search of the V$SQL and V$SQLTEXT views for these table names, but found nothing. How can tables be put in the buffer cache if there is no SQL statement refering to them? I'd like to find the session and program which is using these tables that no one is supposed to be using.
Kevin Tyson

This can be due to recursive SQL. Means the SQL not fired directly by the app but fired by oracle to satistfy some requirment. It can be related to some system tables or other users tables.
Example of system tables:
Oracle use system tables to reflect the current state of the database like when you insert records it update the extent information and when you create the object it update the data dictionary so that object reflect in that etc etc etc
Example of users tables:
you fired an insert statement to insert one record in table emp but to insert that record oracle has to check the state of foreign key data by querying dept and other tables so enev if you didn't specify dept table oracle use it internally to check the integrity constraint.
Daljit Singh

How to tune effectively to the buffer cache hit ratio?

We have a database with following sga sizes;
shared pool : 256 MB
Buffer Cache: 880 MB
Large pool: 32 MB
Java pool: 32 MB
Total SGA: 1201.435 mb. From the health check, i found Buffer Cache Hit Ratio is giving the trouble. so, i need advice from dba gurus, should Buffer Cache Hit ratio be increase or decreasee, in order to improve the performance?
Please help me
Ateeq

I will generate statspack tommorrow morning when there will be lot of activity on the database. In the meantime, some output from Health check toad are:
->!Buffer Cache Hit Ratio : 82.3246
-->[Segments with > 100 extents] Exec Time 1 seconds
! TABLE IN_CHIYODA.SPEC_REVISION_DOCUMENT_MAIN: 107 Extents
! TABLE EF2_DATA.N3RGRPRGRP: 126 Extents
! TABLE EF2_DATA.N3OBJATTR: 192 Extents
! TABLE EF2_DATA.EFT_UID: 119 Extents
! TABLE EF2_DATA.N2FILEOBJ: 121 Extents
! TABLE EF2_DATA.N2IFOBJ: 211 Extents
! TABLE EF2_DATA.N2REVGRP: 128 Extents
! INDEX EF2_DATA.N3OBJATTR_RLTLEFTRELINDEX: 122 Extents
! INDEX EF2_DATA.N3OBJATTR_RLTRIGHTRELINDEX: 114 Extents
! INDEX EF2_DATA.PK_N3OBJATTR: 119 Extents
! INDEX EF2_DATA.EFI_UID_N1UID: 120 Extents
! INDEX EF2_DATA.EFI_UID_N1OBJOBID: 103 Extents
! INDEX EF2_DATA.N1BOBJOBID_N2IFOBJ: 186 Extents
! INDEX EF2_DATA.N2IFOBJ_N1BOBJOBID: 159 Extents
! INDEX EF2_DATA.N2IFOBJ_N1NAME: 115 Extents
! INDEX EF2_DATA.PK_N2IFOBJ: 158 Extents
! INDEX EF2_DATA.N2IFOBJ_MYINDEX: 187 Extents
Can you advice anthing based on these results.
Thanks

10g RAC - updates immediately reflected (blocks cleared from buffer cache)?

We've recently upgraded to 10g RAC (4 nodes on linux using a netapp filer for storage) and we're seeing some issues with data in our database intermittently looking different than data in our application cache. we're trying to diagnose the issue (app vs. db) and i'm researching any issues with data blocks being cached on a specific node and not being immediately reflected on other nodes? has anyone seen an issue similar to this? i'm not convinced that the problem is in the database given that my research has come up dry but i'm wondering if anyone has seen this?

We've recently upgraded to 10g RAC (4 nodes on linux using a netapp filer for storage) and we're seeing some issues with data in our database intermittently looking different than data in our application cache. we're trying to diagnose the issue (app vs. db) and i'm researching any issues with data blocks being cached on a specific node and not being immediately reflected on other nodes? has anyone seen an issue similar to this? i'm not convinced that the problem is in the database given that my research has come up dry but i'm wondering if anyone has seen this?

Swapping and Database Buffer Cache size

I've read that setting the database buffer cache size too large can cause swapping and paging. Why is this the case? More memory for sql data would seem to not be a problem. Unless it is the proportion of the database buffer to the rest of the SGA that matters.

Well I am always a defender of the large DB buffer cache. Setting the bigger db buffer cache alone will not in any way hurt Oracle performance.
However ... as the buffer cache grows, the time to determine 'which blocks
need to be cleaned' increases. Therefore, at a certain point the benefit of a
larger cache is offset by the time to keep it sync'd to the disk. After that point,
increasing buffer cache size can actually hurt performance. That's the reason why Oracle has checkpoint.
A checkpoint performs the following three operations:
1. Every dirty block in the buffer cache is written to the data files. That is, it synchronizes the datablocks in the buffer cache with the datafiles on disk.
It's the DBWR that writes all modified databaseblocks back to the datafiles.
2. The latest SCN is written (updated) into the datafile header.
3. The latest SCN is also written to the controlfiles.
The following events trigger a checkpoint.
1. Redo log switch
2. LOG_CHECKPOINT_TIMEOUT has expired
3. LOG_CHECKPOINT_INTERVAL has been reached
4. DBA requires so (alter system checkpoint)

Oracle buffer cache size

I need to calculate buffer cache size calculation for get operation.
SELECT o.object_name, h.status, count(*) number_of_blockes
FROM V$BH h, DBA_OBJECTS o WHERE h.objd=o.data_object_id
AND o.owner NOT IN('SYS','SYSTEM','SYSMAN')
AND h.status NOT IN('free')
GROUP BY o.object_name,h.status
ORDER BY count(*) DESC;
Used the above query, so i got the number of blocks used to cache data.
I performed a get operation in one db and number of blocks noticed.
But the problem is same operation in another db shows different number of blocks.
Both db are same configuration.
Anyone notices this issue??

Why do you expect them to be the same?
Oracle version of each database?
Number of objects in each database?
Size of buffer cache in each database?
The amount of query activity that would actually load blocks into the buffer cache in each database is not likely to be "the same".
Identical data can take up a different number of blocks in different databases, depending on how it was loaded, transactions on that data, etc, so the number of blocks used in the buffer cache is likely to be different in different databases, even for the same data set.

How to remove an object from Buffer Cache

Hi,
I have a simple question. How can I remove an object from the Buffer Cache in Oracle 10gR2 ?
I am doing some tuning tasks in a shared development database, so I can't do "alter system flush shared_pool" because it will affect other people who are running their queries. So I want to remove from Buffer Cache only the objects that I know that I am the only reader. I can see the objects that I want to be removed by querying the V$BH view.
By the way, I did some "alter system flush shared_pool" and my objects were not removed from the Buffer Cache, and they are not in the "Keep".
Thanks In Advance,
Christiano

Further more, you can use CACHE | NOCACHE on table level to indicate how you want Oracle handle the data blocks of said table.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_7002.htm#i2215507
CACHE | NOCACHE | CACHE READS
Use the CACHE clauses to indicate how Oracle Database should store blocks in the buffer cache. If you specify neither CACHE nor NOCACHE, then:
In a CREATE TABLE statement, NOCACHE is the default
In an ALTER TABLE statement, the existing value is not changed.
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.
As a parameter in the LOB_storage_clause, CACHE specifies that the database places LOB data values in the buffer cache for faster access.
Restriction on CACHE You cannot specify CACHE for an index-organized table. However, index-organized tables implicitly provide CACHE behavior.
NOCACHE For data that is not accessed frequently, this clause indicates that the blocks retrieved for this table are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is performed. NOCACHE is the default for LOB storage.
As a parameter in the LOB_storage_clause, NOCACHE specifies that the LOB value either is not brought into the buffer cache or is brought into the buffer cache and placed at the least recently used end of the LRU list. The latter is the default behavior.
Restriction on NOCACHE You cannot specify NOCACHE for an index-organized table.
CACHE READS CACHE READS applies only to LOB storage. It specifies that LOB values are brought into the buffer cache only during read operations but not during write operations.

Unexpected CR copies in buffer cache

Hello,
While trying to understand the mechanisms of the Oracle buffer cache I ran a small experiment and observed an unexpected outcome. I believe that my expectation was wrong and I would therefore appreciate, if someone could explain me what I misunderstood.
From what I understood, a consistent read (CR) copy of a buffer in the cache is created, when the old content of a buffer is to be read, e.g. in order to ignore the changes made by a yet uncommitted transaction when querying a table. I also thought, that CR copies in the buffer cache may be reused by subsequent queries that need a rolled back image of the corresponding block.
Now I ran the following experiment on an otherwise idle 10.2 DB.
1. I create a table BC_TEST (in a non-ASSM tablespace)
-> V$BH shows one buffer A with status XCUR for this table - V$BH.CLASS# is 4, which indicates a segment header according to various sources on the internet.
2. Session 1 inserts a row in the table (and doesn't commit)
-> Now V$BH shows 8 buffers with status XCUR belongig to table BC_TEST. I believe this is the blocks from an extent being allocated to the table (I would have expected only one data block to be loaded into the cache in addition to the header that was already there from step 1). There is still the buffer A with CLASS# = 4 from step 1, one buffer B with status XCUR and CLASS# = 1, which indicates a data block according to various sources on the internet, and 6 additional blocks with status FREE and CLASS# = 14 (this value is decoded differently in various internet sources).
3. Session 2 issues a "select * from bc_test"
-> V$BH shows 2 additional buffers with status CR and the identical FILE#/BLOCK# as buffer B from step 2. I understand that one consistent read copy needs to be done in order to revert the uncommitted changes from step 2 - I don't however understand why *2* such copies are created.
Note: With a small variation of the experiment, if I run "select * from bc_test" in Session 2 between step 1 and 2, then I will subsequently only get 1 CR copy in step 3 (as I would expect).
4. Session 2 issues "select * from bc_test" again
-> V$BH shows yet another additional buffer with status CR and the identical FILE#/BLOCK# as buffer B from step 2 (i.e. 3 such buffers in total). Here I don't understand, why the query can't reuse the CR copy already created in step 3 (which already shows buffer B without the changes from the uncommitted transaction in step 2).
5. Session 2 repeatedly issues "select * from bc_test" again
-> The number of buffers with status CR and the identical FILE#/BLOCK# as buffer B from step 2 increases by one with each dditional query up to a total number of 5. After that the number of those buffers remains constant after the further queries. However various statistics for session 2 ('consistent gets', 'CR blocks created', 'consistent changes' ,'data blocks consistent reads - undo records applied' ,'no work - consistent read gets') suggest, that session 2 continues to generate current read copies with every "select * from bc_test" (are the buffers in the buffer cache maybe just reused from that point on?).
To summarize I have the following question:
(I) Why does the insert of a single row (in step 2) load 8 blocks into the buffer cache - and what does the CLASS# = 14 indicate?
(II) Why does the first select on the table (step 3) create 2 CR copies of the (single used) data block of the table (rather than one as I would expect)?
(III)) Why do further queries create CR copies of that single data block (rather than reusing the CR copy created by the first select statement)?
(IV) What limits the number of created CR copies to 5 (is there some parameter controlling this value, is it depending on some cache sizing or is it simply hardcoded)?
(V) What exactly triggers the creation of a CR copy of a buffer in the buffer cache?
Thanks a lot for any reply
kind regards
Martin
P.S. Please find below the protocol of my experiment
Control Session
SQL> drop table bc_test;
Table dropped.
SQL> create table bc_test (col number(9)) tablespace local01;
Table created.
SQL> SELECT bh.file#, bh.block#, bh.class#, bh.status, bh.dirty, bh.temp, bh.ping, bh.stale, bh.direct, bh.new
2 FROM V$BH bh
3 ,dba_objects o
4 WHERE bh.OBJD = o.data_object_id
5 and o.object_name = 'BC_TEST'
6 order by bh.block#;
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     Y N N N N N
Session 1
SQL> insert into bc_test values (1);
1 row created.
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     Y N N N N N
     5     210     1 xcur     Y N N N N N
     5     211     14 free     N N N N N N
     5     212     14 free     N N N N N N
     5     213     14 free     N N N N N N
     5     214     14 free     N N N N N N
     5     215     14 free     N N N N N N
     5     216     14 free     N N N N N N
8 rows selected.
Session 2
SQL> select * from bc_test;
no rows selected
Statistics
     28 recursive calls
     0 db block gets
     13 consistent gets
     0 physical reads
     172 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 xcur     N N N N N N
     5     211     14 free     N N N N N N
     5     212     14 free     N N N N N N
     5     213     14 free     N N N N N N
     5     214     14 free     N N N N N N
8 rows selected.
Session 2
SQL> /
no rows selected
Statistics
     0 recursive calls
     0 db block gets
     5 consistent gets
     0 physical reads
     108 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
SQL>
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 xcur     Y N N N N N
     5     211     14 free     N N N N N N
     5     213     14 free     N N N N N N
     5     214     14 free     N N N N N N
8 rows selected.
SQL>
Session 2
SQL> select * from bc_test;
no rows selected
Statistics
     0 recursive calls
     0 db block gets
     5 consistent gets
     0 physical reads
     108 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
SQL>
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 xcur     Y N N N N N
     5     211     14 free     N N N N N N
     5     213     14 free     N N N N N N
8 rows selected.
Session 2
SQL> select * from bc_test;
no rows selected
Statistics
     0 recursive calls
     0 db block gets
     5 consistent gets
     0 physical reads
     108 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 xcur     Y N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     211     14 free     N N N N N N
     5     213     14 free     N N N N N N
9 rows selected.
Session 2
SQL> select * from bc_test;
no rows selected
Statistics
     0 recursive calls
     0 db block gets
     5 consistent gets
     0 physical reads
     108 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
SQL>
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 xcur     Y N N N N N
7 rows selected.
Session 2
SQL> /
no rows selected
Statistics
     0 recursive calls
     0 db block gets
     5 consistent gets
     0 physical reads
     108 redo size
     272 bytes sent via SQL*Net to client
     374 bytes received via SQL*Net from client
     1 SQL*Net roundtrips to/from client
     0 sorts (memory)
     0 sorts (disk)
     0 rows processed
SQL>
Control Session
SQL> /
FILE# BLOCK#     CLASS# STATUS D T P S D N
     5     209     4 xcur     N N N N N N
     5     210     1 xcur     Y N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
     5     210     1 cr     N N N N N N
7 rows selected.

hi,
To make your code/query results more readable, please enclose it in tag.
I also thought, that CR copies in the buffer cache may be reused by subsequent queries that need a rolled back image of the >corresponding block.I don't think there is any CR copy in cache. Every time a new query reads a consistent image of data, it will read rollback blocks from the buffer cache to generate a consistent image, so there is not any CR copy which could be reused. For testing this, with every "select * from BC_TEST" from second session, every time you will see a new CR in v$bh
There is quite difficult to comment on the topics about merely an iota of resources available on internet.
(I) Why does the insert of a single row (in step 2) load 8 blocks into the buffer cache - and what does the CLASS# = 14 indicate?Difficult go say about class#14 as you know there is not official documentation available.
To insert a row in a block, oracle is picking up the blocks which are free for dta insertion. How and hoe many blocks to pick up, don't know as nothing about this is documented.
(II) Why does the first select on the table (step 3) create 2 CR copies of the (single used) data block of the table (rather than one as I would expect)?Quite difficult to answer, some person like tom Kyte can answer on this i think. First time there are 2 Cr but later only one CR per select statement.
(III)) Why do further queries create CR copies of that single data block (rather than reusing the CR copy created by the first select statement)?Because at a given point in time, a single block may have many versions available in the cache (one session update one row, creating a version of block. Other session inserting a row in the same block, creating another version). At every read, oracle is required to create the latest read consistent image for the session wanting to access the block.
(IV) What limits the number of created CR copies to 5 (is there some parameter controlling this value, is it depending on some cache sizing or is it simply hard coded)?
As far as i know, no parameter is for this and this is oracle internal architecture which is undocumented.
(V) What exactly triggers the creation of a CR copy of a buffer in the buffer cache?As you know that when a session changes a data block (by performing DML on any single or multiple rows), the old image of block is sent to the rollback blocks in the buffer cache and data is modified in the actual block in cache. Another session wants to access the data from the same block but this session should not see the data which has not been committed by the first session so oracle needs to build an image of this datablock for session 2 with its original shape with only the committed data.
If this session 2 will also modify some rows in the block, there is another version of this block in the cache and for session 3, there is required to be another read consistent image to be built.
Salman

Will Oracle look into the database buffer cache in this scenario?

hi guys,
say I have a table with a million rows, there are no indexes on it, and I did a
select * from t where t.id=522,000.
About 5 minutes later (while that particular (call it blockA) block is still in the database buffer cache) I do a
select * from t where t.id >400,000 and t.id < 600,000
Would Oracle still pick blockA up from the database buffer cache? if so, how? How would it know that that block is part of our query?
thanks

Without an Index, Oracle would have done a FullTableScan on the first query. The blocks would be very quickly aged out of the buffer cache as they have been retrieved for an FTS on a large table. It is unlikely that block 'A' would be in the buffer_cache after 5minutes.
However, assuming that block 'A' is still in the buffer_cache, how does Oracle know that records for the second query are in block 'A' ? It doesn't. Oracle will attempt another FullTableScan for the second query -- even if, as in the first query -- the resultset returned is only 1 row.
Now, if the table were indexed and rows were being retrieved via the Index, Oracle would use the ROWID to get the "DBA" (DataBlockAddress) and get the hash value of that DBA to identify the 'cache buffers chain' where the block is likely to be found. Oracle will make a read request if the block is not present in the expected location.
Hemant K Chitale
http://hemantoracledba.blogspot.com

How to clear file cache (or buffer cache?) in the system

i found that after copying a large file, say >200M the system's memory drop 200M exactly until i delete the file. it is suspected that the memory is used for file cache.
After installing memtool, the prtmem command shows the following:
Total memory: 983 Megabytes
Kernel Memory: 106 Megabytes
Application: 193 Megabytes
Executable & libs: 40 Megabytes
File Cache: 495 Megabytes
Free, file cache: 60 Megabytes
Free, free: 87 Megabytes
It shows that nearly 500M of system's memory is used for file cache.
The temporary solution i use now is to copy a large file, say 300M, and delete that file.
eg
cp temp1.txt temp2.txt
rm temp2.txtAnd then most of the file cache will be freed out.
is there any way to release this file cache?
I've checked the system use the default value for the bufhwm parameter. ie, about 20M. however, as i know, this bufhwm parameter is related to buffer cache. is it really related to file cache?

To answer your question directly - delete the file or unmount the file system.
To answer your question indirectly - You are worrying about the wrong thing here. Also the buffer cache is slightly different the file system page cache. The file system page cache is behaving exactly as it should as is the virtual memory subsystem. When a system is operating for some period of time, the amount of free memory will always drop towards LOTSFREE and, if allowed, stay right above LOTSFREE - forever - if the work behavior of the machine stays about the same. This is usually because of the file system page cache.
Its nothing to worry about. Actually you want that to happen. Otherwise your disks would be getting the crap kicked out of them all the time.

Buffer cache hit ration found 99.7%,still the app users complains.

Here in my database,i querey the v$sysstat and found the buffer cache hit ration 99.7% ,by looking that hit ration there is room improvements.
what are the other things which can examine here ?
hare krishna
Alok

As others have said, buffer cache hit ratio is only one of the measurements - and it is often improperly applied, making it worse than useless.
Since this is in production,. it's too late to do anything about the design. So we skip that very important step and go to the SQL statements ...
What are the users complaining about, in detail? Is it the system, or is it a specific operation? Use that knowledge to attempt to define a single SQL statement or a small set of SQL statements, and then start tuning those.
The other possibility, seen A LOT these days, is that the app was written in Visual Basic, .Net or Java and uses the "build the statement on the fly and execute immediate" method. In that case, your server is probably sitting at very high CPU useage and your shared pool is used very inefficiently. Use the V$PGA_TARGET_ADVICE and V$SHARED_POOL_ADVICE views (described in the Administrator's manual and the Performance Tuning manual) to adjust these memory segments properly. All youi can do is alleviate the result of bad development.
And finally, you may simply have gone into swapping or paging, the evil that occurs when you attempt to a) put multiple instances on a server, or b) put the instance and the application background tasks on the same server, or c) do not use PGA_AGGREGATE_TARGET properly.

Database Buffer Cache Doubt

Hi Oracle Community,
We know that Database Buffers will be in 4 modes right??
Free/Empty
Pinned
Dirty and
Clean Buffers.
Dirty buffer has the committed data and when the committed data is written back to disk..the dirty buffer becomes Clean buffer.
Now what my question is..
Which process makes the clean buffers to free/empty buffers??

PrafullaNath wrote:
One more thing Dirty buffers not only means committed data .It may contain uncommitted data.generally dirty buffers means changed block.As per my knowledge when LGWR flush the dirty buffer to disk it cleans the buffer cache.Yes, dirtiness of the buffered block is not related to whether the change has been commited, only to whether the block has been changed in the buffer and the DBWR has not yet modified the block on disk. A block can be clean without the change that has been made to it being commited.

Pinning blocks to the Buffer Cache

Similar Messages

Maybe you are looking for