Will I increase my Buffer Cache ?

Oracle 9i
Shared Pool 2112 Mb
Buffer Cache 1728 Mb
Large Pool 32Mb
Java Pool 32 Mb
Total 3907.358 Mb
SGA Max Size 17011.494 Mb
PGA
Aggregate PGA Target 2450 Mb
Current PGA Allocated 3286059 KB
Maximum PGA Allocated (since Startup) 3462747 KB
Cache Hit Percentage 98.71%
The Buffer Cache Size advise is telling me that if I increase the Buffer Cache to 1930Mb i will get a 8.83 decrease in phyiscal reads (And its get better the more I increase it)
The question is .. can I safely increase it (In light of my current memory allocations) ? Is it worth it .. ?

Two things stand out:
Your sga max size is 17Gb, but you are only using about 4Gb of it - so you seem to have 13Gb that you are not making best use of.
Your pga aggregate target is 2.4Gb, but you've already hit a peak of 3.4Gb - which means your target may be too small - so it's lucky you had all that spare memory which hadn't gone into the SGA. Despite the availability of memory, some of your queries may have been rationed at run-time to try to minimise the excess demand.
Is this OLTP or DSS - where do you really need the memory ? (Have a look in v$process to see the pga usage on a process by process level).
How many processes are allowed to connect to the database ? (You ought to allow about 2Mb - 4Mb per process to the pga_aggregate_target for OLTP) and at least 1Mb per process for the buffer cache.
Where do you see time lost ? time on disk I/O, or time on CPU ? What type of disk I/O, what's the nature of the CPU usage. These figures alone do not tell us what you should do with the spare memory you seem to have.
A simple response to your original question would be that you probably need to increase the pga_aggregate_target, and you might as well increase the buffer size since you seem to have the memory for both.
On the downside, changing the pga_aggregate_target could cause some execution plans to change; and changing the buffer size does change the limit size on a 'short' table, which can cause an increase in I/O as an unlucky side effect if you're a little heavy on "long" tablescans.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Similar Messages

  • Buffer Cache hit ratio low (40.42%)

    Can someone help me with a good guide or advice in order to increase my Buffer Cache hit ratio? If I am not wrong databases should have +85% hit ratio for a good performance.
    thanks

    Here is a script that will bump up your BCHR
    http://www.oracledba.co.uk/tips/choose.htm
    I think you understood from that you shouldn't worry about your bchr but better focus on your real problems i.e. parts of your app that run slowly and people are expecting quicker resposnse.
    Gints Plivna
    http://www.gplivna.eu

  • Buffer Cache Hit

    Hello !
    I am relativelly new to DBA so I have some doubts. I have read that the a high Buffer Cache Hit ratio means that the DB does not have to do so many reads on the disk. I am now checking our production db every day (a third part company istalled EBS and now they have left). The Buffer Cache Hit ratio is always (in the time people are working) on 100% or a bit under (99, 98...). It is ok for the buffer cache to be above 90% but it is also really ok for it to be almoust all the time on 100%? We have a 9.2.0.6 on Win2003 DB, the hit ratio % was read from EM, in SQLPlus:
    SQL> select 1-(sum(decode(name,'physical reads',value,0))/
    2 (sum(decode(name,'db block gets',value,0)) +
    3 (sum(decode(name,'consistent gets',value,0))))) "Hit Ratio"
    4 from v$sysstat;
    Hit Ratio
    ,996897321
    Is this ok?
    Thanks for advices.

    I calculate the physical_reads_per_hour and tune to reduce this by increasing the buffer cache, adding indexes and archiving old rows.
    To see the physical reads per hour, use:
    select
    host_name,instance_name,(round((sysdate-i.startup_time)*100))/100 updays,
    SUM(DECODE(Name, 'consistent gets',Value,0)) consistent,
    ROUND(((SUM(DECODE(Name, 'consistent gets', Value, 0))+
    SUM(DECODE(Name, 'db block gets', Value, 0)) -
    SUM(DECODE(Name, 'physical reads', Value, 0)) )/
    (SUM(DECODE(Name, 'consistent gets',Value,0))+
    SUM(DECODE(Name, 'db block gets', Value, 0)))) *100,2)
    BlkHit,
    round(SUM(DECODE(Name, 'physical reads',Value,0))/to_number(sysdate-i.startup_time)/24) Physrds_per_hour,
    SUM(DECODE(Name, 'consistent gets',Value,0))/to_number(sysdate-i.startup_time)/24 Con_per_hour,
    SUM(DECODE(Name, 'db block gets',Value,0)) Dbblock,
    SUM(DECODE(Name, 'db block gets',Value,0))/to_number(sysdate-i.startup_time)/24 Dbblock_per_hour,
    SUM(DECODE(Name, 'physical reads',Value,0)) Physrds
    from V$SYSSTAT,v$instance i
    group by host_name,instance_name,(sysdate-i.startup_time)
    To see what is taking memory, look for large tables in memory and add indexes:
    set pages 30
    set heading on
    COLUMN OBJECT_in_memory FORMAT A40
    COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
    column meg_in_memory format 9999999999
    SELECT COUNT(*)*8192/1024/1024 meg_in_memory,
    o.object_type,o.OBJECT_NAME Object_in_Memory
    FROM DBA_OBJECTS o, V$BH bh
    WHERE o.DATA_OBJECT_ID = bh.OBJD
    AND o.OWNER != 'SYS'
    and o.object_name like upper('%&object_name%')
    GROUP BY o.OBJECT_NAME,o.object_type
    having count(*)>0
    ORDER BY COUNT(*);
    To see what is taking I/O:
    COLUMN OBJECT_in_memory FORMAT A40
    COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
    column buffers_read_into_memory format 9999999999
    set termout off
    drop table alan9;
    drop table alan10;
    create table alan9 nologging as
    select OBJD,FILE#,BLOCK# from v$bh;
    create table alan10 nologging as
    select OBJD,FILE#,BLOCK# from v$bh
    minus
    select OBJD,FILE#,BLOCK# from alan9;
    set termout on
    SELECT COUNT(*) buffers_read_into_memory,
    o.OBJECT_NAME Object_in_Memory
    FROM DBA_OBJECTS o, alan10 bh
    WHERE o.DATA_OBJECT_ID = bh.OBJD
    AND o.OWNER != 'SYS'
    GROUP BY o.OBJECT_NAME
    having count(*)>0
    ORDER BY COUNT(*);
    set termout off
    drop table alan9;
    drop table alan10;
    set termout on

  • To keep query in buffer cache

    i want to ask how to keep a query in buffer cache always?
    a query which runs frequently in a database will always stay in buffer cache due to LRU. LRU will not allow that query to flush out form buffer cache as it is running frequently.but if i want to place a query explicitly in buffer cache what should i do?please answer it soon..

    i have recently completed the ORACLE DBA courseware and in an interview the interviewer asked me that if he want to place a query explicitly in buffer cache what will i do?
    as a fresher my knowledge is limited and i am trying to improve it continuously..
    while the interviewer was a senior oracle DBA, according to my knowledge i told him that we can keep objects like tables indexes in keep cache by declaring so or if the same query is running continuously it will automatically remain in LRU .putting a query is a new stuff i was searching for it but i wasn't getting answer for it so finally i decided to put this question on forum...
    i am trying hard to get a job as a DBA but all in vain i am nt getting one really it's becoming frustrating for me i have great hopes on oracle and besides hope i like learning oracle from beginning of my graduation thats y i decided to make my career in oracle and specially a DBA...
    now let's see what happens....

  • 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

  • Will increasing the buffer size make flash streaming video stop stalling?

    I have surmised all this on my own so it could be just a fantasy, but:
    I am often the victim of slow internet connections. This means that when I try and watch streaming video it constantly pauses. It's my understanding that increasing the buffer size of flash would help prevent this but I can't figure out how to do that.
    Thanks

    You can pause the video just long enough for the player to load enough content. Most Flash player show a loading bar if you hover the player. For short pieces you can load the entire content before starting the play.

  • How to remove blocks from buffer cache for a specific object

    hi everybody,
    is it possible to remove blocks which belogns to a specific object (a table for ex) from buffer cache.
    as you know, there is
    alter system flush buffer_cache;command but it does it's job for all buffer cache. if you ask me why i want this, for tuning reasons. I want to test some plsql codes when they run as if they are running for the first time (reading from disk).
    ps: I use oracle 11g r2

    Hi mustafa,
    Your performance will not degrade if you run the query second time ( if i understood correctly, you worry about the performance if you execute the procedure second time). Executing/running the code/sql statements over and over again will have following two good benefits.
    1) This will avoid hard parsing (Hard parsing is resource intensive operation and this generally increase the overall processing time.
    2) This will avoid physical read IO (You gonna see the benefits if data blocks already cached and you dont have to spend time in reading blocks from disk. Reading from disk is much costlier and time consuming operation as compared to data in RAM)
    Having that said sometime bad written queries will acquire more blocks then required and consume most part of buffer cache, and this can some times effect the other important blocks and force to flush out from buffer cache.
    Oracle have built some intelligence for large full table scan operations for e.g will doing full table scan(I hope you already know what is fts) oracle will put its blocks at end of LRU chain. So these will be the buffers will would flush out first then any other.
    From oracle documentation:
    "When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list. This is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.
    You can control this default behavior of blocks involved in table scans on a table-by-table basis. To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table or cluster. You can specify this behavior for small lookup tables or large static historical tables to avoid I/O on subsequent accesses of the table."
    Regards
    Edited by: 909592 on Feb 6, 2012 4:37 PM

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

  • 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

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

  • 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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • ESE - Event Log Warning: 906 - A significant portion of the database buffer cache has been written out to the system paging file...

    Hello -
    We have 3 x EX2010 SP3 RU5 nodes in a cross-site DAG.
    Multi-role servers with 18 GB RAM [increased from 16 GB in an attempt to clear this warning without success].
    We run nightly backups on both nodes at the Primary Site.
    Node 1 backup covers all mailbox databases [active & passive].
    Node 2 backup covers the Public Folders database.
    The backups for each database are timed so they do not overlap.
    During each backup we get several of these event log warnings:
     Log Name:      Application
     Source:        ESE
     Date:          23/04/2014 00:47:22
     Event ID:      906
     Task Category: Performance
     Level:         Warning
     Keywords:      Classic
     User:          N/A
     Computer:      EX1.xxx.com
     Description:
     Information Store (5012) A significant portion of the database buffer cache has been written out to the system paging file.  This may result  in severe performance degradation.
     See help link for complete details of possible causes.
     Resident cache has fallen by 42523 buffers (or 27%) in the last 903 seconds.
     Current Total Percent Resident: 26% (110122 of 421303 buffers)
    We've rescheduled the backups and the warning message occurences just move with the backup schedules.
    We're not aware of perceived end-user performance degradation, overnight backups in this time zone coincide with the business day for mailbox users in SEA.
    I raised a call with the Microsoft Enterprise Support folks, they had a look at BPA output and from their diagnostics tool. We have enough RAM and no major issues detected.
    They suggested McAfee AV could be the root of our problems, but we have v8.8 with EX2010 exceptions configured.
    Backup software is Asigra V12.2 with latest hotfixes.
    We're trying to clear up these warnings as they're throwing SCOM alerts and making a mess of availability reporting.
    Any suggestions please?
    Thanks in advance

    Having said all that, a colleague has suggested we just limit the amount of RAM available for the EX2010 DB cache
    Then it won't have to start releasing RAM when the backup runs, and won't throw SCOM alerts
    This attribute should do it...
    msExchESEParamCacheSizeMax
    http://technet.microsoft.com/en-us/library/ee832793.aspx
    Give me a shout if this is a bad idea
    Thanks

  • Find available space in buffer cache

    Hi.
    I want to find available space from buffer cache. First thought was to make it 8i-9i comp, by not using v$bh to calculate sum of memory and available space.
    I have the following pl/sql block to calculate the values:
    declare
    num_free_blck integer;
    num_all_blck integer;
    num_used_blck integer;
    overal_cache number := 0;
    used_cache number := 0;
    free_cache number := 0;
    blck_size integer;
    pct_free number := 0;
    begin
    select count(1) into num_free_blck from v$bh where status='free';
    select count(1) into num_all_blck from v$bh;
    select count(1) into num_used_blck from v$bh where status <> 'free';
    select value into blck_size from v$parameter where name ='db_block_size';
    used_cache := (blck_size * num_used_blck)/(1024*1024);
    free_cache := (blck_size * num_free_blck)/(1024*1024);
    overal_cache := (blck_size * num_all_blck)/(1024*1024);
    pct_free := ((free_cache/overal_cache)*100);
    dbms_output.put_line('There are '||num_free_blck||' free blocks in buffer cache');
    dbms_output.put_line('There are '||num_used_blck||' used block in buffer cache');
    dbms_output.put_line('There are totally '||num_all_blck||' blocks in buffer cache');
    dbms_output.put_line('Overall cache size is '||to_char(overal_cache,'999.9')|| 'mb');
    dbms_output.put_line('Used cache is '||to_char(used_cache,'999.9')||' mb');
    dbms_output.put_line('Free cache is '||to_char(free_cache,'999.9')||' mb');
    dbms_output.put_line('Percent free db_cache is '||to_char(pct_free,'99.9')||' %');
    end;
    The result of the execution is:
    SQL> @c:\temp\bh
    There are 3819 free blocks in buffer cache
    There are 4189 used block in buffer cache
    There are totally 8008 blocks in buffer cache
    Overall cache size is 62.6mb
    Used cache is 32.7 mb
    Free cache is 29.8 mb
    Percent free db_cache is 47.7 %
    PL/SQL-prosedyren ble fullført.
    SQL>
    This is not correct according to the actuall size of the buffer cache:
    SQL> select name,value from v$parameter where name='db_cache_size';
    NAME
    VALUE
    db_cache_size
    67108864
    SQL>
    Anyone that have an idea bout this?
    Thanks
    Kjell Ove

    Mark D Powell wrote:
    select decode(state,0,'Free',
    1,'Read and Modified',
    2,'Read and Not Modified',
    3,'Currently being Modified',
    'Other'
    ) buffer_state,
    count(*)  buffer_count
    from    sys.xx_bh
    group by decode(state,0,'Free',
    1,'Read and Modified',
    2,'Read and Not Modified',
    3,'Currently being Modified',
    'Other'
    Provided the OP figures out that xx_bh is probably a view defined by sys on top of x$bh this will get him the number of free buffers - which may be what he wants - but apart from that your query is at least 10 years short of complete, and the decode() of state 3 is definitley wrong.
    The decode of x$bh.state for 10g is:
         decode(state,
              0,'free',
              1,'xcur',
              2,'scur',
              3,'cr',
              4,'read',
              5,'mrec',
              6,'irec',
              7,'write',
              8,'pi',
              9,'memory',
              10,'mwrite',
              11,'donated'
         ), and for 11g it is:
         decode(state,
               0, 'free',
               1, 'xcur',
               2, 'scur',
               3, 'cr',
               4, 'read',
               5, 'mrec',
               6, 'irec',
               7, 'write',
               8, 'pi',
               9, 'memory',
              10, 'mwrite',
              11, 'donated',
              12, 'protected', 
              13, 'securefile',
              14, 'siop',
              15, 'recckpt',
              16, 'flashfree', 
              17, 'flashcur',
              18, 'flashna'
         ), (At least, that was the last time I looked - they may have changed again in 10.2.0.5 and 11.2.0.2)
    Regards
    Jonathan Lewis

  • How to increase the buffer size ?

    Our BI system displays the following message when I execute a query on the web : buffer too small
    How to increase the buffer size ?
    Thanks in advance

    Indeed, we are using  Bex Web 7.0
    The query uses a big structure and when I execute it on the web, it takes a long time (> 5 min) and I receive folowing message on  top of the result page : " could not buffer query structures. Buffer too small "
    When I execute the query in Bex analyzer, it takes a long time too but we dont get the message
    I have checked the cache size:
          -  Local cache : 100 MB
          - Global cache : 200 MB
    Please let me know any solution as there is no BASIS  TEAM. The guy who installed the soft was a consultant and is no more reachable.
    Thanks in adavnce

  • Many "Flushing buffer cache" in  11.1.0.7

    Hello,
    I am getting "ALTER SYSTEM: Flushing buffer cache" in out alert log continuously . I have not done any buffer pool flushing  but still it coming . does anyone know is there any oracle scheduled job will do this ? or this will happen only by issuing a manual command ?
    Any thoughts will be highly appreciated.
    Thu Jul 11 03:46:27 2013
    Archived Log entry 151129 added for thread 1 sequence 92387 ID 0xc7afa6e dest 1:
    Thu Jul 11 03:48:07 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:50:28 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:51:29 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:52:25 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:53:00 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:53:29 2013
    ALTER SYSTEM: Flushing buffer cache
    Thu Jul 11 03:57:27 2013
    Thanks
    Aju

    This is not normal. Can be issued manually or by sheduled jobs, or by 3rd party software. Are you running PeopleSoft?
    As adviced already check AUDIT_TRAIL, check that auditing is enabled first, and issue one flush manually to be sure that this action is logged.
    Bug 12530225 : ALTER SYSTEM: FLUSHING BUFFER CACHE MESSAGES IN ALERT.LOG
    Regards
    Ed

Maybe you are looking for