当前位置:  数据库>oracle

RAC之间消息传输流量控制

    来源: 互联网  发布时间:2017-06-21

    本文导语: RAC系统中,对于节点和节点之间数据块一致性的保证是通过消息的机制来保证的,也就是我们常说的gcs和ges的这些消息来确保的。这些消息分别有LMD和LMS的进程在实例之间进行传输;LMD负责处理message的信息,如块的状态,lock lev...

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不足引发的问题,但是通常,这确实需要猜测了,不如直接获取的GV$GES_TRAFFIC_CONTROLLER直观。

我们最为常见的问题就是1619155.1中介绍的 RAC hang / LMD crashes instance with ORA-600[kjmscndscq:timeout]

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;


    
 
 

您可能感兴趣的文章:

 
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。












  • 相关文章推荐
  • RAC +GPFS添加节点的问题~~~~~~~~~~~~·
  • 配置Oracle RAC需要注意的问题
  • Linux Oracle RAC内核参数
  • Linux下Oracle RAC一个节点宕机导致共享存储无法挂载的故障排除
  • Oracle RAC 10.2.0.1升级到10.2.0.4
  • Oracle10201 RAC升级到10204后导出数据时报EXP-00056错误
  • 与Oracle RAC相关的连接配置写法实例
  • [Oracle] RAC 之 - 负载均衡深入解析
  • RAC cache fusion机制实现原理分析
  • 基于Linux平台的Oracle RAC 10g集群教程:删除节点所需要的步骤
  • 如何在RAC环境下修改Oracle字符集
  • Oracle RAC 状态检查
  • IP地址数字互转 iis7站长之家
  • redhat 5.5全新安装oracle rac的问题[1000分]
  • oracle 11g RAC 常用命令整理分享
  • Oracle 10201 RAC升级到10204
  • Redflag Linux安装Oracle 10gR2 RAC记事
  • 基于Linux平台的Oracle RAC 10g集群教程:添加节点所需要的步骤
  • Oracle10g RAC for Linux配置全过程


  • 站内导航:


    特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

    ©2012-2021,,E-mail:www_#163.com(请将#改为@)

    浙ICP备11055608号-3