Oracle RAC cache fusion原理测试

Oracle RAC cache fusion是RAC最核心的工作机制，他把所有实例的SGA虚拟成一个大的SGA区,每当不同的实例请求相同的数据块，这个数

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教程：实例故障恢复

Linux-6-64下安装Oracle 12C笔记

在CentOS 6.4下安装Oracle 11gR2(x64)

Oracle 11gR2 在VMWare虚拟机中安装步骤

Debian 下 安装 Oracle 11g XE R2

本文永久更新链接地址：

喜欢 (0)赏

[搞代码]

分享 (0)