命中率模型是在owi之前比较常用的一种诊断性能问题的方法，通过命中率的计算，发现系统中的一些设置是否合理，当命中率不高的时候，通过调整一些参数和设置，提高命中率，有效的提高系统的性能和吞吐量。但当系统的命中率很高的时候，系统的性能问题和瓶颈就无法使用命中率模型来有效的定位，因为命中率说到底是一种平均值，而均值会隐藏系统的问题，这里暂且讨论oracle系统上几个相关的命中率的计算。另外会再讨论owi模型。
在awi的报告中，首先是oracle实例和snapshot信息，然后就是report summary，最后是main report。
Report summary一共包含：
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
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：
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的命中率和其它的计算牵涉到几个动态视图：
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的空间。
原文：http://www.cnblogs.com/xpchild/p/3695017.html