背景
客户RAC 11.2.0.4环境在巡检时，发现大量ORA-27090日志报错，整体应用暂时没有表现出异常，但是错误一直刷日志，需要分析具体报错原因。
具体报错如下：
问题分析
官方解析
通过查找ora-27090官方说明，大意是不能预定系统的异步IO资源，看起来像是某个参数设置过小导致。MOS官方对此也有相应专属文章介绍此类ORA报错。
[oracle@dbrac1 ~]$ oerr ora 27090
27090, 00000, "Unable to reserve kernel resources for asynchronous disk I/O"
// *Cause: The system call to reserve kernel resources for asynchronous I/O
// has failed.
// *Action: Check errno
ORA-27090 - Unable to Reserve Kernel Resources for Asynchronous Disk I/O (Doc ID 579108.1)
上述文章中主要说明是fs.aio-max-nr= 3145728设置过小导致，推荐值3145728。但本系统已经设置为3145728，不可能是此参数引起，需要验证是否其他原因导致。
日志分析
节点2日志分析
通过报错信息，得知此ora-27090在RAC节点2报有异常，再次梳理节点2日志，查找初次报错的时间点，为11月3日早上2点0分7秒（在ckpt trc文件中，具体时间为2020-11-03 02：00：07.819），具体报错内容为保存控制文件快照时，找不到本地文件，报ora-27037，ora-27090。
节点2 ora-27037异常原因
需要注意，保存控制文件的名字为snapcf_c5crm1.f，这就比较奇怪，在节点2保存为什么是snapcf_c5crm1.f这个名字，按理应该和rman配置中一致，查看具体rman配置，snapcf_c5crm2.f
节点1日志分析
对于节点2报错信息，需要结合节点1日志一起分析，节点1日志，11月3日早上2点0分7秒（ora trc中报错时间 2020-11-03 02：00：07.795）左右也有类似报错信息，报错信息ora-00245，ora-27090，报错意思大概是备份控制文件控制信息失败。
节点1定时任务
节点1日志只所以会备份控制文件，是因为在凌晨2点有清理归档日志脚本运行，所以有触发备份控制文件操作。
清理日志脚本内也出现备份控制文件失败报错，ora-00245，ora-27090，再次验证节点2报错又清理归档日志脚本引起。
清理日志脚本输出日志，时间点为（2020-11-03 02：00：07.997）
问题时间列表
下面梳理下本次报错的时间线。
| 节点一 | 节点二 | |
|---|---|---|
| 2020-11-03 02：00：00 | 清理日志脚本启动 | |
| 2020-11-03 02：00：07.795 | 节点1日志出现备份控制文件失败信息ora-00245，ora-27090 | |
| 2020-11-03 02：00：07.819 | 节点2日志出现备份控制文件失败信息ora-27037，ora-27090 | |
| 2020-11-03 02：00：07.997 | 节点1清理归档日志脚本输出日志出现备份控制文件失败信息ora-00245，ora-27090 | |
| 2020-11-03 02：00：11之后 | 节点2日志陆续出现ora-27090报错信息 |
总结
针对本此故障的处理，采用重启节点2实例的方式解决，之后MOS也有相关说明，可以把控制文件快照位置放在共享ASM磁盘组中，即可屏蔽此错误。但是目前还存在几个问题没有特别明白：
1、在节点1执行的备份控制文件操作，为何被发到节点2执行
2、在节点2执行也可，为何备份还是按照节点1设置的rman保留路径
3、为何此报错在节点2切换在线日志之后，5分钟后会重复提示
关于以上几个问题，还需查找相关MOS 资料。