Luckily I have never had this situation in production,
and what I have read also suggests using the ascii
file created from 'BACKUP CONTROLFILE TO TRACE' for
recovery. I just had a little time on my hands and
decided to give it a try. As I stated, I am by no
means an expert in recovery (more like a novice), I
was just stating what I observed. Maybe someone else
will let us know their opinion.
Thanks for your input.
Rob Pegram
- "Jesse, Rich" <Rich.Jesse_at_qtiworld.com> wrote:
> Is this recovery method valid? The loss of
> controlfiles is supposed to be
> recovered using the trace file generated from a
> previous BACKUP CONTROLFILE
> TO TRACE, isn't it? At least according to the
> Oracle8 Backup and Recovery
> class it is.
>
> The part that concerns me is that you are recovering
> using an ONLINE redo
> log (don't know if it was the active one or not).
> Could be the paranoid in
> me, but that just doesn't seem right. The admission
> that "I don't think
> this is 100% true for every situation" would seem to
> suggest that you agree
> that this method shouldn't be used for
> backup/recovery on production
> databases.
>
> My $.02.
>
> Rich Jesse System/Database
> Administrator
> Rich.Jesse_at_qtiworld.com Quad/Tech
> International, Sussex, WI USA
>
> -----Original Message-----
> Sent: Friday, October 26, 2001 08:30
> To: Multiple recipients of list ORACLE-L
>
>
> Tim,
>
> > You can not simply cancel a "recover
> > database using backup
> > controlfile" since Oracle is expecting you perform
> a
> > complete recovery (
> > since your not using the UNTIL CANCEL/TIME/CHANGE
> )
> > and canceling a complete
> > recovery leaves the stop SCN in the controlfile at
> > infinity... Therefore,
> > the recovery is never complete and you will always
> > receive the "needs media
> > recovery message"...
>
> I don't think this is 100% true for every situation.
>
> I am no recovery expert, but I just did this the
> other
> day, and to verify it, I ran the test again this
> morning.
>
> 1. Shutdown abort
> 2. Delete all current controlfiles
> 3. Replaced the binary controlfiles from last hot
> backup (they were copied as part of the backup
> script)
> 4. Startup mount
> 5. Recover database using backup controlfile
> 6. Kept applying logs - only trick was that the
> last
> log was an online redo log, so I had to type in that
> log explicitly. There I received the message Media
> Recover Complete.
> 7. Alter database open resetlogs.
>
> Rob Pegram
> Oracle Certified DBA
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Jesse, Rich
> INET: Rich.Jesse_at_qtiworld.com
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from). You may
> also send the HELP command for other information
> (like subscribing).
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Robert Pegram
INET: pegramrg_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Fri Oct 26 2001 - 11:14:04 CDT
