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
