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 次手动开机

阅读指引

一、故障现象

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

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

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

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

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

宿主机侧取证：

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 实锤网卡挂载关系）：

两块网卡 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）：

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）中记录：

<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）：

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 读盘头逐一确认（关键一锤）：

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 —— 死锁闭环：

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 开机连环坑（关机挂盘过程中）

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

四、修复动作详录

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

# 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）：

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 依旧失败；正确方案为分卡：

# 以 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

生效定义：

<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）

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：

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、双监听）自动拉起——证明开机自愈能力恢复，后续直接重启虚拟机不会再瘫。

五、最终验证

$ 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 回包

六、遗留事项与建议

七、备份文件索引

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

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

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

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

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

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

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

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

[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/磁盘组问题的第二翻找点）

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

本次抓到：

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（网卡定义的权威文件，不是日志但必查）

/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 起不来的细查点）

/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：

# 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"

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

/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 重定向到文件——本次死锁期的输出直接给出因果：

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 之下再往下挖）

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 层）

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

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

第一轮：网络不通

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

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

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（挂盘）才能解锁一切。

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

「找不到 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 死锁（本次最烧脑）

新 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 可复用的日志技巧清单

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

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

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

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 的对照）

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 凭据循环（死锁侧写）

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 启动行为的历史对比（第二次开机的「无声胜有声」）

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 的重定向输出（死锁定案）

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 —— 双源不一致的原文

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 —— 一条沉睡四个月才发挥价值的日志

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 语法坑（工具会自答）

$ 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 时改试 -?）

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

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

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

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

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 ↔ 网段

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

# 集群栈分层诊断
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*