Oracle RAC cache fusion原理测试

Oracle RAC cache fusion是RAC最核心的工作机制,他把所有实例的SGA虚拟成一个大的SGA区,每当不同的实例请求相同的数据块,这个数据块就需要在实例间进行传递。那到底什么时候传递呢?加上RAC有4个节点,其中的一个节点执行了一条SQL是全表扫描一张表,这个时候这个节点把这张表的数据加载到缓存;其他的节点如果需要相同的数据块会取第一个节点的数据,那是需要的时候去,还是第一个节点推送呢?

  实验设定:

1.清空4个节点的share pool和databuffer,其实当清除第一个节点的时候,其他的节点都已经清除了,从执行清除语句的时间就可以看出。清除后查下各节点data buffer中有没有缓存将要执行的SQL的表。

2.在第一个节点上执行一条SQL.,在其他的节点上看data buffer中是否缓存SQL的表,如果有,说明是数据块是主动推送的。

  实验结论:

数据块从第执行的节点推送到其他的节点上,RAC虽然使得使用的资源多了几倍,但由于cache fusion这个特性,上了RAC后的系统系统是否有提升还是未知之数。

---清理4个节点(54,55,56,57)shared_pool和buffer_cache

现在节点54上清理share pool和data buffer

SQL> alter system flush shared_pool;

系统已更改。

SQL> alter system flush buffer_cache;

系统已更改。

---在其他的节点55,56,57上同样执行

---在第54个节点测试语句

SQL> SELECT COUNT(1)

2  FROM MM_DISTRIBUTION W

3  WHERE    W.DATA_AREA LIKE ‘03‘

4    || ‘%‘

5  AND W.CREATE_DATE > TO_DATE(‘2013-01-01‘, ‘yyyy-mm-dd‘);

已用时间:  00: 00: 02.40

执行计划

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

Plan hash value: 3507380501

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

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

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

|   0 | SELECT STATEMENT    |                 |     1 |    13 |  5209   (2)| 00:01:03 |       |       |

|   1 |  SORT AGGREGATE     |                 |     1 |    13 |            |          |       |       |

|   2 |   PARTITION LIST ALL|                 | 43668 |   554K|  5209   (2)| 00:01:03 |     1 |     2 |

|*  3 |    TABLE ACCESS FULL| MM_DISTRIBUTION | 43668 |   554K|  5209   (2)| 00:01:03 |     1 |     2 |

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

Predicate Information (identified by operation id):

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

3 - filter("W"."CREATE_DATE">TO_DATE(‘2013-01-01 00:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘) AND

"W"."DATA_AREA" LIKE ‘03%‘)

统计信息

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

2997  recursive calls

0  db block gets

24196  consistent gets

23581  physical reads

0  redo size

334  bytes sent via SQL*Net to client

338  bytes received via SQL*Net from client

2  SQL*Net roundtrips to/from client

39  sorts (memory)

0  sorts (disk)

1  rows processed

SQL> /

已用时间:  00: 00: 00.28

执行计划

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

Plan hash value: 3507380501

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

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

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

|   0 | SELECT STATEMENT    |                 |     1 |    13 |  5209   (2)| 00:01:03 |       |       |

|   1 |  SORT AGGREGATE     |                 |     1 |    13 |            |          |       |       |

|   2 |   PARTITION LIST ALL|                 | 43668 |   554K|  5209   (2)| 00:01:03 |     1 |     2 |

|*  3 |    TABLE ACCESS FULL| MM_DISTRIBUTION | 43668 |   554K|  5209   (2)| 00:01:03 |     1 |     2 |

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

Predicate Information (identified by operation id):

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

3 - filter("W"."CREATE_DATE">TO_DATE(‘2013-01-01 00:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘) AND

"W"."DATA_AREA" LIKE ‘03%‘)

统计信息

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

0  recursive calls

0  db block gets

23554  consistent gets

0  physical reads

0  redo size

334  bytes sent via SQL*Net to client

338  bytes received via SQL*Net from client

2  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

1  rows processed

---在4个节点查看share_pool中的SQL是否同步

select sql_text from v$sql s where sql_text like ‘%MM_DISTRIBUTION%‘;

---在4个节点查看测试buffer_cache,可以看到其他的3个节点都已同步缓存数据

select count(b.object_name)

from sys.v_x$bh a, user_objects b

where a.OBJ = b.object_id

and b.object_name = ‘MM_DISTRIBUTION‘

and a.STATE <> 0;     ---state=0表示free,其他表示已占用

COUNT(B.OBJECT_NAME)

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

23543   

Oracle RAC cache fusion原理测试

时间: 2024-10-13 02:28:22

Oracle RAC cache fusion原理测试的相关文章

Oracle RAC cache fusion原理測试

Oracle RAC cache fusion是RAC最核心的工作机制.他把全部实例的SGA虚拟成一个大的SGA区,每当不同的实例请求同样的数据块,这个数据块就须要在实例间进行传递. 那究竟什么时候传递呢? 假设RAC有4个节点,当中的一个节点运行了一条SQL是全表扫描一张表,这个时候这个节点把这张表的数据载入到缓存:     方式1 :其它的节点假设须要同样的数据块会取第一个节点的数据,那是须要的时候取. 方式2 :还是第一个节点推送.   实验设定: 1.清空4个节点的share pool和

RAC Cache Fusion 原理理解

cache fusion  .   grd  .  drm   .   gcs  .   ges cache fusion 1.RAC是一个数据库执行在多个实例上.通过DLM(Distributed Lock Management):分布式锁管理器 来解决并发问题.RAC各个节点间的共享资源,为了保证每一个节点訪问数据的一致性.所以须要使用DLM来协调各个实例间的资源竞争訪问. 这个DLM在RAC中就叫Cache Fusion. 2.在cache Fusion 中,每一个数据块都被映射成Cach

Oracle Rac ——Cache Fusion

Cache Fusion (缓存融合) 实际意义上讲就是通过互连网络在集群各个节点内的SGA之间进行块传递,这样做的好处是避免多次将块写入磁盘,再重新读入到其他实例的缓存中.当一个块从磁盘读入RAC环境中的首个实例的sga中,该块会被赋予一个锁资源(区别于行级锁),以让其他实例知道该块正在被使用(或是读),当另一个实例请求该块的操作时,当前实例sga会传递一个块的副本给另一个实例(该块为最新,并未改变):如果内存中的块已经被改变,但改变尚未提交,会传递一个CR副本,并改变相应的锁资源的级别.从本

ORACLE RAC集群原理

ORACLE RAC原理:在一个应用环境当中,所有的服务器使用和管理同一个数据库,目的是为了分散每一台服务器的工作量,硬件上至少需要两台以上的服务器,而且还需 要一个共享存储设备.同时还需要两类软件,一个是集群软件,另外一个就是Oracle数据库中的RAC组件.同时所有服务器上的OS都应该是同一类OS, 根据负载均衡的配置策略,当一个客户端发送请求到某一台服务的listener后,这台服务器根据我们的负载均衡策略,会把请求发送给本机的RAC组件处 理也可能会发送给另外一台服务器的RAC组件处理,

Oracle RAC Study之--Cache Fusion

Oracle RAC Study之--Cache Fusion Concept of cache fusion Cache Fusion basically is about fusing the memory buffer cache of multiple instance into one single cache. For example if we have 3 instance in a RAC which is using the same datafiles and each i

Oracle RAC 负载均衡测试(结合服务器端与客户端)

Oracle RAC 负载均衡使得从客户端发起的连接能够有效地分配到监听器负载较小的实例上.有两种方式实现客户端负载均衡,一是通过配置客户端的load_balance,一是通过配置服务器端的remote_listener参数.两种方式各有优劣,而且两者并不相互排斥,因此可以结合两种方式来更加有效的实现负载均衡.本文将描述两者结合的使用情况(oralce 10g rac). 有关客户端与服务端负载均衡的单独测试请参考:              Oracle RAC 客户端连接负载均衡(Load

GitHub: Oracle RAC Database on Docker 未测试 改天试试

https://github.com/oracle/docker-images/blob/master/OracleDatabase/RAC/OracleRealApplicationClusters/README.md Oracle RAC Database on Docker Oracle Real Application Clusters (RAC) is an option to the award-winning Oracle Database Enterprise Edition.

深入理解Oracle RAC 12c

深入理解Oracle RAC 12c(顶尖专家权威指南唯一最新版数据库著作 Oracle第一社区技术大牛翻译 Amazon五星推荐) [美]Syed Jaffar Hussain(赛义德 贾法尔 侯赛因),Tariq Farooq(塔里克 法鲁克),Riyaj Shamsudeen(瑞亚吉沙姆斯丁),Kai Yu(于凯) 著   赵燚 梁涛 程飞 李真旭 译 ISBN 978-7-121-24066-9 2014年10月出版 定价:99.00元 488页 16开 编辑推荐 <深入理解 Oracl

Oracle RAC中的几个IP

oracle11g开始,设置了SCAN ip,除此之外还有public ip,virtual ip,private ip,容易让人犯晕. 下面逐一解释: public ip: 类似与单实例的oracle数据库ip,主要用于管理\访问. virtual ip(vip): oracle在rac架构中专用,这个vip用于实现故障转移,当一个节点发生故障时,其vip会"浮动"到另外一个正常的节点,也即该正常节点对应着两个vip了. SCAN: Single Client Access Name