No swaps anyware still hit Ratio around 4% for Initial Record Buffer

Dear Gurus
I am using ABAP NW7.0 System.
in the system all buffers  have hit ratio  99+%
but the initial record buffer hit ratio it below 10%
any way there is no swaps at all still hit Ratio is 4%
The current parameters are:
rsdb/ntab/irbdsize   --->6000
rsdb/ntab/entrycount---> 20000
HITRATIO  -
>        %         4
HITS         -
>              64
REQUESTS    -
>             1.729
DB access quality %   -
>       4
DB access      -
>          1.656
DB access saved    -
>         64
Reorgs        -
>               0
Allocated     -
>    KB     6.625
Available     -
>    KB     6.000
Used         -
>     KB     1.099*
Free         -
>     KB     4.901
Available     -
>           5.000
Used         -
>            1.656
Free           -
>         * 3.344*
Objects swapped    -
>          0
Frames swapped    -
>           0
Total          -
>              0
Pl suggest me how can i have the hitratio more.
Thanks in advance

Hello,
Unfortunately we can not tell exactly why the value is low,
however it is not necessarily an incorrect value.
The quality of a buffer and how often it is accessed is measured by the
'%Hit Ratio'. This value will indicate if the information stored in the
buffers, such as table entries, programs and screens, is being hit
directly from the buffer itself or, on the other hand, if the system
needs to bring that data from the database since it was not found in the
buffer.
To find out the buffers with poor quality, first check the system
startup time. When the system is started, all buffers (except the
program buffer which has a pre-load) are initially empty. Therefore,
all objects that are accessed for the first time have to be read from
the database and then loaded into the buffers.
If objects are not yet in the buffer, the hit ratio for the buffer will
be low. The hit ratio increases from the time objects are loaded into
the buffers. The rate of the increase depends on the workload in the
system and is different for each buffer.So it is to be noted that how often you restart the system which resuls in the loading of object again and causes hit rate to be low.
Poor buffer quality is not always due to a real problem. For example,
transports into a system can reduce buffer quality. Keep in mind though
that a value lower does not always shows that you have a problem.
A more pressing concern would be if we saw swaps on the system. As you
can see, there are no swaps.
Swapping occurs when the buffer is full, and the SAP System has to
load additional objects into the buffer. Objects in the buffer that
were used the least recently are removed. In this context, the term
"swap" means the objects removed from the buffer are lost and cannot
be replaced until a new database access is performed (replacing what
was lost).
There are two possible reasons for swapping
1 There is no space left in the buffer data area
  The buffer is too small. You should increase the buffer size.
2 There are no directory entries left.
Therefore, to conclude, although the hitratio appears low it does
not mean that there are any performance issues. The fact that there is
sufficient free space and there are no swaps confirm this.
You can try to increase size of intial record buffer(in steps) as from current setting it seems to be small.
I hope this helps.
Regards,
Archana

Similar Messages

  • Swapping in ST02 in Initial Record Buffer rsdb/ntab/irbdsize

    Hello All,
    I've been trying to do some tuning in ST02 and was hoping someone might be able to explain why I am getting such a low hit rate on the Initial Records Buffer, and the high level of swapping, when there appears to be plenty free space and plenty free entries.
    Here are the stats I see.
    Efficiency       
    HITRATIO          %        42
    HITS                    9,645
    REQUESTS               22,790
    DB access quality %        42
    DB access              13,136
    DB access saved         9,645
    Reorgs                      0
    Size             
    Allocated        KB     8,750
    Available        KB     7,500
    Used             KB     1,053
    Free             KB     6,447
    Directory entries
    Available              10,000
    Used                    3,801
    Free                    6,199
    Swaps            
    Objects swapped         9,335
    Frames swapped              0
    Resets            Total                       0
    Any clues would be much appreciated.
    Thanks
    Steve

    I have the same issue and my parameter settings are currently:
    rsdb/ntab/irbdsize - 41500
    rsdb/ntab/entrycount 45000
    Are there any other suggestions? See below for swap information.
    Efficiency        HITRATIO          %        43
                       HITS                   10,243
                       REQUESTS               23,731
                       DB access quality %        43
                       DB access              13,488
                       DB access saved        10,243
                       Reorgs                      0
    Size              Allocated        KB    42,906
                       Available        KB    41,500
                       Used             KB     4,717
                       Free             KB    36,783
    Directory entries Available              11,250
                       Used                    9,759
                       Free                    1,491
    Swaps             Objects swapped         3,728
                       Frames swapped              0
    Resets            Total                       0

  • Low Hit Ratio for Export/Import Buffer

    Hi,
    Do low hit ratio (less than 70%) for Export/Import buffer causes performance issue?
    I didnt get any Note related to this.
    Any help will be appreciated.
    Thanks,
    Saurabh

    Thanks everyone,
    Basicaly all the buffers(Program/Nametab/CUA/Screen/Genric Key/Single record) has hit ratio around 99% , but for export/import buffer its 60%. which is indeed less.
    This is what i intended to ask, if this low hit ratio for export/import buffer has much impact ?
    Any note if anyone remembers?
    Thanks,
    Saurabh

  • Database buffer cache hit ratio is less that 90%

    Hi All,
    For the following query i get result less than 90%
    SELECT ROUND(((1 -(phy.VALUE /(cur.VALUE con.VALUE)))*100),2) "HIT RATIO"+
    FROM SYS.v_$sysstat cur,
    SYS.v_$sysstat con,
    SYS.v_$sysstat phy
    WHERE cur.NAME = 'db block gets'
    AND con.NAME = 'consistent gets'
    AND phy.NAME = 'physical reads' ;
    HIT RATIO
    +81.79+
    Please advice me what may be the reasons and how can i make it more than 90%.
    I have metalink access. Can i raise this issue with Oracle metalink?
    Thanks and regards,
    Arun Kumar

    user8853422 wrote:
    Thnaks for the reply..
    I have noticed for the another database it is 23.29.
    But i did not get any complaints from application side yet.
    It's laudable that you want to be proactive and fix the database before people complain, but I'll second what the others said, targetting a specific hit ratio is useless for that.
    Who told you to run that hit ratio script? There are a number of reasonable methodologies to determine if there might be problems, but that isn't one of them. Waiting for users to complain may or may not work, some users simply accept poor performance, thinking that's just the way it is.
    What are you really trying to accomplish?

  • STATSPACK REPORT (BUFFER HIT RATIO)

    my statspack report shows that my buffer ration is 83%...what factors i need to look to imporve the buffer hit ratio. Thanks

    I deleted because i realized that i took the statspack report of 1 day period.
    Below is the Statspack report of 1 hour. Can you please let me know if i still need to increase database buffer cache?
    STATSPACK report for
    Database DB Id Instance Inst Num Startup Time Release RAC
    ~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
    4254163 TEST1 1 28-Jun-07 23:30 10.2.0.3.0 NO
    Host Name: Linux3 Num CPUs: 2 Phys Memory (MB): 7,968
    ~~~~
    Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
    ~~~~~~~~ ---------- ------------------ -------- --------- -------------------
    Begin Snap: 32 03-Jul-07 11:59:13 23 11.0
    End Snap: 42 03-Jul-07 14:07:33 26 11.3
    Elapsed: 128.33 (mins)
    Cache Sizes Begin End
    ~~~~~~~~~~~ ---------- ----------
    Buffer Cache: 100M Std Block Size: 8K
    Shared Pool Size: 100M Log Buffer: 33,823K
    Load Profile Per Second Per Transaction
    ~~~~~~~~~~~~ --------------- ---------------
    Redo size: 1,259.57 8,598.13
    Logical reads: 148.39 1,012.92
    Block changes: 6.41 43.76
    Physical reads: 41.91 286.09
    Physical writes: 0.73 5.02
    User calls: 15.66 106.91
    Parses: 4.07 27.77
    Hard parses: 0.27 1.85
    Sorts: 1.70 11.61
    Logons: 0.01 0.07
    Executes: 9.59 65.47
    Transactions: 0.15
    % Blocks changed per Read: 4.32 Recursive Call %: 83.09
    Rollback per transaction %: 6.03 Rows per Sort: 11.39
    Instance Efficiency Percentages
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 100.00 Redo NoWait %: 100.00
    Buffer Hit %: 71.77 In-memory Sort %: 100.00
    Library Hit %: 93.15 Soft Parse %: 93.34
    Execute to Parse %: 57.58 Latch Hit %: 100.00
    Parse CPU to Parse Elapsd %: 97.12 % Non-Parse CPU: 86.74
    Shared Pool Statistics Begin End
    Memory Usage %: 91.37 92.38
    % SQL with executions>1: 77.55 80.43
    % Memory for SQL w/exec>1: 83.11 84.69
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time
    CPU time 132 48.3
    db file sequential read 89,745 91 1 33.4
    db file scattered read 29,289 35 1 13.0
    control file parallel write 2,558 6 2 2.1
    log file parallel write 2,294 3 1 1.0
    Host CPU (CPUs: 2)
    ~~~~~~~~ Load Average
    Begin End User System Idle WIO WCPU
    0.11 0.11 2.26 2.65 95.09 0.90 0.24
    Instance CPU
    ~~~~~~~~~~~~
    % of total CPU for Instance: 1.06
    % of busy CPU for Instance: 21.63
    %DB time waiting for CPU - Resource Mgr:
    Memory Statistics Begin End
    ~~~~~~~~~~~~~~~~~ ------------ ------------
    Host Mem (MB): 7,967.6 7,967.6
    SGA use (MB): 316.0 316.0
    PGA use (MB): 57.8 62.6
    % Host Mem used for SGA+PGA: 4.7 4.8
    Time Model System Stats DB/Inst: TEST1/TEST1 Snaps: 32-42
    -> Ordered by % of DB time desc, Statistic name
    Statistic Time (s) % of DB time
    sql execute elapsed time 212.3 92.7
    DB CPU 124.2 54.2
    parse time elapsed 21.6 9.4
    hard parse elapsed time 19.7 8.6
    PL/SQL execution elapsed time 4.3 1.9
    hard parse (sharing criteria) elaps 1.4 .6
    connection management call elapsed 1.4 .6
    PL/SQL compilation elapsed time 1.2 .5
    repeated bind elapsed time 0.1 .0
    hard parse (bind mismatch) elapsed 0.1 .0
    sequence load elapsed time 0.0 .0
    DB time 228.9
    background elapsed time 48.2
    background cpu time 39.3
    Wait Events DB/Inst: TEST1/TEST1 Snaps: 32-42
    -> s - second, cs - centisecond, ms - millisecond, us - microsecond
    -> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by Total Wait Time desc, Waits desc (idle events last)
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    db file sequential read 89,745 0 91 1 79.6
    db file scattered read 29,289 0 35 1 26.0
    control file parallel write 2,558 0 6 2 2.3
    log file parallel write 2,294 0 3 1 2.0
    db file parallel write 2,179 0 3 1 1.9
    log file sync 1,089 0 2 2 1.0
    os thread startup 7 0 1 120 0.0
    latch free 3 0 0 89 0.0
    SQL*Net break/reset to client 640 0 0 0 0.6
    direct path read 140 0 0 1 0.1
    control file sequential read 3,599 0 0 0 3.2
    SQL*Net more data to client 2,121 0 0 0 1.9
    db file parallel read 49 0 0 1 0.0
    cursor: pin S wait on X 2 100 0 16 0.0
    read by other session 4 0 0 5 0.0
    direct path write 24 0 0 0 0.0
    latch: shared pool 1 0 0 2 0.0
    SQL*Net message from client 120,211 0 47,282 393 106.6
    wait for unread message on broadc 7,631 100 7,517 985 6.8
    Streams AQ: waiting for messages 1,540 100 7,512 4878 1.4
    Streams AQ: qmn slave idle wait 275 0 7,508 27302 0.2
    Streams AQ: qmn coordinator idle 554 51 7,508 13553 0.5
    Streams AQ: waiting for time mana 25 52 6,643 ###### 0.0
    SQL*Net message to client 120,215 0 0 0 106.6
    class slave wait 7 0 0 1 0.0
    SQL*Net more data from client 146 0 0 0 0.1
    Background Wait Events DB/Inst: TEST1/TEST1 Snaps: 32-42
    -> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by Total Wait Time desc, Waits desc (idle events last)
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    control file parallel write 2,557 0 6 2 2.3
    log file parallel write 2,290 0 3 1 2.0
    db file parallel write 2,179 0 3 1 1.9
    os thread startup 7 0 1 120 0.0
    db file sequential read 1,456 0 1 0 1.3
    db file scattered read 25 0 0 8 0.0
    control file sequential read 156 0 0 0 0.1
    latch: shared pool 1 0 0 2 0.0
    rdbms ipc message 25,017 92 59,496 2378 22.2
    pmon timer 2,576 100 7,513 2917 2.3
    Streams AQ: qmn slave idle wait 275 0 7,508 27302 0.2
    Streams AQ: qmn coordinator idle 554 51 7,508 13553 0.5
    smon timer 26 96 7,148 ###### 0.0
    Streams AQ: waiting for time mana 25 52 6,643 ###### 0.0
    Wait Event Histogram DB/Inst: TEST1/TEST1 Snaps: 32-42
    -> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
    -> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
    -> % of Waits - value: .0 indicates value was <.05%, null is truly 0
    -> Ordered by Event (idle events last)
    Total ----------------- % of Waits ------------------
    Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s
    LGWR wait for redo copy 7 100.0
    SQL*Net break/reset to cli 640 99.2 .6 .2
    SQL*Net more data to clien 2121 100.0
    control file parallel writ 2558 84.2 12.0 .7 1.4 1.5 .2
    control file sequential re 3599 99.9 .1
    cursor: pin S wait on X 2 100.0
    db file parallel read 49 93.9 2.0 4.1
    db file parallel write 2179 68.2 19.9 6.8 4.0 .9 .1 .1
    db file scattered read 29K 90.7 6.0 .5 .5 .6 .8 .9
    db file sequential read 89K 89.4 2.8 1.3 3.6 1.5 .7 .6
    direct path read 140 87.1 2.9 .7 1.4 7.1 .7
    direct path write 24 100.0
    latch free 3 100.0
    latch: messages 1 100.0
    latch: shared pool 1 100.0
    log file parallel write 2294 77.4 17.3 2.0 1.3 1.1 .8 .2
    log file sync 1089 62.4 28.8 3.3 1.7 2.5 1.1 .2
    os thread startup 7 100.0
    read by other session 4 50.0 25.0 25.0
    SQL*Net message from clien 120K 95.2 1.6 .9 .3 .1 .2 .1 1.7
    SQL*Net message to client 120K 100.0
    SQL*Net more data from cli 146 100.0
    Streams AQ: qmn coordinato 554 49.1 .2 .2 50.5
    Streams AQ: qmn slave idle 275 100.0
    Streams AQ: waiting for me 1540 .2 99.8
    Streams AQ: waiting for ti 25 36.0 16.0 48.0
    class slave wait 7 85.7 14.3
    pmon timer 2577 .5 .1 .1 99.3
    rdbms ipc message 25K 2.3 1.3 1.4 .4 .4 .3 32.1 61.8
    smon timer 26 100.0
    wait for unread message on 7631 .0 .0 100.0 .0

  • One reason why buffer hit ratio just might be bogus

    Hi.
    Still trawling through statspack trying to make some sense of it ...
    But looking at this, (on undo segments) I have perhaps another reason to sneer at the old buffer cache hit ratio: (in the sense of using it to tune, or of using it to justify action / lack of action).
    "The header is also a data block that is frequently modified , so it generally remains in the buffer cache. Therefore, gets of the rollback segment header block increase the buffer cache hit ratio; this artificial increase in the hit ratio can mislead you into thinking that you have allocated enough data blocks to the buffer cache"
    :taken from the OP Exam 033 text, p.295

    Hi Dan,
    The problem is about the usefulness of ratio's in-general, it's not specifically about the BCHR. . . .
    This whole thing arose from the Oracle7 performance tuning classes where Oracle Corporation suggested that the BCHR be kept over 90%. . . .
    Is the BCHR "bogus"? It is what it is, a ratio. . . .
    I agree wit Ben, it does have limited use as an "indicator", that the buffer cache MIGHT be too small to cache the working set of frequently-referenced data blocks. I have my notes here:
    http://www.dba-oracle.com/t_buffer_cache_hit_ratio_value.htm
    Oh, and as to the buffer cache advisory, it's not perfect (as is any predictive model) and I rarely see one that does not suggest that adding RAM will reduce physical I/O.
    Anyway, in just a few years all this will be a moot issue, espeially since solid-state disk has hit $100 per gig. Without spinning platters, there is no need for a large buffer cache at all . . . .
    Hope this helps. . .
    Donald K. Burleson
    Oracle Press author
    Author of "Oracle Tuning: The Definitive Reference":
    http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

  • MaxDB Catalog cache hit ratio too low

    Hello,
    We use Maxdb version 7.6 and 7.7 on various systems.
    Each week the report of EarlyWatch indicates to me that the catalog
    cache ratio is too low. ( < 60% )
    We modified the value of parameter CAT_CACHE_SIZE of 10000 towards
    20000 then 50000 then 100000 then 200000 then 400000.
    That did not have any effect on the catalog cache hit ratio.
    In the forums sdn or the notes sap one gives no other method to improve
    this ratio, except always increasing the value of parameter
    CAT_CACHE_SIZE .
    Do you have another solution?
    Thank you in advance
    Best regards
    Frédéric Blaise
    e-Kenz S.A.

    Hi,
    don't be too afraid of this value. If you use (internally) some statements where all tables have to be checked like update statistics (with some option) or do some selects on some statistical info, then this value goes down as there are sooooooooo many tables around in a R/3-system that no CAT_CACHE_SIZE-value will be sufficient to hold all their descriptions in the cache. Therefore with some of these commands, the cache is turned round and round, thus reducing the hit ratio. It is a good idea to increase the value to hold many of the normally used descriptions in parallel, but opposite to other caches the hit ration will always be low.
    Elke

  • Cache Hit Ratio -19

    Hi all I am using 10gR2 on Solaris 10.
    My users were complaining about the DB being very slow, so I found out that the cache hit ratio is -19.113 (Courtesy TOAD). I checked the SGA and found out that the Buffer Cache was way less than the Shared Pool size. Will the increase of the Buffer Cache size help?
    Thanks.

    Cache performance may be improved by increasing the buffer pool but if your database is very write intensive tables may age out of a larger cache as well.
    There is no guarantee that caching will improve dramatically. But its sounds from your description a good reason to increase the buffer pool.
    But remember as a DBA tuning via startup parameters may only give you small improvements; your greatest improvements will be gained by reviewing what the code is doing and ensuring its optimisation.
    For example we had an off the shelf scheduler which seemed to be working fine until we tried to put hundreds of items through it in mins, then because a debug setting was still enabled in the code supplied, it backed up. Without running statspack to diagnose the application we would not have spotted this code issue. Once we showed the vendor the statspack report they supplied us a no debug patch to the code!
    You could also look into using multiple buffer pools (KEEP_POOL RECYCLE_POOL DEFAULT) to split up the LRU aging of critical cached data blocks and fast aged data blocks. But you need to have the spare physical memory for this...... is your system memory rich.

  • RAC - buffer cache hit ratio

    Hi, I'm a newbie to the forums, so please bear with me.
    I am trying to determine if the usual buffer cache hit ratio figures are irrelevant when used on a RAC environment, because of Cache Fusion and the blocks being moves between the SGA's of the instance?

    Buffer cache hit ratios are always relevant (but not necessarily an indicator of performance).
    Wether it is coming in by cache fusion or a direct read from a datafile, you are still moving a datablock into the cache or reading from the cache.

  • How can I increase my Library Cache Hit Ratio?

    I was wondering if anyone can help me out regarding the values that I am getting for my Library Cache hits stats
    Half of the samples that I have taken on a periodic interval today have ranged from 89% to 96%.
    The SQL that I have used is,
    SELECT
    sysdate,
    SUM(PINS-RELOADS)/SUM(PINS)*100
    from v\$librarycache
    Also, Running the AWR report for 4am to 4pm, see below
    Shared Pool Statistics AWR report
                        Begin      End
    Memory Usage %:           50.83      42.43
    % SQL with executions>1:      55.56      77.13
    % Memory for SQL w/exec>1:      74.12
    Regarding the current SGA settings,
    SQL> show parameter sga_target;
    NAME TYPE VALUE
    sga_target big integer 1184M
    SQL>
    SQL> select pool,name,bytes/1048576 "Size in MB" from v$sgastat where name = 'free memory';
    POOL NAME Size in MB
    shared pool free memory 135.742641
    large pool free memory 15.9389648
    java pool free memory 16
    The main questions are,
    a) is the low Library cache hit ration particularly low?
    b) if I want to improve this figure, it is advised that the 'SHARED_POOL_SIZE' parameter should be increased.
    Obviously Oracle itself is in charge of this at present, so what can I do to improve?
    c) Are there any really good links to help me to understand the figures that appear in the AWR report.

    a) is the low Library cache hit ration particularly low?
    I didnt understand this.Can you please rephrase?
    b)
    Well indeed that shared pool controls the allocation and everything about Library Cache but it doesnt mean that increasing the value will stop all the issues.Its among the hardest parameters to be tuned infact for the reason that what primarly comes into it,sql statements,code and all that,that is not written entirely by a dba/tuner.Its by developers who does some times not so good things that are required to make shared pool work properly.Very commonly occuring mistake can be quoted as the lack of use of bind variabls and constant use of literals.In that case,eventualy we will have a hard parse of all the statements which will eat up the shared pool some time or the other.No matter what size it may be,it will end to the same result.Hit ratio is a guiding factor,not the end goal of tuning.Its been documented so many places,here,other forums,even in OU books also that looking and tuning alone the hit ratio may not end up at the expected or right results.You should look for the Parse statistics in the AWR report how they are working.How many are Parse(hard),Parse(total) statistics coming up?What is the sql execute to parse time,elapsed time and the related statistics.They will be helpful in getting things sorted out more nicely and correctly.
    I am sure I have missed so much than I said.Surely you will get more better advice on this.Have patience and wait.
    b)Documentation will be a good point.Performance tuning in that is a good resource.
    http://www.oracle.com/pls/db102/to_toc?pathname=server.102%
    2Fb14211%2Ftoc.htm&remark=portal+%28Getting+Started%29
    I am not sure about a specific book about AWR but this one is good for over all knowledge about tuning of Oracle.
    http://www.mcgraw-hill.co.uk/html/007222729X.html
    Aman....

  • Default Buffer Pool Busy Waits and Default Buffer Pool Hit Ratio

    Hi experts,
    I am having oracle database with version 11gR2 on windows server 2003 platform.
    I am continuously getting alerts related to "Default Buffer Pool Busy Waits" and "Default Buffer Pool Hit Ratio."
    I have fired some of the queries(which contain view like v$session_wait) to get information of sessions that causing the same issue,but unable to get it.
    Please help me to resolve the same issue.

    Hi - Try this query for Buffer busy wait
    COL class FORM a10
    COL total_waits FORM 9,999,999,999
    COL "WAITS %" FORM 9999999
    COL time_waited FORM 9999999
    COL "TIME %" FORM 9999999
    COL event FORM a24
    COL avg_wait FORM 9999.99
    SELECT a.event event, substr(c.wait_class,1,9) class,
    a.total_waits total_waits, a.time_waited/100 time_waited,
    a.average_wait avg_wait
    -- a.average_wait/100 avg_wait -- displays seconds instead of 100s
    FROM v$system_event a, v$event_name b, v$system_wait_class c
    WHERE a.event_id=b.event_id
    AND b.wait_class#=c.wait_class#
    AND a.time_waited/100 > 0
    AND (event LIKE '%HW%' OR event = 'buffer busy waits')
    -- AND c.wait_class in ('Application','Concurrency','User I/O')
    ORDER BY 1 DESC;

  • Negative Values of Library Cache Hit Ratio in AWR Report

    Hi all,
    We are getting Negative values of Library cache hit ratio in AWR Report of 11g(11.2.0.3) with Solaris[tm] OE (64-bit).
    Please suggest us why it shows negative value.
    Instance Efficiency Percentages (Target 100%)
    Buffer Nowait %: 99.87 Redo NoWait %: 99.99
    Buffer Hit %: 92.17 In-memory Sort %: 100.00
    Library Hit %: -3,321.23 Soft Parse %: 81.95
    Execute to Parse %: 92.88 Latch Hit %: 95.11
    Parse CPU to Parse Elapsd %: 87.25 % Non-Parse CPU: 81.39
    Regards,
    Madhan
    Edited by: user12078989 on Jul 25, 2012 7:40 AM

    Hi Aman,
    DB not restarted during this time.. we don't have production access. we will get awr report automatically from customer daily. also i am getting issue in our local environment v$rowcache view gets values is negative for dc_users and dc_tablespaces parameter may be it's related production issue...

  • Problem with the cache hit ratio

    Hello,
    I ma having a problem with the cache hit ratio I am geting. I am sure, 100% sure, that something has got to be wrong with the cache hit ratio I am fetching!
    1) I will post the code that I am using to retrieve the cache hit ratio. I've seen about a thousand different equations, all equivalent in the end.
    In oracle cache hit ratio seems to be:
    cache hits / cache lookups,
    where cache hits <=> logica IO - physical reads
    cache lookups <=> logical IO
    Now some people use the session logical Reads stat, from teh view v$sysstat; others use db block gets + db consistent gets; whatever. At the end of the day its all the same, and this is what i Use:
    SELECT (P1.value + P2.value - P3.value) AS CACHE_HITS, (P1.value + P2.value) AS CACHE_LOOKUPS, P4.value AS MAX_BUFFS_SIZEB
    FROM v$sysstat P1, v$sysstat P2, v$sysstat P3, V$PARAMETER P4
    WHERE
    P1.name = 'db block gets' AND
    P2.name = 'consistent gets' AND
    P3.name = 'physical reads' AND
    P4.name = 'sga_max_size'
    2) The problem:
    The cache hit ratio I am retrieving cannot be correct. In this case i was benchamarking a HUGELY inneficient query, consisting of the Union of 5 Projections over the same source table, and Oracle is configured with a relatively small SGA of 300 MB. They query plan is awful, the database will read the source database table 5 times.
    And I can see in the physical data statistics of the source tablespace, that total Bytes read is aproximatly 5 times the size of the text file that I used to bulk load data into the databse.
    Some of the relevant stats, wait events:
    db file scattered read     1129,93 seconds
    Elapsed time: 1311,9 seconds
    CPU time: 179,84
    SGA max Size: 314572800 Bytes
    And total bytes read: 77771964416 B (aproximatly 72 Gga bytes)
    the source txt loaded to the database was aprox 16 G
    Number of reads was like 4.5 times the source datafile.
    I would say this, given the difference between CPU time and Elapsed Time, it is clear that the query spent almost all of its time doin DB file scattered reads. How is it possible that i get the following cache hit ratio:
    Cache hit Ratio: 0,92
    Cache hits: 109680186
    Cache lookups: 119173819
    I mean only 8% of that Logical I/O corresponded to physical I/O? It is just not possible.
    3) Procedure of taking stats:
    Now to retrieve these stats I snapshot the system 2 times. One before the query, one after the query.
    But: this is not done in a single session. In total 3 sessions are created. One session two retrieve the stats before the query, one session to run the query, a last session to snapshot after the query.
    Could the problem, assuming there is one, be related to this:
    "The V$SESSTAT view contains statistics on a per-session basis and is only valid for the session currently connected. When a session disconnects all statistics for the session are updated in V$SYSSTAT. The values for the statistics are cleared until the next session uses them."
    What does this paragraph mean. Does it mean that the v$sysstat only shows you the stats of the last session that closed? Or does it mean thtat v$sysstat is increamented with the statistics of each v$sessionstat once a session terminates? If so, then my procedure for gathering those stats should be correct.
    Can anyone help me sort out the origin of such a high cache hit ratio, with so much I/O being done?

    sono99 wrote:
    Hi,s
    first of, let me start by saying that there were many things in your post that you mentioned that I could no understand. 1. Because i am not an Oracle Expert, i use whatever RDBMS whenever i need to. 2. Because another problem has come up and, right now, i cannot inform myself to be able to comprehend it all.Well, could it be that you need to understand the database you are working on in order to comprehend it? That is why we strongly advise you to read the concepts manual first, you need to understand the architecture that Oracle uses, as well as the basic concepts of how oracle does locking and maintains read consistency. It does these different than other database engines, and some things become nonsense if looked at from the viewpoint of a single user.
    >
    quote:
    It would be useful to see the execution plan jhust in case you have simplified the problem so much that a critical detail is missing.
    First, the query code:
    2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:>SQL> CREATE TABLE FAVFRIEND
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 2 NOLOGGING TABLESPACE TARGET
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 3 AS
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 4 SELECT ID as USRID, FAVF1 as FAVF FROM PROFILE
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 5 UNION ALL
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 6 SELECT ID as USRID, FAVF2 AS FAVF FROM PROFILE
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 7 UNION ALL
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 8 SELECT ID as USRID, FAVF3 AS FAVF FROM PROFILE
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 9 UNION ALL
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 10 SELECT ID as USRID, FAVF4 AS FAVF FROM PROFILE
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 11 UNION ALL
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 12 SELECT ID as USRID, FAVF5 AS FAVF FROM PROFILE
    [2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 13 ;
    Now, Althought it is clear from the query that the statement is executed with the NOLOGGiNG, i have disabled the logging entirely for the tablespace.There are certain rules about nologging that may not be obvious. Again, this derives from the basic Oracle architecture, and if you use the wrong definitions of things like logging, you will be led down the primrose path to confusion.
    >
    Futhermore, yes, the RDBMS is a test RDBMS... I have droped the database a few times... And I am constantly deleting an re-inserting data into the source database table named PROFILE.>
    I also make sure do check all the datafile statistics, and for this query the amount of RedoLog, Undo "Log", Templife used is negligible, practically zero.Create table is DDL, which has implied commits before and afterwards. There is a lot going on, some of it dependent on the volume of data returned. The Oracle database writer writes things out when it feels like it, there are situations where it might just leave it in memory for a while. With nologging, Oracle may not care that you can't perform recovery if it is interrupted. So you might want to look into statspack or EM to tell you what is going on, the datafile statistics may not be all that informative for this case.
    >
    Most of the I/O is reading, a few of the I/O is writing.
    My idea is not to optimize this query, it is to understand how it performs. Well, have you read the Concepts manual?
    I have other implementations to test, namely I having trouble with one of them.
    Furthermore, I doubt the query Plan Oracle is using actually involves tablescans (as I I'd like it to do); because in the Wait Events, most of the wait time for this query is spent doing "db file scattered read". And I think this is different from a tablescan.Please look up the definition of [db file scattered read|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref703].
    >
    Do you really have to use sessions external to the query session ? Can you query v$mystat joined to v$statname from the session itself.
    No, I don't want to that!
    I avoid as much as possible having the code I execute being implemented in java. Why do you think java has anything to do with this? In your session, desc v$mystat and v$statname, these are views you can look at.
    When i can avoid it I don't query the database directly through JDBC, i use the RDBMS command line client, which is supposed to be very robust. Er, is that sqlplus?
    So yes, I only connect to the database with JDBC... in very last session.
    Of course, I Could Have put both the gather stats before query and gathers stats after query a single script: the script that would be also runing the query.
    But that would cause me a number of problems, namely some of the SQL i build has to be implemented dynamically. And I don't want to be replicating the snapshoting code into every query script I make. This way I have one sql with the snapshoting scripts; and multiple scripts for running each query. I avoid code replication in this manner.Instrumentation is a large subject; dynamic sql generation is something to be avoided if possible. Remember, Oracle is written with the idea that many people are going to be sharing code and the database, so it is optimized in that way. For SQL parsing in particular, if every SQL is different, you get a performance problem called "hard parsing." You can (and generally should, and sometimes can't avoid) use bind variables so that Oracle doesn't need to hard parse every SQL. In fact, this is one of those things that applies to other engines besides Oracle. I would recommend you read Tom Kyte's books, he explains what is going on in detail, including in some places the non-Oracle viewpoint.
    >
    Furthermore, Since the database is not a production database, it is there so I can do my tests. I don't have to be concerned with what other sessions may be doing to my system. There are only the sessions I control.No, there are sessions Oracle controls. If you are on unix, you can easily see this, but there are ways to see it on Windows, too. In some cases, your own sessions can affect themselves.
    >
    then what it the array fetch size ? If the array fetch size is large enough the number of block visits would be similar to the number of physical block reads.
    I don't know what the arraysize you mention is. i have not touched that parameter. So whatever it is, it's the default.You should find out! You can go to http://tahiti.oracle.com and type array fetch size into the search box. You can also go to http://asktom.oracle.com and do the same thing, with some more interesting detail.
    >
    By the way, I don't get the query results into my client, the query results are dumped into a target output table.
    So, if the arraysize has something to do with the number of rows that Oracle is returning the client in each step... I think it doesn't matter.You may hear this phrase a lot:
    "It depends."
    >
    As for the query plan, If i am not mistaken you can't get get query plans for queries that are: create table as select.What?
    JG@TTST> explain plan for create table jjj as select * from product_master;
    Explained.
    JG@TTST> select count(*) from plan_table;
      COUNT(*)
             3
    I can however commit the create table part and just call for the evalution of the Select part of the query; i believe it should be same.
    "Optimizer"     "Cost"     "Cardinality"     "Bytes"     "Partition Start"     "Partition Stop"     "Partition Id"     "ACCESS PREDICATES"     "FILTER PREDICATES"
    "SELECT STATEMENT"     "ALL_ROWS"     "2563"     "586110"     "15238860"     ""     ""     ""     ""     ""
    "UNION-ALL"     ""     ""     ""     ""     ""     ""     ""     ""     ""
    "TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "512"     "117222"     "3047772"     ""     ""     ""     ""     ""
    "TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
    "TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
    "TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
    "TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
    This query plan was taken from sql developer, exported to txt, and the PROFILE table here has only 100k tuples.
    Right now I am more concerned with testing the MODEL query. Which Oracle doesn't seem to be able any more... but that is a matter for another thread.
    Regarding this plan. The Union ALL seems to be more than just a binary Operator... IT seems to be Neray.
    The union all on that execution plan seems to be taking as leaf tables 5 99sono.Profile tables, and be making a table scan to them all. So I'd say that the RDBMS should only scan each database block once and not 5 times.
    But: It doesn't seem to be so. IT seems like what oracle is doing is scanning completly each the table, and then moving on to next select statement in the UNION ALL. Because given the amount of source table that was read, 5 times greater than the size of the source table. Oracle didn't reuse read blocks.
    But this is just my feeling.Your feeling is uninteresting. Telling us what you really hope to accomplish might be more interesting.
    Anyway, in terms of consistent gets, how many consistent gets should the RDBMS be doing? 5
    One for each table block?It depends.
    >
    My best regards,
    Nuno (99sono xp).

  • Buffer cache hit ratio query

    Hi,
    I would appreciate some advice please.
    My Oracle 10.2.0.4.0 database starts off in the day with a buffer cache hit ratio of almost 100% but this drops gradually in the course of the day as the system gets busier. Is this something I need to be concerned about if no performance problem has been reported by the users?
    I would have thought this should be a normal situation, i.e. as the system gets busier, I would expect that less number of calls to the buffer cache will be satisfied because many more calls are using up the memory?
    Please note that I've done some reading up on this but would like some suggestions from more experienced people than myself on what I should normally expect and what should or should not be a concern.
    thanks

    user8869798 wrote:
    hi,
    thanks again for your response and apologies for not being able to get back yesterday.No problem :) .
    >
    - What i am doing and how - it is the backend database r our Finance application, many users with various transactions.Okay , that sounds like a "normal" database with normal workload.
    - configuring buffer cache size - I haven't done anything manually yet, it's all been as installed, this is what I'm trying to figure out whether it is something I should be looking into doing simply because of the dropping hit ratio and not because of any reported performance problem.If you don't have much of the knowledge, its the best to take use of the advisories which would tell you in a better and in a graphical way that whether you should or shouldn't be worries. Look at the view v$db_cache_advice which can suggest to you that whether you would need to tweak the buffer cache or not.
    >
    - looking at the queries - What is the easiest way of doing this in an environment where many users are running different queries? What's the easiest way to identify queries that we may need to have a closer look at?Easiest way? Well, let the users come back to you ;-) .
    >
    - Basically, I'm just trying to ascertain whether or not I need to be concerned that my hit ratio drops below 89% even though no performance problem has been reported. If it is something that I should look into, then what is the best way to go about it?
    I believe that's answered by couple of us already, nope.
    Aman....

  • Buffer Cache hit Ratio

    Hi All,
    My DB Version: 10.2.0
    OS: Windows Server 2003
    I run the following script to get Hit ratio's
    SELECT cur.inst_id, 'Buffer Cache Hit Ratio ' "Ratio", to_char(ROUND((1-(phy.value / (cur.value + con.value)))*100,2)) "Value"
    FROM gv$sysstat cur, gv$sysstat con, gv$sysstat phy
    WHERE cur.name = 'db block gets'
    AND con.name = 'consistent gets'
    AND phy.name = 'physical reads'
    and phy.inst_id=1
    and cur.inst_id=1
    and con.inst_id=1
    union all
    SELECT cur.inst_id,'Buffer Cache Hit Ratio ' "Ratio", to_char(ROUND((1-(phy.value / (cur.value + con.value)))*100,2)) "Buffer Cache Hit Ratio"
    FROM gv$sysstat cur, gv$sysstat con, gv$sysstat phy
    WHERE cur.name = 'db block gets'
    AND con.name = 'consistent gets'
    AND phy.name = 'physical reads'
    and phy.inst_id=2
    and cur.inst_id=2
    and con.inst_id=2
    union
    SELECT inst_id, 'Library Cache Hit Ratio ' "Ratio", to_char(Round(sum(pins) / (sum(pins)+sum(reloads)) * 100,2)) "Library Cache Hit Ratio"
    FROM gv$librarycache group by inst_id
    union
    SELECT inst_id,'Dictionary Cache Hit Ratio ' "Ratio", to_char(ROUND ((1 - (SUM (getmisses) / SUM (gets))) * 100, 2)) "Percentage"
    FROM gv$rowcache group by inst_id
    union
    Select inst_id, 'Get Hit Ratio ' "Ratio",to_char(round((sum(GETHITRATIO))*100,2)) "Get Hit"--, round((sum(PINHITRATIO))*100,2)"Pin Hit"
    FROM GV$librarycache
    where namespace in ('SQL AREA')
    group by inst_id
    union
    Select inst_id, 'Pin Hit Ratio ' "Ratio", to_char(round((sum(PINHITRATIO))*100,2))"Pin Hit"
    FROM GV$librarycache
    where namespace in ('SQL AREA')
    group by inst_id
    union
    select a.inst_id,'Soft-Parse Ratio ' "Ratio", to_char(round(100 * ((a.value - b.value) / a.value ),2)) "Soft-Parse Ratio"
    from (select inst_id,value from gv$sysstat where name like 'parse count (total)') a,
    (select inst_id, value from gv$sysstat where name like 'parse count (hard)') b
    where a.inst_id = b.inst_id
    union
    select a.inst_id,'Execute Parse Ratio ' "Ratio", to_char(round(100 - ((a.value / b.value)* 100),2)) "Execute Parse Ratio"
    from (Select inst_id, value from gv$sysstat where name like 'parse count (total)') a,
    (select inst_id, value from gv$sysstat where name like 'execute count') b
    where a.inst_id = b.inst_id
    union
    select a.inst_id,'Parse CPU to Elapsed Ratio ' "Ratio", to_char(round((a.value / b.value)* 100,2)) "Parse CPU to Elapsed Ratio"
    from (Select inst_id, value from gv$sysstat where name like 'parse time cpu') a,
    (select inst_id, value from gv$sysstat where name like 'parse time elapsed') b
    where a.inst_id = b.inst_id
    union
    Select a.inst_id,'Chained Row Ratio ' "Ratio", to_char(round((a.val/b.val)*100,2)) "Chained Row Ratio"
    from (SELECT inst_id, SUM(value) val FROM gV$SYSSTAT WHERE name = 'table fetch continued row' group by inst_id) a,
    (SELECT inst_id, SUM(value) val FROM gV$SYSSTAT WHERE name IN ('table scan rows gotten', 'table fetch by rowid') group by inst_id) b
    where a.inst_id = b.inst_id
    union
    Select inst_id,'Latch Hit Ratio ' "Ratio", to_char(round(((sum(gets) - sum(misses))/sum(gets))*100,2)) "Latch Hit Ratio"
    from gv$latch
    group by inst_id
    /* Available from 10g
    union
    select inst_id, metric_name, to_char(value)
    from gv$sysmetric
    where metric_name in ( 'Database Wait Time Ratio', 'Database CPU Time Ratio')
    and intsize_csec = (select max(intsize_csec) from gv$sysmetric)
    order by inst_id
    What i am getting after this is:
    INST_ID Ratio Value
    1 Buffer Cache Hit Ratio .83
    1 Chained Row Ratio 0
    1 Dictionary Cache Hit Ratio 77.5
    1 Execute Parse Ratio 45.32
    1 Get Hit Ratio 75.88
    1 Latch Hit Ratio 100
    1 Library Cache Hit Ratio 99.52
    1 Parse CPU to Elapsed Ratio 24.35
    1 Pin Hit Ratio 95.24
    1 Soft-Parse Ratio 89.73
    i have a doubt with buffer cache hit ratio, can anyone please help me to understand this

    Buffer Cache Hit Ratio .83Quite weird value. It seems your system is doing all physical reads, which seems unrealistic.
    I had a 10.2.0.1 database where i saw this kind of result for cache hit ratio and after patching it to 10.2.0.4, it started showing results correctly.
    Probably it could be some Oracle 10g bug which made this odd display of hit ratio information in data dictionary. Can you try patching your database to latest 10g PSU, or contact Oracle support for a one-off patch for this problem
    Salman

Maybe you are looking for

  • Dowloaded Itunes, not playing on ipod...... scanning through songs instead

    I bought a cd from itunes, and imported it onto my play list. It does not play on my ipod. Any help......?

  • Windows 7 UAC

    To get round the Vista UAC 'trust message' I codeSigned my application which worked fine but in windows 7 it now displays the 'Do you want to allow the following program to make changes to this computer?' message. Does anyone know how I can get rid o

  • HT2311 itune will not open

    it read when i try and open itunes that the application could not be opened. an unknown error occurred (13014). help i think my startup disk is fill.

  • My ipad has no volume even though turned up to maximum

    My ipad has lost all its sound even though it is turned up to the maximum. 

  • Core dump on COMMIT in Pro C

    Hi all, I was wondering if anyone has encoutered this problem - and, more importantly, how he/she solved it. I have Pro-C application with embedded SQL which reads the file and imports the data into database. It does a bunch of queries and then a lot