asm中dismount导致rac一个节点宕机该怎么办

这篇文章将为大家详细讲解有关asm中dismount导致rac一个节点宕机该怎么办，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
asm日志/u01/app/grid/diag/asm/+asm/+ASM1/traceThu Jul 30 02:10:46 2015
WARNING: Waited 15 secs for write IO to PST disk 0 in group 1.WARNING: Waited 15 secs for write IO to PST disk 1 in group 1.WARNING: Waited 15 secs for write IO to PST disk 2 in group 1.WARNING: Waited 15 secs for write IO to PST disk 0 in group 1.WARNING: Waited 15 secs for write IO to PST disk 1 in group 1.WARNING: Waited 15 secs for write IO to PST disk 2 in group 1.Thu Jul 30 02:10:47 2015
NOTE: 免费云主机域名process _b000_+asm1 (38695) initiating offline of disk 0.3915941304 (DATA2_0000) with mask 0x7e in group 1NOTE: process _b000_+asm1 (38695) initiating offline of disk 1.3915941302 (DATA2_0001) with mask 0x7e in group 1NOTE: process _b000_+asm1 (38695) initiating offline of disk 2.3915941303 (DATA2_0002) with mask 0x7e in group 1
NOTE: checking PST: grp = 1GMON checking disk modes for group 1 at 12 for pid 28, osid 38695ERROR: no read quorum in group: required 2, found 0 disksDirty Detach Reconfiguration complete
Thu Jul 30 02:10:47 2015WARNING: dirty detached from domain 1NOTE: cache dismounted group 1/0xB368755B (DATA2) <–自己dismounted了SQL> alter diskgroup DATA2 dismount force /* ASM SERVER:3009967451 */Thu Jul 30 02:11:24 2015
NOTE: Instance updated compatible.asm to 11.2.0.0.0 for grp 1SUCCESS: diskgroup DATA2 was mounted <自己又mounted了SUCCESS: ALTER DISKGROUP DATA2 MOUNT /* asm agent *//* {0:31:15779} */
alert可以看到ASM磁盘dismount，并且是错误“Waited 15 secs for write IO to PST”的问题，这是ASM特有的心跳超时检测，
ASM instance会定期检查每个asm disk是不是能正常反馈Generally this kind messages comes in ASM alertlog file on below situations,Delayed ASM PST heart beats on ASM disks in normal or high redundancy diskgroup,thus the ASM instance dismount the diskgroup.By default, it is 15 seconds.By the way the heart beat delays are sort of ignored for external redundancy diskgroup.ASM instance stop issuing more PST heart beat until it succeeds PST revalidation,but the heart beat delays do not dismount external redundancy diskgroup directly.上面描述，可以理解为下面几点：1. ASM实例会定期检查每一个磁盘组的磁盘状态，是否通信正常；2. 这个检查，只是针对normal和high冗余模式，对于external冗余，不会遇到这个错误；3. 默认情况是15s超时，也就是说15s磁盘组还是没有对ASM实例响应的话，就会dismount磁盘组。在存储网络出现问题的情况下，会引发这个错误的出现。也就是说，在ASM定期发出检查信息的时候，如果磁盘没有在15s内反馈的话，就认为磁盘已经无法访问。实际情况是上面的凌晨2:10时间点正好是做全库备份时间,估计大量的写入导致io响应慢

在11.2.0.3.0之后才有这个参数出现，也就是说ASM实例对磁盘超时的检测是在11.2.0.3之后才出现的

set pages 9999;

SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV (‘Instance’)
AND y.inst_id = USERENV (‘Instance’)
AND x.indx = y.indx
AND upper(x.ksppinm) like ‘%ASM_H%’;
显示如下:_asm_hbeatiowaitnumber of secs to wait for PST Async Hbeat IO return_asm_hbeatwaitquantumquantum used to compute time-to-wait for a PST Hbeat check在存储网络条件不是很好的情况下可以设置检查时间长点,其实在12.1.0.2默认就是120秒了alter system set “_asm_hbeatiowait”=120 scope=spfile;重启asm 继续观察关于asm中dismount导致rac一个节点宕机该怎么办就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

相关推荐: Redis进程内消耗的是什么

这篇文章给大家分享的是有关Redis进程内消耗的是什么的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。Redis进程内消耗主要包括：自身内存+对象内存+缓冲内存+内存碎片。内存。因为redis的数据都是存储在内存当中。内存数据库相比一…