解决方案
我们应该使用 FSCK 进行以下检查并尝试修复 ACFS。
FSCK 完成的时间取决于文件系统和要检查的文件数量。
使用详细选项，fsck 必须为所有目录和文件生成此信息。
这会显着影响性能，尤其是对于包含大量文件的文件系统。
fsck处理：
Fsck 尝试验证文件系统的所有元数据。
此过程的一部分包括验证元数据块空闲列表。
必须检查空闲块本身以确保它是正确类型的元数据块，并且必须检查空闲列表以确保没有丢失条目并且列表中没有循环。
由于文件可以按任何顺序删除，因此这些空闲块可以位于卷上的任何位置。
由于文件删除的随机性，处理和验证这些列表会产生大量随机 I/O。
如果 fsck 花费太长时间，可以中断它，因为它正在检查模式下运行。
fsck 检查并修复现有的 Oracle ACFS。
此命令只能在卸载的文件系统上运行。
运行 fsck 需要 root 权限。
必须加载 Oracle ACFS 驱动程序才能使 fsck 工作。
要确认或者放弃受影响的 ACFS 文件系统上的任何一致性问题，请按如下方式运行 FSCK：
- 如下卸载每个节点上的 ACFS 文件系统（作为 root 用户）并保持卸载以避免损坏。
否则会得到警告：
fsck.acfs: ACFS-00511: /dev/asm/<VOLUME_NAME> is mounted on at least one node of the cluster.
# /usr/sbin/umountall -F acfs
或者
# /usr/sbin/umount [MOUNT_POINT]
其中：MOUNT_POINT 是 ACFS 文件系统。
- 然后，按如下方式在关联的 ADVM 卷上执行 FSCK（如果是 RAC，则从每个节点执行）：
在 Linux 上
# script /tmp/fsck_[node name].txt # /sbin/fsck -a -y -t acfs /dev/asm/[VOLUME_NAME] # exit
在 Solaris 上
# script /tmp/fsck_[node name].txt # /usr/sbin/fsck -F acfs -y -o a,v /dev/asm/[VOLUME_NAME] # exit
在 IBM-AIX 上
# /usr/sbin/fsck -V acfs -y -o a,v /dev/asm/[VOLUME_NAME]
其中：
/dev/asm/[VOLUME_NAME 是 ADVM 卷。
重要提示：默认情况下，fsck 仅检查并报告任何错误。
在检查模式下，如果需要很长时间，可以取消 fsck。
必须指定 -a 标志以指示 fsck 修复文件系统中的错误。
如果检查模式在合理的时间内完成，并且报告了问题，请在修复模式下运行 fsck。
在修复模式下，fsck 不能被中断，否则会导致文件系统处于更糟糕的状态（数据丢失取决于损坏的性质）。
# /sbin/fsck -a -y -t acfs /dev/asm/[VOLUME_NAME]
- 如果是RAC，则在每个节点上挂载ACFS文件系统。
在 fsck 修复后手动挂载总是更好。
# /usr/sbin/mount -v acfs /dev/asm/[VOLUME_NAME] [MOUNT_POINT]
其中：
/dev/asm/[VOLUME_NAME] 是 ADVM 卷。
MOUNT_POINT 是 ACFS 文件系统。
或者
# /usr/sbin/mount -v acfs -o all none none
例子：
使用“/sbin/acfsutil info fs”找到正确的卷并执行 fsck。
[HOSTNAME]:(+ASM2)/opt/oracle > /sbin/acfsutil info fs /acfs1 ACFS Version: 11.2.0.4.0 flags: MountPoint,Available,Corrupt mount time: Fri Jun 10 17:29:14 2016 volumes: 1 total size: xxxxxxxxxxxx total free: xxxxxxxxxxxx primary volume: /dev/asm/[VOLUME_NAME2]
默认情况下，fsck 只检查和报告任何错误。
必须指定 -o a 选项以指示 fsck 修复文件系统中的错误。
在少数情况下，fsck 在继续检查文件系统之前会提示问题。
这些案例包括：
- 如果 fsck 检测到文件系统上正在进行另一个 fsck。
- 如果 fsck 检测到未加载 Oracle ACFS 驱动程序。
- 如果文件系统看起来不是 Oracle ACFS。
在检查模式下，fsck 也会提示是否有由于关闭不完全而没有完全处理的事务日志。
要在非交互模式下运行，请包含 -y 或者 -n 选项以对任何问题回答是或者否。
问题
我们注意到与 ACFS 文件系统关联的不同 asm 元数据视图、asmcmd 和 os 输出中存在许多不一致之处。
数据库显示 RMAN 或者 dbverify 损坏。
数据库使用 ACFS。
ALTER DISKGROUP CHECK REPAIR 恢复干净，但我们仍然看到错误或者检查损坏返回正面，例如：
$ /sbin/acfsutil info fs -o iscorrupt [MOUNT_POINT] acfsutil info fs: ACFS-03037: not an ACFS file system
$ /sbin/acfsutil info fs -o iscorrupt [MOUNT_POINT] 1
“/sbin/acfsutil info fs”的输出也在标志下显示损坏。
例如：
$ /sbin/acfsutil info fs [MOUNT_POINT] ACFS Version: 18.3.0.0.0 on-disk version: 47.0 compatible.advm: 18.3.0.0.0 ACFS compatibility: 18.3.0.0.0 flags: MountPoint,Available,Corrupt,AutoResizeEnabled