cen19c01（Oracle 19c RAC 单节点）网络与 CRS 故障修复报告

故障时段：2026-08-28 21:00 ～ 23:45（宿主机时钟；VM 内时钟慢 16h，对应 VM 日志 05:00 ～ 07:45）
环境：Windows 11 宿主机 + VMware Workstation，虚拟机 D:\虚拟机\centos_19c_rac单
集群：Oracle 19c GI 单节点（ClusterName: oel-cls），ASM（OCR 组 EXTERNAL 3 盘 + DATA 组 2 盘），数据库 cen19c / 实例 cen19c1
处理人：Claude（SSH 远程接管），用户侧配合 1 次手动开机

阅读指引

你想	读
3 分钟了解发生了什么	§二结论 → §五验证
复盘整件事的来龙去脉	§三排查 → §四修复 → §十时间线
学「日志怎么看、怎么找」	§八日志地图（8.3 路径实录 / 8.5 原文段落）
当手册查	§九报错码速查 / §十一决策树 / §十二命令速查

一、故障现象

虚拟机网络完全不通（宿主机 ping 不通虚拟机，虚拟机无外网）
网络修复后 CRS 起不来：CRS-4535: Cannot communicate with Cluster Ready Services，数据库无法对外服务

二、最终结论（四个叠加根因）

#	根因	性质
1	Windows 更新重装 VMware 虚拟网卡（VMnet1/VMnet8 带 `#2` 后缀），两个虚拟网段对调漂移：NAT 从 `192.168.126.0/24` 变为 `192.168.40.0/24`，仅主机从 `192.168.62.0/24` 变为 `192.168.126.0/24`。虚拟机内静态 IP 与集群记录全部错位	诱因
2	OCR 盘 ocr01 从 vmx 配置中脱落（scsi1:1 直接是 ocr02）。OCR 磁盘组为 EXTERNAL 冗余 3 盘结构，缺一盘整组拒绝 mount（ORA-15042），OCR 不可读	直接原因
3	快照链 CID 失配：vmx 中 scsi1:0（RAC 双节点模板复制残留）错挂系统盘 base vmdk 并以独立磁盘模式长期写入，base 被写脏后 VMware 关机时更新其内容 ID（CID），快照子盘 `cl1-000001.vmdk` 记录的父 CID 与之不匹配 → 开机报「父虚拟磁盘在子虚拟磁盘创建之后被修改过」	连锁坑
4	集群网卡记录过时 + haip↔ASM↔OCR 死锁：GPnP profile 与 OCR 中 public/interconnect 定义仍指向旧网段旧网卡；OCR 打不开时 haip 起不来，ASM 硬依赖 haip，ASM 不起则 +OCR 永远挂不上	深层死锁

三、排查过程（因果链复盘）

本章是因果链概览；每一步的完整命令、日志原文与「怎么找到这条日志」的过程，见 §八（日志地图与排查路径实录）。

3.1 网络层：从「不通」到「网段错位」

宿主机侧取证：

scss 复制代码

ipconfig /all
  → VMnet1(仅主机) = 192.168.126.1/24
  → VMnet8(NAT)    = 192.168.40.1/24
  → 有线网卡断开，宿主机走 Wi-Fi（192.168.31.x）

C:\ProgramData\VMware\vmnetnat.conf   → NAT 网关 192.168.40.2/24
C:\ProgramData\VMware\vmnetdhcp.conf  → NAT DHCP 池 192.168.40.128-254

关键观察：VMnet 网卡名带 #2 后缀 → 虚拟网卡被重装过（Windows 大版本更新典型副作用），子网被重新分配。

虚拟机侧取证（读取 vmx 实锤网卡挂载关系）：

虚拟机网卡	挂载（vmx）	当时配置 IP	该网络真实网段	结果
ens33	NAT (VMnet8)	192.168.126.191	192.168.40.0/24	❌ 错位
ens36	仅主机 (VMnet1)	192.168.40.191	192.168.126.0/24	❌ 错位

两块网卡 IP 正好对调。原因：当初建机时 NAT=126 段、仅主机=62 段（/etc/hosts 中 priv=192.168.62.191、网关写 192.168.126.2 均为佐证），Windows 更新后两个网段漂移，VM 内静态 IP 未动。

3.2 CRS 层：由浅入深的三条故障线

网络修复（IP 对调）后 CRS 仍起不来，排查沿三条线收敛：

线路 A ------ 网卡定义（GPnP profile / OCR）：

csharp 复制代码

alert.log 刷屏：CRS-42216: No interfaces are configured on the local node for
interface definition ens36(:.*)?:192.168.62.0

GPnP profile（$GI_HOME/gpnp/cen19c01/profiles/peer/profile.xml）中记录：

xml 复制代码

<gpnp:Network id="net1" IP="192.168.126.0" Adapter="ens33" Use="public"/>
<gpnp:Network id="net2" IP="192.168.62.0"  Adapter="ens36" Use="asm,cluster_interconnect"/>

两条定义均与实际网卡/网段不符。此时 oifcfg 报 PRIF-10（依赖 OCR），不可用。

线路 B ------ OCR 存储（ASM）：

sql 复制代码

ocrcheck → PROC-26: Insufficient quorum to open OCR devices
ASM alert → ORA-15040/15042: ASM disk "2" is missing from group 2
           ERROR: ALTER DISKGROUP ALL MOUNT（OCR 组 mount 失败）

kfed 读盘头逐一确认（关键一锤）：

设备	dskname	vfstart/vfend	结论
/dev/asm_ocr_1	（缺失）	-	设备不存在！
/dev/asm_ocr_2	OCR_0000	24~32	vote file 在此盘
/dev/asm_ocr_3	OCR_0001	0	MEMBER 正常
/dev/asm_data_1/2	DATA_0000/1	0	DATA 组正常

OCR 组为 KFDGTP_EXTERNAL（EXTERNAL 冗余）------该冗余模式下任一成员盘缺失即整组拒绝 mount。multipath/udev（99-oracle-asmdevices.rules 按 DM_UUID 匹配）中 asm_ocr_1 对应的 WWID 设备不存在 → 回溯 vmx 发现 D:\share_disk\centos19c\share-cen19c-ocr01.vmdk 文件还在磁盘上，但 vmx 里没有挂载条目（scsi1:1 直接是 ocr02）。

线路 C ------ 死锁闭环：

ini 复制代码

crsd 需要 OCR ──→ OCR 在 +OCR 组（需 ASM mount）
ASM 硬依赖 ora.cluster_interconnect.haip（START_DEPENDENCIES=hard(...haip...)）
haip 的配置存于 OCR ──→ OCR 读不了 → haip start 60s 超时 abort（CRS-5818/5017）
                           ↑______________________________________|
                              完美死锁，crsctl modify res -init 亦被拖死

第一次开机 ASM 能起（+OCR 因缺盘 mount 失败但进程在）属侥幸路径；修复盘后第二次启动反而陷入完整死锁。

3.3 开机连环坑（关机挂盘过程中）

现象	原因	处置
vmrun 反复「通信出错」	本机 `C:\ProgramData\VMware\hostd\proxy.xml` 缺失，vmrun IPC 不可用；文件关联启动、SendKeys、AppActivate 均失效	最终由用户在 GUI 手动点开机（一次）
「找不到文件 CentOS 7 64 位-cl1.vmdk」弹窗（文件实际存在）	bash heredoc 追加 vmx 产生 LF 行尾，与原 CRLF 混合，GUI 解析异常	`sed -i 's/\r*$/\r/'` 统一 CRLF 后 GUI 重载即通过
「父虚拟磁盘内容 ID 与子盘不匹配 / 模块 Disk 启动失败」	scsi1:0 错挂 base vmdk 被写脏（vmware.log 见 scsi1:0 numIOs=1344），VMware 关闭写句柄时更新 base CID（`3a92671e`），子盘 parentCID 仍为 `733a397d`	① 定位 base 文件内 CID 文本偏移（559 字节处），`dd conv=notrunc` 等长写回 `733a397d`；② vmx 中 `scsi1:0.present = "FALSE"` 除雷

教训：VM 运行日志中 scsi1:0 的 1344 次 IO 是关键线索------同一物理 vmdk 同时充当快照链父盘和另一 SCSI 设备的独立盘，写入必然污染父盘。此类模板复制残留必须清除。

四、修复动作详录

第 1 步：虚拟机内网卡 IP 对调（网络修复）

bash 复制代码

# ens33 = NAT 出口
cat > /etc/sysconfig/network-scripts/ifcfg-ens33 <<'EOF'
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=yes
IPV6INIT=no
NAME=ens33
UUID=c96bc909-188e-ec64-3a96-6a90982b08ad
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.40.191
PREFIX=24
GATEWAY=192.168.40.2
DNS1=192.168.40.2
DNS2=223.5.5.5
EOF

# ens36 = 仅主机（public，无网关）
cat > /etc/sysconfig/network-scripts/ifcfg-ens36 <<'EOF'
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
IPV6INIT=no
NAME=ens36
DEVICE=ens36
ONBOOT=yes
IPADDR=192.168.126.191
PREFIX=24
EOF

nmcli connection reload && nmcli connection up ens33 && nmcli connection up ens36

第 2 步：挂回 ocr01 磁盘（关机状态，宿主机侧）

vmx 追加（格式对齐既有磁盘块，注意全 CRLF）：

ini 复制代码

scsi1:5.mode = "independent-persistent"
scsi1:5.deviceType = "disk"
scsi1:5.present = "TRUE"
scsi1:5.fileName = "D:\share_disk\centos19c\share-cen19c-ocr01.vmdk"
scsi1:5.redo = ""

开机后 udev 按 DM_UUID 自动恢复 /dev/asm_ocr_1，multipath 名 asm_ocr_1 回归。

第 3 步：修复快照 CID + 禁用 scsi1:0（见 3.3 表格第 3 行）

第 4 步：GPnP profile 改写（gpnptool 离线流程）

第一次尝试将 public 与 interconnect 同置 ens36/126（同卡同段），gipcd 不识别，haip 依旧失败；正确方案为分卡：

bash 复制代码

# 以 root，从原始备份生成编辑副本
sed -i 's|IP="192.168.126.0" Adapter="ens33" Use="public"|IP="192.168.126.0" Adapter="ens36" Use="public"|; \
        s|IP="192.168.62.0" Adapter="ens36" Use="asm,cluster_interconnect"|IP="192.168.40.0" Adapter="ens33" Use="asm,cluster_interconnect"|' \
    /tmp/p_edit2.xml

# grid 用户签名 + 校验
gpnptool sign -p=/tmp/p_edit2.xml -o=/tmp/p_signed2.xml -ovr
gpnptool verify -p=/tmp/p_signed2.xml

# put 失败（gpnpd 已死）→ 走离线覆盖：
crsctl stop has -f
cp /tmp/p_signed2.xml $GI_HOME/gpnp/cen19c01/profiles/peer/profile.xml
chown grid:oinstall ... && chmod 640 ...
crsctl start has

生效定义：

xml 复制代码

<gpnp:Network id="net1" IP="192.168.126.0" Adapter="ens36" Use="public"/>
<gpnp:Network id="net2" IP="192.168.40.0"  Adapter="ens33" Use="asm,cluster_interconnect"/>

HAIP（169.254.x.x 链路本地地址）挂在 interconnect 网卡 ens33 上，单节点自环，不依赖外部网络可达性。

第 5 步：死锁自解（storage agent 路径）

cssd/evmd 随新 profile 转在线后，ora.storage 的 kgfoCheckMountExt 重试循环最终自行拉起 ASM 实例，+OCR（3 盘齐）成功 mount，OCR 恢复可读，crsd 随即转在线。此步骤无需人工干预，等待即完成。

第 6 步：oifcfg 双侧同步（OCR + profile）

csharp 复制代码

oifcfg getif → PRIF-30: Network information in OCR and GPnP profile differs

oifcfg delif -global -force
oifcfg setif -global ens36/192.168.126.0:public
oifcfg setif -global ens33/192.168.40.0:cluster_interconnect,asm

oifcfg getif → 两行定义，警告消失

第 7 步：nodeapps VIP 网卡绑定

ora.net1.network 的 USR_ORA_IF=ens33 仍为旧值，导致 VIP/SCAN/监听/ONS 全链 OFFLINE：

bash 复制代码

srvctl modify nodeapps -node cen19c01 -A 192.168.126.181/255.255.255.0/ens36
srvctl start nodeapps -node cen19c01

第 8 步：重启 HAS 验证全栈自愈

crsctl stop has -f && crsctl start has 后全部资源（含数据库 cen19c1 Open、VIP、SCAN、双监听）自动拉起------证明开机自愈能力恢复，后续直接重启虚拟机不会再瘫。

五、最终验证

vbnet 复制代码

$ crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

$ crsctl stat res -t（摘要）
ora.asm / ora.OCR.dg / ora.DATA.dg      ONLINE ONLINE
ora.cen19c.db                           ONLINE ONLINE  Open
ora.cen19c01.vip / ora.scan1.vip        ONLINE ONLINE
ora.LISTENER.lsnr / LISTENER_SCAN1      ONLINE ONLINE  running
ora.net1.network / ora.ons / cvu / qosmserver   ONLINE

$ ip -4 addr show ens36
    inet 192.168.126.191/24   (public)
    inet 192.168.126.181/24   secondary ens36:1  (VIP)
    inet 192.168.126.180/24   secondary ens36:2  (SCAN)
    （ens33 上：192.168.40.191 + HAIP 169.254.x.x）

宿主机 ping 126.191 / 126.181 / 126.180 → 全部 2/2 回包

六、遗留事项与建议

项	说明	建议
ASMNET1LSNR_ASM / asmnet1 成员 1 OFFLINE	Flex ASM 弹性成员槽位，单节点不影响（DB Open、监听正常）	可不管
guest 内 50G sdb（mpatha）消失	即被禁用的 scsi1:0（模板残留），未进 ASM、非系统盘	无影响，保持禁用
`/etc/hosts` 中 `192.168.62.191 cen19c01-priv`	历史条目，不再使用	可清理（非必须）
interconnect 走 NAT 卡 ens33	单节点 HAIP 自环无影响；若未来扩双节点需重规划	注意
vmx 再改必守规则	纯 CRLF、改前备份、关机状态修改	记牢
Windows 大版本更新后	检查 VMnet 网段是否漂移、VM 磁盘挂载是否完好	更新后例行检查

七、备份文件索引

备份	位置
vmx 修改前原件	`D:\虚拟机\centos_19c_rac单\centos_19c_rac单.vmx.bak-20260828`
GPnP profile 原件	VM 内 `/root/profile.xml.bak-*`
base vmdk CID 原值	`3a92671e`（已改为 `733a397d`，如需回退可 dd 写回）
ifcfg 原件	VM 内 `ifcfg-ens33.bak / ifcfg-ens36.bak`（network-scripts 目录）

八、日志地图与排查路径实录（报错日志怎么看、怎么找）

本机变量对照：GI_HOME=/u01/app/19.3.0/grid，grid 用户 ORACLE_BASE=/u01/app/grid，节点名 cen19c01。

8.1 分层诊断入口：先定层，再翻日志（不要上来就扎进日志海）

CRS 故障的第一条纪律：用状态命令把故障「定层」，再去看对应层的日志，避免在几百 MB 的 trace 里无头苍蝇。

命令	回答的问题	本次结果
`crsctl check crs`	HAS/CSS/EVM/CRS 四层哪层断？	HAS✓ CSS✓ EVM✓ CRS✗ → 问题在 crsd 或其依赖
`crsctl stat res -init -t`	ohasd 层各资源状态（不依赖 OCR，OCR 挂了也能看）	除 crsd 外全 ONLINE → crsd 的依赖链有问题
`crsctl stat res -t`	crsd 层资源（OCR 挂了会直接报错------报错本身就是线索）	报错 → 佐证 OCR 不可用
`ocrcheck`	OCR 可读吗？	`PROC-26 Insufficient quorum` → 存储层问题
`ocrcheck -local`	OLR（本地注册表，纯文件）坏了吗？	正常 → 排除 OLR 嫌疑
`oifcfg getif`	网卡定义、OCR 与 profile 是否一致？	`PRIF-10`（OCR 不可读）/ 后期 `PRIF-30`（双源不一致）

8.2 日志文件地图（本次实际翻过的每一处）

① 集群总日志 alert.log（第一翻找点）

bash 复制代码

/u01/app/grid/diag/crs/cen19c01/crs/trace/alert.log

用法：tail -n 100 + grep 过滤刷屏项。本次抓到的关键行：

csharp 复制代码

[GIPCD] CRS-42216: No interfaces are configured ... ens36(:.*)?:192.168.62.0
        → 网卡定义与实际不符的第一实锤（刷屏错误，先 grep -v 归类再看别的）
[OCRCHECK] CRS-1013: The OCR location in an ASM disk group is inaccessible
        → OCR 打不开的集群侧表现
[ORAROOTAGENT] CRS-5818/CRS-5017: Aborted 'start' for ora.cluster_interconnect.haip
        → haip 起不来的直接记录

② ASM 实例 alert（OCR/磁盘组问题的第二翻找点）

bash 复制代码

/u01/app/grid/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log

本次抓到：

sql 复制代码

ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "2" is missing from group number "2"
ERROR: ALTER DISKGROUP ALL MOUNT /* asm agent call crs */
        → OCR 组缺盘、mount 失败的铁证，直接指向存储

③ GPnP profile（网卡定义的权威文件，不是日志但必查）

bash 复制代码

/u01/app/19.3.0/grid/gpnp/cen19c01/profiles/peer/profile.xml
grep -o '<gpnp:Network [^/]*/>' profile.xml

Use="public/cluster_interconnect/asm" 的定义是 GIPCD 42216 的对照源。

④ ohasd 两个 agent 的 trace（haip/storage 起不来的细查点）

bash 复制代码

/u01/app/grid/diag/crs/cen19c01/crs/trace/ohasd_orarootagent_root.trc   ← root 代理：haip、storage、vip
/u01/app/grid/diag/crs/cen19c01/crs/trace/ohasd_oraagent_grid.trc       ← grid 代理：asm、listener
/u01/app/grid/diag/crs/cen19c01/crs/trace/ocssd.trc                     ← cssd/HAIP 线索

本次三个决定性 grep：

bash 复制代码

# 1) HAIP 是否真的尝试过启动（历史对比法：对比两次开机）
grep -a 'HAIP:  starting' ohasd_orarootagent_root.trc
# 第一次 boot 有：  "HAIP: starting inf 'ens36', suggestedIp '169.254.26.248'"
# 死锁期完全没有此行 → haip 卡在配置读取阶段，根本没走到分配 IP

# 2) storage 卡哪了（credential 循环）
grep -a 'storage' ohasd_orarootagent_root.trc | tail
# 反复刷：clsCredOcrKeyExists: SYSTEM.credentials...ASM.Self... not found
#        Error 4 opening dom root → storage 读不到 OCR 凭据域（因为 OCR 没挂）

# 3) cssd 对 HAIP 网络的抱怨
grep -a 'HAIP' ocssd.trc
# "No HAIP network info configured in GPNP profile, using defaults"

⑤ 老日志目录（注意：本机为空，别扑空后放弃）

bash 复制代码

/u01/app/19.3.0/grid/log/cen19c01/{ohasd,crsd,cssd,...}/     ← 本机被清空过，全程无输出

两套日志体系并存 ：老 $GI_HOME/log/<node>/ 与新 ADR $ORACLE_BASE/diag/crs/<node>/crs/trace/。一套空就换另一套，别在一棵树上吊死。

⑥ 资源启动命令的现场输出（最容易被忽略的日志）

crsctl start res ora.asm -init 重定向到文件------本次死锁期的输出直接给出因果：

sql 复制代码

CRS-2672: Attempting to start 'ora.cluster_interconnect.haip'
CRS-2674: Start of 'ora.cluster_interconnect.haip' failed     ← ASM 是被 haip 拖死的实锤
CRS-4000: Command Start failed

⑦ 系统层（ASM 之下再往下挖）

bash 复制代码

ls -l /dev/asm*                 # 数盘：4/5 → 缺谁一目了然
/sbin/multipath -ll             # WWID→dm→sd 映射，确认哪块盘物理不存在
cat /etc/udev/rules.d/99-oracle-asmdevices.rules   # 按 DM_UUID 反查缺的 WWID
kfed read /dev/asm_ocr_2 | grep -E 'dskname|grptyp|vfstart'   # 直读盘头
dmesg | tail                    # 内核层磁盘/网卡错误（排查文件系统损坏恐慌时用）

⑧ 宿主机侧（VMware 层）

bash 复制代码

vmware.log（VM 目录）           # scsi1:0 numIOs=1344 → base 被写脏的物证
C:\ProgramData\VMware\vmnetnat.conf / vmnetdhcp.conf   # NAT 真实网段/网关/DHCP 池
*.vmx                           # ethernetX/scsiX:Y 挂载关系（一切虚拟拓扑的源头）

8.3 排查路径实录：从症状到根因的日志追踪链

第一轮：网络不通

ini 复制代码

ping 不通 → ipconfig /all（宿主机）
  看到 VMnet 网卡名带 #2 → 「虚拟网卡被重装过」的假设
→ 对照 vmnetnat.conf / vmnetdhcp.conf
  实锤 NAT=40 段、仅主机=126 段，与 VM 内静态 IP 全部错位
→ 读 vmx 确认 ens33=NAT、ens36=仅主机
  两块卡 IP 正好对调 → 修复方向：VM 内 ifcfg 对调
（要点：VM 侧「配置」与宿主机侧「事实」两张表对着看，错位立现）

第二轮：crsd 起不来（三条线收敛）

bash 复制代码

crsctl check crs：只有 CRS✗
→ crsctl stat res -init -t：crsd OFFLINE 其余 ONLINE
→ tail alert.log：42216 刷屏（网卡定义 62 段不存在）────────── 线 A：profile 过时
→ oifcfg getif：PRIF-10 → ocrcheck：quorum 错 ──────────────── 线 B：OCR 存储
→ ASM alert：ORA-15042 缺盘 → ls /dev/asm* 数出 4/5
→ multipath -ll + udev rules：缺 asm_ocr_1 的 WWID
→ vmx：ocr01 根本没挂载（文件在 D:\share_disk\ 好好的）────── 线 B 终点：磁盘脱落

三条线的关系：A 是历史遗留（4 月就在），B 是致命伤（OCR 读不了），先修 B（挂盘）才能解锁一切。

第三轮：挂盘后的开机连环坑

csharp 复制代码

「找不到 cl1.vmdk」弹窗
→ ls 文件明明在 → diff 备份 vmx 只差我追加的 5 行
→ file 命令：CRLF/LF 混合 → 统一 CRLF 解决
（要点：自己改过的东西是第一嫌疑人，diff 备份最快洗清/坐实）

「父磁盘 CID 与子盘 parentCID 不匹配」弹窗
→ 这报错本身就是完整诊断：直接 head -c 4096 两个 vmdk | grep -ao 'CID=...'
→ base: CID=3a92671e ≠ delta: parentCID=733a397d
→ 为什么 base 会变？回看 vmware.log 关机段：scsi1:0 numIOs=1344 且正常 Closing
   → scsi1:0 挂的就是 base 本体 → 写脏 → 关机时 VMware 更新 CID
（要点：报错文案读仔细，「谁在什么之后被修改」已经把方向指好了）

第四轮：haip↔ASM↔OCR 死锁（本次最烧脑）

kotlin 复制代码

新 profile 后 cssd/evmd ONLINE 了，ASM 仍 OFFLINE
→ crsctl start res ora.asm -init 输出重定向：
   "Start of ora.cluster_interconnect.haip failed" → 查 ASM 依赖
→ crsctl stat res ora.asm -init -p | grep START_DEP
   hard(..., ora.cluster_interconnect.haip, ...) → ASM 被 haip 硬依赖
→ haip 死因：orarootagent trc 里 grep 'HAIP: starting' 历史对比
   （正常 boot 有此行、现在没有）+ storage trc 的 credential not found
   → haip 要读 OCR、OCR 要 ASM mount、ASM 要 haip ------ 死锁闭环，三方日志互证
→ crsctl modify res -init 想摘依赖：同样卡死（也被 OCR 拖住）
→ 解法不是绕，而是等/触发 storage agent 的 kgfo 重试自行拉起 ASM
   （07:02 asm_pmon 出现 → +OCR mount → ocrcheck 恢复 → crsd ONLINE，链条雪崩式恢复）

8.4 可复用的日志技巧清单

先定层再翻日志：check crs → init 资源 → 对应层日志，三级跳。
刷屏错误先归类 ：grep -vE 'CRS-42216' 排掉刷屏项，剩下的才是新线索。
历史对比法 ：同一日志文件里 grep 关键行为（如 HAIP: starting），对比故障前后两次开机------「该出现的行没出现」比错误行更有诊断价值。
trace 段落定位 ：grep -an '关键字' file | tail -1 拿行号，再 awk 'NR>=s && NR<=s+40' 取整段上下文，避免只看单行误判。
命令输出也是日志：交互命令（crsctl start/srvctl）的 stdout 重定向存档，报错往往比日志更直接。
双日志体系都查 ：$GI_HOME/log 与 ADR diag 二选一扑空就换另一个。
配置当证据用：vmx、profile.xml、udev rules、hosts 不是日志但常是终审证据，「配置 vs 事实」对照表是最快的定位手法。

8.5 关键日志原文段落（保留时间戳与完整上下文）

① alert.log ------ GIPCD 网卡定义刷屏（每 1~4 秒一条，先归并再分析）

css 复制代码

2026-08-29 05:54:28.226 [GIPCD(3264)]CRS-42216: No interfaces are configured on the local node
  for interface definition ens36(:.*)?:192.168.62.0:
  available interface definitions are
  [ens33(:.*)?:192.168.40.0][ens36(:.*)?:192.168.126.0][ens36:1(:.*)?:169.254.0.0]
  [ens36(:.*)?:[fe80:...]][ens33(:.*)?:[fe80:...]].
（这条信息量极大：左半句=集群期望，右半句=系统实际------两张表直接同框对比，错位一目了然）

② ASM alert ------ OCR 组 mount 失败完整段（注意 DATA 的对照）

vbnet 复制代码

NOTE: client cen19c1:cen19c:oel-cls mounted group 1 (DATA)
NOTE: cache began mount (first) of group DATA 1/0x2E4021B1
NOTE: cache mounting (first) external redundancy group 1/0x2E4021B1 (DATA)
NOTE: cache mounting group 1/0x2E4021B1 (DATA) succeeded
NOTE: cache began mount (first) of group OCR 2/0x2E5021B2
NOTE: cache dismounting (clean) group 2/0x2E5021B2 (OCR)
NOTE: cache ending mount (fail) of group OCR number=2 incarn=0x2e5021b2
ERROR: diskgroup OCR was not mounted
SUCCESS: diskgroup DATA was mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "2" is missing from group number "2"
ERROR: ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:5:3} */
（读法：DATA 成功 ≠ ASM 没问题；OCR 失败才是主线。"disk 2 missing" 的 disk# 是组内编号，
 用 kfdhdb.dskname 对号入座------本例 disk2 = OCR_0002 = /dev/asm_ocr_1 = 缺失的那块）

③ orarootagent_root.trc ------ storage agent 凭据循环（死锁侧写）

yaml 复制代码

2026-08-29 06:45:50.580 : CLSCRED: clsCredDomInitRootDom: Using user given storage context...
2026-08-29 06:45:50.599 : [ora.storage] 9348 Error 4 querying length of attr ASM_DISCOVERY_ADDRESS
2026-08-29 06:45:50.601 : [ora.storage] 9348 Error 4 querying length of attr ASM_STATIC_DISCOVERY_ADDRESS
2026-08-29 06:45:50.616 : CLSCRED: clsCredOcrKeyExists: Obj dom :
   SYSTEM.credentials.domains.root.ASM.Self.e4c6bf09...root not found
2026-08-29 06:45:50.616 : [ora.storage] 9066 Error 4 opening dom root in 0x7fc8b018c980
（同一模式每秒重复 → storage 在等 OCR 凭据域，而凭据在 +OCR 里没 mount ------ 死锁的一只脚）

④ 同文件 ------ HAIP 启动行为的历史对比（第二次开机的「无声胜有声」）

matlab 复制代码

2025-04-20 05:30:34 : HAIP:  starting inf 'ens36', suggestedIp '169.254.26.248', ... ← 有
2026-08-29 05:26:26 : HAIP:  starting inf 'ens36', suggestedIp '169.254.26.248', ... ← 有（当晚首次开机）
（2026-08-29 06:36 之后死锁期：grep 全文再无此行）                                   ← 没了
配合 alert.log：
2026-08-29 06:47:44 [ORAROOTAGENT] CRS-5818: Aborted command 'start' for 'ora.cluster_interconnect.haip'
2026-08-29 06:47:45 [OHASD]        CRS-2757: Command 'Start' timed out waiting for response
2026-08-29 06:47:45 [ORAROOTAGENT] CRS-5017: ... "ora.cluster_interconnect.haip start" encountered error
结论：haip 卡在"读配置"阶段 60 秒超时，从未走到"分配 IP"那一步。

⑤ crsctl start res ora.asm -init 的重定向输出（死锁定案）

sql 复制代码

CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'cen19c01'
CRS-2674: Start of 'ora.cluster_interconnect.haip' on 'cen19c01' failed
CRS-2679: Attempting to clean 'ora.cluster_interconnect.haip' on 'cen19c01'
CRS-2681: Clean of 'ora.cluster_interconnect.haip' on 'cen19c01' succeeded
CRS-4000: Command Start failed, or completed with errors.
（我明确请求 start asm，CRS 却先去 start haip------依赖关系直接暴露在输出里）

⑥ oifcfg getif ------ 双源不一致的原文

csharp 复制代码

ens36  192.168.126.0  global  public
ens33  192.168.40.0   global  cluster_interconnect,asm        ← GPnP profile（我已改）
Only in OCR: ens33  192.168.126.0  global  public             ← OCR 残留旧值
Only in OCR: ens36  192.168.62.0   global  cluster_interconnect,asm
PRIF-30: Network information in OCR and GPnP profile differs  ← 明示两处都要改

⑦ ocssd.trc ------ 一条沉睡四个月才发挥价值的日志

vbnet 复制代码

gipchaInternalReadGpnp: No HAIP network info configured in GPNP profile, using defaults, ret gipcretFail (1)
（2025-04-20 与 2026-08-29 两次开机都有------说明 HAIP 配置从不依赖 profile 的 net2 网段，
 真正的家当在 OCR 的 SYSTEM.haip 命名空间。这正是死锁期"haip 不动"的底层解释）

⑧ gpnptool 语法坑（工具会自答）

typescript 复制代码

$ gpnptool sign -pfile=xxx        → Error: unknown switch "-pfile=..."
$ gpnptool sign -help              → Error: unknown switch "-help"
$ gpnptool sign -?                 → 打印完整用法：-p= / -o= / -ovr
（Oracle 小工具的 help 开关经常不是 -help，报 unknown switch 时改试 -?）

九、报错码速查表（本次全部出场）

报错码	含义	本次出现场景	看到后该查
CRS-4638/4529/4533/4537	HAS/CSS/EVM/CRS 各自在线	check crs 的正常回显	4535 才是异常
CRS-4535	无法与 CRS 通信	crsd 没起（贯穿全程）	stat res -init 找 crsd 依赖
CRS-4530/4534	CSS/EVM 通信失败	栈更深未起（第二次开机早期）	先等/查 ohasd 拉起顺序
CRS-42216	集群接口定义与实际网卡不符	GIPCD 持续刷屏	profile.xml ↔ ip addr 对照
PRIF-10	oifcfg 初始化集群注册表失败	OCR 不可读期间 oifcfg 全废	先修 OCR 再回来
PRIF-30	OCR 与 profile 网络信息不一致	profile 手改后、OCR 未同步	delif/setif 双侧统一
PROT-602 / PROC-26	OCR 物理存储访问失败（quorum 不足）	ocrcheck 全程报	ASM → DG mount → 数盘
ORA-15032/15040/15042	DG 变更未全执行/组不完整/缺盘 N	ASM mount OCR 组失败	kfed 定位 disk N 是谁
CRS-1013	ASM DG 中的 OCR 位置不可访问	alert.log 里 OCRCHECK 记录	同 PROC-26 链路
CRS-2672/2674	尝试启动/启动失败（资源名即线索）	start asm 触发 start haip 失败	失败资源的依赖与日志
CRS-2757	start 等资源响应超时	haip 卡 60s 被 ohasd 判超时	agent trc 的 CLSN 段
CRS-5818	资源 start 被中止	同上的另一面	同上
CRS-5017 / CLSN00107	资源脚本执行出错/详情在 trc	haip、storage 反复出错	按提示去指定 trc 找段落
CRS-4000	命令失败（总结码）	start asm 收尾	无信息量，看前面行
CRS-4123/4133	HAS 已启动/已停止	stop/start has 正常回显	---
CLSCRED1079	OCR 凭据域键不存在	storage 循环报	OCR 是否 mount
CLSGPNP_NO_DAEMON	gpnpd 未运行	gpnptool put 失败	停 HAS 走离线覆盖 profile
ORA-01081	实例已在运行无法再 startup	手动 sqlplus 撞上 storage 已拉起 ASM	直接利用现状继续
ORA-00911/SP2-0158	自己脚本的语法错（sqlplus 转义）	v$ 转义失败两次	修自己的命令，别怀疑系统

十、完整事件时间线（宿主机时钟；VM 内时钟慢 16 小时，对照见括号）

坑：VM 系统时钟与宿主机差 16h，VM 日志时间戳全部需 +16h 换算。对照锚点：VM 06:29 开机 = 宿主机 22:29。

时刻(宿主机)	事件	证据来源
~21:20	VM 当晚首次开机（旧 vmx，缺 ocr01）	vmware-0.log
21:2x	用户报「网络不通」；宿主机侧 ipconfig/VMware conf 取证，定位网段漂移	ipconfig、vmnetdhcp.conf
21:3x	VM 内 ifcfg 两卡 IP 对调，网络恢复（126.191 可 ping）	用户执行，回包确认
21:4x-21:5x	SSH 接管（VM 内 05:53）；CRS 诊断启动：check crs=4535	crsctl 输出
21:5x (05:54)	alert.log 确认 GIPCD 42216；ocrcheck quorum；GPnP profile 读取	alert.log
22:0x (06:0x)	ASM alert ORA-15042 → kfed/multipath/udev → 锁定 asm_ocr_1 设备不存在 → vmx 无 ocr01 挂载；VMDK 文件在共享目录找到	各命令输出
22:01	vmx 备份 + 追加 scsi1:5（当时埋下 LF 行尾小坑）	bak 文件 mtime
22:02	VM shutdown（vmware.log 正常关闭记录，scsi1:0 最后 IO 统计）	vmware.log
22:03-22:15	开机通道连环失败：vmrun 通信出错 / 文件关联无效 / vmware-vmx 直启退出 / SendKeys 失灵	各次尝试输出
22:16	用户手动点开机 → 弹「找不到 cl1.vmdk」→ 定位 vmx 混合行尾 → 统一 CRLF	弹窗 + file 命令
22:2x	再点开机 → 弹「父磁盘 CID 不匹配」→ dd 改回 base CID=733a397d + 禁用 scsi1:0	vmdk 头 grep
22:29 (06:29)	VM 开机成功，asm_ocr_1 回归（5/5 盘齐）	/dev/asm*
22:3x (06:33)	profile 第一次手术：net1/net2 同卡同段 → put 失败（gpnpd 已死）→ 停 HAS 离线覆盖 → start has	profile.xml.bak-0633
22:35-22:48 (06:35-06:48)	cssd/evmd 上线但 haip 反复 abort（06:47 asmstart.log 暴露 haip 依赖）、storage 凭据循环 → 死锁识别（modify -init 亦卡死 RC=124）	agent trc、CRS-5818
22:5x (06:5x)	profile 第二次手术：interconnect 分卡到 ens33/40 → 重启 HAS；cssd 稳定在线	p_signed2.xml
22:5x-23:0x (06:5x-07:0x)	ocrcheck -local 排除 OLR；kfed 全家福确认组结构完好	kfed、ocrcheck -local
23:02 (07:02)	storage agent 重试循环自行拉起 ASM；手动 sqlplus 撞 ORA-01081 反向确认	asm_pmon 出现
23:0x	+OCR mount 成功，ocrcheck 恢复，crsd ONLINE ------ 死锁雪崩式解开	ocrcheck
23:1x	oifcfg delif/setif 双侧同步（PRIF-30 消失）	getif
23:2x	重启 HAS 验证自愈：DB cen19c1 Open；发现 net1.network USR_ORA_IF=ens33 旧绑定	stat res -t
23:3x	srvctl modify nodeapps -A .../ens36 → VIP .181 / SCAN .180 / 双监听全部 ONLINE	资源树、ip addr
23:4x	宿主机 ping 三个地址全通；重启 HAS 二次自愈确认；收尾归档	ping 2/2

十一、排障决策树（本次走通的路径通用化）

bash 复制代码

CRS 起不来
│
├─ crsctl check crs 定层
│   ├─ HAS 不在线 → ohasd.bin / init.ohasd / OHASD 启动脚本（本次未涉及）
│   ├─ CSS 不在线 → vote disk 问题：kfed 看 vfstart、multipath/udev 数盘（本次第二次开机短暂出现）
│   └─ CRS 不在线（本次主线）
│       │
│       ├─ ocrcheck
│       │   ├─ 失败（本次 PROC-26 quorum）
│       │   │   ├─ ASM 实例不在？
│       │   │   │   ├─ 查依赖：stat res ora.asm -init -p 的 START_DEPENDENCIES
│       │   │   │   ├─ 依赖项（haip）自身起不来？
│       │   │   │   │   └─ 三角互证：haip需要OCR配置 / OCR需要ASM / ASM需要haip
│       │   │   │   │       → 识别死锁 → 解法：让 storage agent 的 kgfo 重试拉起 ASM
│       │   │   │   │         （或手动 sqlplus startup；modify -init 此局不可用）
│       │   │   │   └─ 磁盘不可见？→ ls /dev/asm* → multipath -ll → udev rules → vmx 挂载
│       │   │   └─ ASM 在但 DG mount 失败（本次首夜 ORA-15042）
│       │   │       └─ 数盘定位缺失成员 → kfdhdb.dskname 对号 → 物理找回或重建
│       │   └─ 成功 → 查 crsd 自身日志/凭据（本次未涉及）
│       │
│       └─ crsd 在线但 VIP/监听 OFFLINE（本次收尾阶段）
│           └─ stat res ora.net1.network -f 看 USR_ORA_IF 是否旧网卡
│               → srvctl modify nodeapps -A <vip>/<mask>/<新网卡>
│
└─ 配置对照法贯穿始终：vmx ↔ 实际磁盘 / profile ↔ ip addr / OCR ↔ profile / hosts ↔ 网段

十二、关键命令速查（本次高频使用）

bash 复制代码

# 集群栈分层诊断
crsctl check crs
crsctl stat res -init -t          # ohasd 层（不依赖 OCR）
crsctl stat res -t                # crsd 层（含 DB/VIP/SCAN）
ocrcheck / ocrcheck -local
oifcfg getif                       # OCR vs profile 一致性（PRIF-30）

# ASM 直读盘头（绕过实例）
kfed read /dev/asm_ocr_1 | grep -E 'dskname|grpname|grptyp|vfstart|vfend'

# GPnP profile 手术
gpnptool sign -p=in.xml -o=out.xml -ovr
gpnptool verify -p=out.xml
gpnptool put -p=out.xml            # gpnpd 存活时；否则停 HAS 后直接覆盖文件

# 网卡/VIP 绑定
srvctl modify nodeapps -node <node> -A <vip>/<mask>/<ifname>
srvctl start nodeapps

报告完 · 2026-08-29*