source：  https://my.oschina.net/u/3635497/blog/3025812

 

RAC系统中，对于节点和节点之间数据块一致性的保证是通过消息的机制来保证的，也就是我们常说的gcs和ges的这些消息来确保的。这些消息分别有LMD和LMS的进程在实例之间进行传输。
LMD负责处理message的信息，如块的状态，lock level等信息。而LMS会负责数据块的传输。我们这不讨论一致性的机制，主要关注在消息传输的流量和控制上。

不管是LMS还是LMD的消息传递，这些信息传输，都是通过UDP的协议透过进行消息的传递的。而在实例之间进行消息传输的时候，消息的传递是彼此交互式的，不能由一个节点一直发送，而另外一个节点只负责持续的负责接收。所以在实例之间传输的时候就要平衡，传输消息的几率，控制彼此之间的合理流量，RAC里通过引入ticket的概念对彼此之间传输的流量和几率进行控制。

对于ticket概念的理解和best practice，Oracle有两篇相关文档可以参考：

Resolving ORA-481 and "terminating the instance due to error 481" (Doc ID 1950963.1)

Best Practices and Recommendations for RAC databases using very large SGA (e.g. 100 GB) (Doc ID 1619155.1)

这里我们可以看到，Oracle是通过某一个节点持有的ticket的数量对发送和接受消息进行流量控制的。一个节点发送一则消息队列的同时会带着一个ticket到对端，对端的ticket会增加。本地的ticket会减少，本地节点会根据可用的buffer和已经收到的信息以及发送的请求ticket的信息（null-req）计算本地可用的tickets。当本地没有ticket可用，本地的LMS/LMD就会进入消息等待队列，并持续的检查ticket latch里的信息，判断是否有可用的ticket的信息可用。直到对端发送回message，并带回可用的tickets后，本地才能再继续发送消息到对端。

我们可以查询动态视图：GV$GES_TRAFFIC_CONTROLLER 来获取每个节点上avalible的tickets数量，并且可以通过TCKT_WAIT判断LMS或者LMD是否正在等待ticket。如果我们持续的看到这里彼此都在等待，说明UDP buffer里package信息，没有被及时的处理，或者在传输的过程丢掉了。当然，我们也可以凭经验看lms/lmd在crash之前里的队列的消息传输情况来判断是否是ticket不足引发的问题。这不如直接获取的GVGEST​RAFFICC​ONTROLLER来获取每个节点上avalible的tickets数量，并且可以通过TCKTW​AIT判断LMS或者LMD是否正在等待ticket。如果我们持续的看到这里彼此都在等待，说明UDPbuffer里package信息，没有被及时的处理，或者在传输的过程丢掉了。当然，我们也可以凭经验看lms/lmd在crash之前里的队列的消息传输情况来判断是否是ticket不足引发的问题。这不如直接获取的GVGES_TRAFFIC_CONTROLLER直观。

我们为常见的问题就是：

1. RAC hang / LMD crashes instance with ORA-600[kjmscndscq:timeout] (Doc ID 1619155.1)

2. ORA-00481 After "The instance eviction reason is 0x2" due to Lack of Ticket (Doc ID 1644015.1)

这两个问题相对比较明显：

告警日志中：ORA-600[kjmscndscq:timeout]或者 ora-00481错误之前提示的"The instance eviction reason is 0x2"

都是说明实例之间的由于tickets短缺，引发了LMS/LMD之间的消息传输超时出现的故障。

这种问题在HP的平台上尤为明显，因为HP平台上的LMS一般都不是真正的RR（real time）模式的进程，导致LMS没能得到CPU的及时调度。关于进程优先级的问题，请参考以下文档: HP-UX: HPUX_SCHED_NOAGE and Scheduling Priority-Policy for LMS in RAC (Doc ID 759082.1)

所以对于HP的平台上的用户，如果SGA区比较大（通常超过100G），业务频繁在多个节点上更新相同的表活数据块，是很容易碰见此类问题的。

以下文档给出了大部分的解决方案：

ORA-00481 After "The instance eviction reason is 0x2" due to Lack of Ticket (Doc ID 1644015.1)

Best Practices and Recommendations for RAC databases using very large SGA (e.g. 100 GB) (Doc ID 1619155.1)

如果您在12.1.0.2的版本上运行您的系统，需要注意的是LMD进程在各个节点之间要保持数量一致（默认的个数是和CPU个数相关的），如果LMD个数不同，需要打补丁17821214。