Re: ASM Header Block Corruption: Do you Monitor for It?
From: Ludovico Caldara <ludovico.caldara_at_gmail.com>
Date: Fri, 18 Mar 2016 16:34:28 +0100
Message-ID: <CALSQGrKRB0M-SPsMgWVAKofYKXBrywjqqaasdDNJsH7Oa-tTyg_at_mail.gmail.com>
Hi, it is a good practice. I've got a recent issue by a customer where I was not able to add nodes to a running cluster and realized that the cause were the corrupted headers of ALL the ASM disks. I fixed the headers LIVE with the existing nodes running, without affecting the cluster availability.
Had the customer decided to restart the cluster prior to add the new nodes, he would have exposed it to an important downtime... HTH 2016-03-18 16:26 GMT+01:00 <fmhabash_at_gmail.com>:
Date: Fri, 18 Mar 2016 16:34:28 +0100
Message-ID: <CALSQGrKRB0M-SPsMgWVAKofYKXBrywjqqaasdDNJsH7Oa-tTyg_at_mail.gmail.com>
Hi, it is a good practice. I've got a recent issue by a customer where I was not able to add nodes to a running cluster and realized that the cause were the corrupted headers of ALL the ASM disks. I fixed the headers LIVE with the existing nodes running, without affecting the cluster availability.
Had the customer decided to restart the cluster prior to add the new nodes, he would have exposed it to an important downtime... HTH 2016-03-18 16:26 GMT+01:00 <fmhabash_at_gmail.com>:
> Recently, we got affected by a nasty ASM header block corruption. We were
> able to kfed repair and, subsequently, mount the DG. We realized, though,
> that such corruption will not affect the cluster/DB while it is running. It
> only gets you when ASM is restarted and it needs to mount the DG.
>
>
>
> Given this scenario, I believe it is best practice, then, to monitor such
> corruption in some regular automated fashion. I never had to, but this
> incident, making it look it is necessary.
>
>
>
> How are you addressing this potential issue?
>
>
>
> ----------------------------------------
> Thanks
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Mar 18 2016 - 16:34:28 CET