Removing a diskgroup from a corrupt ASM database
daniel....@visaer.com
cannot see the disks. Therefore the diskgroup DATA is unmounted and
cannot be remounted.
I'm ready to start over from scratch, I dropped the non-ASM database,
but still have an ASM database that knows about an unmounted
diskgroup. But I cannot drop it because it is unmounted and I cannot
mount it because it is corrupt.
What do I do to free up this ASM instance to create a new diskgroup?
I'd even drop the entire ASM database but I cannot delete it via
DBCA. Short of uninstalling Oracle and reinstalling and creating
everything new, what can I do?
johnb...@sbcglobal.net
Look at the oracle doc ... drop diskgroup force ... and/or create
diskgroup force.
Oracle has comprehensive free doc on how to administer ASM. Probably
a better way to understand the environment than posting messages in a
newsgroup ... i'm just saying.
Mark D Powell
Daniel, you have not provided enough information about how ASM is
configured for anyone to give you specific advice. As John noted the
ASM documentation has a lot of information that may allow you to
recover from the loss. What you can do will depend on how ASM and the
diskgroup was configured: ASM mirrow, external mirror, etc ....
HTH -- Mark D Powell --
johnb...@sbcglobal.net
Hey Daniel I received an email failure trying to reply back to the
email you sent me. So here's a second attempt here.
John, I've long since tried the commands you suggested. I've read the
doc exhaustively. I've searched the web. The posting on the newsgroup
was a next step down the line, thank you.
My ( attempted reply ):
***************************
As part of DR testing and validating that we can recover from anything
ASM related the CREATE DISKGROUP ... FORCE has worked well for us.
It doesn't matter if the diskgroup is can be mounted or fails during a
mount attempt ... it destroys anything ASM related on the disks and re-
initializes them. This may be an 11g only thing so you might need to
upgrade the ASM to 11g before FORCE become s a valid option in ASM
create diskgroup.
onedbguru
Anyone using "single disks" (as opposed to SAN mirrored/RAIDed LUNS)
without the use of failure groups is asking for trouble. Replacing
the failed device is futile without having thoroughly worked out the
failover mechanisms to be able to reconstruct it without having to
restore all of your databases. Should you proceed with the the
"FORCE" option, you will need to be able to restore all of your
databases that resided in that ASM instance. If you have more than
one or it is very large, you have pretty much succeeded in toasting
your entire environment because of 1) a lack of understanding ASM or
2) lack of funding by pointy-haired morons that really don't value
their data.
One other thing you might consider for having designed this
environment in this manner:
alter dba update resume;
johnb...@sbcglobal.net
snip
> > As part of DR testing and validating that we can recover from anything
> > ASM related the CREATE DISKGROUP ... FORCE has worked well for us.
>
> > It doesn't matter if the diskgroup is can be mounted or fails during a
> > mount attempt ... it destroys anything ASM related on the disks and re-
> > initializes them. This may be an 11g only thing so you might need to
> > upgrade the ASM to 11g before FORCE become s a valid option in ASM
> > create diskgroup.
>
> Anyone using "single disks" (as opposed to SAN mirrored/RAIDed LUNS)
> without the use of failure groups is asking for trouble. Replacing
> the failed device is futile without having thoroughly worked out the
> failover mechanisms to be able to reconstruct it without having to
> restore all of your databases. Should you proceed with the the
> "FORCE" option, you will need to be able to restore all of your
> databases that resided in that ASM instance.
Who exactly does not know that?
Anyone who has deployed ASM without testing and documenting and
recovering from all conditions including having to rebuild the ASM
diskgroups from scratch just has not done their homework.
Go back and read the original post in this thread if you still are not
understanding what was asked.
daniel....@visaer.com
>
> - Show quoted text -
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.
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.
Thanks in advance for your help.
Dan
johnb...@sbcglobal.net
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.
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.
daniel....@visaer.com
>
> - 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
johnb...@sbcglobal.net
snip
Well I am glad you are back operating now ...
The ASM syntax is a little peculiar no doubt. I am using external
redundancy letting my storage arrays do the mirroring ... ( lots of
varied opinions here on how to use ASM on one side and the other ).
No FAILGROUPs.
You certainly need ( as far as I know ) commas between multiple disks
in the straight up case ... ( like ):
CREATE DISKGROUP some_name EXTERNAL REDUNDANCY DISK '/some_path/disk1'
FORCE,'/some_path/disk2' FORCE;
If you haven't already trashed it you should have something left over
from the original create via dbca that would have had the syntax used
the first time around by the GUI ... for whatever that's worth.
Have fun!
daniel....@visaer.com
>
> - Show quoted text -
All set. The recreating of the database was no problem. And I did
have a template from my original creation of the database. Thanks
again for your help!
Dan