小亦平台会持续给大家科普一些Oracle数据库的应急处理方案，运维朋友们可以在应急处理方案专栏查看更多案例。
问题概述
- 核心问题： 监控日志中出现 IPC SEND Timeout 错误。
- 主要现象： RAC 集群监控日志中报告了 Inter-Process Communication (IPC) 发送超时错误。
问题分析
IPC SEND Timeout 错误通常表明 Oracle RAC 集群中节点间进程通信（IPC）出现了问题。IPC 是 RAC 节点间进行缓存融合（Cache Fusion）和状态同步的关键机制。当某个节点无法在预期时间内通过 IPC 通道（通常基于高速网络和底层操作系统 IPC 机制）成功发送消息到另一个节点时，就会产生此错误。这通常意味着：
- 网络问题： 节点间的私有网络（通常用于 Cache Fusion）出现延迟、丢包或中断。
- 节点负载过高： 某个节点 CPU 资源耗尽或系统负载极高，导致无法及时处理 IPC 消息。
- 操作系统或集群软件问题： 操作系统 IPC 资源耗尽、bug，或者 Oracle Clusterware (CRS) 自身出现问题。
- 硬件问题： 网络硬件（网卡、交换机）或服务器硬件故障。
这种错误可能导致节点间同步失败，严重时可触发节点驱逐（Node Eviction），影响数据库的可用性和性能。
解决方案
- 数据库各资源服务情况。
crsctl status res --t确认所有资源正常：
TARGET栏和STATE栏显示状态相同；
ASM的服务两个都是Started，DB的两个服务都是open
- 确认各节点数据库都已不响应。
检查当前数据库状态是否是OPEN
su - oracle
$ sqlplus / as sysdba
SQL> select status from v$instance; [正常为open]
查看是否有报错信息或异常提示信息；
su - oracle
$ sqlplus / as sysdba
SQL> show parameter background_dump_dest [查询alert日志路径]
$ cd /u01/app/oracle/diag/rdbms/orcl/orcl1/trace
$ tail -100f alert*.log [检查alert日志中是否存在报错信息，比如Ora-开头的报错信息]
检查当前数据库是否存在活动会话；
su - oracle
$ sqlplus / as sysdba
SQL> select status,count(*) from v$session group by status;
手动切换redo日志，查看数据库alert是否有反应。
su - oracle
$ tail -100f alert*.log [动态打开数据库alert日志]
$ sqlplus / as sysdba
SQL> alter system switch logfile;
[正常情况下，alert日志会有如下信息]
看是否能正常结束并在alert日志中写入相关信息
以上均无返回错误信息，确认数据库状态正常
- 查看数据库alert日志 , 确认CRS是否自身已经发动了节点重启。如果没有自动重启，按如下顺序进行：停节点2数据库实例、停节点2 ASM实例、启动节点2 ASM实例、启动节点2数据库实例，停节点1数据库实例、停节点1 ASM实例, 启动节点1数据库实例、启动节点1 ASM实例,完成重启服务
su - oracle
sqlplus / as sysdba
show parameter background_dump_dest [根据输出找到alert文件路径]
$ cd 日志路径
$ tail -100f alert*.log
1>停止实例
srvctl stop instance -d <数据库名> -i <实例名> -o immediate
2>停止crs进程
root用户下执行
crsctl stop crs
验证步骤：
crs_stat --t确认已关闭(11g使用crsctl status res --t)
ps --ef | grep ora_确认无返回Oracle核心进程
查看alert日志确认正常关闭
Ipcs --a确认共享段已释放
1>收集HANG trace信息
$ sqlplus /nolog
connect / as sysdba
oradebug setmypid
oradebug unlimit
oradebug hanganalyze 3
！！人工等待60s（原来为执行一存储过程，但数据库HANG时无法执行该过程）
oradebug hanganalyze 3
oradebug tracefile_name --得到trace文件名
exit
2>对未导出堆栈信息的进程从操作系统收集堆栈信息
grep -in "timed out; stack" trc文件，返回例如：
odspddb2_ora_1020648.trc:259447: Short stack dump: ... timed out; stack dump taking longer than 30000 ms
odspddb2_ora_1020648.trc:263447: Short stack dump: ... timed out; stack dump taking longer than 30000 ms
head -270000 odspddb2_ora_1020648.trc | tail -10000> /tmp/trc.log
打开该临时文件，搜索timed out，找到所在的进程号
OSD pid info: Unix process pid: 840048, image: oracleodspddb2@BJ1ODSDB02
*** 2011-01-12 11:30:17.376
Short stack dump: ... timed out; stack dump taking longer than 30000 ms
ps -ef | grep <pid>确认进程是oracle后台关键进程还是普通连接进程
AIX使用：
truss -aef -p <进程号> >output.txt
等待30秒后，可使用ctrl+c终止
procstack <进程号>
HP使用：
tusc -aef -T "%H:%M:%S" -p <进程号> >output.txt
等待30秒后，可使用ctrl+c终止
pstack <tnslsnr进程号>
3>收集systemstat trace信息
新开登录窗口，新生成trc文件，避免累积生成的trc文件太大，也有利于并行收集
$ sqlplus /nolog
connect / as sysdba
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 266
！！人工等待60s（原来为执行一存储过程，但数据库HANG时无法执行该过程）
oradebug dump systemstate 266
oradebug tracefile_name
--得到trace文件名
Exit
操作步骤：在grid用户下
Sqlplus "/ as sysadba"执行shutdown abort
验证步骤：
Ps --ef | grep asm确认相关进程已消失
操作步骤：在grid用户下
Sqlplus "/ as sysadba"执行startup
验证步骤：
Ps --ef | grep asm确认相关进程已启动
- 确认数据库状态正常，通知应用
检查当前数据库状态是否是OPEN
su - oracle
$ sqlplus / as sysdba
SQL> select status from v$instance; [正常为open]
查看是否有报错信息或异常提示信息；
su - oracle
$ sqlplus / as sysdba
SQL> show parameter background_dump_dest [查询alert日志路径]
$ cd /u01/app/oracle/diag/rdbms/orcl/orcl1/trace
$ tail -100f alert*.log [检查alert日志中是否存在报错信息，比如Ora-开头的报错信息]
检查当前数据库是否存在活动会话；
su - oracle
$ sqlplus / as sysdba
SQL> select status,count(*) from v$session group by status;
手动切换redo日志，查看数据库alert是否有反应。
su - oracle
$ tail -100f alert*.log [动态打开数据库alert日志]
$ sqlplus / as sysdba
SQL> alter system switch logfile;
[正常情况下，alert日志会有如下信息]
看是否能正常结束并在alert日志中写入相关信息
以上均无返回错误信息，确认数据库状态正常
- 应急救治结束
点击即刻前往小亦知识库查看应急预案完整版：www.ces-xiaoyi.com.cn/#/welcome/k…
运维工作中遇到难题？立即提交工单：www.ces-xiaoyi.com.cn/#/workOrder… 小亦平台工程师火速响应，助您快速修复故障!
