某客戶RAC數據庫服務器主機輪流發生集群與主機重啟，數據庫連接不上問題，如下為故障診斷思路。
一、故障現象
告警日志:
Sun Feb 09 14:18:42 2020
Auto-tuning: Shutting down background process GTX2
Sun Feb 09 15:06:00 2020
NOTE: ASMB terminating
Errors in file /opt/oracle/App/diag/rdbms/xxxx/xxxx1/trace/xxxx1_asmb_7463.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 68 Serial number: 5
Errors in file /opt/oracle/app/diag/rdbms/xxxx/xxxx1/trace/xxxx1_asmb_7463.trc:
Errors in file /opt/oracle/app/diag/rdbms/xxxx/xxxx1/trace/xxxx1_asmb_7463.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 68 Serial number: 5
ASMB (ospid: 7463): terminating the instance due to error 15064
Termination issued to instance processes. Waiting for the processes to exit
Sun Feb 09 15:06:11 2020
Instance termination failed to kill one or more processes
Instance terminated by ASMB, pid = 7463
Sun Feb 09 15:12:24 2020
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = UNLIMITED
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB
RECOMMENDATION:
Total System Global Area size is 24 GB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 12289 (page size 2048 KB, total size 24 GB) system wide to
get 100% of the System Global Area allocated with large pages
********************************************************************
從數據庫告警日志可以發現，核心進程asmb 在2.9日15.06分 突然提示正在終止，隨后一節點數據庫報錯，不能與 ASM通信, 也就是連不上 ASM存儲,檢查ASM告警日志發現，核心進程ASMB 在2.9日15.06分 被kill 掉，隨后一節點的ASM實例掛掉，導致一節點數據庫也緊跟著掛掉
二、故障原因
從15:03開始
一節點開始報 voting file所在的磁盤，IO通信有超時的現象，磁盤hang住, 到15.05分開始 ocr_vote磁盤離線，一節點被剔出集群，
后續檢查主機，發現主機重啟過，檢查操作系統日志，發現從15.02分開始，: INFO: task ocssd.bin:16080 blocked for more than 120 seconds. 有任務被hung 住，
該錯誤是由于IO子系統的處理速度不夠快，不能在120秒將緩存中的數據全部寫入磁盤。IO系統響應緩慢，導致越來越多的請求堆積，最終IO 耗盡，系統內存全部被占用，導致系統失去響應，發生故障。
三、故障解決
建議一：
可以調整 操作系統參數，
vm.dirty_ratio=20
vm.dirty_background_ratio=3
目前操作系統配置文件/etc/sysctl.conf 中 沒有這兩個參數 ，建議調整，sysctl -p 生效，（調整該操作系統參數不用重啟主機） vm.dirtybackgroundratio 這個參數指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如5%）就會觸發pdflush/flush/kdmflush等后臺 回寫進程運行，將一定緩存的臟頁異步地刷入外存;
操作系統參數說明:
vm.dirty_ratio 這個參數則指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如10%），系統不得不開始處理緩存臟頁（因為此時臟頁數量已經比較多，為了避免數據丟失需要將一定臟頁刷入外存）；在此過程中很多應用進程可能會因為系統轉而處理文件IO而阻塞。
建議二:
另外在檢查中，發現該主機未配置大頁，建議配置大頁，可以極大提升數據庫性能
后期調整后至今沒有發現主機重啟，故障解決。
原文閱讀：
https://www.modb.pro/db/22702?YYF更多數據庫相關干貨，歡迎訪問墨天輪官網：https://www.modb.pro/?YYF
