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命中率的计算：

Tips：

Large pool分配：

　　1，  mts分配uga

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

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

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

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

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

oracle命中率模型计算,布布扣,bubuko.com