Re: Removing a diskgroup from a corrupt ASM database
Date: Mon, 25 May 2009 18:00:58 -0700 (PDT)
Message-ID: <4bb07000-1149-4deb-8db9-76e6a577f8d2_at_h23g2000vbc.googlegroups.com>
On May 23, 7:28 pm, johnbhur..._at_sbcglobal.net wrote:
> On May 22, 2:53 pm, daniel.oster..._at_visaer.com wrote:
>
> > I had a disk failure so that the databases (ASM and actual database)
> > 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?
>
> 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.
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;
Received on Mon May 25 2009 - 20:00:58 CDT