首页 > 代码库 > oracle命中率模型计算

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的空间。