技术分享 | Oracle RAC集群节点2被驱逐案例

原创 于 2025-10-28 11:55:44 发布 · 465 阅读 · 10 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#oracle #数据库

本文为墨天轮数据库管理服务团队第135期技术分享，内容原创，作者为技术顾问罗海鸥，如需转载请联系小墨（VX：modb666）并注明来源。如需查看更多文章可关注【墨天轮】公众号。

适用范围

Oracle RAC 11G、12C、19C

问题概述

客户一套RAC节点，版本为12.2.0.1。2025-07-31 07:39:21 节点2被驱逐。

以下是节点2alter日志。

2025-07-31T07:20:49.680473+08:00
Thread 2 advanced to log sequence 116120 (LGWR switch)
  Current log# 7 seq# 116120 mem# 0: +DATA/FDCDB/ONLINELOG/group_7.271.1000847113
  Current log# 7 seq# 116120 mem# 1: +ARC/FDCDB/ONLINELOG/group_7.269.1000847113
2025-07-31T07:20:51.220283+08:00
Archived Log entry 193846 added for T-2.S-116119 ID 0xeac4c440 LAD:1
2025-07-31T07:38:00.059963+08:00
minact-scn: got error during useg scan e:12751 usn:1
minact-scn: useg scan erroring out with error e:12751
2025-07-31T07:39:00.979683+08:00
IPC Receiver dump detected. Sender instance 1 Receiver pnum 570 ospid 41888 [oracle@fdcdb2 (PPA7)], pser 12
2025-07-31T07:39:00.979980+08:00
Errors in file /oracle/app/diag/rdbms/fdcdb/fdcdb2/trace/fdcdb2_ppa7_41888.trc:
2025-07-31T07:39:21.277326+08:00
Detected an inconsistent instance membership by instance 1
Errors in file /oracle/app/diag/rdbms/fdcdb/fdcdb2/trace/fdcdb2_lmon_14788.trc  (incident=1987597):
ORA-29740: evicted by instance number 1, group incarnation 14
Incident details in: /oracle/app/diag/rdbms/fdcdb/fdcdb2/incident/incdir_1987597/fdcdb2_lmon_14788_i1987597.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-07-31T07:39:22.156952+08:00
Errors in file /oracle/app/diag/rdbms/fdcdb/fdcdb2/trace/fdcdb2_lmon_14788.trc:
ORA-29740: evicted by instance number 1, group incarnation 14
Errors in file /oracle/app/diag/rdbms/fdcdb/fdcdb2/trace/fdcdb2_lmon_14788.trc  (incident=1987598):
ORA-29740 [] [] [] [] [] [] [] [] [] [] [] []
Incident details in: /oracle/app/diag/rdbms/fdcdb/fdcdb2/incident/incdir_1987598/fdcdb2_lmon_14788_i1987598.trc
2025-07-31T07:39:22.367538+08:00
CJQ0 (ospid: 17003): terminating the instance due to error 481
2025-07-31T07:39:23.851520+08:00
System state dump requested by (instance=2, osid=17003 (CJQ0)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/diag/rdbms/fdcdb/fdcdb2/trace/fdcdb2_diag_14756_20250731073923.trc
2025-07-31T07:39:24.449532+08:00

节点1alter日志显示：

2025-07-31T07:38:33 节点1的LMS进程无法和节点2连接

07:39:00 等待超时，

07:39:21 节点2被驱逐

2025-07-31T07:13:53.757631+08:00
Thread 1 advanced to log sequence 77598 (LGWR switch)
  Current log# 4 seq# 77598 mem# 0: +DATA/FDCDB/ONLINELOG/group_4.267.1000847077
  Current log# 4 seq# 77598 mem# 1: +ARC/FDCDB/ONLINELOG/group_4.260.1000847077
2025-07-31T07:13:55.322692+08:00
Archived Log entry 193845 added for T-1.S-77597 ID 0xeac4c440 LAD:1
2025-07-31T07:28:14.833306+08:00
Thread 1 advanced to log sequence 77599 (LGWR switch)
  Current log# 2 seq# 77599 mem# 0: +DATA/FDCDB/ONLINELOG/group_2.263.1000846993
  Current log# 2 seq# 77599 mem# 1: +ARC/FDCDB/ONLINELOG/group_2.258.1000846993
2025-07-31T07:28:16.360189+08:00
Archived Log entry 193847 added for T-1.S-77598 ID 0xeac4c440 LAD:1
2025-07-31T07:38:33.029246+08:00
LMS1 (ospid: 23514) has detected no messaging activity from instance 2
USER (ospid: 23514) issues an IMR to resolve the situation
Please check USER trace file for more detail.
2025-07-31T07:38:33.035568+08:00
LMS4 (ospid: 23521) has detected no messaging activity from instance 2
2025-07-31T07:38:33.035590+08:00
Communications reconfiguration: instance_number 2 by ospid 23514
2025-07-31T07:38:33.035740+08:00
LMS3 (ospid: 23519) has detected no messaging activity from instance 2
2025-07-31T07:38:33.036206+08:00
LMS0 (ospid: 23512) has detected no messaging activity from instance 2
2025-07-31T07:38:33.043106+08:00
USER (ospid: 23521) issues an IMR to resolve the situation
Please check USER trace file for more detail.
2025-07-31T07:38:33.043264+08:00
USER (ospid: 23519) issues an IMR to resolve the situation
Please check USER trace file for more detail.
2025-07-31T07:38:33.043562+08:00
USER (ospid: 23512) issues an IMR to resolve the situation
Please check USER trace file for more detail.
2025-07-31T07:38:33.047480+08:00
LMS2 (ospid: 23516) has detected no messaging activity from instance 2
USER (ospid: 23516) issues an IMR to resolve the situation
Please check USER trace file for more detail.
2025-07-31T07:38:33.077660+08:00
LMON (ospid: 23508) drops the IMR request from LMS4 (ospid: 23521) because IMR is in progress and inst 2 is marked bad.
LMON (ospid: 23508) drops the IMR request from LMS3 (ospid: 23519) because IMR is in progress and inst 2 is marked bad.
LMON (ospid: 23508) drops the IMR request from LMS0 (ospid: 23512) because IMR is in progress and inst 2 is marked bad.
LMON (ospid: 23508) drops the IMR request from LMS2 (ospid: 23516) because IMR is in progress and inst 2 is marked bad.
2025-07-31T07:39:00.964588+08:00
IPC Send timeout detected. Sender: ospid 41916 [oracle@fdcdb1]
Receiver: inst 2 binc 2 ospid 41888
2025-07-31T07:39:21.290230+08:00
Detected an inconsistent instance membership by instance 1
Evicting instance 2 from cluster
Waiting for instances to leave: 2 
2025-07-31T07:39:21.444234+08:00
IPC Send timeout to 2.3 inc 12 for msg type 65518 from opid 26
2025-07-31T07:39:21.444310+08:00
IPC Send timeout to 2.3 inc 12 for msg type 151 from opid 26
2025-07-31T07:39:21.444366+08:00
IPC Send timeout to 2.3 inc 12 for msg type 73 from opid 26
2025-07-31T07:39:21.444401+08:00
IPC Send timeout to 2.2 inc 12 for msg type 65521 from opid 25

问题原因

根本原因：网络拥塞导致节点2被驱逐，以下是分析过程。

1、lmon分析

节点1 lmon分析

节点1的lmon进程trc文件fdcdb2\_lmon\_14788.trc表明故障原因是网络无法通信。（根据MOS解释kjxgrrcfgchk: Initiating reconfig, reason 3表示网络无法连接。）

*** 2025-07-31T07:38:33.046462+08:00
2025-07-31 07:38:33.046 : kjxgrrcfg: done (device ok) - ret = 3  hist 0x1679a (initial rsn: 3, cachd rsn: 0)
kjxgrrcfgchk: Initiating reconfig, reason=3
kjxgrrcfgchk: COMM rcfg - Disk Vote Required
kjfmReceiverHealthCB_CheckAll: Recievers are healthy.
2025-07-31 07:38:33.046 : kjxgrnetchk: start 0x44281b3b, end 0x4428d185
2025-07-31 07:38:33.046 : kjxgrnetchk: Network Validation wait: 46 sec
kjxgrnetchk: ce-event: from inst 1 to inst 2 ver 0x3cff
kjxgrrcfgchk: prev pstate 6  mapsz 1024
kjxgrrcfgchk: new  bmp: 1 2 
kjxgrrcfgchk: cnct bmp: 1 2 
kjxgrrcfgchk: disc bmp: 
kjxgrrcfgchk: work bmp: 1 2 
kjxgrrcfgchk: rr  bmp: 1 2

image.png

节点2 lmon分析

07:32:52开始知道节点2被驱逐，一直存在网络等待。

2025-07-31 07:29:29.457 : GSIPC:BSEND: last proc to post me: pid 38.14864 in kjc.h LINE:2308 ID:KJCS Post snd proxy to flush msg
2025-07-31 07:29:29.457 : GSIPC:BSEND: deq msg 0x2a5f756e0 type 44 qtm 30049 us seq 0.514174518 from opid 38 to 1.2
2025-07-31 07:29:29.457 : GSIPC:BSEND: last proc to post me: pid 38.14864 in kjc.h LINE:2308 ID:KJCS Post snd proxy to flush msg
IPCLW:[0.913]{E}[WAIT]:PROTO: [1753918372165022]PT DMP_REQ at seq 1292873920 from peer 192.168.2.10:14404

*** 2025-07-31T07:32:52.165931+08:00 IPCLW:[0.914]{-}[WAIT]:UTIL: [1753918372165022] PCNH 0x7f6c64fdcf78 State: 1 MSN: 392301845 Seq: 1292873920 Last Rcv 0:0:0.116.116424 Last valid Rcv 0:0:7.273.273813 IPCLW:[0.915]{-}[WAIT]:UTIL: [1753918372165022] Peer: LMS1.KSMSQ_dlm.23514 AckSeq: 1292873920. # Coalesced: 0 IPCLW:[0.916]{-}[WAIT]:UTIL: [1753918372165022] IVPort: 45836 TVPort: 6284 IMPT: 29019 RMPT: 17464 Ongoing Recv: No, last retrans dmp seq 0 IPCLW:[0.917]{-}[WAIT]:UTIL: [1753918372165022] Flags: 0x00000001 THint: 0x44cab1bf00000226 IHint: 0x705ddeb40000001f IPCLW:[0.918]{-}[WAIT]:UTIL: [1753918372165022] IPCLW State Dump IPCLW:[0.919]{-}[WAIT]:UTIL: [1753918372165022] UDP PORT 0x7f6c6dd93ad8, [LMS1.KSMSQ_dlm] Dump IPCLW:[0.920]{-}[WAIT]:UTIL: [1753918372165022] ID: 0x3b5d2e10 Type: UDP PT Opts: [] Flags: [], Address: 192.168.2.20:9149, MPT: No IPCLW:[0.921]{-}[WAIT]:UTIL: [1753918372165022] Last DataReady time 0:0:0.67.67549 Last Unrel msg rcvd time 487199:32:52.165.165022 IPCLW:[0.922]{-}[WAIT]:UTIL: [1753918372165022] ACNH Dump IPCLW:[0.923]{-}[WAIT]:UTIL: [1753918372165022] PCNH Dump IPCLW:[0.924]{-}[WAIT]:UTIL: [1753918372165022] PCNH 0x7f6c65ff79d8 State: 1 MSN: 2057350729 Seq: 2099703066 Last Rcv 8062:40:44.501.501764 Last valid Rcv 8062:40:44.501.501764 IPCLW:[0.925]{-}[WAIT]:UTIL: [1753918372165022] Peer: LMS1.KSMSQ_dlm.9072 AckSeq: 2099703066. # Coalesced: 0 IPCLW:[0.926]{-}[WAIT]:UTIL: [1753918372165022] IVPort: 45836 TVPort: 60222 IMPT: 29019 RMPT: 10109 Ongoing Recv: No, last retrans dmp seq 0 IPCLW:[0.927]{-}[WAIT]:UTIL: [1753918372165022] Flags: 0x00000000 THint: 0x44cab0510000001f IHint: 0x47d663e50000001f IPCLW:[0.928]{-}[WAIT]:UTIL: [1753918372165022] PCNH 0x7f6c65ff7448 State: 1 MSN: 595742835 Seq: 14107475 Last Rcv 8241:8:1.748.748540 Last valid Rcv

2、lms分析

节点1 lms分析

07:32:51开始，lms进程出现网络相关等待

*** 2025-07-31T07:32:51.968793+08:00
IPCLW:[0.618]{E}[WAIT]:PROTO: [1753918371968513]RETRANS DBG local acnh 0x7f71db3b3ea8 dump:
IPCLW:[0.619]{-}[WAIT]:UTIL: [1753918371968513]  ACNH 0x7f71db3b3ea8 State: 1 MSN: 1776967435 Seq: 461160960 # Pending: 53
IPCLW:[0.620]{-}[WAIT]:UTIL: [1753918371968513]   Peer: LMS0.KSMSQ_dlm.14795 AckSeq: 0
IPCLW:[0.621]{-}[WAIT]:UTIL: [1753918371968513]   Flags: 0x00000000 IHint: 0x64d73e5e0000001f THint: 0x2457a2fa000000fd 
IPCLW:[0.622]{-}[WAIT]:UTIL: [1753918371968513]   Local Address: 192.168.2.10:44600 Remote Address: 192.168.2.20:44440
IPCLW:[0.623]{-}[WAIT]:UTIL: [1753918371968513]   Remote PID: ver 0 flags 1 trans 2 tos 0 opts 0 xdata3 2dd3 xdata2 4fada3f2
IPCLW:[0.624]{-}[WAIT]:UTIL: [1753918371968513]             : mmsz 8472 mmr 9200 mms 2 xdata 1e1dd769
IPCLW:[0.625]{-}[WAIT]:UTIL: [1753918371968513]   IVPort: 26295 TVPort: 55145 IMPT: 14510 RMPT: 11731   Pending Sends: Yes Unacked Sends: Yes 
IPCLW:[0.626]{-}[WAIT]:UTIL: [1753918371968513]   Send Engine Queued: No sshdl -1 ssts 0 rtts 1753918371968771 snderrchk 8 creqcnt 1
IPCLW:[0.627]{-}[WAIT]:UTIL: [1753918371968513]   Unackd Messages 1776967382 -> 1776967434. SSEQ 461160907 Send Time: 0:0:0.210.210159 SMSN # Xmits: 64 EMSN 0:0:0.210.210159
IPCLW:[0.628]{-}[WAIT]:UTIL: [1753918371968513]  Pending send queue: 
IPCLW:[0.629]{-}[WAIT]:UTIL: [1753918371968513]    [0] Mbuf 0x7f71db165af0 MSN 1776967382 Seq 461160907 -> 461160908 # XMits: 64
IPCLW:[0.630]{-}[WAIT]:UTIL: [1753918371968513]    [1] Mbuf 0x7f71d9a7b5f0 MSN 1776967383 Seq 461160908 -> 461160909 # XMits: 64
IPCLW:[0.631]{-}[WAIT]:UTIL: [1753918371968513]    [2] Mbuf 0x7f71db11ba50 MSN 1776967384 Seq 461160909 -> 461160910 # XMits: 63
IPCLW:[0.632]{-}[WAIT]:UTIL: [1753918371968513]    [3] Mbuf 0x7f71db165f10 MSN 1776967385 Seq 461160910 -> 461160911 # XMits: 62
IPCLW:[0.633]{-}[WAIT]:UTIL: [1753918371968513]    [4] Mbuf 0x7f71db40f7f0 MSN 1776967386 Seq 461160911 -> 461160912 # XMits: 62
IPCLW:[0.634]{-}[WAIT]:UTIL: [1753918371968513]    [5] Mbuf 0x7f71db404ed0 MSN 1776967387 Seq 461160912 -> 461160913 # XMits: 61
IPCLW:[0.635]{-}[WAIT]:UTIL: [1753918371968513]    [6] Mbuf 0x7f71db3fd730 MSN 1776967388 Seq 461160913 -> 461160914 # XMits: 60
IPCLW:[0.636]{-}[WAIT]:UTIL: [1753918371968513]    [7] Mbuf 0x7f71db1377d0 MSN 1776967389 Seq 461160914 -> 461160915 # XMits: 60
IPCLW:[0.637]{-}[WAIT]:UTIL: [1753918371968513]    [8] Mbuf 0x7f71db404ab0 MSN 1776967390 Seq 461160915 -> 461160916 # XMits: 59
IPCLW:[0.638]{-}[WAIT]:UTIL: [1753918371968513]    [9] Mbuf 0x7f71db400490 MSN 1776967391 Seq 461160916 -> 461160917 # XMits: 59

节点2 lms分析

07:32:52 出现网络等待

2025-07-31 07:29:29.457 : GSIPC:BSEND: last proc to post me: pid 38.14864 in kjc.h LINE:2308 ID:KJCS Post snd proxy to flush msg
2025-07-31 07:29:29.457 : GSIPC:BSEND: deq msg 0x2a5f756e0 type 44 qtm 30049 us seq 0.514174518 from opid 38 to 1.2
2025-07-31 07:29:29.457 : GSIPC:BSEND: last proc to post me: pid 38.14864 in kjc.h LINE:2308 ID:KJCS Post snd proxy to flush msg
IPCLW:[0.913]{E}[WAIT]:PROTO: [1753918372165022]PT DMP_REQ at seq 1292873920 from peer 192.168.2.10:14404

*** 2025-07-31T07:32:52.165931+08:00 IPCLW:[0.914]{-}[WAIT]:UTIL: [1753918372165022] PCNH 0x7f6c64fdcf78 State: 1 MSN: 392301845 Seq: 1292873920 Last Rcv 0:0:0.116.116424 Last valid Rcv 0:0:7.273.273813 IPCLW:[0.915]{-}[WAIT]:UTIL: [1753918372165022] Peer: LMS1.KSMSQ_dlm.23514 AckSeq: 1292873920. # Coalesced: 0 IPCLW:[0.916]{-}[WAIT]:UTIL: [1753918372165022] IVPort: 45836 TVPort: 6284 IMPT: 29019 RMPT: 17464 Ongoing Recv: No, last retrans dmp seq 0 IPCLW:[0.917]{-}[WAIT]:UTIL: [1753918372165022] Flags: 0x00000001 THint: 0x44cab1bf00000226 IHint: 0x705ddeb40000001f IPCLW:[0.918]{-}[WAIT]:UTIL: [1753918372165022] IPCLW State Dump IPCLW:[0.919]{-}[WAIT]:UTIL: [1753918372165022] UDP PORT 0x7f6c6dd93ad8, [LMS1.KSMSQ_dlm] Dump IPCLW:[0.920]{-}[WAIT]:UTIL: [1753918372165022] ID: 0x3b5d2e10 Type: UDP PT Opts: [] Flags: [], Address: 192.168.2.20:9149, MPT: No IPCLW:[0.921]{-}[WAIT]:UTIL: [1753918372165022] Last DataReady time 0:0:0.67.67549 Last Unrel msg rcvd time 487199:32:52.165.165022 IPCLW:[0.922]{-}[WAIT]:UTIL: [1753918372165022] ACNH Dump IPCLW:[0.923]{-}[WAIT]:UTIL: [1753918372165022] PCNH Dump IPCLW:[0.924]{-}[WAIT]:UTIL: [1753918372165022] PCNH 0x7f6c65ff79d8 State: 1 MSN: 2057350729 Seq: 2099703066 Last Rcv 8062:40:44.501.501764 Last valid Rcv 8062:40:44.501.501764 IPCLW:[0.925]{-}[WAIT]:UTIL: [1753918372165022] Peer: LMS1.KSMSQ_dlm.9072 AckSeq: 2099703066. # Coalesced: 0

3、等待事件分析

故障期间等待事件情况：

07:30:00至07:50:00 数据库存在大量row cache lock和GC等待，这应该是故障引起的。

image.png

对比30号相同时间段，30号没有异常等待事件。

image.png

说明故障期间，私网存在问题。

4、网络分析

客户这边数据库每天07：30都有一波定时任务，并且多套数据库都经过一个交换机，导致私网延迟30s发生了节点驱逐。

image.png

建议定时任务错开事件，避免网络拥塞。

解决方案

客户自行重启了异常节点，故障已自动恢复。

墨天轮从乐知乐享的数据库技术社区蓄势出发，全面升级，提供多类型数据库管理服务。墨天轮数据库管理服务旨在为用户构建信赖可托付的数据库环境，并为数据库厂商提供中立的生态支持。
墨天轮数据库服务官网：https://www.modb.pro/service

MoMoSQL666
关注
Oracle RAC 节点驱逐检查过程与 MySql 的比较
ZaxfSass的博客
09-30 125
Oracle RAC 提供了更丰富的视图和命令来检查节点和集群的状态，而 MySql 则使用了不同的命令和变量来实现相同的功能。不同的数据库系统可能具有不同的节点驱逐检查过程，开发人员需要根据所使用的数据库系统的要求进行相应的操作。在分布式数据库系统中，节点驱逐是一项重要的任务，它涉及从集群中移除一个节点，以确保系统的高可用性和稳定性。本文将比较 Oracle RAC 和 MySql 在节点驱逐检查过程方面的差异，并提供相应的源代码示例。在驱逐节点之前，必须先停止节点上的数据库实例。
Oracle-RAC集群数据库实例相互驱逐问题
sinat_36757755的博客
05-30 1319
用户一套Oracle RAC两节点集群，出现数据库实例相互驱逐问题，集群只能运行一个节点的数据库实例，第二个节点数据库实例加入会导致另一个节点的实例被驱逐。
oracle rac实例驱逐,如果有人问你11g RAC如何实现驱逐与重启，请看这篇文章！
weixin_31785177的博客
04-04 863
rac 在实施过程中已经几乎成为标配了，最近接触了几个rac节点重启的案例，做一个总结与整理。节点驱逐是我们日志工作中经常遇到的一个问题，有时候是节点重起了，有时候是集群重起了，有时候只是数据库实例重启了。当这类问题出现时，首先远程或者跑到客户现场分析故障，总有这样那样的原因，最近抽空在mentalink和google上收集了很多资料，做了如下总结，另外因为涉及的东西太多了，有的地方直接用英语原文...
一次内存资源耗尽+磁盘100%导致的RAC节点驱逐
yejb7456的博客
05-24 2741
节点驱逐
紧急救援！Oracle RAC节点驱逐元凶：私网Packet Reassembles Failed“包重组失败”一招救命
最新发布
Jackyimi的博客
08-02 723
IPC超时引发Oracle RAC节点驱逐？根本元凶是私网Packet Reassembles Failed​！本文深度解析包重组失败如何触发实例崩溃，并给出缓冲区参数调优终极方案，附MOS官方诊断依据+运维命令速查。告别突发宕机，运维必藏！
故障处理：Oracle RAC集群CTSS时钟同步故障案例分析与解决
提供数据库技术支持(系统优化，故障处理，安装升级，数据恢复等）
06-27 1063
Oracle RAC集群CTSS时钟同步故障处理案例 摘要：某6节点Oracle RAC（11.2.0.4）集群出现CTSS时钟同步异常，其中节点3-6无法与参考节点1同步。分析发现节点3的GIPC通信异常导致"Msg NOT meant for this member"等错误。经排查，该问题由操作系统防火墙配置不当引起，调整防火墙规则后问题解决。案例表明，在部署Oracle RAC时需确保各节点间通信端口畅通，特别是CTSS依赖的6200端口。建议生产环境采用NTP而非CTSS进行时间
Oracle RAC集群启动与关闭，涵盖所有版本
热门推荐
IT邦德
03-02 1万+
Oracle的安装高可用RAC安装部署将是提升你个人实力、提升薪酬的重要利器
Oracle RAC 集群启动顺序
LuciferLiu_DBA
08-22 2592
前几天使用脚本在 RockyLinux 9.4 安装 Oracle 11GR2 RAC，安装完之后发现集群无法正常启动，后经过分析发现原来是因为 RHEL9 版本默认安装移除了软件包，需要人为手动安装，在 RHEL8 之前是默认安装的。在分析问题的过程中，顺便对 Oracle RAC 集群启动顺序进行了更深入的了解，下面简单整理了一下，分享给大家一起看看，本文主要是以 11GR2 为例。
Oracle RAC IPC Send timeout detected问题分析处理
听雪楼主
10-10 1170
Oracle RAC IPC Send timeout detected问题分析处理
如何诊断 11.2 集群节点驱逐问题 (文档 ID 1674872.1)
xxjj2003的专栏
02-29 827
如何诊断 11.2 集群节点驱逐问题 (文档 ID 1674872.1) 转到底部 文档内容 用途   适用范围   详细信息   节点驱逐概要   1.0 - 会导致重启的进程
RAC中节点被驱逐的条件
babymouse1212的博客
05-02 1355
转自：http://www.oracleplus.net/arch/1291.html 我这里主要是想讲讲rac中关于node被驱逐进而导致reboot的情况。 首先说说rac中的心跳, 关于oracle clusterware中的心跳有两种，如下： 1. Disk heartbeat (voting device) - IOT 2. Network heartbeat (across t
一次RAC实例驱逐详细分析及解决方案
cipr45348的博客
06-06 3006
一 问题说明 接同事邮件，紧急处理客户extent RAC节点实例驱逐故障分析。我们根据客户提供的日志，结合具体的环境及详细的trace文件进行分析，在尽可能的情况下，给出故障结论，由于故障发生时...
如何诊断RAC数据库上的“IPC Send timeout”问题
flawless_521的专栏
08-18 1478
RAC 数据库上比较常见的一种问题就是“IPC Send timeout”。数据库Alert log中出现了“IPC Send timeout”之后，经常会伴随着ora-29740 或者 "Waiting for clusterware split-brain resolution"等，数据库实例会因此异常终止或者被驱逐出集群。 比如: 实例1的ALERT LOG： Thu Ju
oracle集群断电重启,Oracle10.2.0.4 RAC 2节点集群节点被驱逐导致系统异常重启
weixin_39649660的博客
04-05 384
oracle 10.2.0.4redhat 5.4linuxOCSS.LOG日志：1.正常的节点2[ CSSD]2013-12-03 15:07:52.100 [1258428736] >WARNING: clssnmPollingThread: node rac1 (1) at 50 1.625521e-315artbeat fatal, eviction in 29.240 s...
oel6.3上 oracle RAC 上节点驱逐检查过程。
DATA
04-18 1912
RAC上是vmware vspere的虚拟机上有两个OEL6.3的虚拟机，上面跑的库是11.2.0.4 发现节点2挂掉了 1.检查节点1的alert [root@racnode1 racnode1]# pwd /u01/apps/grid/gridhome/11.2.0/grid/log/racnode1 [root@racnode1 racnode1]# tail -1
oracle rac实例驱逐,Oracle RAC 导致实例驱逐的五大原因
weixin_39854923的博客
04-04 415
转自：http://www.linuxidc.com/Linux/2013-05/84930.htm这篇文档在MOS上看到被翻译成了中文，觉得比较实用，因此贴出来方便别人查阅，后期会尽量多贴一些MOS上的中文技术资料，希望可以帮到别人，同时也算自己学习的一个过程。本文档针对导致实例驱逐的主要问题为DBA提供了一个快速概述。问题1：警报日志显示ora-29740是实例崩溃/驱逐的原因症状：...
关于心跳网络引起的Oracle RAC的节点驱逐（不是实例驱逐）
msdnchina的专栏@JiNan,ShanDong
06-03 2651
关于心跳网络引起的Oracle RAC的节点驱逐（不是实例驱逐）
oracle rac 仲裁盘_【学习笔记】深入研究Oracle RAC节点驱逐的条件和案例
weixin_39605455的博客
12-28 753
天萃荷净Oracle研究中心学习笔记：分享一篇关于Oracle数据库RAC环境中节点间管理的文章，详细介绍了RAC节点驱逐条件和管理方法。本站文章除注明转载外，均为本站原创： 转载自loveOracleо wife & love life —Roger 的Oracle技术博客本文链接地址: 关于oracle rac节点的驱逐我这里主要是想讲讲rac中关于node被驱逐进而导致reboot的...
记录一次RAC节点驱逐的分析
文档搬运工
08-20 1874
RDBMS 12.1.0.1  OS redhat 6.6 X64 。 在晚上10点多发现节点被驱逐了 。两个节点的alert log分别如下： IPC Send timeout detected. Sender: ospid 56076 [oracle@XXXXX01 (QM03)] Receiver: inst 2 binc 4 ospid 32706 Wed Jul 25 22:11...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值