前几天给 ASM 磁盘组加盘，本来觉得是 routine 操作：盘怼上去， rebalance power 给上，盯着进度跑完就收工。结果这次栽了个不大不小的跟头，记录一下。

事情的经过

加完盘， rebalance 正常开跑，前半程都顺。眼看着快完工了，进度不动了——查操作进度，剩余时间已经显示 0 。按理说时间归零就差临门一脚，可左等右等，这脚就是踢不进去，状态一直挂着，加盘始终不算成功。

rebalance 卡住，别干等，先翻 ASM 的日志。这一翻，果然有货：    

Errors in file /oracle/gridbase/diag/asm/+asm/+ASM2/trace/+ASM2_ora_293185.trc:
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Additional information: 128
Additional information: 8

顺带提一句，那行 "No such file or directory" 看着像盘路径有问题，别被带偏——盘一直好好挂着呢。真正的关键就是第一行： ORA-27090 ，内核的异步 I/O 资源不够用了。

背景简单说一下。 Linux 上 Oracle 的 I/O 走的是异步路子，每个在途的异步 I/O 请求都得从内核那儿占一个坑，而坑的总数由参数 fs.aio-max-nr 控制，系统里所有进程、所有实例共享这一个池子。

那为啥平时好好的，一加盘就爆？因为 rebalance 本质上是整个磁盘组的大挪移，短时间内要搬海量的 extent ，并发异步 I/O 一下冲高，直接把池子占满了。 ASM 再想提交新的异步 I/O ，内核摆手：没坑了。于是 ORA-27090 ， rebalance 卡在最后一段出不去。

拿着错误号去 MOS 一搜， 579108.1 对上了号，后面还挂着 Bug 13554729 。方向很明确： fs.aio-max-nr 太小，调大它。

看了一眼机器上的配置，就是当初装集群时官方推荐的那个默认值：

fs.aio-max-nr = 1048576

咋解决

改 /etc/sysctl.conf ，把官方默认的 1048576 提到 3145728 ：

# 官方默认的
fs.aio-max-nr = 1048576
# 改成
fs.aio-max-nr = 3145728

RAC 环境，两边节点都得改。改完 sysctl -p 生效。这个参数最舒服的地方是：不用重启集群、不用重启实例，正在跑的 rebalance 也不用动，改完就完事。不然为了个加盘还得挑维护窗口，那才叫憋屈。

改完就是等。大约 20 多分钟后， rebalance 自己走完了，磁盘组恢复正常，收工。

这次能比较快定位，就靠两条：

rebalance 卡住别干等，第一时间翻 ASM 的 alert log 和 trace ，答案都在里面；

看到 ORA-27090 ，基本可以直接往 fs.aio-max-nr 上想，命中率极高。

另外两个实操建议：机器上实例多、盘多、 rebalance power 给得猛， aio 池子都容易被吃爆，加盘前可以瞅一眼 /proc/sys/fs/aio-nr 和 aio-max-nr ，看看余量心里有个数；这参数改完即时生效、零重启，该出手时就出手。