Re: benefits of multiple switch logfile calls?

"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. 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.

> 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:

"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."

The bottom line is our recovery has worked and works good. You may have some better ways but I'll have to say you've been very critical of something that works and to my knowledge follows oracle's doc. Please show me where I'm wrong on this.

Regards
Lynn Sattler

>
> Regards
> HJR
Received on Mon Dec 08 2003 - 13:18:37 CST