Re: benefits of multiple switch logfile calls?

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<3fd4d2c3$0$13682$afc38c87_at_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.

I have located your writeups at www.geocities.com/lydian_third. They are very well written and appear to have a ton of knowledge behind them. I am saving off this url for future reference.

I've found in the backup /recovery doc your explaination of rebuilding the controlfile (any what you've said in these posts). I agree that if you don't need resetlogs your are in better shape.

I take your correction about what oracle support told me about "using backup controlfile" because if whay you use works it is superior.

However see below of where I have a problem with your communications.

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

What I do have a problem with is your attitude!

I agree that I don't know everything about how oracle recovery works. I feel that oracle training / knowlege wise, this is the most important place to put your effort and training dollars.

But you're very critical of someone's (really some group of people's) technique that works, is proven to work, works repeatedly, but maybe doesn't stand up to your standards knowledgewise, and could be improved some. It's almost as though my lack of knowledge has caused you to be so critical, not the facts of our ability to recover?

Maybe what's going on is a difference of opinion on how important it is to Not use "resetlogs" at d/r. I've never considered this to be an issue in the past, however with your input, I'm aware that I will have a recovery problem at d/r from when I do the resetlogs till I get a hot backup started (and in some senarios till the newly getting cut archive logs are on tape).

My idea of protecting this time frame with a rerestore of the d/r tapes will only work using what you've shown in your recovery doc of using a terribly convoluted process of getting the system to recover with the newly numbered archive log files after the first recovery completes.

regards,
Lynn
>
> You are of course free to continue to do as you see fit.
>
> HJR
Received on Tue Dec 09 2003 - 16:54:46 CST