RAC 數據庫上比較常見的一種問題就是“IPC Send timeout”。數據庫Alert log中出現了“IPC Send timeout”之後，經常會伴隨着ora-29740 或者 "Waiting for clusterware split-brain resolution"等，數據庫實例會因此異常終止或者被驅逐出集羣。
比如:
實例1的ALERT LOG：
Thu Jul 02 05:24:50 2012
IPC Send timeout detected.Sender: ospid 6143755<==發送者
Receiver: inst 2 binc 1323620776 ospid 49715160<==接收者
Thu Jul 02 05:24:51 2012
IPC Send timeout to 1.7 inc 120 for msg type 65516 from opid 13
Thu Jul 02 05:24:51 2012
Communications reconfiguration: instance_number 2
Waiting for clusterware split-brain resolution <==出現腦裂
Thu Jul 02 05:24:51 2012
Trace dumping is performing id=[cdmp_20120702052451]
Thu Jul 02 05:34:51 2012
Evicting instance 2 from cluster <==過了10分鐘，實例2被驅逐出集羣
實例2的ALERT LOG：
Thu Jul 02 05:24:50 2012
IPC Send timeout detected. Receiver ospid 49715160 <==接收者
Thu Jul 02 05:24:50 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lms6_49715160.trc:
Thu Jul 02 05:24:51 2012
Waiting for clusterware split-brain resolution
Thu Jul 02 05:24:51 2012
Trace dumping is performing id=[cdmp_20120702052451]
Thu Jul 02 05:35:02 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lmon_6257780.trc:
ORA-29740: evicted by member 0, group incarnation 122 <==實例2出現ORA-29740錯誤，並被驅逐出集羣
Thu Jul 02 05:35:02 2012
LMON: terminating instance due to error 29740
Thu Jul 02 05:35:02 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lms7_49453031.trc:
ORA-29740: evicted by member , group incarnation
在RAC實例間主要的通訊進程有LMON, LMD, LMS等進程。正常來說，當一個消息被髮送給其它實例之後，發送者期望接收者會回覆一個確認消息，但是如果這個確認消息沒有在指定的時間內收到（默認300秒），發送者就會認爲消息沒有達到接收者，於是會出現“IPC Send timeout”問題。
這種問題通常有以下幾種可能性：
1. 網絡問題造成丟包或者通訊異常。
2. 由於主機資源(CPU、內存、I/O等）問題造成這些進程無法被調度或者這些進程無響應。
3. Oracle Bug.
在這方面的Oracle Bug不是太多，大多數時候都是網絡或者資源問題造成這種情況。
爲了分析這種問題，網絡和資源監控工具是非常必要的。推薦安裝OSWBB，對於如何安裝和使用OSWBB，請參考文章利器OSW (OSWatcher
Black Box) 之簡介篇。
下面是一個由於主機資源緊張造成的“IPC Send timeout”例子：
實例1的Alert log中顯示接收者是2號機的進程1596935，
Fri Aug 01 02:04:29 2008
IPC Send timeout detected.Sender: ospid 1506825 <==發送者
Receiver: inst 2 binc -298848812 ospid 1596935 <==接收者
查看當時2號機的OSWatcher的vmstat輸出：
zzz ***Fri Aug 01 02:01:51 CST 2008
System Configuration: lcpu=32 mem=128000MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
25 1 7532667 19073986 0 0 0 0 5 0 9328 88121 20430 32 10 47 11
58 0 7541201 19065392 0 0 0 0 0 0 11307 177425 10440 87 13 0 0 <==idle的CPU爲0，說明CPU100%被使用
61 1 7552592 19053910 0 0 0 0 0 0 11122 206738 10970 85 15 0 0
zzz ***Fri Aug 01 02:03:52 CST 2008
System Configuration: lcpu=32 mem=128000MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
25 1 7733673 18878037 0 0 0 0 5 0 9328 88123 20429 32 10 47 11
81 0 7737034 18874601 0 0 0 0 0 0 9081 209529 14509 87 13 0 0 <==CPU的run queue非常高
80 0 7736142 18875418 0 0 0 0 0 0 9765 156708 14997 91 9 0 0 <==idle的CPU爲0，說明CPU100%被使用
上面這個例子說明當主機CPU負載非常高的時候，接收進程無法響應發送者，從而引發了“IPC Send timeout”。
下面是一個由於網絡問題造成的“IPC Send timeout”例子：
實例1的Alert log中顯示接收者是2號機的進程49715160，
Thu Jul 02 05:24:50 2012
IPC Send timeout detected.Sender: ospid 6143755 <==發送者
Receiver: inst 2 binc 1323620776 ospid 49715160 <==接收者
查看當時2號機的OSWatcher的vmstat輸出，沒有發現CPU和內存緊張的問題，查看OSWatcher的netstat輸出，在發生問題前幾分鐘，私網的網卡上有大量的網絡包傳輸。
Node2:
zzz Thu Jul 02 05:12:38 CDT 2012
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 10.182.3 10.182.3.2 4073847798 0 512851119 0 0 <==4073847798 - 4073692530 = 155268 個包/30秒
zzz Thu Jul 02 05:13:08 CDT 2012
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 10.182.3 10.182.3.2 4074082951 0 513107924 0 0 <==4074082951 - 4073847798 = 235153 個包/30秒
Node1:
zzz Thu Jul 02 05:12:54 CDT 2012
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 10.182.3 10.182.3.1 502159550 0 4079190700 0 0 <==502159550 - 501938658 = 220892 個包/30秒
zzz Thu Jul 02 05:13:25 CDT 2012
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 10.182.3 10.182.3.1 502321317 0 4079342048 0 0 <==502321317 - 502159550 = 161767 個包/30秒
查看這個系統正常的時候，大概每30秒傳輸幾千個包：
zzz Thu Jul 02 04:14:09 CDT 2012
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 10.182.3 10.182.3.2 4074126796 0 513149195 0 0 <==4074126796 - 4074122374 = 4422個包/30秒
這種突然的大量的網絡傳輸可能會引發網絡傳輸異常。對於這種情況，需要聯繫網管對網絡進行檢查。在某些案例中，重啓私網交換機或者調換了交換機後問題不再發生。（請注意，網絡的正常的傳輸量會根據硬件和業務的不同而不同。）
下面是一個由於I/O問題造成的“IPC Send timeout”例子：
實例的Alert log中顯示接收者是1號機的LMON進程：
Sun Feb 22 07:57:30 2014
IPC Send timeout detected. Receiver ospid 44105801 [oracle@db1 (LMON)] <========================接收者
查看這個進程生成的trace文件db1_lmon_44105801.trc，發現當時LMON的函數都是和IO有關的：
kjxgmpoll: stalled for 94 seconds (threshold 42 sec)
----- Call Stack Trace -----
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
<- ksdxfdmp <- ksdxcb <- sspuser <- 48bc <- sigthreadmask
<- sslsstehdlr <- sslsshandler <- 48bc <- skgfsio <- skgfqio
<- ksfd_skgfqio <- ksfd_io <- ksfdread <- kfk_ufs_sync_io <- kfk_submit_ufs_io
<- kfk_submit_io <- kfk_io1 <- kfkRequest <- kfk_transitIO <- kfioSubmitIO
<- kfioRequestPriv <- kfioRequest <- ksfd_kfioRequest <- 576 <- ksfd_osmio
<- ksfd_io <- ksfdread <- kccrbp <- kccgrd <- kjxgrf_rr_read
<- kjxgrDD_rr_read <- kjxgrimember <- kjxggpoll <- kjfmact <- kjfdact
<- kjfcln <- ksbrdp <- opirip <- opidrv <- sou2o
<- opimai_real <- ssthrdmain <- main <- start
總結一下，對於“IPC Send timeout”：
1) 通過Oracle自帶的CHM (Cluster Health Monitor)的輸出來檢查當時的資源、網絡使用情況。CHM只在某些平臺和版本上存在，關於CHM，請參考文章11gR2
新特性：Oracle Cluster Health Monitor(CHM)簡介。
2) 如果沒有CHM，請安裝OSWBB來監控網絡和主機資源。
3) 檢查網絡上是否有UDP或者IP包丟失的情況、網絡上是否有錯誤。
4) 檢查所有節點的網絡設置是否正確。比如，所有節點MTU的設置必須是一致的，如果Jumbo Frame被使用的話，需要保證交換機可以支持MTU爲9000.
5) 檢查服務器是否有CPU使用率高或者內存不足的情況。
6) 檢查實例被驅逐之前是否有數據庫hang或者嚴重的性能問題。
在下面的MOS文檔中有針對“IPC Send timeout”的介紹：
Top 5 issues for Instance Eviction (Doc ID 1374110.1)