[20151014]关于result cache.txt

--11G 开始支持result cache,把执行的结果保存在共享池,从而一定程度减少逻辑读,而那些对象或者那些语句适合做result cache呢?
--自己在前一段时间想把一些表设置RESULT_CACHE为MODE FORCE,访问这些对象时,可以利用result cache模式。
--另外我本来想一些语句通过sql patch的方式加入提示/*+ result_cache */ ,结果不成功。
--参考链接:http://blog.itpub.net/267265/viewspace-1377511/

--那些对象可以这样呢?
--我个人觉得那些执行频次很高的sql语句以及"只读"表(指很少修改的表)做为首选。测试看看:

1.测试环境:
SCOTT@test> @ver1
PORT_STRING          VERSION        BANNER
-------------------- -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx  11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

SCOTT@test> create table t as select rownum id , lpad('x',200,'x') name  from dual connect by level<=1e4;
Table created.

create unique index pk_t on t (id);
alter table t add constraint pk_t primary key (id);

--分析表忽略。
SCOTT@test> select rowid,t.id from t where id in (1,1000);
ROWID                      ID
------------------ ----------
AABNepAAEAAAACjAAA          1
AABNepAAEAAAAJCAAN       1000

--这两条记录在不同的块中。
--设置result_cache=mode force.

SCOTT@test> alter table t result_cache (mode force);
Table altered.

2.测试:
--注:为了测试方便,打开2个会话,一个设置了set autot traceonly stat;另外一个用来查询相关视图以及一些dml语句。
--session 2:
SCOTT@test> variable x number ;
SCOTT@test> exec :x :=1;
PL/SQL procedure successfully completed.

SCOTT@test> set autot traceonly stat;
SCOTT@test> select * from t where id=:x;
Statistics
----------------------------------------------------------
         34  recursive calls
          0  db block gets
         34  consistent gets
          0  physical reads
          0  redo size
        787  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT@test> select * from t where id=:x;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        787  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--可以发现第2次执行逻辑读已经为0.说明使用result cache.

3.检查相关视图:

--session 1:
SCOTT@test> SELECT id,TYPE,status,NAME,object_no,cache_id,invalidations,scn FROM v$result_cache_objects;
ID TYPE        STATUS    NAME                              OBJECT_NO CACHE_ID                    INVALIDATIONS          SCN
--- ----------- --------- ------------------------------ ------------ --------------------------- ------------- ------------
  0 Dependency  Published SCOTT.T                              317353 SCOTT.T                                 0  13205305992
  1 Result      Published select * from t where id=:x               0 cxm3q1hv157ps2t68sgc4wp3cg              0  13205305992

SCOTT@test> select * from GV$RESULT_CACHE_DEPENDENCY;
     INST_ID    RESULT_ID    DEPEND_ID    OBJECT_NO
------------ ------------ ------------ ------------
           1            1            0       317353

SCOTT@test> select owner,object_name,object_id,data_object_id from dba_objects where owner=user and object_name in ('T','PK_T');
OWNER  OBJECT_NAME             OBJECT_ID DATA_OBJECT_ID
------ -------------------- ------------ --------------
SCOTT  PK_T                       317354         317354
SCOTT  T                          317353         317353

--可以发现依赖的对象的OBJECT_NO=317353,也就是表T。而不是索引(我以为也会依赖索引)。

4.现在修改id=1000;
--session 1:
SCOTT@test> update t set name=name where id=1000;
1 row updated.

SCOTT@test> commit ;
Commit complete.

--session 2:
SCOTT@test> select * from t where id=:x;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        787  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT@test> select * from t where id=:x;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        787  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--可以发现存在逻辑读,这从一个侧面说明如果这个对象存在修改,会直接导致result cache失效。依赖的对象是表,而不是数据块(感
--觉如果这样代价有点高)。

5.继续测试:
--session 2:
SCOTT@test> select count(*) from t ;
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         25  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT@test> select count(*) from t ;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
--这个语句执行计划应该使用主键索引。

--session 1:
SCOTT@test> SELECT id,TYPE,status,NAME,object_no,cache_id,invalidations,scn FROM v$result_cache_objects;
ID TYPE        STATUS    NAME                              OBJECT_NO CACHE_ID                    INVALIDATIONS          SCN
--- ----------- --------- ------------------------------ ------------ --------------------------- ------------- ------------
  0 Dependency  Published SCOTT.T                              317353 SCOTT.T                                 1  13205306169
  3 Result      Published select count(*) from t                    0 gp1k5qq6gk8spd439xt91vnwb0              0  13205306238
  2 Result      Published select * from t where id=:x               0 cxm3q1hv157ps2t68sgc4wp3cg              0  13205306171
  1 Result      Invalid   select * from t where id=:x               0 cxm3q1hv157ps2t68sgc4wp3cg              0  13205305992

SCOTT@test> select * from GV$RESULT_CACHE_DEPENDENCY;
     INST_ID    RESULT_ID    DEPEND_ID    OBJECT_NO
------------ ------------ ------------ ------------
           1            3            0       317353
           1            2            0       317353

--即使执行select count(*) from t ;,我开始以为这样会依赖主键索引,结果依赖的还是表T。
--说明一下:RESULT_ID=3的记录,对应DEPEND_ID=0,而SELECT * FROM v$result_cache_objects where DEPEND_ID=0的记录表scott.T .
--这样说明即使存在DML语句也会导致result cache失效。

6.修改记录看看:
-- session 1:
SCOTT@test> select * from  t where id=999 for update ;
ID NAME
--- -----
999 test

SCOTT@test> commit ;
Commit complete.

-- session 2:
SCOTT@test> select count(*) from t ;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         25  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--说明:我选择select .. for update 测试,结果一样。result cache失效。

SCOTT@test> SELECT id,TYPE,status,NAME,object_no,cache_id,invalidations,scn FROM v$result_cache_objects;
ID TYPE        STATUS    NAME                              OBJECT_NO CACHE_ID                    INVALIDATIONS          SCN
--- ----------- --------- ------------------------------ ------------ --------------------------- ------------- ------------
  0 Dependency  Published SCOTT.T                              317353 SCOTT.T                                 3  13205306490
  5 Result      Published select count(*) from t                    0 gp1k5qq6gk8spd439xt91vnwb0              0  13205306493
  1 Result      Invalid   select * from t where id=:x               0 cxm3q1hv157ps2t68sgc4wp3cg              0  13205305992
  2 Result      Invalid   select * from t where id=:x               0 cxm3q1hv157ps2t68sgc4wp3cg              0  13205306171
  3 Result      Invalid   select count(*) from t                    0 gp1k5qq6gk8spd439xt91vnwb0              0  13205306238
  4 Result      Invalid   select count(*) from t                    0 gp1k5qq6gk8spd439xt91vnwb0              0  13205306433

6 rows selected.

--我感觉依赖的本质是scn。继续测试就可以看到问题了:

7.修改记录然后回滚。
SCOTT@test> update t set name=name where id=998;
1 row updated.

SCOTT@test> rollback;
Rollback complete.

SCOTT@test> select count(*) from t ;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
-- result cache 有效!

SCOTT@test> update t set name=name where id=998;
1 row updated.
--不提交

SCOTT@test> select count(*) from t ;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--我没有提交或者执行了rollback,都不会影响结果集。

SCOTT@test> commit ;
Commit complete.

SCOTT@test> select count(*) from t ;

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         25  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--consistent gets=25。结果集失效。

8.总结:
---从以上测试,可以说明result cache 使用范围仅仅合适频繁执行,涉及对象表少量修改的语句。或者也许一些数据仓库DML结果集很少变
--化的情况。这样才能一定程度减少逻辑读,提高性能。

--另外可以通过查询视图确定v$result_cache_objects,确定那些对象不合适做result cache。
--看看生产系统:

> SELECT id,TYPE,status,NAME,object_no,cache_id,invalidations,scn FROM v$result_cache_objects where INVALIDATIONS>=1000;
     ID TYPE        STATUS    NAME                    OBJECT_NO CACHE_ID            INVALIDATIONS          SCN
------- ----------- --------- -------------------- ------------ ------------------- ------------- ------------
336708 Dependency  Published XXXXXX_XXX.YF_DB01          96396 XXXXXX_XXX.YF_DB01           8420  13860014605
  39171 Dependency  Published XXXXXX_XXX.GY_XTCS          94089 XXXXXX_XXX.GY_XTCS         318486  13860074094
  39283 Dependency  Published XXXXXX_XXX.GY_YHCS          94111 XXXXXX_XXX.GY_YHCS         499397  13860074730
      3 Dependency  Published XXXXXX_XXX.GY_YGDM          94105 XXXXXX_XXX.GY_YGDM           4094  13859061872

--这些对象也许不适合修改表的result cache属性为force。当然要仔细评估。我们的系统刷屏语句实在太厉害了。

--我简单写一个脚本:
$ cat d_buffer.sql
col executions1 new_value x1
col buffer_gets1 new_value x2
col ELAPSED_TIME1 new_value x3
col ROWS_PROCESSED1 new_value x4

col executions2 new_value y1
col buffer_gets2 new_value y2
col ELAPSED_TIME2 new_value y3
col ROWS_PROCESSED2 new_value y4

select executions executions1,buffer_gets buffer_gets1,elapsed_time elapsed_time1,rows_processed rows_processed1  from v$sqlarea where sql_id='&&1';
prompt ... sleep &&2 , waiting ....
host sleep &&2
select executions executions2,buffer_gets buffer_gets2,elapsed_time elapsed_time2 ,rows_processed rows_processed2 from v$sqlarea where sql_id='&&1';
select (&y2-&x2)/(&y1-&x1) "每次buffer_gets",&y1- &x1 "执行次数" ,  (&y3-&x3)/(&y1-&x1) "每次执行时间" , (&y4-&x4)/(&y1-&x1) "平均处理记录数" from dual ;

SQL> select sql_id,sql_text,executions from v$sqlarea where sql_id='ff511u9ndctfr';
SQL_ID        SQL_TEXT                                                       EXECUTIONS
------------- ------------------------------------------------------------ ------------
ff511u9ndctfr Select CSZ From GY_XTCS Where CSMC =:1                             250432

SQL> @d_buffer ff511u9ndctfr 10

EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1
------------ ------------ ------------- ---------------
      255148       200085      15952863          255150

... sleep 10 , waiting ....

EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2
------------ ------------ ------------- ---------------
      255657       200397      15980172          255659

每次buffer_gets     执行次数 每次执行时间 平均处理记录数
--------------- ------------ ------------ --------------
   .61296660118          509 53.652259332              1

--10内执行509次,平均下来50次/秒。真不知道开发什么写代码的????

[20151014]关于result cache.txt相关推荐

  1. [20190214]11g Query Result Cache RC Latches.txt

    [20190214]11g Query Result Cache RC Latches.txt --//昨天我重复链接http://www.pythian.com/blog/oracle-11g-qu ...

  2. Oracle 11g新特性:Result Cache

    结果集缓存(Result Cache)是Oracle Database 11g新引入的功能,除了可以在服务器端缓存结果集(Server Result Cache)之外,还可以在客户端缓存结果集(Cli ...

  3. oracle 结果缓存,Result cache结果缓存

    结果缓存 结果缓存默认是可以开启的 , 可以通过下面的方式查询其是否开启 SQL> SQL> show parameter RESULT_CACHE_MAX_SIZE NAME       ...

  4. Oracle结果集缓存(Result Cache)--服务器、客户端、函数缓存

    Oracle结果集缓存(Result Cache)--服务器.客户端.函数缓存 在11g中,Oracle提供了结果集缓存特性.该缓存是在共享内存中存储全部的结果集,如果一个查询SQL被执行,且它对应的 ...

  5. oracle result_cache_max_size,当设置RESULT_CACHE_MAX_SIZE参数并且重启过database后,Query Result Cache 还是被禁用的。...

    来源于: Query Result Cache is disabled After Setting RESULT_CACHE_MAX_SIZE And Restarting The Database ...

  6. Oracle优化 latch free问题Result Cache:RC Latch引起数据库缓慢

    Oracle12.1的库在业务高峰期非常慢,分析AWR发现latch free导致,具体定位为:Result Cache: RC Latch事件引起数据库缓慢 1.优化之前awr部分信息 awr整体负 ...

  7. oracle sample 慢,【案例】Oracle优化 latch free问题Result Cache:RC Latch引起数据库缓慢...

    天萃荷净 Oracle12.1的库在业务高峰期非常慢,分析AWR发现latch free导致,具体定位为:Result Cache: RC Latch事件引起数据库缓慢 1.优化之前awr部分信息 a ...

  8. Oracle 11g 新特性 -- Result Cache(结果高速缓存)

    Oracle 从11g开始引入了结果集缓存(result cache)的新特性,用于存储经常使用的SQL语句和函数的查询结果,将来语句再执行的时候,oracle直接的访问内存得到结果.其优点是重用相同 ...

  9. oracle 11g 之 result cache

    oracle 11g 之 result cache 今天是2013-10-12,打算最近时间研究一下shared pool的相关原理以及awr报告分析.今天学习一下在oracle 11g shared ...

  10. [20181015]为什么是3秒.txt

    [20181015]为什么是3秒.txt --//以前测试:连接http://blog.itpub.net/267265/viewspace-2144765/=>为什么是12秒.txt. --/ ...

最新文章

  1. 电磁场与电磁波第二章 电磁场的基本规律
  2. 区块链基础知识系列 第四课Hyperledger fabric 1.0网络组成及构建流程
  3. MFC的Application Wizard所生成的各种文件功能
  4. matlab数学建模题及答案,数学建模中30道经典 MATLAB程序.doc
  5. c语言能编写嵌入式程序吗,嵌入式c语言编程之嵌入式c语言编程思想
  6. c语言程序转换成单片机语言,STC12C2052AD单片机AD转换C语言程序(成功)
  7. 行为型设计模式(二)
  8. 通过电话拨号上网的家用计算机,拨号上网需计算机、电话线、帐号和()
  9. 55-将单链表原地逆置(三种方法)
  10. dos2unix和unix2dos命令
  11. 使用Jt2Go控件显示3D模型 / View 3D Model with JT2GO
  12. 空气动力学类毕业论文文献有哪些?
  13. Windows Presentation Foundation 用户指南
  14. 华为云服务器宕机,阿里云无人撼动!
  15. 遥感基础之:LAI、FPAR、PAR、APAR
  16. pdo mysql 建库_pdo 创建数据库
  17. RS-485自收发电路的参考设计
  18. 编程英语:RegExp 正则表达式
  19. VC---强制重启电脑的代码
  20. FL Studio 编辑软件入门讲解

热门文章

  1. 汉字与区位码互转(转)
  2. 子级Repeater获取 父级Repeater 中的值
  3. 【笔记】定积分的近似计算
  4. C# 判断字符中是否包含中文
  5. vue修改数组元素方法
  6. web前端性能优化的技巧
  7. hdu-1521 排列组合 指数型母函数
  8. [2017浙工大之江学院决赛 H] qwb与学姐(并查集,按秩合并,最小生成树,LCA)...
  9. TCP和UDP Socket
  10. openDrive has Free Direct Linking !