oracle 选反集合,聊聊Oracle 11g的Result Cache（一）

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

Oracle最常见的Cache就是SGA中的Buffer Cache和Shared Pool。两者一个是缓存数据块，另一个是缓存处理过的执行计划。一个是避免系统出现的频繁物理读过程，一个是避免系统出现的频繁硬解析过程。在Oracle 11g中，Oracle更近了一步，直接将结果集合缓存，推出了Result Cache特性。本篇就介绍一下这个特性。

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

SQL> show parameter result_cache

NAMETYPEVALUE

------------------------------------ ----------- ------------------------------

client_result_cache_lagbig integer 3000

client_result_cache_sizebig integer 0

result_cache_max_resultinteger5

result_cache_max_sizebig integer 2080K

result_cache_modestringMANUAL

result_cache_remote_expirationinteger0

2、一个简单的Result Cache示例

下面我们来看一个简单的Result Cache示例，有一个基本的认识。选择Oracle 11gR2来进行试验。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE11.2.0.1.0Production

创建实验数据表T，确定当前Result Cache功能开启。

SQL> create table t as select * from dba_objects;

Table created

SQL> select count(*) from t;

COUNT(*)

----------

72735

SQL> show parameter result_cache_max

NAMETYPEVALUE

------------------------------------ ----------- ------------------------------

result_cache_max_resultinteger5

result_cache_max_sizebig integer 2080K

result_cache_max_size是Result Cache功能开启的重要参数，只要设置为非零，我们就可以使用Result Cache功能。

--注意，是SCOTT用户，而非SYS用户；

SQL> show user

USER 为 "SCOTT"

--第一次执行语句

SQL> select /*+ result_cache */* from t where wner='SCOTT';

已选择18行。

已用时间:00: 00:00.15

执行计划

----------------------------------------------------------

Plan hash value: 1601196873

------------------------------------------------------------------------------

| Id| Operation| Name| Rows| Bytes | Cost(%CPU)| Time|

------------------------------------------------------------------------------------------------

|0 | SELECT STATEMENT||17 |3519 |273(1)| 00:00:04 |

|1 |RESULT CACHE| gsk6j3p8jdcqa788k6gyfj9tv1|||| |*2 |TABLE ACCESS FULL| T|17 |3519 |273(1)| 00:00:04 |

-----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("OWNER"='SCOTT')

Result Cache Information (identified by operation id):

------------------------------------------------------

1 - column-count=15; dependencies=(SCOTT.T); parameters=(nls); name="select /*+ result_cache */* from t where wner='SCOTT'"

统计信息

----------------------------------------------------------

308recursive calls

0db block gets

1149consistent gets

0physical reads

0redo size

2348bytes sent via SQL*Net to client

422bytes received via SQL*Net from client

3SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

18rows processed

上面三个语句明显展示了Result Cache功能特点。

默认情况下，Oracle Result Cache是不开启的。只有对使用了Result Cache Hint的情况下，才能让SQL语句的结果集合进入Result Cache。

在第一句SQL中，我们希望筛选出owner=’SCOTT’的结果集合，因为是第一次执行，所以有一定的逻辑读操作和递归SQL查询。但是，注意此时的执行计划和我们通常常见的执行计划有一定的差异。Oracle构造了一个名字为gsk6j3p8jdcqa788k6gyfj9tv1的结果集Cache，并且保存在其中。这个与我们日常见到的简单FTS之后就返回结果有些诧异。

此时，我们通过v$result_cache_objects可以看到这个对象存在。

SQL> select id, cache_id, status, name from v$result_cache_objects;

ID CACHE_IDSTATUSNAME

---------- ------------------------------ --------- --------------------------------------------------------------------------------

0 SCOTT.TPublished SCOTT.T

1 gsk6j3p8jdcqa788k6gyfj9tv1Published select /*+ result_cache */* from t where wner='SCOTT'

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

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

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

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

已选择18行。

已用时间:00: 00: 00.01

执行计划

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id| Operation| Name | Rows| Bytes | Cost (%CPU)| Time|

--------------------------------------------------------------------------

|0 | SELECT STATEMENT||17 |3519 |273(1)| 00:00:04 |

|*1 |TABLE ACCESS FULL| T|17 |3519 |273(1)| 00:00:04 |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("OWNER"='SCOTT')

统计信息

----------------------------------------------------------

4recursive calls

0db block gets

1119consistent gets

0physical reads

0redo size

2348bytes sent via SQL*Net to client

422bytes received via SQL*Net from client

3SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

18rows processed

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

--第三次，纯Result Cache应用

SQL> select /*+ result_cache */* from t where wner='SCOTT';

已选择18行。

已用时间:00: 00: 00.00 –成本几乎为零；

执行计划

----------------------------------------------------------

Plan hash value: 1601196873

------------------------------------------------------------------------------

| Id| Operation| Name| Rows| Bytes | Cost(%CPU)| Time|

--------------------------------------------------------------------------------------------

|0 | SELECT STATEMENT||17 |3519 |273

(1)| 00:00:04 |

|1 |RESULT CACHE| gsk6j3p8jdcqa788k6gyfj9tv1 |||

| |

|*2 |TABLE ACCESS FULL| T|17 |3519 |273

(1)| 00:00:04 |

-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("OWNER"='SCOTT')

Result Cache Information (identified by operation id):

------------------------------------------------------

1 - column-count=15; dependencies=(SCOTT.T); parameters=(nls); name="select /

*+ result_cache */* from t where wner='SCOTT'"

统计信息

----------------------------------------------------------

0recursive calls

0db block gets

0consistent gets

0physical reads

0redo size

2348bytes sent via SQL*Net to client

422bytes received via SQL*Net from client

3SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

18rows processed

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

3、同步问题

另一个担心问题就是同步，如果我们此时增加数据库表scott的记录数目，看看Result Cache能不能及时反馈。

--数据变化了

SQL> insert into t select * from dba_objects where wner='SCOTT';

18 rows inserted

SQL> commit;

Commit complete

注意，此时cache object立刻反映了这样的变化。

SQL> select id, cache_id, status, name from v$result_cache_objects;

ID CACHE_IDSTATUSNAME

---------- ------------------------------ --------- --------------------------------------------------------------------------------

0 SCOTT.TPublished SCOTT.T

1 gsk6j3p8jdcqa788k6gyfj9tv1Invalidselect /*+ result_cache */* from t where wner='SCOTT'

我们发现，缓存对象立刻从Published状态变化为Invalid状态，表示失效了。借助一个视图，我们可以“猜测”其中的奥妙。

SQL> select * from v$result_cache_dependency;

RESULT_IDDEPEND_IDOBJECT_NO

---------- ---------- ----------

1077312

SQL> select object_name from user_objects where object_id=77312;

OBJECT_NAME

-------------------------------------------------------------------------

T

注意这个名字为依赖关系的视图，他告诉我们：结果对象1，依赖对象0，这个对象的object_id=77312，而这个id号恰恰就是我们的数据表T。

在另一个层面上，我们在v$result_cache_objects中也看到了ID 1和2,恰恰也就印证了这个。我们猜想过程是这样：在使用Result Cache过程中，Oracle维护了这个结果集合和基础表那些对象有关系的依赖关系对应。一旦发生了基础表变化，无论是从数据到内容，都会引发对Result Cache对象的失效过程。从而在下一次使用SQL的时候直接重新查结果。

我们证明一下：

SQL> select /*+ result_cache */* from t where wner='SCOTT';

已选择36行。

已用时间:00: 00: 00.01

执行计划

----------------------------------------------------------

Plan hash value: 1601196873

---------------------------------------------------------------------------------------------

| Id| Operation| Name| Rows| Bytes | Cost(

%CPU)| Time|

--------------------------------------------------------------------------------

-----------------

|0 | SELECT STATEMENT||17 |3519 |279

(1)| 00:00:04 |

|1 |RESULT CACHE| gsk6j3p8jdcqa788k6gyfj9tv1|||

||

|*2 |TABLE ACCESS FULL| T|17 |3519 |279

(1)| 00:00:04 |

---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("OWNER"='SCOTT')

Result Cache Information (identified by operation id):

------------------------------------------------------

1 - column-count=15; dependencies=(SCOTT.T); parameters=(nls); name="select /

*+ result_cache */* from t where wner='SCOTT'"

统计信息

----------------------------------------------------------

1recursive calls

1db block gets

1057consistent gets

0physical reads

132redo size

3410bytes sent via SQL*Net to client

433bytes received via SQL*Net from client

4SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

36rows processed

第一次执行，返回正确的结果集合，进行逻辑读。但是Result Cache ID号没有变化。查看统计信息。

SQL> select id, cache_id, status, name from v$result_cache_objects;

ID CACHE_IDSTATUSNAME

---------- ------------------------------ --------- --------------------------------------------------------------------------------

0 SCOTT.TPublished SCOTT.T

3 gsk6j3p8jdcqa788k6gyfj9tv1Published select /*+ result_cache */* from t where wner='SCOTT'

1 gsk6j3p8jdcqa788k6gyfj9tv1Invalidselect /*+ result_cache */* from t where wner='SCOTT'

一个新的Published对象被创建，id取值为3，但Cache ID值没有变化。Oracle又建立起一个新的维护依赖关系。

SQL> select * from v$result_cache_dependency;

RESULT_IDDEPEND_IDOBJECT_NO

---------- ---------- ----------

3077312

进一步，如果我们变更的不是scott用户呢？会不会失效？

--无关SCOTT的数据插入

SQL> insert into t select * from dba_objects where wner='SYS';

30922 rows inserted

SQL> commit;

Commit complete

SQL> select * from v$result_cache_dependency;

RESULT_IDDEPEND_IDOBJECT_NO

---------- ---------- ----------

SQL> select id, cache_id, status, name from v$result_cache_objects;

ID CACHE_IDSTATUSNAME

---------- ------------------------------ --------- --------------------------------------------------------------------------------

0 SCOTT.TPublished SCOTT.T

1 gsk6j3p8jdcqa788k6gyfj9tv1Invalidselect /*+ result_cache */* from t where wner='SCOTT'

3 gsk6j3p8jdcqa788k6gyfj9tv1Invalidselect /*+ result_cache */* from t where wner='SCOTT'

虽然我们插入的数据没有影响到结果集合，但是Cache依然还是失效了。看来这种关系还是很敏感的。也就说明了Result Cache使用的一个前提：目标数据表变化小。

下面我们继续讨论Result Cache的一些特性和用途。