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: benefits of multiple switch logfile calls?

Re: benefits of multiple switch logfile calls?

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Tue, 9 Dec 2003 06:36:34 +1100
Message-ID: <3fd4d2c3$0$13682$afc38c87@news.optusnet.com.au>


Comment in line.

"lsattle" <lsattle_at_yahoo.com> wrote in message news:95898986.0312081118.32b480b1_at_posting.google.com...
> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
news:<3fd28737$0$20308$afc38c87_at_news.optusnet.com.au>...
> > "lsattle" <lsattle_at_yahoo.com> wrote in message
> > news:95898986.0312061724.322dd9b2_at_posting.google.com...
> >
> > > I will have to do some homework on what you are saying. I agree,
> > > using the trace (non binary) version of the controlfile will work
> > > (I've proved it during cloning). However you are coming across as
> > > expert with all the answers.
> >
> > There might be a reason for that.
>
> I have researched old doc that I have and have thought out a few
> things.
> All of my doc talks about backing up the controlfile (binary). None
> of it addresses exactly a disaster recovery full restore. (although I
> would argue that it implies you will restore this binary control file
> instead of a backed up copy of the real control files). I agree and
> understand that you can't make all of your plans to to a d/r restore,
> but must be flexible to handle all situations.
>
> I also agree that it is just fine to rebuild your control files from
> the "bu to trace" file.
>
> However let me state that I will question where you are coming from
> later on in my post.
>
> >
> > >My orignal intention of posting against
> > > the original message was that I have found Oracle's older writeups to
> > > have holes.
> >
> > Certainly.
> >
> > >I never remember seeing them say to not bu and restore
> > > the online redo logs (but one of their documents we looked at this
> > > week did say to skip the online redo logs). Maybe I'm wrong, I have
> > > some old doc from the mid nineties (class material also) and I will
> > > look it up.
> >
> > It pays to keep current. I dread to think of the nonsense that was
taught in
> > 8.0 Performance Tuning. It's still not perfect, but at least these days
they
> > are strongly dissuading people from Buffer Cache Hit Ratio tuning
> > approaches. But the 8.0 backup and recovery stuff was pretty sound, and
I
> > don't remember any particular howlers. Before that... dunno. But I
wouldn't
> > be applying version 7 backup and recovery techniques to an 8.0+
database,
> > regardless.
> >
> > > In totality I'm reading your bone of contention to be that I restore
> > > the binary control file and use it in the recovery (at D/R). What I'm
> > > not sure of is where / why you are saying I am at risk.
> >
> > Because (RMAN excepted) there is seldom a need to use the binary version
of
> > the backup controlfile; because doing so requires a resetlogs; because a
> > resetlogs renders all prior backups and archive logs redundant;
therefore a
> > resetlogs requires an immediate new backup to be taken; therefore your
> > database is vulnerable to a further failure until that backup is
complete;
> > and that none of that risk and expense need be incurred in the first
place.
> >
> I'm questioning you on these points. At first I thought this argument
> had some merrit, but after some thinking I don't agree. If I do a
> d/r recovery and have to do a resetlogs, I am not in any kind of bad
> position (at least not any worse than you are). If 8 hours (let say
> 10pm) after a d/r recovery of my type I still have recovery to this
> point in time assuming I have my archive logs up to then. I can
> always restore the system again (with the d/r backups used in the
> first recovery) and let the recovery run to the 10pm archive logs.
> Now grant you I may not have as nice of a "file" recovery during this
> time frame till I run a new hot backup at the d/r site.
>
> But let me ask you what you do that gets you out of this same
> situation. If you do a d/r restore and build the control files with
> the "bu to trace" file don't you have to resetlogs when you open the
> db.

No you don't. And that's the point.

>Maybe I'm wrong but Oracle support told me once that anytime you
> do a recovery that has messed with the control files you have to add
> the "using backup controlfile" parameter to the recover database
> statement. Using the "using backup controlfile' parameter forces a
> resetlogs I believe.

You believe incorrectly, and have misunderstood Oracle support. When you restore a binary version of the control file, yes a resetlogs is required. When you use the trace file method of recovery, there is no resetlogs.

>
> > And mainly because the actions one takes when performing recovery should
> > depend on the nature of the failure, or the nature of the result
required,
> > not something which originally came across as a one-size-fits-all,
> > lowest-common-denominator, mis-use of recovery commands.
> >
> > > Why does oracle provide a backup command to back up the binary
> > > controlfile?
> >
> > Because there are certain occasions when it might be appropriate!
> >
> > >
> > > You come across as an expert with "the only way". How many d/r
> > > recoveries have tested / proved out?
> >
> > Then you're reading me wrong. Everyone is entitled to find a backup and
> > recovery scenario which works for them, and which they are happy with.
All
> > I'm saying is that this isn't, or shouldn't, be 'fumble in the dark'
stuff.
> > The consistency and recovery mechanisms which Oracle uses are quite well
> > documented, easily understood, and a scientific approach to backup and
> > recovery is therefore perfectly attainable. That, as a result, whichever
> > backup and recovery strategy you opt for should be based on those
scientific
> > principles, should be logical, robust and capable of withstanding
changing
> > circumstances.
> >
> > And that in a public forum, one should push 'best practice', not stuff
which
> > happens to work for a particular person/organisation with a particular
> > set-up, the subtle details of which we can never really find out here.
>
> Again I ask you where are you coming from on this? I've looked at
> your website but could not figure out how to read your recovery docs.
> In your arguments to me you have never referenced any Oracle doc that
> would criticize what we are doing.
>
> You said in one of your earlier posts "Restoring a controlfile
> unnecessarily is a crazy thing to do, since it requires the use of the
> 'until cancel' syntax, which itself requires that the database then be
> opened with a resetlogs, which thus means no prior backups or archives
> are usable without severe hoop-jumping"
>
> If your above statement is accurate (and maybe it is) please reference
> the Oracle doc you got it from or else I will accuse you of your own
> statements from a prior post:

Sorry. But scientific testing requires a bit more than being able to quote Oracle documents off the top of my head. Read their own backup and recovery documents, however, and you will see that there is nothing wrong with the statement that you quote, at all.

Try www.geocities.com/lydian_third. Look under 'Books'. Find the one on backup and recovery.

> The bottom line is our recovery has worked and works good.

The bottom line is actually as evidenced in this reply of yours. You don't know how Oracle works (trace file recoveries do not require a resetlogs.).

You are of course free to continue to do as you see fit.

HJR Received on Mon Dec 08 2003 - 13:36:34 CST

Original text of this message

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