《Oracle RAC性能优化》

一 RAC环境

RAC架构，2节点信息

节点1

SQL> show parameter instance

NAME TYPE VALUE

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

active_instance_count integer

cluster_database_instances integer 2

instance_groups string

instance_name string RACDB1

instance_number Integer 1

instance_type string RDBMS

open_links_per_instance integer 4

parallel_instance_group string

parallel_server_instances integer 2

节点2

SQL> show parameter instance

NAME TYPE VALUE

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

active_instance_count integer

cluster_database_instances integer 2

instance_groups string

instance_name string RACDB2

instance_number integer 2

instance_type string RDBMS

open_links_per_instance integer 4

parallel_instance_group string

parallel_server_instances integer 2

数据库版本

SQL> select * from v$version;

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE 10.2.0.1.0 Production

TNS for Linux: Version 10.2.0.1.0 - Production

NLSRTL Version 10.2.0.1.0 - Production

操作系统信息

节点1

[oracle@rac1 ~]$ uname -a

Linux rac1 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux

节点2

[oracle@rac2 ~]$ uname -a

Linux rac2 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux

[oracle@leonarding1 admin]$ uname -a

Linux leonarding1.oracle.com 2.6.32-200.13.1.el5uek #1 SMP Wed Jul 27 21:02:33 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

RAC所有资源信息

[oracle@rac2 ~]$ crs_stat -t

Name Type Target State Host

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

ora....B1.inst application ONLINE ONLINE rac1

ora....B2.inst application ONLINE ONLINE rac2

ora....DB1.srv application ONLINE ONLINE rac2

ora.....TAF.cs application ONLINE ONLINE rac2

ora.RACDB.db application ONLINE ONLINE rac2

ora....SM1.asm application ONLINE ONLINE rac1

ora....C1.lsnr application ONLINE ONLINE rac1

ora.rac1.gsd application ONLINE ONLINE rac1

ora.rac1.ons application ONLINE ONLINE rac1

ora.rac1.vip application ONLINE ONLINE rac1

ora....SM2.asm application ONLINE ONLINE rac2

ora....C2.lsnr application ONLINE ONLINE rac2

ora.rac2.gsd application ONLINE ONLINE rac2

ora.rac2.ons application ONLINE ONLINE rac2

ora.rac2.vip application ONLINE ONLINE rac2

二 聊一聊RAC性能的几点看法

引言：在好的技术也是为应用服务的，对我们技术人员来讲，学习技术应该有一套好的方法和思路，你先要知道为什么要学习这种技术，这种技术用在什么地方，可以解决什么问题。然后才是学习，最后测试验证，在职场中我们不能在用以前在学校中学习的方式来充电和进修啦，在学校是先学然后才明白为什么学，还有甚者学习就是为了考试并且很多东西在工作中都用不上，而作为职场人生，我们要快速转变身份，做一名应用型人才，以应用为导向，先了解我们需要什么，能够解决什么问题，可不可以在短时间内学会，然后去思考技术方案。上来说了点题外话，下面我们来说一说Oracle RAC架构的优化思路

一系统网络层面的思考

你的系统是应用在互联网上，还是局域网环境，如果是互联网级的应用，当用户感觉系统慢了的时候，首先检查是不是client访问server之间的网络环境不佳造成的，例如有没有使用VPN，有没有网络流量限制，是否存在网络延迟。其次在看request接入系统之后的检查分析。

如果是局域网级的应用，绝大多数是系统体系之后的问题了。

二系统体系之内的思考

一整套系统是由，前台、后台、网络、操作系统、应用、存储等元素构成的，那么造成系统性能低下的原因也都可能出现在上述其中之一。在面对这么多可能因素的时候我们从哪些地方先期入手呢，来看看在进行RAC优化之前，你应该了解什么？

1.应用层面：从应用程序的角度探索，例如数据缓存量大小，应用支持的并发数，SQL语句执行效率，大家不要小看一条小小的SQL语句，往往大问题都是由小地方导致的，而且根据经验90%问题都是由于SQL语句迟缓造成的。

2.单实例层面：大家知道一个RAC都是由多个实例组成的，每个实例的性能优略直接会影响整体性能。可以检查实例的参数配置是否合理，每个实例的执行效率是否高效，优化每个实例的资源使用。

3.操作系统层面：这里主要关注的是操作系统的内核参数配置，有的参数会直接影响数据库的参数有效性，且大部分是内存级参数，例如内存分配参数，内存页面参数，虚拟内存参数等。从整体上看操作系统层面是影响RAC性能最小的一个方面。

重点是思路，从什么地方开始考虑，一层一层的查询排除。

4.RAC机制层面：主要有两方面内容，第一 cache fusion，我们都知道Oracle RAC为保证数据的一致性，会在实例与实例之间大量进行数据块复制、交叉、迁移，这些动作都会产生锁定，维护这些锁资源就会导致全局性等待事件，等待越长性能越差，是性能下降的原因之一。第二内联网interconnection效率问题，当出现网络阻塞、网络延迟、网络丢包、网络带宽不足，不足以支持大量数据传输，也会导致RAC的性能下降。我们提倡使用快速的网络传输通道，减少数据在内存间的传输时间。

5.RAC能否提高性能

这是大多数刚刚使用RAC的朋友经常会问到的，这里需要重申一下，RAC的提出是为了解决实例级别HA高可用的，并不是为了提高单实例数据库效率的。但有可能使用RAC后系统性能会变好，这是因为同样的工作使用到了更多的节点资源，例如 CPU 内存存储等，这里请记住只是有可能，但不绝对。

注：看你怎么使用它！

6.RAC节点数和性能是什么关系

这个问题也是很多朋友喜欢追问的，RAC节点数越多性能越好嘛？非也非也，我们不能认为6个节点的RAC就比4个节点的RAC好，也不能认为节点数与性能是一种线性关系，不同的业务反应出来的性能特点是不同的，例如内存共享资源锁定数据传输内联网效率都是RAC的性能参考因素，具体看你怎么使用它。

总结：RAC不一定能够提高性能，应用系统千差万别，不同业务有不同特点，重点要看RAC应用在什么业务系统上，我们可以采用业务分割减少数据在实例内存间的传递

我们还可以将任务充分分配到所有节点上进行并行处理，充分利用所有RAC节点的资源。

这里没有放之四海而皆准的原则，必须经过实际测试，这就叫“RAC的知行合一”方法论！

三 比较单实例（让RAC只open一个实例）和多实例下，RAC对大表（不要创建索引）查询的效率（可以先将cache buffer清空）

目的：真实测试RAC究竟能否提高性能？RAC架构机制对性能有何影响？

1.启动2个节点查看状态

[oracle@rac1 ~]$ crs_stat -t

Name Type Target State Host

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

ora....B1.inst application ONLINE ONLINE rac1

ora....B2.inst application ONLINE ONLINE rac2

ora....DB1.srv application ONLINE ONLINE rac2

ora.....TAF.cs application ONLINE ONLINE rac2

ora.RACDB.db application ONLINE ONLINE rac1

ora....SM1.asm application ONLINE ONLINE rac1

ora....C1.lsnr application ONLINE ONLINE rac1

ora.rac1.gsd application ONLINE ONLINE rac1

ora.rac1.ons application ONLINE ONLINE rac1

ora.rac1.vip application ONLINE ONLINE rac1

ora....SM2.asm application ONLINE ONLINE rac2

ora....C2.lsnr application ONLINE ONLINE rac2

ora.rac2.gsd application ONLINE ONLINE rac2

ora.rac2.ons application ONLINE ONLINE rac2

ora.rac2.vip application ONLINE ONLINE rac2

两个节点所有进程都已经启动

2.创建一张大表

SQL> create table leo1 as select * from dba_objects; 创建leo1表循环加载记录到160万，表上没有索引

Table created.

SQL> insert into leo1 select * from leo1;

50351 rows created.

SQL> commit;

Commit complete.

SQL> insert into leo1 select * from leo1;

100702 rows created.

SQL> commit;

Commit complete.

SQL> insert into leo1 select * from leo1;

201404 rows created.

SQL> commit;

Commit complete.

SQL> insert into leo1 select * from leo1;

402808 rows created.

SQL> commit;

Commit complete.

SQL> insert into leo1 select * from leo1;

805616 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from leo1;

COUNT(*)

----------

1611232

3.只open一个实例，查询大表

现在两个实例都在open状态

SQL> select instance_name,host_name,status from gv$instance order by 1;

INSTANCE_NAME HOST_NAME STATUS

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

RACDB1 rac1 OPEN

RACDB2 rac2 OPEN

我们停掉一个racdb2实例，只保留racdb1实例启动

[oracle@rac2 ~]$ srvctl stop instance -d racdb -i racdb2 -o immediate

SQL> select instance_name,host_name,status from gv$instance order by 1;

INSTANCE_NAME HOST_NAME STATUS

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

RACDB1 rac1 OPEN

在racdb1实例上清空data_buffer缓冲区

SQL> alter system flush buffer_cache;

System altered.

SQL> set autotrace traceonly;

SQL> select * from leo1 where object_type ='TABLE';

51776 rows selected.

执行计划

Execution Plan

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

Plan hash value: 2716644435

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

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

| 0 | SELECT STATEMENT | | 38799 | 6706K| 4899 (2) | 00:00:59 |

|* 1 | TABLE ACCESS FULL| LEO1 | 38799 | 6706K| 4899 (2)| 00:00:59 |

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

Predicate Information (identified by operation id):

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

1 - filter("OBJECT_TYPE"='TABLE')

Note

-----

- dynamic sampling used for this statement

统计信息

Statistics

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

128 recursive calls

0 db block gets

25524 consistent gets

22025 physical reads

0 redo size

2498843 bytes sent via SQL*Net to client

38342 bytes received via SQL*Net from client

3453 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

51776 rows processed

4.启动2个实例，查询大表

[oracle@rac2 ~]$ srvctl stop instance -d racdb -i racdb2 -o open

SQL> set autotrace off

SQL> select instance_name,host_name,status from gv$instance order by 1; 现在2个实例已经都启动了

INSTANCE_NAME HOST_NAME STATUS

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

RACDB1 rac1 OPEN

RACDB2 rac2 OPEN

节点1 清空data_buffer缓冲区

SQL> alter system flush buffer_cache;

System altered.

节点2 清空data_buffer缓冲区

SQL> alter system flush buffer_cache;

System altered.

在节点1上再次查询leo1大表，比较2次查询的性能

SQL> set autotrace traceonly;

SQL> select * from leo1 where object_type ='TABLE';

51776 rows selected.

执行计划

Execution Plan

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

Plan hash value: 2716644435

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

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

| 0 | SELECT STATEMENT | | 38799 | 6706K| 4899 (2) | 00:00:59 |

|* 1 | TABLE ACCESS FULL| LEO1 | 38799 | 6706K| 4899 (2)| 00:00:59 |

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

Predicate Information (identified by operation id):

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

1 - filter("OBJECT_TYPE"='TABLE')

Note

-----

- dynamic sampling used for this statement

统计信息

Statistics

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

86 recursive calls

0 db block gets

25519 consistent gets

22024 physical reads

0 redo size

2498843 bytes sent via SQL*Net to client

38342 bytes received via SQL*Net from client

3453 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

51776 rows processed

比较2次查询的性能

单实例 RAC模式

Cost (%CPU)=4899 Cost (%CPU)=4899

consistent gets=25524 consistent gets=25519

physical reads=22025 physical reads=22024

小结：Cost (%CPU)执行计划的代价是一样的，RAC模式下的一致性读和物理读性能稍微好一点，这是我用vm虚拟机测试出来的结果，如果放在真实物理机环境下效果应该更加明显。

四 比较一下你机器上RAC两个实例的性能效率指标

RAC模式下一般都是基于cache fusion的性能指标，我们也称之为“GCS【global cache services】等待事件”，这种等待事件产生的原因就是“大量数据块在内存中传递并且严重影响业务的性能”，我们可以通过“业务分割”来适当减少数据的传输，负面影响就是不能充分利用所有RAC节点资源。

我们本次重点讨论cache fusion内部发生的等待事件

1.检查Oracle GCS相关的等待事件

如下都是实例内存间全局性的cache等待事件

SQL> select name from gv$sysstat where name like '%gc%' group by name;

NAME

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

gc claim blocks lost

gc cr blocks received

gc cr block receive time

gc current blocks received

gc blocks lost

gcs messages sent

gc current block receive time

gc CPU used by this session

java call heap gc count

gc cr block build time

cleanout - number of ktugct calls

gc cr blocks served

gc current blocks served

gc current block flush time

gc blocks corrupt

gc cr block flush time

gc current block pin time

gc current block send time

java session heap gc count

calls to kcmgcs

gc cr block send time

21 rows selected.

2.一个数据块在“一致性读模式”下从一个实例读到另一个实例需要花费的时间，可以衡量RAC的一致性读性能

SQL> SELECT a.inst_id "Instance",

(a.value+b.value+c.value+d.value)/decode(e.value,0,1, d.value) "BSP Service Time"

FROM gv$sysstat A,

gv$sysstat B,

gv$sysstat C,

gv$sysstat D,

gv$sysstat E

WHERE A.name = 'gc cr block build time'

AND B.name = 'gc cr block send time'

AND C.name = 'gc cr block flush time'

AND D.name = 'gc cr block receive time'

AND E.name = 'gc cr blocks served'

AND B.inst_id = A.inst_id

AND C.inst_id = A.inst_id

AND D.inst_id = A.inst_id

AND E.inst_id = A.inst_id

ORDER

BY a.inst_id; 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Instance BSP Service Time

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

1 3.5 实例2 拷到实例1所花的时间

2 1 实例1 拷到实例2 所花的时间

小结：由此看来实例1比实例2节点处理效率高一点。

进一步查询，可以看到更详细的信息

每个数据块在每个环节所花费的时间

SQL> SELECT A.inst_id "Instance", (A.value/D.value) "Consistent Read Build",

(B.value/D.value) "Log Flush Wait",(C.value/D.value) "Send Time"

FROM GV$SYSSTAT A, GV$SYSSTAT B,

GV$SYSSTAT C, GV$SYSSTAT D

WHERE A.name = 'gc cr block build time'

AND B.name = 'gc cr block flush time'

AND C.name = 'gc cr block send time'

AND D.name = 'gc cr blocks served'

AND B.inst_id=a.inst_id

AND C.inst_id=a.inst_id

AND D.inst_id=a.inst_id

ORDER

BY A.inst_id; 2 3 4 5 6 7 8 9 10 11 12 13

Instance Consistent Read Build Log Flush Wait Send Time

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

1 .081300813 .073170732 .016260163

2 0 .041420118 .017751479

Consistent Read Build：一致性读数据块构造所花时间

Log Flush Wait：刷redo环节所花时间

Send Time：发送数据块环节所花时间

3.检查global cache blocks lost和global cache blocks corrupt 这两个指标用来衡量网络情况，如果网络不好就会产生丢块和坏块。

SQL> SELECT A.VALUE "GC BLOCKS LOST 1",

B.VALUE "GC BLOCKS CORRUPT 1",

C.VALUE "GC BLOCKS LOST 2",

D.VALUE "GC BLOCKS CORRUPT 2"

FROM GV$SYSSTAT A, GV$SYSSTAT B, GV$SYSSTAT C, GV$SYSSTAT D

WHERE A.INST_ID=1 AND A.NAME='gc blocks lost'

AND B.INST_ID=1 AND B.NAME='gc blocks corrupt'

AND C.INST_ID=2 AND C.NAME='gc blocks lost'

AND D.INST_ID=2 AND D.NAME='gc blocks corrupt'; 2 3 4 5 6 7 8 9

GC BLOCKS LOST 1 GC BLOCKS CORRUPT 1 GC BLOCKS LOST 2 GC BLOCKS CORRUPT 2

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

0 0 0 0

实例1和实例2都没有丢块和坏块的现象，原因是实验环境没有业务操作

4.一个数据块在“当前读模式”下从一个实例读到另一个实例需要花费的时间，可以衡量RAC的当前读性能

SQL> SELECT a.inst_id "Instance",

(a.value+b.value+c.value+d.value)/decode(e.value,0,1, d.value) "Current Blk Service Time"

FROM gv$sysstat A,

gv$sysstat B,

gv$sysstat C,

gv$sysstat D,

gv$sysstat E

WHERE A.name = 'gc current block pin time'

AND B.name = 'gc current block send time'

AND C.name = 'gc current block flush time'

AND D.name = 'gc current block receive time'

AND E.name = 'gc current blocks served'

AND B.inst_id = A.inst_id

AND C.inst_id = A.inst_id

AND D.inst_id = A.inst_id

AND E.inst_id = A.inst_id

ORDER

BY a.inst_id; 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Instance Current Blk Service Time

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

1 1.04130435 实例2 拷到实例1所花的时间

2 1.27906977 实例1 拷到实例2所花的时间

小结：由此看来实例2比实例1节点处理效率高一点。

进一步查询，可以看到更详细的信息

每个数据块在每个环节所花费的时间

SQL> SELECT A.inst_id "Instance",

(A.value/D.value) "Current Block Pin",

(B.value/D.value) "Log Flush Wait",

(C.value/D.value) "Send Time"

FROM GV$SYSSTAT A,

GV$SYSSTAT B,

GV$SYSSTAT C,

GV$SYSSTAT D

WHERE A.name = 'gc current block pin time'

AND B.name = 'gc current block flush time'

AND C.name = 'gc current block send time'

AND D.name = 'gc current blocks served'

AND B.inst_id=A.inst_id

AND C.inst_id=A.inst_id

AND D.inst_id=A.inst_id

ORDER BY A.inst_id; 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Instance Current Block Pin Log Flush Wait Send Time

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

1 .003921569 0 .018487395

2 .000798563 0 .013575564

Current Block Pin：获取权限所花时间

Log Flush Wait：刷redo环节所花时间

Send Time：发送数据块到请求的实例环节所花时间

小结：综合对比实例1和实例2的指标参数，在“当前读模式下”实例2的表现要好一些。

5.一个实例获取另一个实例上的数据块的转换指标

SQL> SELECT A.inst_id "Instance", A.value/B.value "Avg Cache Conv. Time",C.value/D.value "Avg Cache Get Time",E.value "GC Convert Timeouts"

FROM GV$SYSSTAT A, GV$SYSSTAT B,GV$SYSSTAT C, GV$SYSSTAT D,GV$SYSSTAT E

WHERE A.name = 'global cache convert time'

AND B.name = 'global cache converts'

AND c.name = 'global cache get time'

AND D.name = 'global cache gets'

AND E.name = 'global cache convert timeouts'

AND B.inst_id = A.inst_id

AND C.inst_id = A.inst_id

AND D.inst_id = A.inst_id

AND E.inst_id = A.inst_id

ORDER BY A.inst_id; 2 3 4 5 6 7 8 9 10 11 12

no rows selected

由于实验环境没有太多业务操作因此占没有结果

6.可以通过一个比例，来评价某个实例的GCS的请求情况

SQL> SELECT a.inst_id "Instance",

(A.VALUE+B.VALUE+C.VALUE+D.VALUE)/(E.VALUE+F.VALUE) "GLOBAL CACHE HIT

RATIO"

FROM GV$SYSSTAT A, GV$SYSSTAT B,

GV$SYSSTAT C, GV$SYSSTAT D,

GV$SYSSTAT E, GV$SYSSTAT F

WHERE A.NAME='global cache gets'

AND B.NAME='global cache converts'

AND C.NAME='global cache cr blocks received'

AND D.NAME='global cache current blocks received'

AND E.NAME='consistent gets'

AND F.NAME='db block gets'

AND B.INST_ID=A.INST_ID AND C.INST_ID=A.INST_ID

AND D.INST_ID=A.INST_ID AND E.INST_ID=A.INST_ID

AND F.INST_ID=A.INST_ID; 2 3 4 5 6 7 8 9 10 11 12 13 14 15

no rows selected

小结：值越小越好，说明来自远程的数据块越少，如果没有 -> 实例之间数据传输为0

五 比较在单实例上的并行执行和多实例上并行执行的效率

首先我们要理解一些什么是单实例的并行和多实例的并行

（1）单实例并行

单个节点服务器，配置有4个CPU，Oracle可以把任务分配到4个CPU资源上同时并行执行，最后进行结果拼接返回给用户。

（2）多实例并行

双节点服务器，每个节点配置有4个CPU，Oracle可以充分利用所有节点上的CPU资源同时并行执行，最后把结果串行化汇总到某一个节点上返回给用户。

注：如果Interconnect导致严重的性能下降，可以考虑把并行限制在某一个实例上，下面我们就来看一下如何限制并行在一个实例上。

Oracle中并行限制的方法

parallel_instance_group：说明把并行进程限制在哪个实例组上

instance_group：当前有哪个实例组

这两个参数一起设置来把并行进程限制在某一个实例上。

实验

节点1

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string

parallel_instance_group string

创建实例组racdb1 racdb2

SQL> alter system set instance_groups='racdb1','racdb2' scope=spfile;

System altered.

静态参数需要重启数据库生效

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string

parallel_instance_group string

SQL> startup force 重启数据库

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 96471284 bytes

Database Buffers 67108864 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

参数生效

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string racdb1, racdb2

parallel_instance_group string

节点2

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string

parallel_instance_group string

创建实例组racdb1 racdb2

SQL> alter system set instance_groups='racdb1','racdb2' scope=spfile;

System altered.

静态参数需要重启数据库生效

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string

parallel_instance_group string

SQL> startup force 重启数据库

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 96471284 bytes

Database Buffers 67108864 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

参数生效

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string racdb1, racdb2

parallel_instance_group string

我们看一下当前会话

SQL> select distinct sid from v$mystat;

SID

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

152

SQL> select name,value,isdefault from v$ses_optimizer_env where sid=152 order by 3,1;

NAME VALUE ISD

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

active_instance_count 2 YES

parallel_execution_enabled true YES

当前活动实例有2个，并行执行已启动

把并行进程限制在racdb1实例上

SQL> alter session set parallel_instance_group='racdb1';

Session altered.

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string racdb1, racdb2

parallel_instance_group string racdb1 并行进程限制在racdb1实例上

我们对leo1表进行并行测试

SQL> select count(*) from leo1;

COUNT(*)

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

1611232

SQL> set autotrace traceonly

SQL> set linesize 400

SQL> alter system flush buffer_cache;

System altered.

SQL> alter table leo1 parallel;

Table altered.

启动2个并行度

SQL> select /*+ parallel(2) */ count(*) from leo1;

Execution Plan

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

Plan hash value: 452265093

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

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

| 0 | SELECT STATEMENT | | 1 | 1348 (1)| 00:00:17 | | | |

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

| 2 | PX COORDINATOR | | | | | | | |

| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | Q1,00 | P->S | QC (RAND) |

| 4 | SORT AGGREGATE | | 1 | | | Q1,00 | PCWP | |

| 5 | PX BLOCK ITERATOR | | 1616K| 1348 (1)| 00:00:17 | Q1,00 | PCWC | |

| 6 | TABLE ACCESS FULL| LEO1 | 1616K| 1348 (1)| 00:00:17 | Q1,00 | PCWP | |

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

统计信息

Statistics

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

12 recursive calls

0 db block gets

22180 consistent gets

22022 physical reads

0 redo size

414 bytes sent via SQL*Net to client

381 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

1 rows processed

把并行进程限制在racdb1和racdb2两个实例上

SQL> alter session set parallel_instance_group='all_instance';

Session altered.

参数生效

SQL> show parameter instance_group

NAME TYPE VALUE

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

instance_groups string racdb1, racdb2

parallel_instance_group string all_instance

现在执行并行查询

SQL> alter system flush buffer_cache;

System altered.

SQL> set autotrace traceonly;

SQL> select /*+ parallel(2) */ count(*) from leo1;

Execution Plan

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

Plan hash value: 452265093

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

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

| 0 | SELECT STATEMENT | | 1 | 1348 (1)| 00:00:17 | | | |

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

| 2 | PX COORDINATOR | | | | | | | |

| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | Q1,00 | P->S | QC (RAND) |

| 4 | SORT AGGREGATE | | 1 | | | Q1,00 | PCWP | |

| 5 | PX BLOCK ITERATOR | | 1616K| 1348 (1)| 00:00:17 | Q1,00 | PCWC | |

| 6 | TABLE ACCESS FULL| LEO1 | 1616K| 1348 (1)| 00:00:17 | Q1,00 | PCWP | |

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

统计信息

Statistics

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

144 recursive calls

4 db block gets

22045 consistent gets

22025 physical reads

672 redo size

414 bytes sent via SQL*Net to client

381 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

1 rows processed

小结：根据对比两次测试结果，总体感觉单实例和多实例的效率相差不多，多实例在一致性读上好一点，单实例在物理读上好一点。大家如果在生产库上可以更多的测试测试，因为不同的业务会产生不同的性能效率，只有真实测试才能得到精确的性能指标。

RAC 性能优化 cache_fusion GCS 并行

《Oracle RAC性能优化》

猜你喜欢