Oracle RAC 相关等待事件总结
目录
Oracle RAC 相关等待事件总结 1
一．gc cr multi block request 3
（一） 等待事件描述： 3
（二） 等待事件产生原因： 4
（三） 等待事件产生的影响： 4
（四） 解决问题方法： 4
二． gc current block 2-way 8
（一） 等待事件描述： 8
（二） 等待事件产生原因： 9
（三） 等待事件影响： 9
（四） 解决问题方法： 9
三． GC CR Block 2-Way/3-Way 10
（一） 等待事件描述： 10
（二） 等待事件产生原因： 10
（三） 解决问题的方法： 11
四．gc cr/current block busy事件 11
（一）等待事件描述： 11
（二）等待事件产生的原因： 12
（三）等待事件的影响： 12
（四）解决问题方法： 12
五．gc buffer busy 等待事件 13
（一） 等待事件描述： 13
（二） 等待事件产生原因： 13
（三） 等待事件的影响： 13
（四） 解决问题的方法： 14
六．gc [current/cr] block/grant congested 14
（一）等待事件的描述： 14
（二）等待事件产生的原因 15
（三）解决问题的过程 15
七．gc cr failure 15
（一） 等待事件描述： 15
（二） 等待事件产生原因： 15
（三） 解决问题的方法： 15
八． gc cr disk read事件 16
（一） 等待事件描述： 16
（二） 等待事件产生原因： 16
（三） 解决问题方法： 16
九． gc cr block lost等待事件 17
（一） 等待事件描述： 17
（二） 等待事件产生原因： 17
十． global cache cr request等待事件 18
（一） 等待事件描述： 18
（二） 等待事件产生原因： 18
（三） 等待事件影响： 18
（四） 解决问题的方法： 19
十一． TX- index contention等待事件 19
（一） 等待事件描述： 19
（二） 等待事件产生原因： 19
（三） 解决问题方法： 19
十二．GC FREELIST等待事件 20
（一）等待事件描述： 20
（二）事件产生原因： 20
（三）解决问题方法： 21
十三．gc remaster 21
（一）等待事件描述： 21
（二）等待事件原因： 21
（三）等待事件影响： 22
（四）解决问题方法： 22
十四．gc current split 22
（一）等待事件描述： 22
（二） 等待事件原因： 23
（三） 等待事件影响： 23
（四） 解决问题方法： 23
一．gc cr multi block request
等待事件描述：
gc cr multi block request 是RAC数据库上比较常见的一种等待事件，在RAC上进行全表扫描(Full Table Scan)或者全索引扫描(Index Fast Full Scan）时，容易产生这样的多块读等待。
当进程请求数据库块时，首先会在本地的CACHE里面查看是否存在，这种查看是根据DBA (Data Block Address) 转化为cache bufferschains,然后再从hash bucket确认是否存在。
如果在本地没发现有块的CACHE，进程就会请求resourcemaster授予共享访问给数据块，然后再去获取数据块的CACHE。
如果请求的BLOCK CACHE在远程的节点，resourcemaster就会使用内部通讯把远程的CACHE传输到本地。当请求的CACHE BUFFER是共享模式的，远程节点就会克隆一个然后传输到本地。否则，就建立PI映像，然后传输到本地。
等待事件产生原因：
1）数据库参数db_file_multiblock_read或者db_block_size设置太大，导致多块读时GC传输量太大；
2）OS上UDP相关的参数设置不够大导致接收发送UDP的缓存区溢出；
3）私网性能；
4）LMS设置问题（个数不足或者不是实时运行(real time)）导致LMS的处理能力不够，不能及时传输global cache data/message。
等待事件产生的影响：
1）这些事件严重影响了数据库的性能，它可能造成查询，修改，建立索引，统计分析异常缓慢。
2）数据库跑批会卡主，影响业务系统运行。
3）CPU使用率过高，会影响其他应用正常运行。
解决问题方法：
很多情况下，降低DB_FILE_MULTIBLOCK_READ_COUNT 并且 加大OS UDP相关参数会将极大缓解gc cr multi block request等待。
查看数据库等待事件
SQL> select name from v$event_name where name like 'gc%';
NAME
----------------------------------------------------------------
gc buffer busy
gc current request
gc cr request
gc cr disk request
gc cr multi block request
gc current multi block request
gc block recovery request
或者查看AWR报告分析等待事件
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc cr multi block request 632,923 32,441 51 35.5 Cluster
DB CPU 13,518 14.8
gc cr grant 2-way 327,717 10,900 33 11.9 Cluster
gc current grant 2-way 190,856 6,855 36 7.5 Cluster
gc current block 2-way 101,154 3,792 37 4.1 Cluster
如果发现AWR TOP5 等待中存在gc cr multi block request而且 它的Avg wait(ms)较高，那么请参考下面的诊断步骤：
（1）查看db_file_multiblock_read_count和db_block_size参数设置。
SQL>show parameter db_block_size
SQL>show parameter db_file_multiblock_read_count
db_block_size一般为8192, db_file_multiblock_read_count一般为16.
（2）参看OS udp相关参数设置，udp 的参数在不同的OS上是不同的，这些参数会设置UDP的接收缓存区和发送缓存区的大小，一般来说接收缓存区要>=发送缓存区。 如果在生产库修改这些参数，最好咨询OS厂商了解注意事项。
AIX上：
#no –a
udp_recvspace
udp_sendspace
a.设置udp_sendspace >=[(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096]，但是不低于 65536.
比如，DB_BLOCK_SIZE=8192, DB_FILE_MULTIBLOCK_READ_COUNT=16，那么udp_sendspace>= (8192 * 16) + 4096=135168.注意这个值只是最低值，并不是Oracle要求必须设置这么大。
b.设置udp_recvspace 为 4到10倍 udp_sendpace
C.由于sb_max 必须 >= udp_recvspaceIf ，可能需要增加sb_max的值(默认为1048576)
d.如果udp的参数设置不合理，可能会产生“socket buffer overflows”，如果这个值非0， 需要增加udp_recvspace:
netstat -s | grep "socket buffer overflows"
Linux上:
#More /etc/sysctl.conf
net.core.rmem_default
net.core.rmem_max
net.core.wmem_default
net.core.wmem_max
官方文档上要求的最低值：
Oracle Database Installation Guide
11g Release 2 (11.2) for Linux
E24321-07
rmem_default 262144
rmem_max 4194304
wmem_default 262144
wmem_max 1048576
可以将这几个值都设为4k：
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 4194304
net.core.wmem_max = 4194304
HP上：
请检查UDP设置是否足够大：
$ /bin/ndd -get /dev/sockets socket_udp_rcvbuf_default
$ /bin/ndd -get /dev/sockets socket_udp_sndbuf_default
确保socket_udp_rcvbuf_default至少是socket_udp_sndbuf_default的两倍。
（3）查看网络情况。
比如用netstat -s 命令查看是否有bad data length, bad checksums, incomplete headers, socket buffer overflows等，注意这些值是累计的，需要查看它们在发生问题的时候是否有增加。
另外可以查看AWR中是否有 "Global Cache Blocks Lost" ，理想情况下这个值是0，如果有较大的block lost，说明网络有问题(按照MOS 文档563566.1进行网络检查)。
还可以请网管查看私网的性能情况。
（4）检查LMS。
1. 查看LMS的trace file，查看是否有异常。
2. 查看LMS进程的优先级是否是实时的(real time）的？
比如AIX:
# ps -elf|grep lms
priority 越小说明优先级越高，PRI小于40说明是Real Time的
3. 查看LMS的个数:
SQL>show parameter GCS_SERVER_PROCESSES
这个值决定了LMS的个数
Default value
If 1 - 3 CPUS, then 1
If 4 - 15 CPUs, then 2
If 16 or more CPUs, then 2 + (CPUs / 32). If the result includes a fraction, then the fraction is disregarded. For example, if you had 20 CPUs, then 2 + (20 / 32) would equal 2 GCS processes.
If CLUSTER_DATABASE is set to false, then 0
If ASM, then 1
在AIX上，有的时候CPU可能是动态增加的，那么一定要注意检查LMS进程的个数是否随之调整了。
gc current block 2-way
等待事件描述：
node 1、node 2的buffer cache里都没有block A，这时node 1读取了某个block A里的某一行，随后node 2也读取了block A或者对block A里的某一行作了DML操作，这两种情况下node 2上都会出现"gc current block 2-way"等待，current在这里表示node 2读取或修改的block版本是最新的，该block里不存在未提交的事务。值得注意的是在"gc current block 2-way"事件发生之后，GRD里会为该block上KJUSERPR(读操作)或者KJUSEREX锁(写操作)
等待事件产生原因：
1）SQL 过多的I/O 操作导致cr grant；
2）insert 大量的数据导到current grant;
3）非常小的buffer cache;
4）flush buffer cache 会加剧gc cr/current grant 2-way;
5）还有可能是过多的节点间交互访问;
6）极差的网络性能;
7）oracle bug；
8）两节点CPU个数不一致；
等待事件影响：
多个进程在同时访问一个block，造成锁竞争了。用RAC就一定要将各个节点隔离化，不管是通过业务隔离，区域隔离还是什么其他隔离手段，最终的目的，就是要各个节点所承担的业务，访问不同的数据对象，最大可能地减少节点间的资源争用，才能发挥RAC集群系统的最大性能。
解决问题方法：
1）如果网络配置没有问题，可以检查一下TCP 和UDP的buffer是否不足
root#netstat -s | grep overflow 值为了0一般情况下。
root#netstat -i
2）查看负载ps aux | grep lms
查看是否是有某些表产生了过多的global cr request
select STATISTIC_NAME stat, OWNER, OBJECT_NAME obj, sum(value) val from v$segment_statistics where STATISTIC_NAME like 'global%' and value > 10000 group by STATISTIC_NAME,OWNER,OBJECT_NAME order by val desc;
3）查看一段时间内，CR的值是否很大。
select CR_REQUESTS cr, CURRENT_REQUESTS cur, DATA_REQUESTS data, UNDO_REQUESTS undo, TX_REQUESTS tx from v$cr_block_server;
4）查看当时的LMS进程CPU使用
ps -efl|head -n 1;ps -efl|grep lms
GC CR Block 2-Way/3-Way
等待事件描述：
CR模式的块传输发生在只读访问的请求中。考虑这样一个场景：一个块以CURRENT模式驻留在实例2上，实例2以独占模式保持了该资源的BL锁。另一个会话连接到实例1来请求该块，阻止。由于Oracle数据库中“其他人看不到未提交的更改”，SELECT语句请求一个查询开始时间的块的特定版本。SCN被用于标识块版本，本质上，SELECT语句请求的版本与块的SCN一致。LMS进程维护实例2的请求，以CURRENT的模式克隆该块到缓冲区，验证SCN版本与请求是一致的，然后发送该块的CR拷贝给FG进程。
这些CR模式传输和CURRENT模式传输之间的主要区别在于，在CR模式传输的情况下，在GRD中没有资源或锁来维护CR缓冲区。从本质上讲，CR模式块不需要全局缓存资源或锁。接收到的CR副本只能由提出请求的会话使用，并且只适用于这个特定的SQL执行中。这就是为什么Oracle数据库不对CR传输获取BL资源的任何锁。
由于没有全局缓存锁保护缓冲区，连接到实例1再次执行这个SQL语句访问那个块时将遭遇gc cr block 2-way 或者 gc cr block 3-way等待事件。
等待事件产生原因：
1）网络传输速度和带宽；
2）IPC协议的代码路径长度；
3）CPU利用率高；
解决问题的方法：
1）运行队列长度和系统CPU利用率；
2）系统和负载调优，以减少延迟；
3）SQL和架构调整，以尽量减少IO和远程高速缓存引用；
四．gc cr/current block busy事件
（一）等待事件描述：
gc cr block busy
实例1和实例2的buffer cache都含有某个block，T1时刻实例1修改了这个block；T2时刻实例2上的会话1读取这个block修改前的CR copy，因为CR copy需要通过应用undo record才能构造出来，且构造的过程中必须将改变记入到实例1的online redo，因此实例2会话1读取的时候在可能会因为如下原因而发生gc cr block busy等待。
当实例1和实例2的buffer cache都含有某个block，T1时刻实例1修改了这个block，但没有commit；T2时刻实例2上的会话1读取这个block，读取的大致过程分解可以分解为以下几个步骤：
1）实例2的LMS向实例1的LMS发起block 读请求；
2）实例1的buffer cache里已经存在了这个block修改后的最新副本B1’，实例1的 LMS在本地的buffer cache里根据B1’再复制出一个新的副本B1’’，此时B1’和B1’’的内容是完全相同的；
3）实例1的LMS从undo segment里找到undo record用来applied到B1’’上，把B1’’回滚到修改前的状态，记为B1；
4）这时实例1的buffer cache 里包含了B1’，B1，其中B1是B1’修改前的内容。
5）利用undo record将B1’’回滚到B1这一过程是会产生redo的，实例1 的LMS进程通知Lgwr进程把redo写入online redolog，写成功后才能进入下一步；
6）实例1上的Lgwr通知实例1上的LMS redo写入完成，实例1上的LMS将B1传输给实例2的LMS；
7）实例2的LMS将结果返回给实例2上的会话1的server process。
gc current block busy
node 1正在更新block A的时候node 2也发起了对block A的更新，这时node 2在等待接收node 1上的LMS进程构造出block A在node 2发起更新时刻的block映像，node 2在接收到block A映像之前，就会处于gc current block busy状态。
（二）等待事件产生的原因：
1）CR copy在实例1上构造过慢；
2）记入online redo过慢；
3）执行完DML语句未提交；
（三）等待事件的影响：
1）数据库性能产生巨大开销，影响正产运行；
2）数据库执行的语句卡主；
3）数据库hang住，严重会导致宕机；
4）IO量开销增大；
（四）解决问题方法：
1）修改后及时提交，且修改的操作尽量与select操作放在同一个节点。
2）实时监控dba_fga_audit_trail，每当观察到dba_fga_audit_trail视图新进来一条被审计到的SQL及其对应的绑定变量后，立刻执行select param_value from sd.sys_parameter where param_code='CA_VCSMS_TIME'，来观察param_value字段何时变成绑定变量的值，如果一直没有变化，那就证明没有提交。
五．gc buffer busy 等待事件
等待事件描述：
- gc buffer busy是RAC数据库中常见的等待事件，11g开始gc buffer busy分为gc buffer busy acquire和gc buffer busy release。
- gc buffer busy acquire是当session#1尝试请求访问远程实例(remote instance) buffer，但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy acquire。
3）gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy release。
等待事件产生原因：
1）热点块(hot block)；
2）低效SQL语句；
3）数据交叉访问；
4）Oracle bug；
5）大量未提交的事务或者系统磁盘设备传输慢；
等待事件的影响：
1）会导致应用端业务处理异常；
2）数据库hang；
3）CPU耗费比较大，性能下降；
4）系统运行缓慢；
解决问题的方法：
1）在AWR中Segments by Global Cache Buffer Busy 记录了访问频繁的gc buffer.
解决方法可以根据热点块的类型采取不同的解决方法，比如采取分区表，分区索引，反向index等等。这点与单机数据库中的buffer busy waits类似。
2）低效SQL语句会导致不必要的buffer被请求访问，增加了buffer busy的机会。在AWR中可以找到TOP SQL。解决方法可以优化SQL语句减少buffer访问。这点与单机数据库中的buffer busy waits类似。
从v$session或者v$session_wait视图中，可以查询到大量的gc buffer busy 等待。检查发现，这些gc buffer busy 全部是由2个SQL 引起的，查看sql的执行计划，分析执行计划。
3）RAC数据库，同一数据在不同数据库实例上被请求访问。
如果应用程序可以实现，那么我们建议不同的应用功能/模块数据分布在不同的数据库实例上被访问，避免同一数据被多个实例交叉访问，可以减少buffer的争用，避免gc等待。
4）建议安装Oracle推荐的最新Patch Set和PSU。
六．gc [current/cr] block/grant congested
（一）等待事件的描述：
请求当前或CR块，并收到了块或授权消息。拥挤的暗示意味着该请求在内部队列中花费超过1毫秒的IPC层传递的消息后，和LMS把它捡起来了。排队可能会影响在主或持有者请求的延迟。地方选区服务器代码将通过提示KCL_WAIT_LMS。
（二）等待事件产生的原因
1）LMS实施的进程中断；
2）后台进程的CPU时间段太短；
3）LMS超载，不能与请求到达率跟上；
4）系统的总负荷或内存不足（分页，交换）；
（三）解决问题的过程
1）CPU利用率和运行队列长度；
2）LMS的过程中CPU使用率；
3）操作系统内存统计信息包括虚拟内存的统计数据（如分页）；
七．gc cr failure
等待事件描述：
请求一个CA CR块，并收到了故障状态或其他一些特殊事件，如发生丢失块。本次活动有时伴有占位事件的多个超时。
等待事件产生原因：
1）丢失数据块；
2）CR前身读取错误；
3）无效格式或块无效SCN；
解决问题的方法：
1）故障的网络硬件；
2）交换机丢包；
3）数据包重组失败；
4）通信缓冲区溢出；
5）网络固件或驱动程序；
八． gc cr disk read事件
等待事件描述：
当node 1需要读取的block在node 2的buffer cache里，且block中包含尚未提交的事务，那么node 2的LMS进程需要使用undo record将该block回滚至node 1发起那一时刻的内容后再传给node 1，假如这时undo record所在的undo block不在node 2的buffer cache里，node 1上就会出现gc cr disk read事件，表示node 1正等待node 2的LMS授予其直接从磁盘读取undo block的权限。
等待事件产生原因：
1）通常在使用索引时；
2）全表扫描时；
解决问题方法：
1）从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；
2）优化sql语句，减少不必要的块读取；
gc cr block lost等待事件
等待事件描述：
在Oracle的RAC环境中，数据库会收集global cache 的工作负载统计信息，并把这些信息通过STATSPACK, AWRs 和 GRID CONTROL等工具呈报。对于每个节点，以及集群汇总统计信息中的global cache数据块丢失的统计信息("gc cr block lost" 和/或 "gc current block lost") 代表了私网通信的包处理效率低或者包的处理存在异常。这些信息是需要定期进行监控和评估来保证私网之间的global cache和 Enqueue服务（gcs/ges）以及集群之间的正常通信。任何块丢失的信息都说明私网在对数据包的处理过程中是存在异常情况并且需要进行调查。
数据库绝大部分的 “global cache lost blocks”的问题都可以直接联系到私网的故障和错误的配置。
等待事件产生原因：
1）Cup软中断故障；
2）硬件问题；
- 等待事件影响：
1）应用入库数据积压严重，影响应用运行；
2）可能会导致节点或实例的驱逐；
3）应用的性能和吞吐量都很差；
4）大量的CPU消耗在网络进程上；
- 解决问题方法：
通过ifconfig查看心跳流量包是否存在丢失，查看overruns 的值。
（RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一）
global cache cr request等待事件
等待事件描述：
当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache 发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHE FUSION,在节点之间直接传递，同时出现global cache cr request等待事件。
从remote cache运输块到本地cache花费的时间还得看这些块是共享还是独占模式，如果块是共享(scur)的，REMOTE CACHE就克隆信息传送过来，否则就要产生一个PI，然后再传送过去。显然，global cache cr request等待事件和db file sequential/scattered read 等待事件有着直接的关系。
等待事件产生原因：
1 ）节点之间内部连接慢或者节点之间传输带宽窄。这个可以通过重新连接获取高速连接；
2 ）存在热点数据块的竞争；
3 ）CPU负载过高或者LMS后台进程不够。正常情况下，只有两个LMS后台进程从CPU那里获取资源，增加LMS进程的数量或者提高它的优先权能够帮助从CPU那里获取更多的资源。隐藏参数 _lm_lms是设置LMS进程数量的；
4 ）大量未提交的事务或者系统磁盘设备传输慢；
等待事件影响：
- 会导致业务做dml导入操作hang住；
解决问题的方法：
1）从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；
2）优化sql语句，减少不必要的块读取；
3）私网通信的包处理效率低或者包的处理存在异常；
TX- index contention等待事件
等待事件描述：
当事务修改索引中的数据时,而相关索引块没有足够的空间的时候,就会发生索引块的分割,在分割的过程中前台进程需要等待分割完毕才能继续操作。 如果这个时候其他会话也要修改这个索引块的数据,那么将会出现索引块的竞争。 (end: TX- index contention).一般索引块的分割持有资源和释放非常短,并不会对数据库造成严重的影响。但是对表操作并发量很大的情况下可能导致严重的竞争。
等待事件产生原因：
- 数据库插入和更新操作。
- 索引所在的表应用给的压力较大；
- 应用程序并发数大时导致了热块竞争，通常伴随着gc类的等待一起发生；
- 在RAC环境中，由于全局缓冲块和全局队列的争用，当私网传输有性能瓶颈时会发生，比如私网流量大或者传输时有丢失的情况而导致不能快速申请到空的索引块，通常伴随着gc类的等待一起发生。
解决问题方法：
1）数据库锁语查询：
select t2.username,t2.sid,t2.serial#,t2.logon_time,event
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time
2）加大索引的block size，数据库默认是8K，可配置成16K，配置步骤如下，sql执行：
（1）alter system set db_16k_cache_size=1M scope=both;
（2）show parameter db_16k_cache_size
（3）create tablespace indexspace datafile 'oracle/oradata/TS_INDEX_01.dbf' size 2G autoextend on next 500m maxsize unlimited blocksize 16k;
3）修正index pctfree为0,大大减少index contention。
4）Hash（散列）分区索引；
5）定期rebuild索引来减轻这样现象；
————————————————
版权声明：本文为CSDN博主「TrsenZhang」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/trsenzhang/article/details/41249989
十二．GC FREELIST等待事件
（一）等待事件描述：
基本上是正在等待LE（锁定元素）期间锁定默认。 LE在某种程度上（粗略地）像缓冲区一样工作哈希链，可以查询X $ KCLFX（LE Freelist结构）和查看有问题的节点上的LENGH是否接近零。
（二）事件产生原因：
Oracle bug
（三）解决问题方法：
1）排查节点是否hang住，
oradebug hanganalyze 3
2）根据官网建议修改参数值,重启hang住的实例
Alter system set '_gc_element_percent'=200 scope=spfile;
十三．gc remaster
（一）等待事件描述：
一个rac集群中有两个节点，节点2在空闲时段cache了一张很大很大的表，到了业务繁忙时段，节点1需要访问该表，如果没有DRM，则会从存储中访问，但是如果有了DRM，就会在节点2中找到该cache资源，从节点2的cache中将该资源传到节点1，这样的话就会消耗大量的带宽，从而消耗了很多资源，产生了等待事件。
（二）等待事件原因：
DRM(Dynamic Resource Management)是oracle 10g的一个新特性，在oracle rac环境中，ORACLE使用GRD(Global Resource Service)来记录各个节点的资源信息，具体是通过GCS(Global Cache Service)和GES(Global Enqueue Service)这两个服务进行管理。由于RAC中每个节点都有自己的SGA和buffer cache，为了保证所有节点cache 资源的一致性和高性能。GCS和GES会指定RAC中的某一个节点的实例来管理cache，这个节点就是Resource Master。当rematering或改变主节点只会发生在重新配置，会自动在两个正常操作实例启动或实例关闭，异常节点就是被集群踢出。所以当以节点A作为主节点是也就是 Resource Master时，这个资源就掌握在节点A中，直到被重新配置。
理论上讲，利用DRM，非master节点对所需资源有频繁访问需求时，可以提升为master节点，从而减少大量后续的跨节点资源访问需求，例：cache resource 被节点B频繁访问时，资源就可以从节点A remaster到节点B。
（三）等待事件影响：
同时系统负载升高，前台反映性能下降。而在DRM完成之后，这些等待消失，系统性能恢复到正常。
（四）解决问题方法：
只需要关闭DRM就能避免这个问题，这2个参数是静态参数，也就是说必须要重启实例才能生效。
_gc_affinity_time=0
_gc_undo_affinity=FALSE
实际上可以设置另外2个动态的隐含参数，来达到这个目的。按下面的值设置这2个参数之后，不能完全算是禁止/关闭了DRM，而是从”事实上“关闭了DRM。
_gc_affinity_limit=250
修改索引initrans 参数
其实修改initrans 参数并没有真正解决问题，随着并发度的不断提升，ITL 槽的争用也越发激烈。
- .反向建索引。利：入库高效了，几乎完全消除了enq:TX-index contention
弊：数据读取低效，本来访问一个索引块即可，现在需要访问多个索引块了。增加了额外I/O开销。
