张乐奕
云和恩墨副总经理 oracle ace 总监
itpub oracle数据库管理版版主、oracle高可用版版主、acoug联合创始人
在 oracle 10.2.0.5 之前，asm 磁盘的头块并没有自己的备份，因此一旦头块损坏，如果没有以前 kfed read 备份出来的信息，也就没有办法使用 kfed merge来作头块恢复，特别是如果一个磁盘组中所有的磁盘头块都出现问题（比如被人为地创建了 pv ），恢复 asm 磁盘头块的操作就会非常麻烦。
但是从 oracle 10.2.0.5 之后，asm 磁盘的头块会自动备份在另外一个块中，这实际上是 oracle 11g 出现的功能，不过经过测试，在 oracle 10.2.0.5 版本中，这个备份也是存在的。
正是因为存在这个备份，所以 oracle 10.2.0.5 之后的 kfed 程序才有了新的 repair 命令，该命令将备份块直接覆盖到磁盘头块，完成修复工作。
在 oracle 10.2.0.4 中，如果尝试执行 kfed repair ，则会报错说命令行参数不正确，此报错说明并不存在 repair 命令:
但是在 oracle 10.2.0.5 中，执行 kfed repair ，则会说无法打开文件空，而这正说明 repair 命令是存在的，报错是因为还需要明确指定要修复哪块磁盘：
那么这个备份块具体存在哪里呢？在 solaris 下的测试，我们使用truss来进行跟踪。
在 trace 文件中，找到下面这段，可以明确地看到 kfed 程序从第 510 个块中读出 4096 字节，然后再写回到第 0 个块中。
同样如果是在 linux 下用裸设备作为 asm 磁盘，并且用 strace 进行 repair 命令的跟踪，也可以得到类似结果。
那么通过 kfed 命令再来验证一下这两个块是否都标志为头块。验证结果表示块类型都为 diskhead 。
那么下一个疑问是，在 11gr2 以后，asm 磁盘组的 au size 可以指定不同的大小，是不是不同的 au size 下的磁盘头块备份都是在第 510个 块呢？还是用 truss 来跟踪一下，这里的 vdisk3 属于一个 au size＝8m 的磁盘组，此时repair命令需要明确指定 aus，否则会报 kfed-00320 错误。
在 trace 文件中，可以发现已经不再是去读第 510 个块，而是改为读第 4094 个块。
用 kfed 验证第 4094 个块，确实标志为 diskhead。
那么也就是 au 1m 的磁盘组头块备份在第 510 个块上，而 au 8m 的磁盘组头块备份在第 4094 个块上，备份块的存储位置有规律吗？有的，始终保存在第 2个au 的倒数第 2 个块上。下面来验证这个观点。
对于默认的磁盘组， au size＝1m ，每个 au 中可以存储 256 个块，块号为 0-255 。第 1 个 au 存储 256 个块，第 2 个 au 最后 1 个块号为 255，倒数第 2 个块号是 254，也就是整体的第 510 个块（从第 1 个 au 的第 1 个块往后算起）。
对于 au size＝8m 的磁盘组，每个 au 可以存储 2048 个块，块号为 0-2047 。第 1 个 au 存储 2048 个块，第 2 个 au 最后 1 个块号为 2047 ，倒数第 2 个块号是 2046 ，也就是整体的第 4094 个块（从第 1 个 au 的第 1 个块往后算起）。
对于其它 au size 磁盘组的验证，看到文章的朋友有兴趣可以自己做一下。
结论：
从 oracle 10.2.0.5 开始， asm 磁盘已经开始自动将头块进行备份，备份块的位置在第 2 个 au 的倒数第 2 个块上（对于默认 1m 的 au 来说，是第 510 个块），如果头块损坏，可以用 kfed repair 命令来修复。因此对于选用 asm 存储作为生产环境的用户来说，尽快升级到 10.2.0.5 是明智的选择。