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@xxxxxxxxx>:
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
