oracle命中率模型计算

命中率模型是在owi之前比较常用的一种诊断性能问题的方法，通过命中率的计算，发现系统中的一些设置是否合理，当命中率不高的时候，通过调整一些参数和设置，提高命中率，有效的提高系统的性能和吞吐量。但当系统的命中率很高的时候，系统的性能问题和瓶颈就无法使用命中率模型来有效的定位，因为命中率说到底是一种平均值，而均值会隐藏系统的问题，这里暂且讨论oracle系统上几个相关的命中率的计算。另外会再讨论owi模型。

在awi的报告中，首先是oracle实例和snapshot信息，然后就是report summary，最后是main report。

　　

Report summary一共包含：

1. load profile：机器的负载情况
2. Instance Efficiency Percentages (Target 100%)：这个即命中率模型计算的各项命中率
3. Shared Pool Statistics：shared pool的统计信息
4. Top 5 Timed Events：owi模型给出的top 5等待事件

Load  profile这一块内容放到oracle性能量化里单独进行讨论

Top 5 Timed Events这一块放到owi模型里讨论

下面根据Report summary中提到的ratio模型来看看各个组件的命中率查询方法。

Instance Efficiency Percentages (Target 100%)
Buffer Nowait %:    99.99    Redo NoWait %:    100.00
Buffer Hit %:    99.03    In-memory Sort %:    100.00
Library Hit %:    99.99    Soft Parse %:    100.00
Execute to Parse %:    45.50    Latch Hit %:    99.83
Parse CPU to Parse Elapsd %:    0.60    % Non-Parse CPU:    -74,999,900.00

1. share pool命中率

　　

share pool顾名思义是共享池，oracle设计的一个理念（concept），尽最大可能资源共享，oracle数据库的设计上处处可以看到这样的设计，share pool是，整个sga也是，服务器进程mts模式的设计也是。

共享带来的好处：

　　1，  节省空间，为了提高数据，这些空间都使用内存，而内存有限，所以共享可以节省空间

　　2，  减少重复的开销，比如sql的解析，如果不共享，每个服务器进程都要parse sql。

共享引入的开销：

资源的共享，在并发的时候，就要保证数据的一致性，而这就要求对共享资源的访问修改必须串行，当前，实现并发对共享资源访问的方法，基本上使用的都是锁的模式。所以，共享会引入管理的复杂度，即锁并发的管理，好的锁得实现，可以最小粒度的减少串行化，提高并发量。

1.1  dictionary cache

　　

dictionary cache存放username，segment， profile data， tablespace ，sequence numbers，metadata等数据字典信息。

V$rowcache：

1. 　　Gets:请求的次数
2. 　　Getmisses：请求未命中，产生了I/O
3. 　　Modifications:被更新的次数

Dictionary cache命中率的计算：

　　

select PARAMETER, sum(gets), sum(getmisses), sum(gets-getmisses)/sum(gets), sum(modifications) from v$rowcache where gets>0
  2  group by parameter;

PARAMETER         SUM(GETS)   SUM(GETMISSES)    SUM(GETS-GETMISSES)/SUM(GETS)    SUM(MODIFICATIONS)
-------------------------------- ---------- -------------- ----------------------------- ------------------
dc_constraints                        26105          17709                     .32162421              25985
dc_tablespaces                    671821624            332                    .999999506                  3
dc_tablespace_quotas                 361936           1821                    .994968724              38936
dc_awr_control                       490926             11                    .999977593              12374
dc_object_grants                     422828          20466                     .95159734                  0
dc_histogram_data                  61172551         789981                    .987086022              99819
dc_rollback_segments              155350233            336                    .999997837                299
dc_sequences                        8448387          28616                    .996612845            8448383
dc_usernames                      220455977           4395                    .999980064                 50
dc_segments                        12950991         869311                    .932876874             306741
dc_objects                         64257294         593589                    .990762309             204066
dc_database_links                  98889512            348                    .999996481                 48
dc_histogram_defs                 226295391        2692490                    .988101879             558557
dc_table_scns                          4085           1621                    .603182375                 17
dc_hintsets                               4              4                             0                  0
dc_users                         1080674219           1936                    .999998209               4027
dc_qmc_cache_entries                      4              3                           .25                  0
outstanding_alerts                   726430            221                    .999695772                 19
dc_files                             160769           1577                    .990190895                 20
dc_object_ids                     107109518         319172                    .997020134              42773
dc_global_oids                     13917214           5956                    .999572041                858
dc_profiles                        42888582              4                    .999999907                  1
global database name                   1522             40                    .973718791                  0

23 rows selected.

1.2  library cache

　　

library cache存放sql cursors， pl/sql programs， java classes等，主要是应用相关的代码，即这里存放着可执行代码。

V$librarycache

　　Reload:               因为空间不足或其它原因被aged out。

　　Invalidations： 因为失效，而从新parse or compile。

使用下面的sql查询：

Xpchild/xpchild@orcl>select namespace, pins, pinhits,reloads, invalidations from v$librarycache order by 1;

NAMESPACE             PINS    PINHITS    RELOADS INVALIDATIONS
--------------- ---------- ---------- ---------- -------------
BODY             174437675  174432698       2615             0
CLUSTER             237743     237312        281             0
INDEX              9702979    9629171      37528             0
JAVA DATA             1396       1392          0             0
JAVA RESOURCE         5082       3569        215             0
JAVA SOURCE           5389       3858        262             0
OBJECT                   0          0          0             0
PIPE                 15862      15779          0             0
SQL AREA        3253149334 3215928721   10753752        535924
TABLE/PROCEDURE  620436845  619644445     352466             0
TRIGGER          208535856  208522398       7590             0

　　

Library cache的命中率的计算方法：

Library cache Hit Ratio =sum(pinhits)/sum(pins)

例如：

Xpchild/xpchild@orcl>select sum(pinhits)/sum(pins) from v$librarycache;

SUM(PINHITS)/SUM(PINS)
----------------------
.991068196

1 row selected.

1.3 Shared pool空间中空闲空间的查看

　　

Xpchild/xpchild@orcl>select * from  v$sgastat where name='free memory' and pool='shared pool';

POOL         NAME                                BYTES
------------ ------------------------------ ----------
shared pool  free memory                     699561872

2, buffer cache

　　

根据v$db_cache_advice来调整data_buffer的大小，但会给系统增加额外的开销，这里默认advice都是关闭的。

1,计算开机以来总的buffer cache hit ratio的方法：

select o.object_name,count(*)  number_of_blocks

from dba_objects o, v$bh bh

where o.data_object_id=bh.objd

and o.owner !='SYS'

GROUP BY O.OBJECT_NAME

ORDER BY COUNT(*) DESC

当在awr里计算的每个snapshot的命中率，是根据interval时间段来取v$sysstat的采样值进行计算而得。

2,计算单独的buffer pool的hit ratio：

select name, DB_BLOCK_GETS,CONSISTENT_GETS,PHYSICAL_READS from v$buffer_pool_statistics;

这里得到每个buffer pool的命中率。

3, 段使用的buffer pool情况

select o.object_name,count(*)  number_of_blocks

from dba_objects o, v$bh bh

where o.data_object_id=bh.objd

and o.owner !='SYS'

GROUP BY O.OBJECT_NAME

ORDER BY COUNT(*) DESC

4,段使用的buffer pool的百分比

根据3计算得到的块数，下面再计算当前的buffer pool的大小。

 select name, BLOCK_SIZE , BUFFERS from v$buffer_pool;

所以buffer pool的命中率和其它的计算牵涉到几个动态视图：

1. v$bh:buffer pool每一个块的情况
2. v$sysstat：系统上统计的物理读和逻辑读的情况
3. v$buffer_pool：每一个buffer pool的大小情况
4. v$buffer_pool_statistics:每一个buffer pool的逻辑读和物理读情况

3   parse

使用v$sysstat统计信息来得到parse相关的统计

Select name, value
From v$sysstat
where name in ('parse time cpu' , 'parse time elapsed' , 'parse count (hard)', 'CPU used by this session');
NAME                                VALUE
------------------------------ ----------
CPU used by this session        199863525
parse time cpu                     195376
parse time elapsed                 355588
parse count (hard)               15455146

Tips：

Large pool分配：

　　1，  mts分配uga

　　2，  并行执行，进程间消息缓冲

　　3，  备份，rman磁盘I/O缓存区。

Cache sequence number可以减少dictionary cache lock的使用，

相同的sql，绑定变量的名称也必须相同。

如果使用mts，那么每一个session会使用10k的shared pool的空间。