要排查和解决Oracle数据库中的“ASM file metadata operation”等待事件，可按照以下步骤进行：

1. 检查ASM实例的等待事件

• 登录ASM实例，执行以下SQL查看当前等待事件：

  SELECT sid, state, event, final_blocking_instance, final_blocking_session 
  FROM gv$session 
  WHERE event = 'enq: DD - contention';
  

  • 如果存在大量enq: DD - contention且阻塞会话指向GPnP Get Item（如文档[1]所述），则可能是GPnP或RBAL进程导致。

2. 检查GPnP进程状态

• 在操作系统层面检查GPnP进程：

  ps -ef | grep -i gpnpc
  

  • 如果发现异常或挂起的GPnP进程，需谨慎终止（需评估集群影响）：

    kill -9 
    

3. 确认ASM磁盘组权限及配置

• 检查ASM磁盘的权限和udev规则是否正确：

  ls -l /dev/oracleasm/disks/*
  udevadm info /dev/  # 确认规则匹配
  

4. 检查存储空间及日志

• 查看ASM磁盘组空间使用：

  SELECT name, total_mb, free_mb FROM v$asm_diskgroup;
  

• 检查ASM和数据库的告警日志：

  tail -f $ORACLE_BASE/diag/asm/+asm//trace/alert_.log
  tail -f $ORACLE_BASE/diag/rdbms///trace/alert_.log
  

5. 分析Hanganalyze及Systemstate Dump

• 在问题发生时生成诊断信息：

  -- ASM实例中执行
  ALTER SESSION SET EVENTS 'immediate trace name hanganalyze level 3';
  ALTER SESSION SET EVENTS 'immediate trace name systemstate level 266';
  

6. 解决方案

• 若确认GPnP进程阻塞（如文档[1]）：

  1. 在OS层终止GPnP进程（需集群环境允许，并评估风险）。
  2. 观察ASM和数据库恢复情况。
  3. 若问题反复出现，考虑升级集群软件或应用相关补丁。

• 其他可能原因：

  • 存储延迟或故障：检查存储性能（I/O延迟、路径健康）。
  • ASM元数据损坏：联系Oracle支持进行ASM元数据验证。

7. 预防措施

• 定期监控ASM和集群健康，确保磁盘组空间充足。
• 更新集群及数据库至推荐版本，修复已知Bug。
• 避免在高峰时段执行ASM元数据操作（如磁盘扩容、Rebalance）。

总结：
“ASM file metadata operation”通常与ASM实例的元数据操作竞争或底层进程阻塞相关。重点检查ASM实例中的enq: DD - contention及GPnP/RBAL进程状态，结合日志和诊断工具定位阻塞源。操作前确保备份关键配置，并在测试环境验证高风险操作。