必须用dd清磁盘头因GI安装时严格校验ASM元数据，仅清首扇区或依赖asmcmd/kfed无法覆盖AU0内残留头信息，需dd if=/dev/zero of=设备 bs=1M count=10彻底清除前10MB。
直接重置 ASM 磁盘头必须用 dd 清零前几 MB，不能只清扇区或依赖 asmcmd 命令；否则集群安装时会拒绝识别磁盘，报 ORA-15036 或 “disk is not empty”。
为什么必须用 dd 清磁盘头，而不是 asmcmd lsdsk 或 kfed repair
ASM 安装阶段（尤其是 GI 安装）会严格校验磁盘头部是否含有效 ASM 元数据。哪怕磁盘已 umount、drop diskgroup、甚至被 dd if=/dev/zero of=/dev/sdX bs=512 count=1 清过第一个扇区，只要后续 AU（Allocation Unit）里残留旧的 ASM 区域头（如 ASM disk header、AU 0 的 KFBH），GI 就会判定该盘“已被使用”，拒绝纳入 OCR 或 DATA 磁盘组。
常见误操作包括：
- 只清
/dev/sdX开头 512 字节 —— 不够，ASM 头可能在 AU 0 的偏移 100KB+ 处 - 用
kfed read /dev/sdX看到kfbh.type: 0就以为干净 —— 实际可能是伪造或残留 - 依赖 multipath 别名（如
/dev/mapper/asm_data01）但没确认底层真实设备路径 ——dd写错设备会导致生产存储损坏
dd 清磁盘头的正确参数与范围
Oracle 官方文档明确要求：对每个 ASM 裸盘，至少清除前 10MB（即 AU 大小 × 2～3 个 AU），确保覆盖 disk header + first AU 的所有元数据区域。19c 默认 AU 大小为 4MB，所以清 10MB 是稳妥下限。
实操命令（以 OCR 盘为例）：
dd if=/dev/zero of=/dev/mapper/asm_ocr_vot01 bs=1048576 count=10
关键点：
-
bs=1048576= 1MB，比bs=1024000更标准，避免部分系统因块对齐问题写入失败 -
count=10表示写入 10 个 1MB 块，即 10MB；若磁盘曾用 1MB AU，建议升到count=20 - 目标设备必须是裸盘（无分区表），用
fdisk -l /dev/sdX确认输出含Disk /dev/sdX doesn't contain a valid partition table - 多路径环境下，务必对
/dev/mapper/xxx操作，而非底层/dev/sdX—— 否则节点间视图不一致
清完后必须验证的三件事
清头不是一劳永逸。以下检查缺一不可，否则安装时仍会失败：
- 在所有 RAC 节点上运行
oracleasm scandisks（如启用 ASMLib）或ls -l /dev/mapper/asm_*确认设备存在且属主为grid:asmadmin - 用
kfed read /dev/mapper/asm_ocr_vot01 | grep -E "(kfbh|dsknum|grpnum)"，输出应全为空或显示kfbh.type: 0（未初始化） - 执行
asmcmd lsdsk -p，确认该盘出现在列表中且PATH列值正确；若显示ORCL:MISSING或完全不出现，说明 udev/multipath 规则未生效或权限不对
OCR 磁盘清头后安装 GI 仍报 ORA-15054 的典型原因
这个错误表面是“disk does not exist”，实际多因清头不彻底或环境残留导致：
- OCR 盘用了 ASM Filter Driver（AFD），但未先执行
afddriverstate supported和afd_label重新标记 —— 清头后 AFD 层仍缓存旧标签 - 节点间时间不同步，导致 CSSD 启动时拒绝挂载刚清过的磁盘（表现为
crsctl check crs显示CRS-4639: Could not contact Oracle High Availability Services） -
/etc/oracle/lastgasp或/u01/app/19.0.0/grid/cdata/下残留旧集群配置，需手动rm -rf并清空/tmp/.oracle
最易被忽略的是：清头操作必须在所有节点完成后再启动任何 GI 进程；任一节点漏清或顺序错乱，都会让 OCR 发现“部分磁盘状态不一致”，直接中止安装。
