环境：
两节点 oracle 11G rac + ACTIVE DATAGUARD
现象：
收到数据库事务响应时间超过阀值的监控短信，伴随大量enq: TX - index contention 等待事件的告警，应用层WEBLOGIC JDBC POOL都达到最大连接数，业务交易响应超时，持续大概两分钟后恢复正常。
原因分析：
1.大量enq: TX - index contention 等待事件怀疑是业务量急剧上升，检查问题时刻前5分钟到问题时刻后5分钟OS CPU使用情况以及数据库每秒事务指标，发现业务量比较平稳，离业务高峰的峰值还差很多，排除交易量突增情况。
2.从V$ACTIVE_SESSION_HISTORY视图检查问题时刻的进程，发现经历enq: TX - index contention 等待事件的进程被固定的几个进程阻塞：
查看进程3926在经历enq:FB-contention 和 gc current multi block request, 其中gc current multi block request等待时间将近12S，而此进程又被6299阻塞。
进一步查看 6299进程的执行情况，有将近20S 中在等待gc current multi block request事件，并没有其他进程阻塞他。
问题重点落到了 gc current multi block request事件。
3. 各应用模块都是独立使用数据库实例，平时GC 类等待事件都是在毫秒级别，而问题时刻达到20秒，继续查看GC 相关信息，发现% off flow controlled messgaes 达到86, off flow controlled messages 解释：无法直接发送消息的比例,这说明在发送消 息的时候tickets不足,需要进行流控
正常时刻：
问题时刻：
4. 通过视图GV$DLM_TRAFFIC_CONTROLLER查看数据库tickets 使用情况，实例1 和实例2的LMS进程数不一致，而且实例1 只有一个进程有可用TICKETS.
INST_ID
LOCAL_NID
TCKT_AVAIL
TCKT_LIMIT
TCKT_RCVD
SND_PROXY
1
0
750
1000
165
12
1
0
0
1000
165
13
1
0
0
1000
165
14
1
0
0
1000
165
15
2
1
750
1000
1
12
2
1
424
1000
1
13
2
1
622
1000
1
14
2
1
423
1000
1
15
2
1
0
1000
1
13
5.进一步分析为LMS进程状态异常，在OS层面检查两个节点LMS后台进程个数，节点1为4个，节点2为3个，同时查看ORACLE参数gcs_server_processes ，节点1为4，节点2为三，数据库内部参数与后台进程一致，但这个结果与GV$DLM_TRAFFIC_CONTROLLER视图中的不一致，LMS进程个数依赖于主机CPU个数(规则如下)。
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
6.检查数据库CPU个数，至此问题原因基本定位，两节点CPU个数不一致导致LMS进程出现异常，从而影响到数据库正常运行。
节点1：
节点2：
解决方案：
1. 增加节点2 CPU 。
2. 调低节点1 gcs_server_processes 参数，使之与节点2 一致。
通过调整节点2CPU 个数后，相同问题没有继续出现。