RE: ASM Header Block Corruption: Do you Monitor for It?
Date: Fri, 18 Mar 2016 14:25:02 -0400
Message-ID: <56ec47ff.4a2d320a.ff2db.08e4_at_mx.google.com>
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_at_gmail.com
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_at_gmail.com> 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_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-l
Received on Fri Mar 18 2016 - 19:25:02 CET