Performance Hit Ratios

Hi
I would like calculate the following hit ratios against my instance performance metrics
1.Buffer Cache Hit %
2.Library Cache Hit %
3.Redo No Wait %
4.Memory Sort %
5.Soft Parse %
6.Commit %
And I need to know what would be the optimal values against this hit ratio for 900 GB database with Aix 5.3 platform.
if i dont have optimal values with query results. What are all the parameter should i need to tune and how much i need to tune?
Kindly help me on this.
Thanks
Ranga

V$PGASTAT
This view gives instance-level statistics on the PGA memory usage and the automatic PGA memory manager. For example:
SELECT * FROM V$PGASTAT;
The output of this query might look like the following:
NAME VALUE UNIT
aggregate PGA target parameter 41156608 bytes
aggregate PGA auto target 21823488 bytes
global memory bound 2057216 bytes
total PGA inuse 16899072 bytes
total PGA allocated 35014656 bytes
maximum PGA allocated 136795136 bytes
total freeable PGA memory 524288 bytes
PGA memory freed back to OS 1713242112 bytes
total PGA used for auto workareas 0 bytes
maximum PGA used for auto workareas 2383872 bytes
total PGA used for manual workareas 0 bytes
maximum PGA used for manual workareas 8470528 bytes
over allocation count 291
bytes processed 2124600320 bytes
extra bytes read/written 39949312 bytes
cache hit percentage 98.15 percent
The main statistics displayed in V$PGASTAT are as follows:
aggregate PGA target parameter: This is the current value of the initialization parameter PGA_AGGREGATE_TARGET. The default value is 20% of the SGA size. If you set this parameter to 0, automatic management of the PGA memory is disabled.
aggregate PGA auto target: This gives the amount of PGA memory Oracle can use for work areas running in automatic mode. This amount is dynamically derived from the value of the parameter PGA_AGGREGATE_TARGET and the current work area workload. Hence, it is continuously adjusted by Oracle. If this value is small compared to the value of PGA_AGGREGATE_TARGET, then a lot of PGA memory is used by other components of the system (for example, PL/SQL or Java memory) and little is left for sort work areas. You must ensure that enough PGA memory is left for work areas running in automatic mode.
global memory bound: This gives the maximum size of a work area executed in AUTO mode. This value is continuously adjusted by Oracle to reflect the current state of the work area workload. The global memory bound generally decreases when the number of active work areas is increasing in the system. As a rule of thumb, the value of the global bound should not decrease to less than one megabyte. If it does, then the value of PGA_AGGREGATE_TARGET should probably be increased.
total PGA allocated: This gives the current amount of PGA memory allocated by the instance. Oracle tries to keep this number less than the value of PGA_AGGREGATE_TARGET. However, it is possible for the PGA allocated to exceed that value by a small percentage and for a short period of time, when the work area workload is increasing very rapidly or when the initialization parameter PGA_AGGREGATE_TARGET is set to a too small value.
total freeable PGA memory: This indicates how much allocated PGA memory which can be freed.
total PGA used for auto workareas: This indicates how much PGA memory is currently consumed by work areas running under automatic memory management mode. This number can be used to determine how much memory is consumed by other consumers of the PGA memory (for example, PL/SQL or Java):
PGA other = total PGA allocated - total PGA used for auto workareas
over allocation count: This statistic is cumulative from instance start-up. Over-allocating PGA memory can happen if the value of PGA_AGGREGATE_TARGET is too small to accommodate the PGA other component in the previous equation plus the minimum memory required to execute the work area workload. When this happens, Oracle cannot honor the initialization parameter PGA_AGGREGATE_TARGET, and extra PGA memory needs to be allocated. If over-allocation occurs, you should increase the value of PGA_AGGREGATE_TARGET using the information provided by the advice view V$PGA_TARGET_ADVICE.
total bytes processed: This is the number of bytes processed by memory-intensive SQL operators since instance start-up. For example, the number of byte processed is the input size for a sort operation. This number is used to compute the cache hit percentage metric.
extra bytes read/written: When a work area cannot run optimally, one or more extra passes is performed over the input data. extra bytes read/written represents the number of bytes processed during these extra passes since instance start-up. This number is also used to compute the cache hit percentage. Ideally, it should be small compared to total bytes processed.
cache hit percentage: This metric is computed by Oracle to reflect the performance of the PGA memory component. It is cumulative from instance start-up. A value of 100% means that all work areas executed by the system since instance start-up have used an optimal amount of PGA memory. This is, of course, ideal but rarely happens except maybe for pure OLTP systems. In reality, some work areas run one-pass or even multi-pass, depending on the overall size of the PGA memory. When a work area cannot run optimally, one or more extra passes is performed over the input data. This reduces the cache hit percentage in proportion to the size of the input data and the number of extra passes performed. Example 7-3 shows how cache hit percentage is affected by extra passes.

Similar Messages

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

  • Performance hit using "where" clause in the query

    Hi All,
    I am facing a huge performance hit in the java code when using "where" clause in queries. Following are the details:
    1. SELECT * FROM Employee
    2. SELECT * FROM Employee where employeeid in (26,200,330,571,618,945)
    There is no difference in Query Execution Time for both queries.
    Business Logic Time is huge in second case as compared to first one (ratio - 1:20).
    Rows returned are more in first case as compared to second case.(ratio - 1:4)
    Business Logic is same for both the cases where I iterate through the ResultSet, get the objects and set them in a data structure.
    Does anybody know the reason of unexpected time difference for the business logic in the second case?

    Since you're mentioning clustering your index, I'll assume you are using Oracle. Knowing what database you are using makes it a lot easier to suggest things.
    Since you are using Oracle, you can get the database to tell you what execution plan it is using for each of the 2 SQL statements, and figure out why they have similar times (if they do).
    First, you need to be able to run SQL*Plus; that comes as part of a standard database installation and as part of the Oracle client installation - getting it set up and running is outside the scope of this forum.
    Second, you may need your DBA to enable autotracing, if it's not already:
    http://asktom.oracle.com/~tkyte/article1/autotrace.html
    http://www.samoratech.com/tips/swenableautotrace.htm
    Once it's all set up, you can log in to your database using sql*plus, issue "SET AUTOTRACE ON", issue queries and get execution plan information back.
    For example:
    SQL> set autotrace on
    SQL> select count(*) from it.ticket where ticket_number between 10 and 20;
      COUNT(*)
            11
    Execution Plan
    Plan hash value: 2983758974
    | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |            |     1 |     4 |     1   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE   |            |     1 |     4 |            |          |
    |*  2 |   INDEX RANGE SCAN| TICKET_N10 |    12 |    48 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("TICKET_NUMBER">=10 AND "TICKET_NUMBER"<=20)
    Statistics
              0  recursive calls
              0  db block gets
              1  consistent gets
              0  physical reads
              0  redo size
            515  bytes sent via SQL*Net to client
            469  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> This tells me that this query used an INDEX RANGE SCAN on index TICKET_N1; the query can't do much better than that logically... In fact, the statistic "1 consistent gets" tells me that Oracle had to examine only one data block to get the answer, also can't do better than that. the statistic, "0 physical reads" tells me that the 1 data block used was already cached in Oracle's memory.
    the above is from Oracle 10g; autotrace is available back to at least 8i, but they've been adding information to the output with each release.
    If you have questions about sql_plus, check the forums at asktom.oracle.com or http://forums.oracle.com/forums/category.jspa?categoryID=18
    since sql*plus is not a JDBC thing...
    Oh, and sql*plus can also give you easier access to timing information, with "set timing on".

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

  • How should i increase over all buffer hit ratio.....

    Hi all,
    As shown below if my DB2 databse buffer Qulaity is low .. How should i increase over all buffer hit ratio..
    Please advice on any sap standrd notes or procedures
    Number                                    1
    Total Size                           80,000  KB
    Physical Reads                         6.65  ms
    Physical Writes                        0.00  ms
    Overall Buffer Quality                86.05  %
    Data Hit Ratio                        85.79  %
    Index Hit Ratio                       87.50  %
    No Victim Buffers                259,079,295
    --rahul

    One of the options is to simply increase the bufferpool size using the following command
    db2 alter bufferpool immediate <bufferpool name> size <new bufferpool size>
    However, this will affect the hit ration for a particular bufferpool. If you have more than one bufferpool, you need to identify the bufferpool(s) with worst hit ratio. In the SAP DBA Cockpit, check using
    Performance -> Bufferpool
    The victim buffer information is only useful in case you use alternate page cleaning.
    Note that there are other options to fight bad bufferpool hit ratio - however, with your small bufferpool size (80MB) maybe increasing the size is the appropriate step.
    Malte

  • 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

  • Differents values for Buffer Hit Ratio

    Hi Everyone!
    I have only a buffer_pool(8k) and when I execute this two querys(below). The "Buffer Hit Ratio" results are very different.
    Anyone know why does this happen?? I searched on the Internet and find out just V$SYSSTAT gather dates of all buffer pools
    while V$BUFFER_POOL_STATISTICS maintains statistics for each buffer pool. But i can't understand why it is so different.
    Any suggestion?
    Thanks!
    SELECT 1- ((p.value - l.value - d.value) / s.value) "Buffer Cache Hit Ratio"
    FROM v$sysstat s, v$sysstat l, v$sysstat d, v$sysstat p
    WHERE s.name = 'session logical reads'
    AND d.name = 'physical reads direct'
    AND l.name = 'physical reads direct (lob)'
    AND p.name = 'physical reads';
    Buffer Cache Hit Ratio
    ,970655577
    SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
    1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
    FROM V$BUFFER_POOL_STATISTICS;
    Hit Ratio
    ,584760575
    ORACLE VERSION: Oracle Server 9.2.0.8.0
    OS: IBM/AIX

    See metalink note STATISTIC "cache hit ratio" - Reference Note 33883.1 for the correct formula to use in your calculation.
    The ratio is of limited value. In and of itself it tells you nothing about the performance of your database.
    There have been numerous threads on the ratio in this forum. You can use search to find them if interested.
    HTH -- Mark D Powell --

  • Buffer hit ratio

    I am using the following:
    SELECT ROUND(((1-(SUM(DECODE(NAME, 'physical reads', value, 0)) /
    (SUM(DECODE(NAME, 'db block gets', value, 0))+
    (SUM(DECODE(NAME, 'CONSISTENT GETS', value, 0))))))*100), 2) || '%' BCHR
    FROM V$SYSSTAT
    to calculate the buffer hit ratio. This query is returning: -1753.28%
    Can someone explain why I am getting this crazy number?
    Thanks,
    mdp

    >>
    Many folks misunderstand that bit about "setting your own BHR", and falsely conclude that it's a useless metric. It's not useless.
    <<
    The buffer cache ratio is useful only when considered in relation to other statistics. The problem is that the majority of users seem to think that that a high ratio value is good and a low ratio value is bad based on absolute values and do not understand that the static is dependent on how SQL plans are being solved. If you measure the ratio when the dominant work on the system is being done via hash joins, full scans that touch the target blocks only once, or make use of PQO during the process you can get a fairly low value, but the system is performing well. On the other had poorly performing SQL can result in a high value for the statistic. The value of the statistics bears no direct relationship to performance of the system and it needs to be emphasized that the ratio must be used in conjunction with other available information. The ratio by itself should be considered useless.
    >>
    If the BHR was totally useless, why does Oracle continue to include it in OEM alert thresholds, and STATSPACK and AWR reports?
    <<
    Over the years Oracle has done lots of things that turned out to be wrong so just because Oracle includes the statistics in certain products does not really provide a lot of support for the validity of the statistic. Known errors in the documentation have made it through two full releases. Again it is the misapplication of the statistic that is really at issue. Unfortunately, many poorly written DBA Administration and Tuning books in the past claimed that ratio could be used to measure database performance, and in point of fact the ratio has only a passing relationship to performance depending on the application.
    HTH -- Mark D Powell --

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

  • 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

  • Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios

    Can please one provide information and sql queries to calculate Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios and if any other ratio for investigation of performance issues in oracle 10g database (10g.1 and 10g.2 both). thanks in advance.

    In and by themselves most of the standard ratio calculations are useless to misleading. All the ratios should always be considered in relation to other data such as total requests for a resource, existence of any outlying values in the associated events, etc ....
    The proper warning being given then you can find most of the standard ratios mentioned with SQL for their calculation in the Performance and Tuning manual for your version of Oracle.
    HTH -- Mark D Powell --

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

  • Cache hit ratio - index sql statement

    I am reading the note 33833.1 on Metalink web site. I have diffult to understand the part in the last page of the note. In the last page author talk of a situation where the cache hit ratio is near 100% but the system is not good because. the author talk of a bad sql statement using a non selective index.
    Anyone can explain me this situation ?
    thanks for all

    Because it can be spoofed easily, cache hit ration should never be used as an indicator of system performance. I could not find the article you refered to I can explain it this way:
    Repeatedly hitting the same large amount of datablocks to return a small amount of data will show an artificially high buffer cache hit ratio because the same block get hit over and over, even though most of the data in them is irrelavent.
    Another example would be using subquries instead of joins or joins on inline views.
    All that being said, a low buffer cache hit ratio over an extended period of time is an indicator that the cache is too small, however a high buffer cache hit ration does not mean that is the right size.
    (it's Monday, I hope this makes sense.)

Maybe you are looking for

  • 1-new slim imac, 1-new vista machine, 1-new airport extreme

    so I've been searching around the threads here and it seems like everyone's problems deal with like not seeing a wireless connection or not being able to print or not being able to file share and you would think that my situation was pretty common; i

  • Correcting useful life of an asset in previous year

    Hi, We have implemented SAP last year in April at one of our sites. At the time of initial upload of assets, we made a mistake and some of the assets were uploaded with incorrect useful life. Till date every month we were running depreciation based o

  • OBIEE 11g Time Hierarchy with YTD function problem

    Hi all, Platform: OBIEE 11.1.1.5.0. We have a Calendar dimension (*time dimension*), that includes the usual time hierarchy (Year > Semester > Quarter> Month > Day). Creating a Pivot Table with a YTD measure, using also the Calendar Table hierarchy,

  • How to define role approver/owner - through condition id in ERM 10.0

    Hi All, We have created a BRF + rule for Role approver with Business Process & Function area by giving the Result value as Condition ID eg., Z001 We have provided this condition ID Z001 - in Role Owners table [Under Set Up- Role Owners] and defined t

  • Not like operator not working while matching text from two tables

    Hello  Everyone, I want to find the Id from table child where the column name  is not matching with at least first term of column name from parent table. I am not getting proper output. can anyone help me. Output should be :-->ID 6 & 7 with child as