ASM磁盘组之所以能够绕开传统文件系统直接管理裸设备，靠的是写在每块磁盘最前面的那一段元数据，也就是常说的磁盘头。Grid Infrastructure在启动和扫描设备时读取的正是这段内容，而v$asm_disk视图中的header status列，本质上就是ASM实例对磁盘头内容的翻译结果。读懂这个字段，就等于拿到了判断一块磁盘能否加入磁盘组、是否已经归属某个磁盘组、磁盘头有没有被覆盖破坏的第一手证据。在RAC集群环境里，磁盘组挂载失败、节点间磁盘可见性不一致这类故障，十有八九都能从这个字段的变化里找到线索。
磁盘头里到底写了什么
ASM对磁盘的管理完全建立在裸设备之上，没有文件系统层，也没有分区表参与。每块ASM磁盘在逻辑上被划分为若干个分配单元，也就是AU，默认大小通常是1MB或4MB。磁盘的第一个AU里保存着磁盘头结构，Oracle内部称之为kfdhdb，这里面记录了磁盘名、所属磁盘组名、磁盘组编号、AU大小、磁盘创建时间戳、ASM软件版本以及兼容性参数等关键信息。ASM实例扫描设备时，只要读到这段合法的头部结构，就能立刻判断出这块盘的身份。
在Windows平台上，ASM并不能随意扫描服务器上的每一块物理盘，而是只认被专门工具标记过的设备。Grid Infrastructure提供的asmtoolg.exe图形工具和asmtool.exe命令行工具负责给物理盘盖章，盖完章的设备会获得一个ORCLDISK开头的标签，比如ORCLDISKDATA0。这个标签同样写在磁盘头区域，之后ASM实例只会打开形如\\.\ORCLDISKDATA0的设备，避免误碰系统盘和其他数据盘。
理解了这一点，header status的来源就清楚了：ASM实例读取磁盘头之后，根据头内容的完整程度和归属信息，把磁盘归入不同的状态类别。也就是说，这个状态反映的不是磁盘的电气或硬件健康程度，而是磁盘头里那段元数据的状态。一块硬件完全正常的盘，只要磁盘头被破坏，照样会显示成UNKNOWN或者CANDIDATE。
-- 查看所有磁盘的头部状态与挂载状态
COL path FOR A30
SELECT group_number, disk_number, mount_status, header_status,
mode_status, state, total_mb, path
FROM v$asm_disk
ORDER BY group_number, disk_number;
七种常见状态的准确含义
v$asm_disk的header status列在日常运维中能见到的取值主要有七种，每一种都对应磁盘头的一种具体情况。先用一张表把含义和典型场景列出来，再对几个容易踩坑的状态做补充说明。
| 状态 | 磁盘头内容 | 典型场景 |
|---|---|---|
| MEMBER | 头信息完整，明确归属于某个磁盘组 | 正常在役的成员盘 |
| CANDIDATE | 头信息为空或已被清除 | 全新磁盘，或头被清零的盘 |
| FORMER | 曾属于某磁盘组，后被删除 | 执行drop disk后的过渡状态 |
| FOREIGN | 头信息属于其他ASM集群或非ASM数据 | 复用了别的环境的盘 |
| PROVISIONED | 已被外部工具预标记，尚未加入磁盘组 | asmtoolg盖章后的新盘 |
| UNKNOWN | 头信息无法识别 | 磁盘头损坏或读取异常 |
| INCOMPATIBLE | 头信息版本与当前ASM不兼容 | 跨大版本复用旧盘 |
MEMBER是唯一让人放心的状态，但要注意它必须和mount_status列结合起来看。一块header status为MEMBER、mount status为CLOSED的盘，说明磁盘头声明它属于某个磁盘组，但这个磁盘组当前并没有挂载，这种情况常见于集群重启后磁盘组没有自动拉起，或者磁盘组只在部分节点上挂载失败。此时磁盘本身没有问题，需要排查的是磁盘组级别的故障。
CANDIDATE是最需要警惕的状态。新盘显示CANDIDATE完全正常，但如果一块原本在役的成员盘突然变成了CANDIDATE，意味着它的磁盘头被覆盖清零了。常见原因包括运维人员在Windows磁盘管理器里对ASM盘执行了初始化或写入签名的操作、存储侧更换映射后LUN被重新处理，或者有人误用了清盘工具。这种情况下绝对不能直接把盘重新加回磁盘组，因为ASM会把它当成一块全新的空盘参与重平衡，原有数据将彻底丢失。
FOREIGN表示磁盘头里写的是别的组织的元数据，可能是另一个ASM集群的盘，也可能是非ASM数据盘。往磁盘组里添加FOREIGN盘时，ASM会直接拒绝，除非显式加FORCE子句。反过来讲，看到FOREIGN的第一反应应该是核实这块盘的来源，确认上面的数据确实不再需要，而不是想着怎么强制加进去。
PROVISIONED是Windows和Linux平台特有的中间状态。通过asmtoolg或asmtool盖章的盘，在加入磁盘组之前会保持PROVISIONED，加入成功后转为MEMBER。如果一块盘盖了章却长时间停留在PROVISIONED，多半是加盘操作没有执行，或者加盘时指定了错误的设备路径。
Windows平台下的排查流程
RAC集群是多节点环境，排查磁盘头问题时要先确认所有节点看到的状态是否一致。单节点查询用v$asm_disk，跨节点对比用gv$asm_disk，重点看同一块盘在不同实例上的header status是否相同。如果某个节点显示MEMBER而另一个节点显示UNKNOWN，问题多半出在该节点的存储链路或多路径配置上，而不是磁盘头本身。
-- 跨节点对比磁盘头状态 SELECT inst_id, group_number, header_status, mount_status, path FROM gv$asm_disk WHERE path LIKE '%ORCLDISK%' ORDER BY path, inst_id;
第二步看ASM实例的告警日志。Windows平台上Grid Infrastructure的ASM诊断目录通常位于C:\app\grid\diag\asm\+asm1\trace\，对应的告警日志文件是alert_+asm1.log。挂载失败时在日志里搜索ORA-15032、ORA-15063、ORA-15040这类错误码，日志会明确写出是哪块盘的头状态导致了挂载中断。如果怀疑集群层的问题，还可以顺着注册表HKEY_LOCAL_MACHINE\SOFTWARE\Oracle下的相关键值确认Grid主目录路径，再检查Windows服务列表中Grid相关服务是否全部处于运行状态。
第三步在操作系统层面核实磁盘。运行diskmgmt.msc打开磁盘管理器，确认物理盘处于联机状态、没有被人初始化过；也可以用diskpart列出磁盘清单。再用asmtool的列表功能查看盖章情况，确认ORCLDISK标签是否还在。
cd /d C:\app\grid\product\19.0.0\grid\bin asmtool -list diskpart list disk
asmtool -list的输出会列出所有已盖章的设备及其标签，如果某块盘的标签丢失，输出里就不会出现它，此时磁盘头大概率被动过。三个层面的信息汇总起来，基本就能定位磁盘头异常的根源在存储、操作系统还是ASM配置。
典型故障场景与修复思路
场景一：磁盘组无法挂载，成员盘显示CANDIDATE。这是磁盘头被覆盖的典型表现。如果磁盘组采用冗余策略，且故障发生时仍有足够副本在线，正确做法是先处理坏盘再恢复磁盘组：把头被破坏的盘从磁盘组中剔除，补一块新盘进来，让ASM完成重平衡。如果整个磁盘组的所有盘头都丢了，就只能走磁盘头恢复路线。需要说明的是，Oracle官方的kfed工具只在Linux和Unix平台的Grid安装介质中提供，Windows环境下可以把磁盘挂到Linux机器上，利用kfed的repair功能从同故障组的伙伴盘重建头部信息，前提是磁盘组至少还有一块头完好的成员盘。
场景二：加盘时报错，磁盘显示FOREIGN。先确认这块盘确实来自其他环境且数据已废弃。确认无误后，用diskpart的clean all命令对整盘清零，这一步会把包括磁盘头在内的所有扇区写零，执行前务必反复核对盘号，清零是不可逆的。清零完成后重新用asmtool盖章，此时磁盘头状态会变成CANDIDATE或PROVISIONED，再正常加入磁盘组即可。
-- 将处理好的新盘加入磁盘组 ALTER DISKGROUP DATA ADD DISK '\\.\ORCLDISKDATA03' NAME DATA_0003 REBALANCE POWER 4;
场景三：盘已盖章却始终是PROVISIONED，加盘命令找不到设备。这种情况优先检查Windows磁盘管理器里该物理盘是否处于脱机状态，SAN环境还要确认所有节点都能看到该LUN、盘符映射一致。磁盘重新联机后，ASM一般需要几分钟完成重新扫描，必要时重启ASM实例触发重新发现。
日常预防措施
磁盘头故障的修复成本远高于预防成本，尤其是Windows平台缺少kfed这类官方修复工具，一旦头信息丢失，处理起来相当被动。日常运维中建议做到以下几点。
- 定期对每块ASM磁盘的第一个AU做扇区级备份，备份文件妥善存放到非ASM存储上，这是头信息被覆盖后唯一的快速恢复途径。
- 保持ORCLDISK标签命名规范，比如CRS盘用ORCLDISKCRS0、数据盘用ORCLDISKDATA0，并维护一份物理盘、标签与磁盘组成员的对照表。
- 严禁在Windows磁盘管理器中对ASM盘执行初始化、新建卷或格式化操作，相关权限只授予数据库运维人员。
- 存储侧变更LUN映射或复用旧盘时，必须走变更流程，复用前确认磁盘头已彻底清除。
- 用asmcmd的md_backup命令定期备份磁盘组元数据，同时明确它备份的是磁盘组结构信息，不包含磁盘头，两者不能互相替代。
- 部署定时监控，对header status的变化做告警，成员盘状态一旦从MEMBER变成其他值立即通知运维。
-- 监控成员盘状态变化的常用查询
SELECT d.path, d.header_status, d.mount_status
FROM v$asm_disk d
WHERE d.header_status NOT IN ('MEMBER', 'PROVISIONED')
AND d.path LIKE '%ORCLDISK%';
把header status当作日常巡检的固定检查项，配合磁盘头备份和规范的标签管理，绝大多数磁盘组层面的故障都能在造成实际影响之前被发现。这个字段查询成本极低，信息量却很大，是RAC集群磁盘管理中性价比最高的监控点之一。
ASM磁盘组header statusRAC集群修改时间：2026-10-01 01:59:33