ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 聊聊Oracle 11g的Result Cache(一)

聊聊Oracle 11g的Result Cache(一)

Linux操作系统 作者:startay 时间:2016-06-22 17:20:15 0 删除 编辑

 

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

 

 

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

 

NAME                                 TYPE        VALUE

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

client_result_cache_lag              big integer 3000

client_result_cache_size             big integer 0

result_cache_max_result              integer     5

result_cache_max_size                big integer 2080K

result_cache_mode                    string      MANUAL

result_cache_remote_expiration       integer     0

 

 

 

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

CORE    11.2.0.1.0  Production

 

 

创建实验数据表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

 

NAME                                 TYPE        VALUE

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

result_cache_max_result              integer     5

result_cache_max_size                big 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'"

 

统计信息

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

        308  recursive calls

          0  db block gets

       1149  consistent gets

          0  physical reads

          0  redo size

       2348  bytes sent via SQL*Net to client

        422  bytes received via SQL*Net from client

          3  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

         18  rows 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_ID                       STATUS    NAME

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

         0 SCOTT.T                        Published SCOTT.T

         1 gsk6j3p8jdcqa788k6gyfj9tv1     Published 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')

 

统计信息

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

          4  recursive calls

          0  db block gets

       1119  consistent gets

          0  physical reads

          0  redo size

       2348  bytes sent via SQL*Net to client

        422  bytes received via SQL*Net from client

          3  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

         18  rows 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'"

 

统计信息

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

          0  recursive calls

          0  db block gets

          0  consistent gets

          0  physical reads

          0  redo size

       2348  bytes sent via SQL*Net to client

        422  bytes received via SQL*Net from client

          3  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

         18  rows 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_ID                       STATUS    NAME

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

         0 SCOTT.T                        Published SCOTT.T

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

 

 

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

 

 

SQL> select * from v$result_cache_dependency;

 

 RESULT_ID  DEPEND_ID  OBJECT_NO

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

         1          0      77312

 

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'"

统计信息

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

          1  recursive calls

          1  db block gets

       1057  consistent gets

          0  physical reads

        132  redo size

       3410  bytes sent via SQL*Net to client

        433  bytes received via SQL*Net from client

          4  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

         36  rows processed

 

 

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

 

 

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

 

        ID CACHE_ID                       STATUS    NAME

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

         0 SCOTT.T                        Published SCOTT.T

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

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

 

 

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

 

 

SQL> select * from v$result_cache_dependency;

 

 RESULT_ID  DEPEND_ID  OBJECT_NO

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

         3          0      77312

 

 

进一步,如果我们变更的不是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_ID  DEPEND_ID  OBJECT_NO

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

 

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

 

        ID CACHE_ID                       STATUS    NAME

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

         0 SCOTT.T                        Published SCOTT.T

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

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

 

 

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

 

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

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17086096/viewspace-2120729/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-07-29

  • 博文量
    45
  • 访问量
    87439