Re: Removing a diskgroup from a corrupt ASM database

From: <johnbhurley_at_sbcglobal.net>
Date: Wed, 27 May 2009 06:15:54 -0700 (PDT)
Message-ID: <f66c94cb-0dc8-4f6b-b71c-b26807ce23d6_at_l32g2000vba.googlegroups.com>



On May 26, 5:19 pm, daniel.oster..._at_visaer.com wrote:

snip

> John, Onedbguru, et al,
>
> Thanks for your help.  I'm just a little taken aback by the sniping at
> me.  I posted one message, suddenly it's grown into a situation where
> I have a "single disk", I've hosed my production system, I should look
> for another job, I should be ashamed of myself for lack of
> preparation, etc.  Respectfully, I'm just looking for a little help on
> this, no big deal.

Hey that's all part of the fun here eh?

I haven't see postings from onedbguru before much around here not sure where he is coming from. Apologies if my remark was a little short but people are implementing ASM right and left without at times going back to square one and seeing "if ASM and all my disks go away completely ... what do I do step by step to get my databases back?".

That's one reason to me that keeping archive logs or important stuff like that in an ASM diskgroup is probably a really really bad idea but that's a slightly different rant.

> Some background: This is a test system.  This is a system on which I
> am trying to better learn ASM.  No, I am not an expert on ASM.  I have
> practiced many scenarios on which I've physically removed disks from a
> running database, rebalanced, put new disks back, rebalanced again,
> etc, etc.  No, maybe I haven't practiced every scenario.
>
> We have a 14 disk Dell Powervault array, I use NORMAL REDUNDANCY in
> ASM.  Per recommendations from many, including Tom Kyte, I'm not using
> the external redundancy provided by the array, instead I'm letting ASM
> do it with its striping/mirroring.
>
> What happened was one day (on its own, not purposely caused by me
> while practicing DR) our Windows system had a disk i/o error, and soon
> after the diskgroup became unmounted and the database crashed.  I have
> run diagnostics on the disks, worked with Dell, made sure all drivers/
> firmware were updated, etc.  THe hardware has passed every check.  I
> tried to remount with the force option, I tried creating the original
> diskgroup from scratch, tried disk discovery, cleared configuration
> (without initializing) etc.  Because I don't care about the data or
> database, I decided to delete the non-ASM database, wipe out the
> array, initialize, re-partition and stamp the disks in ASM.  The disks
> are not set up exactly as before, just with no data.  The ASM database
> still does not see the original diskgroup.  I can probably use a
> different named diskgroup to get this up and running, but ASM is still
> looking for the original.  I can also uninstall/reinstall Oracle and
> start from scratch, but I'd rather not punt if I don't have to.
>
> I hope this is enough info.  It's not a desperate situation, I'm just
> looking for a little help while I research offline.
n

ASM really only accesses disk storage from the disk groups that are available to it. Well except for perhaps an SP file where it will record things like the discovery paths ...

What do you get exactly using the CREATE DISKGROUP blah blah blah FORCE? The FORCE needs to be specified for each disk/lun ...

This should basically tell ASM don't worry about any residual information on the disk/LUN that you see out there that makes you think it used to belong to a prior diskgroup ( which can be the same name or not as the diskgroup being recreated ) ... just do it.

It really should work to fix your situation. Possibly works better or more improved in 11g? But still try and give it a shot in 10 ASM if you have to ... I think it is a valid option in 10. Received on Wed May 27 2009 - 08:15:54 CDT

Original text of this message