2020-05-18
RAC1号节点频繁自动重启，1号节点的crsd日志和alert日志均看不出具体原因，但gicpd.log文件里面，一直循环的报错
25M请教各位专家：
我们的情况是这样的，一套RHEL 6.2 服务器上面的11.2.0.3 RAC 数据库，出现如下问题:
- 1号服务器经常自动重启，或者莫名的hang死；
- 故障时间点的OSW监控显示，CPU/MEMORY/DISK等均正常；
- 1号节点的alert日志和crsd日志里面，均看不出明显原因；
- 在crsd当中，发现了如下信息：2020-05-18 08:41:23.282: [GIPCXCPT][2775185152] gipchaInternalResolve: failed to resolve ret gipcretKeyNotFound (36), host ‘xxxxxx’, port ‘5031-eeef-1b4a-9685’
- 于是去查看了gipcd.log，发现日志一直在重复如下信息：
2020-05-18 08:44:59.776: [GIPCDMON][1029220096] gipcdMonitorCssCheck: found node xxxxxxxnode1
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: found node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: updating timeout node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: updating timeout node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorFailZombieNodes: skipping live node ‘xxxxxxxnode2’, time 0 ms, endp 0000000000000000, 0000000000000920
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorFailZombieNodes: skipping live node ‘xxxxxxxnode2’, time 0 ms, endp 0000000000000000, 00000000000009db
2020-05-18 08:44:59.777: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000357
2020-05-18 08:44:59.777: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000357), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:56171, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(15), send(15), recv(15)
2020-05-18 08:44:59.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000c6d
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000c6d), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:41064, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000129
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000129), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:10654, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(10), retry(0), stamp(3), send(3), recv(3)
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 000000000000088b
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(000000000000088b), len(1032), buf(0x7
fab340b3398), inf(ip: 300.300.300.5:34596, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:04.037: [ CLSINET][1029220096] Returning NETDATA: 1 interfaces
2020-05-18 08:45:04.037: [ CLSINET][1029220096] # 0 Interface ‘bond0’,ip=‘300.300.300.5’,mac=‘00-e0-ed-28-80-d0’,mask=‘255.255.255.0’,net=‘300.300.300.0’,use=‘cluster_int
erconnect’
2020-05-18 08:45:04.777: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000408
2020-05-18 08:45:04.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000408), len(1032), buf(0x7
fab340b3398), inf(ip: 300.300.300.5:32930, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:04.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1)
我一直怀疑是两个节点的私网通信有问题，但是OSW监控显示一直正常，一直到节点重启的时候才无法连通，而且也能正常ping通，ssh互连等等。
各位专家有没有谁有分析思路的？
我来答
添加附件
收藏
分享
问题补充
11条回答
默认
最新
操作系统日志上面完全就是看不出任何信息来，就像一根水管一直在正常流水，但突然就中断了，然后重启后又继续流水一样，但是就是不告诉你为什么就中断了。
补充一点：
- 私有网络采用双网卡，做bound绑定。因为gipcd进程本身就有多网卡自动冗余的工程，不知道会不会和bound产生什么冲突或者bug之类的？
评论
有用 0 打赏 0
先多看看数据库的各种日志吧，首先看看 ASM 日志是否有 ORA-27301、ORA-27302、ORA-27303 等的错误，因两节点 MTU 不一致会导致主机不断重启的故障。我遇到过类似的，如下文章可参考
https://www.modb.co/db/23015
评论 有用 0 打赏 0
@JiekeXu, 这个问题我也查过，MTU配置是没有问题的。这套库以前运行一直正常，直到最近因为内存故障，更换了内存后，就开始出现这种问题。目前更换后的内存比原来的少了一半，但数据库能够正常拉起来，只是过几个钟头后1号节点就会自动重启。
恼火的是，如果是内存硬件上的故障，但是系统日志里面一点消息都没有，整个服务器的情况就像一直运行正常，然后突然间就自动重启了。请了恩墨的维保，看看他们有什么线索没有。
评论 有用 0 打赏 0
附件是两个节点的相关日志，重点关注以下几个故障时间点：
2020年15号的凌晨4点42分左右；
2020年18号的上午9点13分左右；
2020年18号的下午14点05分左右；
以上几个时间点，都是故障时间点，其中：
第一个时间点的现象是，1号节点hang死，没有任何日志记录，直到9点多手动重启后才开始继续写日志；
第二个时间点，是在18号的早上8点40分左右手工启动1号节点CRS，运行到9点13分左右，节点被驱除然后自动重启；
第三个时间点，是在18号早上自动重启后，运行到下午大概14点05分，号节点再次自动重启。
由此可见，这个问题并非是1号节点CRS启动不正常，而是启动后，运行不了多久，短则数十分钟，长则数个小时候就会出现故障。
我觉得可以重点关注一下是否集群的gipcd进程有异常，因为1号节点在CRS运行期间一直循环报同步两个节点均超时，2号节点只是报同步1号节点超时，同步它自己2号则正常。
日志中的IP地址和hostname等信息都做了处理。
来吧兄弟们，姐妹们，都练练手吧，机会难得！
评论 有用 0 打赏 0
补充一点：
第三个故障时间点的时候，1号节点的alert里面有报：CRS-2412:The Cluster Time Synchronization Service detects that the local time is significantly different from the mean cluster time.
这个关于两个节点时间不同步的问题，两个时间点的确存在相差大概1分钟的时间差，可能导致第三个故障时间点的发生。但是对于这个问题，我们初步也排查过，在第二个时间点之前，我们做过NTP时间同步校正，并且1号节点正常运行了1个晚上，之后我们手动关闭了1号节点的CRS以防止生产影响，然后在第二个时间点之前，手工启动了CRS以便继续诊断，结果故障依然再第二个时间点产生了。
评论 有用 0 打赏 0
尝试清除之前的配置信息，重新执行root.sh来配置
具体步骤：
1、/opt/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig
2、在/opt/app/11.2.0/grid/ 目录下执行：root.sh
评论 有用 0 打赏 0
回答交流
Markdown
请输入正文
提交
相关推荐
oracle数据泵impdp报错ORA-01427
回答 1
《OracleDataPumpImport(IMPDP)FailswithErrorORA1427DuringImportingStatistics(DocID1501580.1).pdf》：http
Oracle怎样优化HASH连接？
回答 1
已采纳
Oracle的HASH连接需要将驱动表的select列和join列放入PGA中，所以，应该尽量避免书写selectfrom...语句，将需要的列放在selectlist中，这样可以减少驱动表对PGA的
Oralce字段中clob字段如何拼接？
回答 2
已采纳
concat和||只能把它当成varchar2拼,超长就会报错。正确的方式应该是用dbmslob.append过程来拼接declareaclobdefault'123';bclobdefault'ab
做bi分析的时候，从数据库层面有啥比较好用的权限划分手段？最好能精确到字段级别的（Oracle数据库）
回答 1
建多个视图，不同视图里查询不同的字段，给不同用户授予不同的视图权限Oracle18c以上支持多态表函数，可以动态地在查询中新增减少列，那么可以建一个配置表，在表函数里根据配置表去减少展示的列，并且此函
咨询一下，oracle 备份和加密工具，大家都用什么？单位要买
回答 1
ZDBM数据库备份一体机，是专门针对数据库设计的、具有零数据丢失特性的容灾备份管理平台，旨在帮助企业保障数据安全、盘活海量关键数据。该一体机可持续对数据库进行实时在线备份，并实现在任意时间点的数据恢复
请问这个报错是哪个配置的原因,互信检查了都可以,grid和Oracle用户两个节点的互信
回答 3
后面查到把这个参数加到/etc/sysctl.conf就没有这个报错了!
oracle 12c 数据泵导出整个CPD及所有的PDB,用system和sys用户都不成功
回答 7
12C需要连接到pdb再导出吧，连接到cdb的时候不能导出pdb。在tansnames.ora文件里给pdb创建条目，在expdp的userid里面配置即可
oracle迁移数据库如何预估所需存储大小
回答 7
你这个不准的，数据泵自带的估算出来的是dmp文件的大小，不是导入之后的实际大小。另外像UNDO,TEMP等表空间也需要占用存储的，你得考虑进去。建议去segment视图下查询，注意过滤掉回收站里的。
Oracle中经常delete的系统，如何处理？
回答 2
已采纳
经常delete的表会造成大量的碎片影响性能。一般会进行表空间碎片整理，或者大表碎片整理。
oracle中有张表year,month保存年月，这个结构如何按某个时间范围查询？
回答 3
已采纳
假设你的年是4位字符，比如'2021'；月是2位字符，比如'02'。如果要查询2021年1月到2021年5月，则selectfromtabwhereyear||monthbetween'202101'
问题信息
请登录之后查看
附件列表
请登录之后查看
邀请回答
暂无人订阅该标签，敬请期待~~
热门文章
Oracle 基本原理: 创建触发器和创建序列
Oracle 11g R2 Add a node (增加RAC节点)
[译文] 升级Oracle 21c踩坑：当ORDIM存在但没有SDO时，升级到21c失败
在Oracle中，与ASM相关的有哪些进程？
【生产排故】Oracle 11g 异机rman恢复报错ORA-302failure occurred at sskgpcreates
Oracle 19c: RAC 集群技术的坚持与放弃（含PPT下载）
Oracle 目录权限丢失故障恢复
数据库访问–由于启用了统一审核，切换失败，出现ORA-00600错误
Linux下oracle用户crontab不生效的解决办法
Oracle 比较分页方法-偏移与搜索
