ASM挂起时应attach主进程ora_asm+pid而非辅助进程，用strace -p PID -e trace=io,desc,process -T -s 128聚焦I/O调用；重点关注io_getevents超时、ioctl失败及openat返回ENXIO，结合multipath、udev和/proc/diskstats排查存储链路异常。
ASM实例挂起时怎么用 strace 跟踪后台进程
直接 attach 到 asm 的关键后台进程（比如 ora_<i>asm</i>+<i>pid</i> 或 ora_<i>asm</i>_<i>instance_name</i>）是可行的，但必须选对进程、避开 oracle 内部信号干扰。
常见错误是 strace 所有 asm 进程，结果卡在 semop 或 io_getevents 上，误判为 I/O 卡死——其实只是 Oracle 在等 ASM 实例内部同步信号。
- 优先 attach
ora_<i>asm</i>+<i>pid</i>（如ora_asm_+ASM1），它是 ASM 实例主进程，负责协调磁盘组和 ASM 文件操作 - 避免 attach
ora_<i>asm</i>_<i>pid</i>类型的辅助进程（如ora_asm_12345），它们常处于epoll_wait等待状态，strace 会显示大量重复休眠，无实际诊断价值 - 使用
strace -p <i>PID</i> -e trace=io,desc,process -T -s 128：只跟踪 I/O、文件描述符和进程调用，-T 显示系统调用耗时，-s 防止路径截断 - 如果 strace 输出中频繁出现
io_submit后长时间无io_getevents返回，且伴随大量EAGAIN，说明底层存储响应慢或队列积压
ASM 挂起是否真由 OS 层 I/O 引起
不能只看 iostat -x 1 的 %util 或 await，ASM 挂起更常源于设备路径异常、多路径切换失败、或 udev 规则导致设备名漂移。
典型现象是 crsctl check cluster 正常，但 asmcmd lsdg 卡住，同时 ls -l /dev/oracleasm/disks/ 显示部分盘为 broken 链接或权限异常。
- 检查
/proc/diskstats中对应 ASM 磁盘（如sdb、mpathb）的rd_sec/wr_sec是否长期无增长，若为 0 且 strace 显示io_submit成功但无完成事件，大概率是存储链路中断而非性能瓶颈 - 运行
multipath -ll看路径状态，如果某条路径显示failed或shaky，而 ASM 正在尝试通过该路径重试 I/O，就会表现为“挂起”而非报错 - 确认
/dev/oracleasm/disks/下的盘是否全部指向真实块设备（ls -l看 target），udev 规则若未固定 WWID，重启后可能映射错盘，ASM 尝试读取错误设备会静默等待超时
strace 输出里哪些系统调用值得重点盯
不是所有系统调用都相关。ASM 对 I/O 的封装很深，真正暴露问题的往往是底层异步接口和设备控制调用。
重点关注三类调用：异步 I/O 完成等待、设备控制命令、文件描述符状态变更。忽略大量 gettimeofday、clock_gettime 和 rt_sigreturn ——它们是 Oracle 自身调度开销，非故障根源。
-
io_getevents：返回值为 0 且持续超时（>10s），说明异步 I/O 提交后底层无响应，需立刻查存储链路或驱动 -
ioctl调用中含BLKGETSIZE64或SG_IO：若返回EIO或卡住，表示 ASM 正在探测磁盘容量或发送 SCSI 命令失败，常见于 LUN 不可见或 ACL 未配置 -
openat或open返回ENXIO或ENODEV：说明 ASM 尝试打开某个 disk path 失败，对应路径已失效，但 ASM 还未触发 failover 逻辑
为什么有时 strace 一加就“恢复”，一停又挂
这不是幻觉。strace 本身会强制改变进程调度行为：它让被 trace 进程进入 ptrace_stop 状态，打断 Oracle 的内部超时重试循环；当 strace 退出，进程恢复执行，但某些未清理的等待状态（如未清除的 io_context）会导致后续 I/O 请求直接阻塞。
这往往说明 ASM 已进入某种不一致等待态，比如一个 disk group 的 discovery 过程卡在中间步骤，既没成功也没失败，strace 的介入恰好“重置”了局部状态。
- 遇到这种情况，不要反复启停 strace，先保存当前
oradebug dump systemstate 266和oradebug dump asmsystemstate 1转储 - 检查
Alert.log中最近 5 分钟是否有ORA-15078（disk group force dismount）、ORA-15196（ASM block corruption）或ORA-15335（ASM metadata I/O error） - 若 strace 停止后立即挂起，且
ps -eo pid,comm,wchan | grep <i>asm_pid</i>显示 wchan 为io_schedule或do_io，基本可判定是内核层 I/O 子系统异常，需联系存储厂商并收集dmesg -T输出
