Database Cache Hit ratio is very less

Hi All,
my live database Cache Hit ratio is very less. can some one proposed relevant solution for that.
SELECT (1-((phy.value-phyd.value) / (cur.value + con.value))) * 100 "Cache Hit ratio"
FROM v$sysstat cur, v$sysstat con, v$sysstat phy, v$sysstat phyd
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads'
AND phyd.name = 'physical reads direct';
Cache Hit ratio
47.99717699362490769958384625413175240442
select NAME,VALUE from v$parameter where name like '%db_cache_size%';
NAME VALUE
db_cache_size 335544320
select name, value From v$sysstat
where name in ('db block gets', 'consistent gets', 'physical reads');
NAME VALUE
db block gets 30047032214
consistent gets 691770165681
physical reads 376120181932
Thanks

user1093072 wrote:
Hi all thanks a lot for your answers. i am getting some query time outs and while investigating got less ratios. can some one tell me how to get dicission using this ratios
Buffer Hit % 95.71
Cache Hit ratio 47.99The fact that you get two different values for "the same thing" is a clue that (a) your SQL statement is suspect and (b) your logic is flawed.
You SQL is going to give you some kind of (meaningless) average since the database started up. The report you showed looks like part of an AWR or statspack report which will be covering a short interval of time. The difference between the two percentages may mean the two approaches are using different formula, or it may mean that the result is highly dependent on the time window.
Since you have access to AWR/statspack - run off a report for a (short) interval when the system is performing well, and for when the system is performing badly, and compare them.
As a starting point you could post the two sections "Load Profile" and "Top 5 Timed Events" to the forum for initial comment. If you do so, please make sure you use the "code" tags (see end of post) to make the output readable or you may get no replies.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Similar Messages

  • Database cache  hit ratio is very low  is about 11%

    Dear all,
    Our SAP ERP development server is on sap distributed environment in
    vmware esxi environment.
    centeral instance information
    AEOM1SAP08(172.16.1.87)
    RAM : 4 GB
    CPU : 4 core processors 2.93 Ghz, 2.93 Ghz
    SWAP : 25 GB
    database server information
    AEOM1SAP04(172.16.1.83)
    RAM : 20 GB
    CPU : 8 core processors 2.93 Ghz, 2.93 Ghz
    swap :40 GB
    database server consist of three database instance
    AED sap erp development server(database buffer pool memory 8GB)
    EDE sap enterprise portal server (database buffer pool memory 8 GB )
    AES sap solution manager server (the database currently stopped )
    RAM : 11 GB utillization of database server about 20 GB
    In st04 transaction memory parameters
    physical size of memory --> 20 GB
    current database memory --> 8GB
    database cahe memory --> 5 GB and Hitratio:11%
    proc cache memory --> 1.5 GB and Hitratio 98%
    SQL memory setting --> FIXED
    and the warning are coming as follows
    latch wait time per request(ms) execeeds 20 milliseconds
    wait time per log write(ms) execeeds 10 milliseconds
    check the IO performance of the database server
    and In SM12 large of tables are locking and is running very slow users
    are not able perform their work in development server
    below iam attaced required information
    thanks and regards
    sudheerk
    7382383262

    Hello,
    Please check
    Note #987961 FAQ: SQL Server I/O performance
    regards,
    John Feely

  • Low database cache hit ratio (85%)

    Hi Guys,
    I understand that high db cache hit ratio doesn't indicates that the database is healthy.
    The database might be doing additional "physical" reads due to un-tuned SQL.
    However, can explain why a low cache hit ratio might not indicate the db is unhealthy, as in the db need additional memory allocated?
    What i can think of is probably:
    1. the database might query different data most of the time. As such the data is not read again from cache before it aged out. Even if i add additional memory, the data might not be read again (from memory).
    2. ?
    3. ?
    I'm quite reluctant to list out the databases with below 90% hit ratio as part of the monthly report to the management. To them, below 90% means unhealthy.
    If these ratios to be used in monthly report, there will be a long section to explain why these ratios cannot meet but there is no performance concern.
    As such will need your expert advise on this.
    thanks
    Edited by: Chewy on Mar 13, 2012 1:23 AM

    Nikolay Savvinov wrote:
    In isolation, ratios are useless, but trends in ratios can point to potential problem. If your BCHR is steadily degrading over time, this is something to worry about (you'll have to examine your application for scalability issues)
    I used to think that there was a case for trending through a ratio in the days when databases were small, simple and (by modern standards) not very busy. But I'm no longer sure it was even a good idea then. How much of a change do you need to see before you start worrying - and what time-granularity would you take as your baseline. When a ratio varies between 98% and 99% during daylight hours, how do you spot a very large problem that's only going make a change of 0.01% over the course of a couple of weeks ?
    I really don't think there's any good SIMPLE way of producing a management sound-bite for every database in the system; each database needs a personal touch, and the number of figures you need to supply on each is not going to be easy to grasp without some graphic assistance. A suggestion I have is simply to pick three "representative" queries from the application (one "small", one "medium" and one "large") and run them once every hour, capturing the plan_hash_value, elapsed time, disk-reads, buffer gets, and CPU for each. A daily graph - 4 lines each - of each query will give management the big picture of variation in response time; a longer term graph based on the daily average with (say) best and worst excluded will give a trend warning. Obvously each database (or even application within database) needs its own three queries, and there may be periods during the day when it is not relevant to worry about a particular query.
    (NB In the past I've run baseline queries from a pl/sql package called by dbms_job, or dbms_scheduler, and stored the resulting cost figures in the database - capturing all the session stats, wait event and time model information)
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Author: <b><em>Oracle Core</em></b>

  • Tivolo storage manager error message is Database Cache Hit Ratio is too low

    Hi  basis friends,we are performing incremental backup from mon-fri.from past two days i was getting error message as 'data base cache hit ratio is too low (97.3,98)and increase buffer pool size value.what is the problem for this error message? how can i overcome this error? give me detail analysis to the issue please.
    Thanks and regards,
    Nani

    Hello Nani,
    The database buffer cache hit ratio is the proportion of Oracle logical reads that do not require operating system (OS) read calls.
    When an Oracle session accesses a block, Oracle executes an instruction path that determines whether or not that block is already in the database buffer cache. We refer to this instruction path as an Oracle logical I/O call.. If the block is not in the buffer cache, then Oracle will execute an OS read call. We refer to this as a physical I/O call.It must be ideally close to 99% and since in your case it is low,that is why you are getting these errors
    Now to increase this you will have to increase the vakue of shortbuffer pool size as suggested by Tivolii.
    Fo that you wil have to increase the value of parameter DB_CACHE_SIZE if you are using Oracle 9i.
    Go through the following link http://download.oracle.com/docs/cd/B13789_01/server.101/b10752/memory.htm
    which will help you understand the concept better
    Hipe it helps
    Rohit

  • Manual calculation of 'Buffer Cache hit ratio'

    Using: Oracle 10.2.0.1.0, Redhat 4, 64bit.
    Manual calculation of ‘Buffer Cache hit ratio’ is very off from what it shown in statspack.
    Statspack shows:
    Instance Efficiency Percentages
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00       Redo NoWait %:   99.97
                Buffer  Hit   %:   99.18    In-memory Sort %:  100.00
                Library Hit   %:   90.43        Soft Parse %:   52.56
             Execute to Parse %:   80.14         Latch Hit %:   99.98
    Parse CPU to Parse Elapsd %:   96.21     % Non-Parse CPU:   56.89
    Manual calculation (Got this formula from Sybex PT book, page 275):
    SQL> select name, 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
    from  v$buffer_pool_statistics;
    NAME                 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
    DEFAULT                                                      .700247215Any idea, why using v$buffer_pool_statistics gives wrong results?
    Thanks regards,

    SYS@oradocms11> select (P1.value + P2.value - P3.value)/(P1.value + P2.value)*100
    2 from v$sysstat P1, v$sysstat P2, v$sysstat P3
    3 where P1.name = 'db block gets'
    4 and P2.name = 'consistent gets'
    5 and P3.name = 'physical reads';
    (P1.VALUE+P2.VALUE-P3.VALUE)/(P1.VALUE+P2.VALUE)*100
    99.6977839
    SYS@oradocms11> select name, 1 - (PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS)) from v$buffer_pool_statistics
    NAME 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
    DEFAULT .997009542
    In my case, both are giving almost same result.

  • Ecc cache hit ratio

    Dear All,
    Where can I get the Database cache hit ratio in ECC 6.0? I upgraded from R/3 4.6C to ERP 2005, and cannot find such information in "ST04". Please help.
    Regards,
    Henry

    problem resolved

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

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

  • Cache hit ratio at enterprise manager

    hit ratio formula is:
    (logical_reads - physical_reads/logical_reads )*100
    Now, if I open Oracle Enterprise Manager and goes to Instance->Configuration->Memory I can see SGA and PGA configuration. I can also see the cache hit ratio, in my case 35%, but it seems that this is not the formula I mentioned above, because when I execute that formula i get 75% hit ratio:
    SELECT 1 -(phy.value / (cur.value + con.value)) "CACHE HIT RATIO"
    FROM v$sysstat cur, v$sysstat con, v$sysstat phy
    WHERE cur.name = 'db block gets'
    AND con.name = 'consistent gets'
    AND phy.name = 'physical reads';
    CACHE HIT RATIO
    ,749500702
    So my question is, what is that hit ratio at Oracle Enterprise Manager?

    Hi Elidas,
    what is that hit ratio at Oracle Enterprise Manager? Thet don't publish their formula, but you can log an SR and ask.
    By itself, the buffer cache hit ratio is not very meaningful, and the data buffer cache hit ratio is largely meaningless for decision support and data warehouse applications because of their propensity to have full-table scans and parallel full-table scans (which may bypass the data buffers entirely, using PGA memory).
    The buffer cache hit ratio is most meaningful for databases with an undersized db_cache_size, where the "working set" of frequently-referenced data has not been cached. Oracle provides the data buffer cache advisory utility (v$db_cache_advice) in the standard AWR report. (and later releases of STATSPACK reports). Oracle has expanded the advisory utilities to include a shared pool, Java and PGA advisory.
    Here are my notes:
    http://www.dba-oracle.com/m_buffer_cache_hit_ratio.htm
    Hope this helps. . .
    Donald K. Burleson
    Oracle Press author

  • 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

  • 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 ratio 48

    just now I have checked the buffer cache hit ratio is 48% . In my production database . is It any problem.
    Thank You
    Prasad

    Maybe, maybe not.
    You might want to post your question into a more appropriate forum : General Database Discussions
    Nicolas.

  • Cache hit ratio

    What is the difference between these two queries??
    which is the cache hit ratio???
    SELECT sum(gets) "GETS",
    sum(getmisses) "MISSES",
    (100*(sum(getmisses)/sum(gets))) "RATIO%"
    FROM v$rowcache;
    Result:
    GETS MISSES RATIO%
    366606     19906     5.42980747723714287272985166636661702209
    SELECT ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit Ratio"
    FROM v$sysstat cur, v$sysstat con, v$sysstat phy
    WHERE cur.name = 'db block gets'
    AND con.name = 'consistent gets'
    AND phy.name = 'physical reads';
    Result:
    Cache Hit Ratio
    98.47

    You do NOT need to increase DB_BLOCK_CACHE.
    Partly that's because it's DB_CACHE_SIZE, but that's a side issue.
    It's not a "valid approach" either.
    These things aren't down to "personal preference". If you do care about the hit ratio, you are wasting your time, sadly misguided, technically misdirected and have bought into one of the longest-running myths about Oracle that exists.
    Those are facts, not mere words.
    Jonathan Lewis, Tom Kyte, Me, Richard Foote, Anjo Kolk, Cary Milsap, Connor McDonald, Kevin Closson... you will not find a technically competent "Oracle expert" on this planet that thinks the buffer cache hit ratio is worth two beans as a measure of anything. Any one of those people can, if they have a mind to, explain for the thousandth time WHY this is so, but quite frankly, they probably have better things to do with their time because the issue has been done to death, over and over and over for years on end.
    You can read the latest discussion of it here, if you like:
    http://groups.google.com.au/group/comp.databases.oracle.server/browse_thread/thread/1a946dbe8dcfa71e/47793b44134e60d6?hl=en#47793b44134e60d6
    It's interminable and silly, but the main "clear arguments" are nevertheless put across quite clearly by a number of people, myself included.
    All I'll do here is remind you that if you have insufficient undo tablespace, you will be re-using the same undo blocks over and over again. That will mean lots of logical reads in the buffer cache, and your hit ratio will rise accordingly. That will result in a "good" ratio, according to you... but it will actually be a symptom of an insufficiently-sized undo tablespace.
    When a tool can't distinguish between "good" things and "bad" but registers the same measurement in both scenarios then, as a matter of plain common sense, that tool is useless.
    The buffer cache hit ratio is likewise worthless as a measure of anything other than "something is going on in the database but I can't tell you what".

  • 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

Maybe you are looking for

  • C309a all-in-one printer gets message: wireless radio is not functioning, contact HP support.

    Wireless connectivity lost this morning. Don't know why. When running diagnostics, I get message: The wirelss radio is not functioning. Contact HP support.

  • Oracle 11g Enterprise Manager Issue -- Cannot run DB & em dbconsole at 1ce

    Hi All I am coming for your help with a query uncommon. I have configured, my oracle 11g database, on windows 32 bit machine. Initially I had set sga_target to enable ASMM expecting Oracle to manage this part. However, upon subsequent restart, DB cou

  • Test Script/case for checking Securities in SAP BW-7.3

    Hi All, Please  test script/case for testing securities/authorizations in BW-7.3 after upgrade. Basically we have upgraded from BW-3.5 to BW-7.3 and as securities concepts got changes we need to test for the same. Thanks. Regards, Manju

  • IN Vs Exists

    Hi , Recently I was asked in an interview: When we would "IN" clause would be preferred to use over "EXISTS" clause. I had told the interviewer that "EXISTS" will ignore NULL value if the table has any. Wheter was I correct? Please provide valueable

  • Installing Windows 7 to a Pavillon

    Before I purchase a Windows 7 dvd, I would like to know if it kan be installed on the device. HP Pavillion dv6836eo Entertainment Notebook Thank you for any answer This question was solved. View Solution.