Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Question on Incomplete Media Recovery

Re: Question on Incomplete Media Recovery

From: Rozz Williams <satarnag_at_hotmail.com>
Date: 19 Oct 2004 10:13:54 -0700
Message-ID: <bc356f74.0410190913.7414f209@posting.google.com>


"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<4174189d$0$10351$afc38c87_at_news.optusnet.com.au>...
> Rozz Williams wrote:
>
>
> You cannot *use* both simultaneously.
>
> As is evident from the rest of your post, you know this. You know that a
> choice has to be made. And the answer to your original question simply
> depends on the choice that you, er, choose to make.

Then I guess my question should be "which controlfile should I use and how would I restore based on the information I provided"  

> > The controlfile on Disk A is a surviving copy
> > containing current information. The controlfile on B will be a
> > restored copy from yesturday's backup.
>
> Yes, I know that. And which do you think you should use? Possessing both is
> not the point. The issue is which one does the intelligent DBA choose to
> use, when he or she knows that using the old copy on disk B will involve a
> resetlogs, and the one on disk A doesn't?

Actually, both will require a resetlogs because if Disk B goes down, I will lose all my online redo logs and all my archived redologs from last backup to point of failure. The only thing restored will be datafiles, one archived redo log backed up immediately after the datafiles and a controlfile. I will have to use resetlogs to create new online redologs and to tell Oracle to reset the SCNs of the datafiles.

> > I was also thinking of the following:
> >
> > 1. delete the control file on Disk A
>
> The essence of recovery is knowing when to stop digging the hole that is
> getting ever deeper!
>
> You have a perfectly functioning controlfile on Disk A. Why on Earth would
> you even *consider* deleting it?

To use the "recover database until cancel using backup controlfile" command.  

> The other essence of recovery is to restore that, and *only* that, which has
> actually failed. Making something else fail yourself by employing the old
> 'delete *' technique is usually not smart!

I agree, I just wanted all my options displayed so knowledgeable DBAs, such as yourself, can provide me with sound advice.

> > 2. Copy the newly restored controlfile from Disk B to Disk A
> > 3. startup mount
> > 4. recover database until cancel using backup controlfile
> > 5. issue a "cancel" (because I do not have any archived redo logs from
> > the last backup to the point of failure)
> > 6. alter database open resetlogs
>
> And you are happy issuing a command, are you, that requires an immediate
> shutdown of your database, a fresh, cold, complete backup, and the
> practical loss of all prior backups and archivelogs?

I am not happy with it. If I had full control of this database, I wouldn't need to do incomplete restores. However, I am only a consultant who is instructed to perform a Backup & Recovery document on a database in which I cannot do any modifications. For example, I would love to implement RMAN (since it's a 9.2.0.4 database) to make recovery from block corruption easier, but I am unable too.

I have no choice in the matter, and unfortunately, the database will need incomplete recovery in the event of media failure. They are totally aware of this and are willing to live with the risk.  

> Let me put it another way. Unless you absolutely, positively *have* to
> perform a resetlogs operation, one usually bends over backwards to make
> sure you don't perform one at all.

I agree, but when they pay you a lot of money and tell you to do something without making changes, one usually takes it up the tail pipe and keeps quiet.  

> > If it makes you feel better, Disk B is actually a bunch of drives
> > running RAID 5.
>
> It doesn't (make me feel better, that is). RAID 5 as a destination for redo
> writing is a no-no. Datafiles, I could live with. Redo logs, not.

I don't know if this old school thinking or not. I used to put any write intensive OS files (such as some datafiles) off of RAID 5 to RAID 0+1 (where each mirrored set of disks had it own independent path to the drives, of course). However, with advancements with disk and hardware RAID technologies, I think this might be a thing in the past.  

> > I just called it Disk B for simplicity sake. I am
> > actually trying to document an incomplete media recovery if more than
> > one drive fails on the RAID unit. The only reason why this will be an
> > incomplete recovery is because the archived redo logs are residing on
> > the RAID unit.
>
> And that's a no-no, too.

I agree, too many eggs in a unsafe basket.  

> Regards
> HJR
Again Thanks. I will assume that my original idea (6 steps) is valid. I will be doing testing later this week, but I didn't want to embarrass myself in front of the client.

Regards... Received on Tue Oct 19 2004 - 12:13:54 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US