ORACLE RAC中最主要存在2種clusterware集群件心跳 & RAC超時機制分析：
1、Network Heartbeat 網絡心跳 每秒發生一次； 10.2.0.4以后網絡心跳超時misscount為60s,；11.2以后網絡心跳超時misscount為30s。
2、Disk Heartbeat 磁盤心跳 每秒發生一次； 10.2.0.4以后 磁盤心跳超時DiskTimeout為200s。
注意不管是磁盤心跳還是網絡心跳都依賴於cssd.bin進程來實施這些操作，在真實世界中任何造成cssd.bin這個普通用戶進程無法正常工作的原因均可能造成上述2種心跳超時， 原因包括但不局限於 CPU無法分配足夠的時間片、內存不足、SWAP、網絡問題、Votedisk IO問題、本次磁盤IO問題等等。
此外在使用ASM的情況下，DB作為ASM實例的Client客戶； ASM實例會對DB實例的ASMB等進程進行監控， 以保證DB與ASM之間通信正常。 若DB的ASMB進程長期無響應(大約為200s)則ASM實例將考慮KILL DB的ASMB進程，由於ASMB是關鍵后台進程所以將導致DB實例重啟。
也存在其他可能的情況，例如由於ASMB 被某些latch block, 會阻塞其他進程，導致PMON進行強制清理。
綜上所述不管是Clusterware的 cssd.bin進程還是ASMB進程，他們都是OS上的普通用戶進程，OS本身出現的問題、超時、延遲均可能造成它們無法正常工作導致。建議在確認對造成OS長時間的網絡、IO延時的維護操作，考慮先停止節點上的Clusterware后再實施。
另可以考慮修改misscount、Disktimeout等 心跳超時機制為更大值，但修改這些值並不能保證就可以不觸發Node Evication。
關於RAC /CRS對於本地盤的問題，詳見如下的SR回復：
Does RAC/CRS monitor Local Disk IO ?
Oracle software use local ORACLE_HOME / GRID_HOME library files for main process operations.
There are some socket files under /tmp or /var/tmp needed for CRS communication.
Also, the init processes are all depending on the /etc directory to spawn the child processes.
Again, this is a complicated design for a cluster software which mainly rely on the OS stability including local file system.
Any changes to storage / OS are all recommended to stop CRS services since those are out of our release Q/A tests.