Re: Removing a diskgroup from a corrupt ASM database
Date: Wed, 27 May 2009 07:50:45 -0700 (PDT)
Message-ID: <69875556-903c-4975-a870-92dc12df3cce_at_l32g2000vba.googlegroups.com>
On May 27, 9:15 am, johnbhur..._at_sbcglobal.net wrote:
> 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.- Hide quoted text -
>
> - Show quoted text -
John,
No problems, appreciate your help.
Per your advice I pursued the recreating of the diskgroup. Nothing worked, I kept getting various errors including ORA-15106, which said my disk paths were wrong. As I knew they were right, I researched further. Finally I found a deeply buried post in MetaLink saying to remove the commas from disk listing in the 'CREATE DISKGROUP' statement. This goes against all the official Oracle doc, but it worked! And without the FORCE option (not sure why). When I did all this from scratch, I created the ASM database and did everything via DBCA. But now, since I had to fix the ASM database, I had to do the create diskgroup manually. I'm able to bounce the ASM database and the diskgroup is mounted and appears healthy.
Here's my create diskgroup statement that worked. I use a fail group for each disk. There's only 13 disks as one slot is empty. CREATE DISKGROUP DATA NORMAL REDUNDANCY
FAILGROUP DATA_0000 DISK '\\.\ORCLDISKDATA0' FAILGROUP DATA_0001 DISK '\\.\ORCLDISKDATA1’ FAILGROUP DATA_0002 DISK '\\.\ORCLDISKDATA2' FAILGROUP DATA_0003 DISK '\\.\ORCLDISKDATA3' FAILGROUP DATA_0004 DISK '\\.\ORCLDISKDATA4' FAILGROUP DATA_0005 DISK '\\.\ORCLDISKDATA5' FAILGROUP DATA_0006 DISK '\\.\ORCLDISKDATA6' FAILGROUP DATA_0007 DISK '\\.\ORCLDISKDATA7' FAILGROUP DATA_0008 DISK '\\.\ORCLDISKDATA8' FAILGROUP DATA_0009 DISK '\\.\ORCLDISKDATA9' FAILGROUP DATA_0010 DISK '\\.\ORCLDISKDATA10' FAILGROUP DATA_0011 DISK '\\.\ORCLDISKDATA11' FAILGROUP DATA_0012 DISK '\\.\ORCLDISKDATA12';
My next task is to build the non-ASM database. Hopefully that will go smoothly and I can get everything back good as new. I'll let you know how I make out.
Again, thanks for the help.
Dan
Received on Wed May 27 2009 - 09:50:45 CDT