概述
缓存一直是解决信息、数据访问效率的一个重要方法。常见的缓存包括内存、前端特殊数据结构等。从宏观角度看,缓存的本质是利用空间来换取时间的手段。数据信息虽然都是保存在系统后端的数据库或者文件系统中,但是为了性能常常会将其以一定形式组织到前端,减少访问过程中的传递链过程。
Oracle最常见的Cache就是SGA中的Buffer Cache和Shared Pool。两者一个是缓存数据块,另一个是缓存处理过的执行计划。一个是避免系统出现的频繁物理读过程,一个是避免系统出现的频繁硬解析过程。在Oracle 11g中,Oracle更近了一步,直接将结果集合缓存,推出了Result Cache特性。因为内容比较多,所以分成3篇来做介绍。
1、Result Cache简述
传统的Oracle数据读写操作,都是将数据块(Data Block)缓存到Buffer Cache中。每次SQL语句来了之后,都是从Buffer Cache中检索数据块,也要发生逻辑读。而Result Cache的原理则是更近了一步,是将SQL结果集直接进行保存,每次SQL语句来了,就直接把结果集合返回回去,连逻辑读都省去了。
在Oracle 11g中,推出了Result Cache这种新特性,对于结果集合进行处理。Result Cache的难点在于两个方面,一个是结果集合与目标SQL的匹配,另一个是作为冗余数据的Cache信息,如何反映数据的最新变化。相同的SQL在不同时候发出来,结果不同如何实现。
从Oracle参数中,可以一窥Result Cache的功能。
![79fcea296b83e9555500da032a5027a9.png](https://i-blog.csdnimg.cn/blog_migrate/01dab8a79c39dc780462c548e1ba3090.jpeg)
2、一个简单的Result Cache示例
下面我们来看一个简单的Result Cache示例,有一个基本的认识。选择Oracle 11gR2来进行试验
创建实验数据表T,确定当前Result Cache功能开启。
select * from v$version;show parameter result_cache_max;conn scott/tiger;create table t as select * from dba_objects;select count(*) from t;
result_cache_max_size是Result Cache功能开启的重要参数,只要设置为非零,就可以使用Result Cache功能。
![3f4e1d3be05ec0fd4ce77e8646768069.png](https://i-blog.csdnimg.cn/blog_migrate/d0981ac7a44c69f60309f8816364a278.jpeg)
第一次执行语句
set timing on;set autotrace traceonly;select /*+ result_cache */* from t where owner='SCOTT';
![77f47041ccaac96d8d78dd721515adb6.png](https://i-blog.csdnimg.cn/blog_migrate/d8e32dfd5fe0707a6fb78910a1bf5005.jpeg)
上面三个红色标记的明显展示了Result Cache功能特点。
默认情况下,Oracle Result Cache是不开启的。只有对使用了Result Cache Hint的情况下,才能让SQL语句的结果集合进入Result Cache。
在第一句SQL中,我们希望筛选出owner='SCOTT'的结果集合,因为是第一次执行,所以有一定的逻辑读操作和递归SQL查询。但是,注意此时的执行计划和我们通常常见的执行计划有一定的差异。Oracle构造了一个名字为c0d139yk6xc6697m7n5kvta43b的结果集Cache,并且保存在其中。这个与平时见到的简单FTS之后就返回结果还是不一样的。此时通过v$result_cache_objects可以看到这个对象存在。
SQL> select id, cache_id, status, name from v$result_cache_objects;
![b6351ad2ccc72f44b18e14459386ffe3.png](https://i-blog.csdnimg.cn/blog_migrate/2adc855594164731dee6e3be4daa6060.jpeg)
v$result_cache_objects可以查看当前内存SGA中缓存的结果集合情况。
在第二个SQL语句中,我们没有使用hint,属于最直接的SQL语句。从执行计划和统计量的情况看,Oracle的确执行FTS扫描Buffer Cache中的逻辑读,执行时间大约为0.01s,比第一次执行的0.06s已经有了提升。
第二次无Hint执行,反映真实信息;
SQL> select * from t where owner='SCOTT';
![ea3397cd9e2930675843f382bccec11d.png](https://i-blog.csdnimg.cn/blog_migrate/df05e9f9089566d9e01f45af799eff59.jpeg)
第三个SQL语句中,再次使用了hint。从执行计划看,使用到了我们第一次生成的那个c0d139yk6xc6697m7n5kvta43b的Cache对象。实际执行时间下降到基本为0。
--第三次,纯result cache应用select /*+ result_cache */* from t where wner='SCOTT';
![cf4ca747284c14de651258a515598586.png](https://i-blog.csdnimg.cn/blog_migrate/eae3da9920885512d05d058b0342e14c.jpeg)
这里可以观察统计量消耗,彻底消灭了逻辑读。也就是说,在使用Result Cache的情况下,根本不会有逻辑读这样的检索操作,而是直接将结果返回回去。
3、同步问题
另一个担心问题就是同步,这里可能就朋友想直接将结果返回回去,那如果表做了更新后,会不会返回错误的数据。下面增加数据库表scott的记录数目,看看Result Cache能不能及时反馈。
--数据变化了insert into t select * from dba_objects where owner='SCOTT';commit;
![e1c58dc0cb5dcb2a3ef5fbe48af41c08.png](https://i-blog.csdnimg.cn/blog_migrate/3f0d6a1270c1692da627999b56d5dcdd.jpeg)
此时cache object立刻反映了这样的变化:缓存对象立刻从Published状态变化为Invalid状态,表示失效了
![ced7a1c568bbce2e09222195d04b13f2.png](https://i-blog.csdnimg.cn/blog_migrate/87f215855793472e3f94be07982d84c3.jpeg)
借助一个视图,我们可以“猜测”其中的奥妙。
SQL> select * from v$result_cache_dependency; RESULT_ID DEPEND_ID OBJECT_NO---------- ---------- ---------- 1 0 145510SQL> select object_name from user_objects where object_id=145510;OBJECT_NAME-------------------------------------------------------------------------T
注意这个名字为依赖关系的视图,他告诉我们:结果对象1,依赖对象0,这个对象的object_id=145510,而这个id号恰恰就是数据表T。
在另一个层面上,我们在v$result_cache_objects中也看到了ID 1和2,恰恰也就印证了这个。我们猜想过程是这样:在使用Result Cache过程中,Oracle维护了这个结果集合和基础表那些对象有关系的依赖关系对应。一旦发生了基础表变化,无论是从数据到内容,都会引发对Result Cache对象的失效过程。从而在下一次使用SQL的时候直接重新查结果。
下面测试一下
SQL> select /*+ result_cache */* from t where owner='SCOTT';--第一次执行,返回正确的结果集合,进行逻辑读。但是Result Cache ID号没有变化。查看统计信息。SQL> select id, cache_id, status, name from v$result_cache_objects;--一个新的Published对象被创建,id取值为6,但Cache ID值没有变化。Oracle又建立起一个新的维护依赖关系。SQL> select * from v$result_cache_dependency;
![093224651c7f3dc392063af6aac3f146.png](https://i-blog.csdnimg.cn/blog_migrate/b31550cf7f521f0ed1a0fbeae95e561e.jpeg)
![71fb3425703864747aca4593316eed32.png](https://i-blog.csdnimg.cn/blog_migrate/b6d2f94ff8c79c82a070e2898ebe52b1.jpeg)
这里假设如果我们变更的不是scott用户呢?会不会失效?
--无关SCOTT的数据插入 SQL> insert into t select * from dba_objects where owner='SYS';SQL> commit;SQL> select * from v$result_cache_dependency;SQL> select id, cache_id, status, name from v$result_cache_objects;
![006a2965c4112e92694d75cad0c8e1b8.png](https://i-blog.csdnimg.cn/blog_migrate/05a470823e02dda7ddd9c5677a4cfdf2.jpeg)
虽然我们插入的数据没有影响到结果集合,但是Cache依然还是失效了。看来这种关系还是很敏感的。也就说明了Result Cache使用的一个前提:目标数据表变化小。
篇幅有限,这里主要介绍result cache的相关实验,关于result cache的原理方面下篇再做介绍,感兴趣的朋友可以关注一下~
![0ca9768f39ab6b722293363bdfcc5b5f.gif](https://i-blog.csdnimg.cn/blog_migrate/5a6d479e3b82b2d4fc0ff52a37c39106.gif)