探讨Oracle 11g的Result Cache深层原理

概述

前面已经用实验给大家介绍了Result Cache相关内容,今天主要讨论一下Oracle 11g Result Cache的深层原理。

从参数看,Oracle提供了Client Result Cache和Server Result Cache两种机制。

探讨Oracle 11g的Result Cache深层原理


Client Result Cache和Server Result Cache

Oracle的Result Cache参数就是表示Server端的Cache功能。Server Result Cache是在Oracle SGA中的Shared Pool里面一块内存池。这个Memory Pool包括两个组成部分,或者说包括两种缓存内容,就是SQL语句的查询结果和PL/SQL函数的返回值结果。Server Result Cache功能的初衷,就是为了缓解一些系统长期高频度的访问某些“稳定性好”的数据。

当启用Result Cache的时候,Oracle的工作流程是这样的。首先,如果result_cache_mode参数是MANUAL,表示只有在使用result_cache和no_result_cache参数的时候,才能启用Result Cache功能。

Oracle解析到SQL语句使用了hint后,就回到缓存中查找相应的记录。如果不存在对应的结果集信息,Oracle就会真正执行这个SQL语句,附带将结果以一个ID保存在shared pool的cache pool中。第二次相同SQL到来之后,就会发现与现有ID的一致性,将结果直接返回。

应该说,Oracle的Result Cache是消除逻辑读,更进一步的缓存策略。但是,所有的缓存都存在一个相同的问题,就是冗余数据(Cache)的一致性。

从目前分析看,Oracle是借助对象之间的“依赖”关系来做到数据同步。首先,我们看一个系列例子:

SQL> conn scott/tiger;
SQL> create table t_tab as select * from dba_tables;
SQL> select /*+result_cache*/count(*) from t_tab, t where t.owner=t_tab.owner and t.object_name=t_tab.table_name;
SQL> col name for a30;
SQL> select id, type, status, name, row_count from v$result_cache_objects;

探讨Oracle 11g的Result Cache深层原理

上面操作涉及到两个对象t和t_tab。我们从v$result_cache_objects视图中,可以看到,Oracle不仅仅将那个结果集合(TYPE=RESULT)保存下来,而且将两个数据表的信息保存下来,作为“Dependency”关系。

从前面的实验,我们可以知道,一旦发生数据表t和t_tab的任何变化,包括数据DML变化操作,两个缓存的依赖对象就会失效,从而引发Result Cache结果集合的失效。注意:这个依赖是非常敏感的,即使是权限变化这样的小事,都会引起Cache的失效。

SQL> grant select on t to hr;
SQL> select id, type, status, name, row_count from v$result_cache_objects;

探讨Oracle 11g的Result Cache深层原理

那么,字面值(SQL语句结构)对缓存有影响吗?

SQL> select /*+result_cache*/count(*) from t_tab, t where t.owner=t_tab.owner and t.object_name=t_tab.table_name;
--新成立一个result cache
SQL> select id, type, status, name, row_count from v$result_cache_objects;
--交换位置
SQL> select /*+result_cache*/count(*) from t, t_tab where t.owner=t_tab.owner and t.object_name=t_tab.table_name;
SQL> select id, type, status, name, row_count from v$result_cache_objects;

探讨Oracle 11g的Result Cache深层原理

探讨Oracle 11g的Result Cache深层原理

当SQL语句结构变化比较大的时候,Result Cache是不会共用的。

下面聊聊Client Result Cache。Client Result Cache全名为Oracle Call Interface(OCI)Client Result Cache。Client Result Cache主要是为了基于OCI的应用程序,每一个Client Result Cache是在一个应用程序中的,所有这个Process的会话,都会共享这个Result Cache。

注意:Client Result Cache和Server Result Cache是完全不同的两个特点。相互之间没有关系。

OCI Client Result Cache是直接在客户端建立缓存,适用于OCCI,JDBC OCI和ODP.NET应用程序。OCI Client Result Cache最直接的好处就是减少数据库相应和资源消耗,提高整体应用体验。

对数据失效的问题,Oracle一旦发现依赖对象的失效,就会反向向客户端发送信息,引起Client Cache的失效。


Result Cache的相关参数解析

Result Cache的功能是通过Oracle一系列加入的参数来进行控制的。本部分介绍一下Oracle Result Cache所使用的参数信息。

Server Result Cache是主体,默认Result Cache在SGA中是有一块区域pool的,通过hint Result_cache和no_result_cache来控制。从shared_pool中,我们可以看到当前result cache的信息。

SQL> select * from v$sgastat where lower(name) like '%result_cache%';
SQL> show parameter result_cache

探讨Oracle 11g的Result Cache深层原理

参数说明:

探讨Oracle 11g的Result Cache深层原理

相对于传统的Oracle内存池,在自动调整时代,Oracle是怎么管理Result Cache大小呢?在启动的时候,根据不同的情况设置,Oracle会选择出Cache Pool的大小。

当设置MEMORY_TARGET的时候,Oracle会将Result Cache的大小设置为Target值的0.25%。如果没有设置MEMORY_TARGET参数,只设置了SGA_TARGET,这个大小为0.5%。如果设置了SHARD_POOL_SIZE参数,这个算法的参数值为1%。

从参数上看,我们可以看到,对于每个Result Cache记录,Oracle都是有保留的。并不是所有结果集合都会被记录。当Result Cache Pool达到设置了本身的限制之后,比可用空间大的结果集合,都不会被缓存。

Result Cache Pool自身使用的是LRU算法,将结果Age Out出去。在RAC环境下,每个实例Instance都可以设置自己的Result Cache大小。


Result Cache模式

在诸多的Result Cache相关参数中,Result Cache Mode是一个重要的开关参数。这个参数控制着当前Oracle是否使用客户端和服务器端Result Cache功能。

在之前的文章中,我们讨论了Result Cache的特性。其中最大引起我们关注的就是Cache对象失效机制,只要查询“依赖”的基础数据表发生了变化,包括表结构、数据和授权关系,Cache缓存对象就会失效。频繁的Cache构建和失效、再次构建失效,要消耗很多CPU和内存空间。所以,从Oracle的角度看:应用程序SQL查询主要对于只读(Read-Only)对象或者变化较小(Read-Mostly)的数据库对象。

初始化参数RESULT_CACHE_MODE用来控制Result Cache功能的开启工作模式,默认是MANUAL。

探讨Oracle 11g的Result Cache深层原理

MANUAL表示SQL语句只有在显示的使用hint RESULT_CACHE的情况下,才会启用Cache功能。与MANUAL对应的取值是FORCE,FORCE的含义是说,无论何时,都会对所有SQL启用Result Cache功能,除非SQL中显示出现了NO_RESULT_CACHE的hint标记。

明显的,result_cache对所有SQL开启是一个不合理的设计。所以,我们通常只要开启默认值MANUAL就好了。


后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注一下~

探讨Oracle 11g的Result Cache深层原理

相关推荐