【ORA】ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O

操作系统是CentOS 5.11

数据库 10.2.0.5.0

晚上查看数据库，发现数据库报错查看相关的trace文件内容如下：

*** SERVICE NAME:(SYS$BACKGROUND) 2017-12-23 20:48:16.958
*** SESSION ID:(363.1) 2017-12-23 20:48:16.958
*** 2017-12-23 20:48:16.958
Start recovery for domain 0, valid = 0, flags = 0x1
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 4: Interrupted system call
Additional information: 3
Additional information: 6
Additional information: 65536
*** 2017-12-23 20:48:17.056
Warning: recovery process cannot use async I/O
*** 2017-12-23 20:48:17.220
KCRP: blocks claimed = 2, eliminated = 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 131072
Longest hash chain = 1
Average hash chain = 2/2 = 1.0
Max compares per lookup = 0
Avg compares per lookup = 0/2 = 0.0
----------------------------------------------
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 4: Interrupted system call
Additional information: 3
Additional information: 128
Additional information: 65536
----- Recovery Hash Table Statistics -------：
Hash table buckets = 131072
Longest hash chain = 1
Average hash chain = 2/2 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 4/4 = 1.0
----------------------------------------------

在网上找了很多帖子，终于找到了一个很有用的帖子：

转自http://blog.csdn.net/hemiao1987/article/details/46044049

内容如下：

数据库从库报错：

Errors in file /home/oracle/admin/emspda/bdump/emspda2_p003_23499.trc:
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 4: Interrupted system call
Additional information: 3
Additional information: 128
Additional information: 65536

通过资料查询发现是因为/etc/sysctl.conf里面的fs.aio-max-nr设置的问题，在redhat 5版本上，这个值默认是65536

http://docs.oracle.com/cd/E11882_01/install.112/e24326/toc.htm#BHCCADGD

此文章中提到，aio-max-nr 的值不应小于1048576。

https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?_afrLoop=433636510624081&type=DOCUMENT&id=579108.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=pxg2yomrf_157

这篇oracle的文章提到fs.aio-max-nr应设置为3145728。为了避免出现问题，将这一参数设置为3145728（反正大了没事。。）

proc 文件系统包含了两个虚拟文件，它们可以用来对异步 I/O 的性能进行优化：

• /proc/sys/fs/aio-nr 文件提供了系统范围异步 I/O 请求现在的数目。

• /proc/sys/fs/aio-max-nr 文件是所允许的并发请求的最大个数

在一个程序中如果涉及到磁盘的IO操作时,有两种情况
1. 程序等待IO操作完成，CPU再接下来处理程序的其他部分（等待IO的时间段内，CPU处于Idle Waiting状态）。
2. 程序不等待IO操作完成，允许CPU处理接下来的其他任务（或者理解为允许CPU处理接下来的不依赖于IO完成的任务）。
显然，第一种情况，CPU的资源白白的浪费了,也就是同步IO。第二种情况更有利于CPU的充分利用,这就是异步IO(asynchronous IO)

我们知道aio-nr是所有当前活动的异步IO进程上下文的总和，其值最多不能超过aio-max-nr的设定值。并且数据库是在机房意外断电的情况下突然关闭的，关闭的一瞬间有大量的事务正在运行，所以重新启动的时候必然有大量的回滚与已提交但没有写入到数据文件的数据要开始写入，这时候的IO量是非常大的，由于启用了异步IO，此时大量的上下文切换达到了操作系统设定的最大值，于是oracle就停止响应了。查询metalink了解到oracle已证实这是一个BUG，官方建议fs.aio-max-nr的值设置为1M或以上可以解决此问题。

解决办法：

 echo "fs.aio-max-nr = 3145728" >> /etc/sysctl.conf

重启oracle服务

参考连接

http://blog.csdn.net/lordcoohoo/article/details/8135152