oracle cache命中率,oracle命中率模型计算

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

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

Report summary一共包含：

load profile：机器的负载情况

Instance Efficiency Percentages (Target 100%)：这个即命中率模型计算的各项命中率

Shared Pool Statistics：shared pool的统计信息

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.00Buffer Hit%: 99.03 In-memory Sort %: 100.00Library Hit%: 99.99 Soft Parse %: 100.00

Execute to Parse %: 45.50 Latch Hit %: 99.83Parse CPUto Parse Elapsd %: 0.60 % Non-Parse CPU: -74,999,900.00

share pool命中率

share

pool顾名思义是共享池，oracle设计的一个理念(concept)，尽最大可能资源共享，oracle数据库的设计上处处可以看到这样的设计，share

pool是，整个sga也是，服务器进程mts模式的设计也是。

共享带来的好处：

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

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

共享引入的开销：

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

1.1dictionary cache

dictionary cache存放username，segment， profile data， tablespace ，sequence

numbers，metadata等数据字典信息。

V$rowcache：

Gets:请求的次数

Getmisses：请求未命中，产生了I/O

Modifications:被更新的次数

Dictionary cache命中率的计算：

select PARAMETER, sum(gets), sum(getmisses), sum(gets-getmisses)/sum(gets), sum(modifications) from v$rowcache where gets>0

2 group byparameter;

PARAMETERSUM(GETS) SUM(GETMISSES) SUM(GETS-GETMISSES)/SUM(GETS) SUM(MODIFICATIONS)-------------------------------- ---------- -------------- ----------------------------- ------------------

dc_constraints 26105 17709 .32162421 25985dc_tablespaces671821624 332 .999999506 3dc_tablespace_quotas361936 1821 .994968724 38936dc_awr_control490926 11 .999977593 12374dc_object_grants422828 20466 .95159734 0dc_histogram_data61172551 789981 .987086022 99819dc_rollback_segments155350233 336 .999997837 299dc_sequences8448387 28616 .996612845 8448383dc_usernames220455977 4395 .999980064 50dc_segments12950991 869311 .932876874 306741dc_objects64257294 593589 .990762309 204066dc_database_links98889512 348 .999996481 48dc_histogram_defs226295391 2692490 .988101879 558557dc_table_scns4085 1621 .603182375 17dc_hintsets4 4 0 0dc_users1080674219 1936 .999998209 4027dc_qmc_cache_entries4 3 .25 0outstanding_alerts726430 221 .999695772 19dc_files160769 1577 .990190895 20dc_object_ids107109518 319172 .997020134 42773dc_global_oids13917214 5956 .999572041 858dc_profiles42888582 4 .999999907 1globaldatabase name 1522 40 .973718791 0

23 rows selected.

1.2library 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 0CLUSTER237743 237312 281 0

INDEX 9702979 9629171 37528 0JAVA DATA1396 1392 0 0JAVA RESOURCE5082 3569 215 0JAVA SOURCE5389 3858 262 0OBJECT0 0 0 0

PIPE 15862 15779 0 0SQL AREA3253149334 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) fromv$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_blocksfromdba_objects o, v$bh bhwhere o.data_object_id=bh.objdand 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_blocksfromdba_objects o, v$bh bhwhere o.data_object_id=bh.objdand 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的命中率和其它的计算牵涉到几个动态视图：

v$bh:buffer pool每一个块的情况

v$sysstat：系统上统计的物理读和逻辑读的情况

v$buffer_pool：每一个buffer pool的大小情况

v$buffer_pool_statistics:每一个buffer pool的逻辑读和物理读情况

3   parse

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

Selectname, valueFromv$sysstatwhere name in (‘parse time cpu‘ , ‘parse time elapsed‘ , ‘parse count (hard)‘, ‘CPU used by this session‘);

NAME VALUE------------------------------ ----------

CPU used by this session 199863525parse time cpu195376parse time elapsed355588parsecount (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的空间。

原文：http://www.cnblogs.com/xpchild/p/3695017.html