如何分析shared_pool的sql命中率
这篇文章给大家介绍如何分析shared_pool的sql命中率，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
创新互联建站是一家朝气蓬勃的网站建设公司。公司专注于为企业提供信息化建设解决方案。从事网站开发，网站制作，网站设计，网站模板，微信公众号开发，软件开发，微信小程序开发，10年建站对发电机回收等多个领域，拥有丰富的营销推广经验。
如果一个SQL语句命中,将大大降低数据库服务器的负载,因为一个sql的硬解析生成执行计划是很消耗资源的。
下面列一下一个sql语句的执行过程。
1.将SQL语句经过hash算法后得到一个值Hash_Value
2.如果该值在内存中存在，那么叫命中执行软分析
3.如果该值不存在，执行硬解析
4.进行语法分析
5.进行语意分析
6如果有视图，将视图的定义取出
7.进行SQL语句的自动改写，如将子查询改成为连接
8.优选最佳的执行计划
9.变量的绑定
10.运行执行计划
11.将结果返回给用户
如果是软分析，直接运行9以后的步骤。
共享池的命中率
select namespace,pins,pinhits,reloads,invalidations from v$librarycache order by namespace;
NAMESPACE PINS PINHITS RELOADS INVALIDATIONS
--------------- ---------- ---------- ---------- -------------
BODY 29530 29446 0 0
CLUSTER 429 421 0 0
INDEX 60 3 0 0
JAVA DATA 0 0 0 0
JAVA RESOURCE 0 0 0 0
JAVA SOURCE 0 0 0 0
OBJECT 0 0 0 0
PIPE 0 0 0 0
SQL AREA 134280 128465 226 32
TABLE/PROCEDURE 63727 59391 4 0
TRIGGER 2375 2356 0 0
已选择11行。
SQL> desc v$librarycache
Name Null Type
----------------------------------------- -------- ----------------------------
NAMESPACE VARCHAR2(15)
GETS NUMBER 可以理解为某个object解析的时候查找的次数(解析阶段)
GETHITS NUMBER get命中次数
GETHITRATIO NUMBER 这个值等于gethits/gets
PINS NUMBER 某个object 解析过后被执行的次数(发生在执行阶段)
PINHITS NUMBER pin命中次数
PINHITRATIO NUMBER 这个值等于pinhits/pins
RELOADS NUMBER 某个object 解析过后被从新加载的次数(需要从新从磁盘读取object)，也就是没有被缓存到library cache中，这个通常由于shared pool 过小
INVALIDATIONS NUMBER 某个对象无效，通常由于对象定义被更改，需要从新解析
DLM_LOCK_REQUESTS NUMBER
DLM_PIN_REQUESTS NUMBER
DLM_PIN_RELEASES NUMBER
DLM_INVALIDATION_REQUESTS NUMBER
DLM_INVALIDATIONS NUMBER
查看总的library cache pinhitratio 应该大于90%，最理想大于95%
实例启动以来的命中率
select sum(pinhits)/sum(pins) from v$librarycache;
SUM(PINHITS)/SUM(PINS)
----------------------
.955756135
根据如下视图可以查看shared_pool建议大小
select * from v$shared_pool_advice
如果SQL的命中率小于90%,我们就要优化,优化的手段如下:
1.加大shared_pool_size 的大小，v$shared_pool_advice 根据这个视图
2.编写程序的时候使用变量传入，而不是使用常量
3.将大的包定在内存中
4.修改初始化参数cursor_sharing
a.Force是比较理想的情况时候使用，如果你的业务逻辑很清晰，应用设计的非常好，那么可以使用FORCE，我对 一 些小的项目设置成FORCE，这样可以减少shared_pool的开支，9i的不建议如此设置，10.2.0.3以前的版本不建议这么设置，有很多bug；
b.EXACE是精确匹配变量的一种解析方式，这个模式下，如果一个sql查询的时候where条件里写a=1和a=2时，优化器会生成新的执行计划，而不认为是一直的sql，占用shared_pool比率很严重；10.2.0.3以后的版本不建议设置；
c.SIMILAR是个折中的方案，让优化器自己去判断，是Oracle比较向往的方式，但是无论是基于规则的优化器还是基于成本的优化器，目前做的都不是很好，Similar的bug目前要比FORCE还要多；
实验进行验证，如下:
conn scott/tiger
create table t1 as select * from emp;
insert into t1 select * from t1;
/
/
commt;
update t1 set empno=1000;
commit;
update t1 set empno=2000 where rownum=1;
commit;
create index i_t1 on t1(empno);
//分析表，告诉数据库表的大小
analyze table t1 compute statistics;
//分析列，告诉数据库empno列的数据分布是不均匀的,只有一行为2000,其它所有行为1000
analyze table t1 compute statistics for columns empno;
show parameter cursor_sharing
exact
SQL> set autot traceonly explain
SQL> select * from scott.t1 where empno=1000;
执行计划
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 229K| 6943K| 320 (5)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T1 | 229K| 6943K| 320 (5)| 00:00:04 |
SQL> select * from scott.t1 where empno=2000;
执行计划
----------------------------------------------------------
Plan hash value: 4068921349
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 31 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 31 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_T1 | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------
实验 SIMILAR
conn /as sysdba
alter system set cursor_sharing=SIMILAR scope=spfile
startup force
set autotrace traceonly
show parameter cursor_sharing
SIMILAR
SQL> set autot traceonly explain
SQL> select * from scott.t1 where empno=1000;
执行计划
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 229K| 6943K| 320 (5)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T1 | 229K| 6943K| 320 (5)| 00:00:04 |
SQL> select * from scott.t1 where empno=2000;
执行计划
----------------------------------------------------------
Plan hash value: 4068921349
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 31 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 31 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_T1 | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------
实验 FORCE
conn /as sysdba
alter system set cursor_sharing=FORCE scope=spfile
startup force
set autotrace traceonly
show parameter cursor_sharing
FORCE
SQL> set autot traceonly explain
SQL> select * from scott.t1 where empno=1000;
执行计划
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 229K| 6943K| 320 (5)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T1 | 229K| 6943K| 320 (5)| 00:00:04 |
SQL> select * from scott.t1 where empno=2000;
执行计划
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 229K| 6943K| 320 (5)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| T1 | 229K| 6943K| 320 (5)| 00:00:04 |
错误的执行计划
实验的总论:
强制匹配(FORCE) 将where条件都用变量来处理,提高了SQL的命中率,但不能区分列值的数据敏感性,会导致部
分sql语句的执行计划不是正确的.
近似匹配(SIMILAR) 将where条件都用变量来处理,提高了SQL的命中率,但可以区分列值的数据敏感性,既保证了
语句的复用,提高的命中率,又可以区分列的条件差异.但oralce有的时候会有bug,导致美好的东西变成
了泡影.所以我们改了以后一定观察一下性能.
精确匹配(EXACT) 将原语句不处理,降低了SQL的命中率,但保证执行计划都是正确的.精确匹配为默认值.
关于如何分析shared_pool的sql命中率就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
本文标题：如何分析shared_pool的sql命中率
当前链接：http://myzitong.com/article/pojcjd.html