Yup, I have used them before for recovery when cloning devices. The tricky part
is that, at least until now, it has not been a standard practice for me to
monitor ASM LUNs corruption enterprise-wide. These are ghost issues and they
will haunt you when you least expect them during a ‘routine’ system reboot
maintenance.
----------------------------------------
Thanks
From: Mark J. Bobak
Sent: Friday, March 18, 2016 12:41 PM
To: Ludovico Caldara; fmhabash@xxxxxxxxx
Cc: ORACLE-L
Subject: Re: ASM Header Block Corruption: Do you Monitor for It?
Hi Fred,
Starting with 11g, the asmcmd command haa 'md_backup' and 'md_restore' for ASM
header backup and restore.
It's been a few years, and my memory is faded, but I believe I configured ASM
header backups at PQ, for at least some dbs.
Hope that helps,
-Mark
On Fri, Mar 18, 2016, 11:35 Ludovico Caldara <ludovico.caldara@xxxxxxxxx> wrote:
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
