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