oracle的节点2无法启动asm实例 提示PMON terminating the instance due to error 481

节点2集群无法启动，检查集群状态

crsctl stat res -t -init
ps -ef|grep d.bin

发现cssd正常，asm没有启动、crsd没有启动，手工启动asm

sqlplus / as sysasm
startup

2分钟后看到asm的告警日志如下

rac环境主机重启，数据库实例1正常启动，但是节点2启动asm无法启动被PMON终止提示error 481

通常是rac之间的haip有问题，看trc文件中有kjzdattdlm: Can not attach to DLM (LMON up=TRUE, DB mounted=FALSE).信息

大致意思是：内核函数 kjzdattdlm 无法挂载绑定 DLM 分布式锁管理器；本地 LMON 进程已就绪，但 ASM 磁盘组未挂载。

启动过程是

1. ASM 实例启动 → 拉起 SMON/RBAL/GMON/LMON 等所有后台进程（LMON 正常启动，标记 LMON up=TRUE）；
2. LMON 尝试初始化 DLM 分布式锁模块，DLM 运行依赖**OCR/Voting 磁盘组挂载完成**；
3. 跨节点 GIPC/GPNP 通信报错，ASM 无法完成集群磁盘组挂载，DB mounted=FALSE；
4. DLM 初始化失败抛出`kjzdattdlm`告警；
5. PMON 检测到集群锁管理器 DLM 致命初始化异常，触发 `terminating the instance due to error 481`，强制关闭 ASM 实例。

目标指向跨节点通信失败，检查专用网络是否ping通。

1、os层面网卡、网络配置、路由、网络交换机等出现问题；

2、iptable、selinux等出现异常；

3、两个节点gipc至少有一个进程存在异常；

如果正常那么就可能与gpnp有关

网格即插即用（Grid Plug and Play，GPnP）是Oracle 11gR2 RAC提供的新组件，该组件的功能由gpnpd.bin守护进程实现。GPnP主要由GPNPD、mDNS、SCAN和GNS组成。mDNS（Multicast Domain Name Service）负责在节点内部进行IP的解析。GPNPD服务提供的是集群配置信息管理，记录在GPnP profile。

GPnP profile存储了整个集群的配置信息，它是一个XML文件，该文件中包括了集群名称、网络类型（public/private）、ASM和CSS的存储信息、数字签名，以及ASM实例的SPFILE文件位置等。在集群中，CSS、GPnP等服务的启动都依赖于GPnP profile文件。

文件位于$GRID_HOME/gpnp/$HOSTNAME/profiles/peer/profile.xml
只能通过gpnptool编辑。

检查通信是否正常可以用find命令

或者像广播一样找一个集群

gpnptool find -c=zhcx-cluster

如果有人修改了profile.xml，那么需要检查一下各项配置是否正确

[grid@db01 ~]$ cd $GRID_HOME/gpnp/`hostname`/profiles/peer
[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -prf_cn
orcl-cluster

[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -net
net1 net2

[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -net1:net_ip -net1:net_use -net1:net_ada
192.168.218.0
public
ens33

[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -net2:net_ip -net2:net_use -net2:net_ada
10.0.0.0
asm,cluster_interconnect
ens34

[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -asm_dis
/dev/asmdisk/*

[grid@db01 peer]$ gpnptool getpval -o- -p=profile.xml -asm_spf
+OCR/orcl-cluster/ASMPARAMETERFILE/registry.253.1231616177

如果配置正常，有可能需要kill 一下gipcd这个进程，让它重新识别一下试试

如果还不行就看看asm中到底使用哪个IP进行专用网通信

#11g
grep -C 2 "cluster interconnect IPC" alert_+ASM1.log|more
#19c
grep -C 1 GPnP alert_+ASM1.log |more

正常的应该是169.154.0.0 专用网络ip，异常的情况使用10.4.18.0这个管理ip

那就需要检查网卡是否存在异常了

在19c中正常情况应该是下面的样子

通过ocssd.trc可以观察到gpnp异常信息

或者结合gpnpd.trc、 gipcd.trc查看

grep rank gipcd.trc|more

如果这里显示rank 0 说明异常，rank 99 说明gipc通信正常。

可能需要重启整个集群、或重启网卡。

检查硬件故障

# 查看异常
dmesg -T | grep -iE "error|fail|fault|warning|timeout|reset|hardware"

# 只看本次启动的错误级日志
journalctl -b -p err

# 查看上次启动的日志（用于排查重启前的问题）
journalctl -b -1 -p err

# 在系统日志中搜索错误
grep -iE "error|fail|critical" /var/log/messages 或syslog

# 实时跟踪内核日志的新增内容
tail -f /var/log/kern.log

smartctl -H /dev/sda 

参考

https://blogs.oracle.com/database4cn/redundant-interconnect-with-highly-available-ip-haip/
https://blogs.oracle.com/database4cn/11gr2-gi/