背景
客戶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 資料。