oracle11g操作频繁引起表空间爆炸_超详细的Oracle 11g的Result Cache原理介绍，附实验说明...-CSDN博客

本文链接：https://blog.csdn.net/weixin_39902870/article/details/113309844

概述

缓存一直是解决信息、数据访问效率的一个重要方法。常见的缓存包括内存、前端特殊数据结构等。从宏观角度看，缓存的本质是利用空间来换取时间的手段。数据信息虽然都是保存在系统后端的数据库或者文件系统中，但是为了性能常常会将其以一定形式组织到前端，减少访问过程中的传递链过程。

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的功能。

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功能。

第一次执行语句

set timing on;set autotrace traceonly;select /*+ result_cache */* from t where owner='SCOTT';

上面三个红色标记的明显展示了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;

v$result_cache_objects可以查看当前内存SGA中缓存的结果集合情况。

在第二个SQL语句中，我们没有使用hint，属于最直接的SQL语句。从执行计划和统计量的情况看，Oracle的确执行FTS扫描Buffer Cache中的逻辑读，执行时间大约为0.01s，比第一次执行的0.06s已经有了提升。

第二次无Hint执行，反映真实信息；

SQL> select * from t where owner='SCOTT';

第三个SQL语句中，再次使用了hint。从执行计划看，使用到了我们第一次生成的那个c0d139yk6xc6697m7n5kvta43b的Cache对象。实际执行时间下降到基本为0。

--第三次，纯result cache应用select /*+ result_cache */* from t where wner='SCOTT';

这里可以观察统计量消耗，彻底消灭了逻辑读。也就是说，在使用Result Cache的情况下，根本不会有逻辑读这样的检索操作，而是直接将结果返回回去。

3、同步问题

另一个担心问题就是同步，这里可能就朋友想直接将结果返回回去，那如果表做了更新后，会不会返回错误的数据。下面增加数据库表scott的记录数目，看看Result Cache能不能及时反馈。

--数据变化了insert into t select * from dba_objects where owner='SCOTT';commit;

此时cache object立刻反映了这样的变化:缓存对象立刻从Published状态变化为Invalid状态，表示失效了

借助一个视图，我们可以“猜测”其中的奥妙。

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;

这里假设如果我们变更的不是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;