ITPub博客

首页 > 数据库 > Oracle > 修改参数一定要确保重启后仍然生效!!--技术人生系列第四十二期-我和数据中心的故事

修改参数一定要确保重启后仍然生效!!--技术人生系列第四十二期-我和数据中心的故事

Oracle 作者:记录每一次错误 时间:2018-12-04 10:09:45 0 删除 编辑

前言:我们首先要欢迎本文作者高斌正是加入中亦科技,高斌此前在oracle工作10年有余,绝对称得上是资深元老级人物,在oracle RAC、一体机方面更是独树一帜;如今加入中亦科技,也让中亦科技的oracle 技术服务力量如虎添翼;在此也欢迎各路高手加入中亦科技,为客户提供更好的技术服务。话不多说,我们来看今天分享的技术案例。



问题来了


用户一套 11.2.0.3  的双节点 RAC 系统安装在 AIX7.1  上。两个节点启动之后,一定会有一个节点的 ora.crsd  资源处于 INTERMEDIATE 状态,换句话说:就是有一个节点的 crsd  启动不起来,那后面的 VIP, listener  等资源自然也就不能被启动了。但是让客户觉得奇怪的是问题并不固定在某一个节点上,有时是节点 1 ,有时会变成节点 2

事实上,上述的描述信息我们可以简单的通过一个命令crsctl stat res -t -init来说明:


从上面信息可以看到,gpnpd/gipcd/cssd等进程都已正常,启动到crsd进程时出现了异常,最终我们无法使用crsctl stat res -t命令来查看crs服务的情况;


如果遇到这样的情况,你会如何进一步跟进核查呢?不妨停下来想一想自己以往的解决方案或者遇到这样的问题你会如何解决........

........

........

........

........

........

........

........

........

........


分析过程


事实上上面的问题还是很清晰的,那么就直奔主题,先看看 crsd.log   里面是否出现了错误,导致了 crsd   资源无法被启动

上面的信息说明, crsd 进程的确尝试了和 gipcd   进程进行通信,   以便获取链接远程节点 xxxx-2   的相关信息,但是很遗憾并没有找到。

那为什么会找不到呢?难道是本地或者对端的gipc进程出了问题了吗?从我们前面看到的gipcd服务进程已经启动,首先这里我们就可以排除掉,那会不会还有别的情况呢?

 

这里要解释一下原理来帮助读者理解为什么 crsd 要和 gipcd 进行通信


原理解释 11gR2 版本的集群开始, gipc 作为一个集群的新的资源(或者叫守护进程)被引入,它的功能是管理本地节点作为心跳网络 ( 也称为集群的私网 ) 的网卡,而且,本地节点的 gipc 进程还需要通过私网网卡和远程节点的私网网卡建立链接,而这样做的主要目的就是因为 Oracle 的集群管理软件从 11gR2   版本开始支持多块私有网卡。而 crsd 作为集群的应用程序资源管理组件,它需要和 gipc 进行通信来获得到远程节点的一个链接,以便和远程节点的 crsd   进行通信,完成自己的初始化过程。关于更多 gipc 的信息,可以参考《 Oracle RAC   核心技术详解》中对 gipc 的介绍。




悬念


既然知道了原理,那么接下来要做的就是看看在 gipc   层面出现了什么问题。以下是节点 1 gipcd.log 信息:

看起来网卡 en2   是作为私网网卡被使用的,而且它的状态也是正常的,但是这段信息 gipcdMonitorCssCheck:updating timeout node xxxx-2 引起了我的注意, gipc 尝试向远程节点发送了一些信息,却发生了超时。

gipc通信超时?难道是节点间的私网通信不通导致的?

答案是否定的!如果是节点间私网私信不通,那么一定这里我们就不会看到cssd进程正常了;对于CRS来说,cssd进程管理了RAC间的网络心跳,如果私网不通,那么意味着cssd进程在启动时根本无法构建集群,同时HAIP也将无法启动,crsctl stat res -t -init命令的输出也会截然不同。

 

知识点 :cssd加入集群是只需要boot ip能通信,一般就没有问题,而RAC上的ASM实例和DB实例需要HAIP(169.254系列ip)正常时才能正常启动(在HAIP未被禁用的情况下)。


思考


这个时候,就需要冷静一下,来思考是否有别的可能了。既然问题是信息发送不过去,而别的组件通信是正常的,而不同的组件之间通信时会使用不同的端口,消息的长度也可能不同,那么还有两种可能:


1.        UDP 或者 TCP 的端口范围有问题

2.        UDP 或者 TCP 的发送或者接收缓冲区大小有问题。

 

当然还可能是其他和网络相关的参数设置导致的,不过这种可能性要小很多。


分析到这里之后,在 MOS 上找了一下 AIX 环境中针对网络相关参数的推荐值,以下是一部分参数和它们的推荐值:

用户在检查了相关的参数之后,发现原来是 udp_sendspace   参数出现了问题,被设置成了 8192 。看到了这里,基本上就真相大白了 原来是这个参数太低,导致了 gipc   在发送一些信息给远程节点的 gipc   时信息被截断了,造成了这个问题


问题解决


用户在把这个值修改成 655360 ,   并重新启动了两个节点的 gipcd.bin   进程之后,问题就被解决了。这里要说明一下的是,所谓重启 gipcd.bin   就是指使用操作系统的“ kill -9 <process id of gipcd.bin > ”命令来中止 gipcd.bin   进程,集群在发现这进程被终止之后,会自动启动新的进程。这种方式对集群的运行并没有影响

总结

+

+


后续与用户的沟通中我们了解到,原来用户的确是想把参数 udp_sendspace  从原来的 8192 改成 65536 ,而且也确实改了,但是之前的修改在重启之后并没有生效,才导致了问题。

在此,小编正式提醒各位伙伴改参数的时候一定要特别注意,否则后续可能会有一系列的问题随之而来!!


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547066/viewspace-2283439/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
性格开朗,有较强的学习能力,对oracle数据库的体系结构,搭建RAC,timesten,goldengate,分布式数据库,dataguard,系统调优有较深入的了解, 尤其是oracle优化,深入学习的主机命令,对数据库的优化,SQL语句的优化有深入的认识,目前正在shell脚本,mysql,以后会有计划学习大数据和python。

注册时间:2018-07-23

  • 博文量
    182
  • 访问量
    324478