Winnie,
Sorry, but that is not correct. You must open with
resetlogs when performing an incomplete recovery.
Using the BACKUP CONTROLFILE clause does NOT signify
an incomplete recovery. Using an UNTIL clause
specifies incomplete recovery.
In order to do complete recovery, whether you have a
current or backup controlfile, you must have the
current online log. If you're using the current
controlfile it knows to use the online log when it
reaches the last log sequence to finish the complete
recovery. If you're using a backup controlfile, you
have to manually point it to the current online log.
This is one of the many reasons why you shouldn't
recreate the controlfile unless absolutely necessary
(e.g. to change the db_name). In fact there is at
least one recovery option, and there are probably
others, which can't be done if you've recreated the
controlfile, which is creating the datafile when you
don't have a copy of it, but you have all the archived
logs since it was added to the db. If you recreate
the controlfile the information needed to properly
create the datafile header is gone. But I digress...
Back to the original issue, let's say that the last
archived log is log sequence 500 and log group 2 has
the current log sequence 501.
RECOVER DATABASE USING BACKUP CONTROLFILE;
this will eventually prompt for archived log
sequence 501 because this is a backup controlfile so
it doesn't have an entry for this sequence.
specify the full path for a member of log group 2
You will then get a "media recovery complete" message.
You will not get prompted for log sequence 502 because
recovery will have hit the end of file marker in the
online log so it knows that there are no further
changes to apply (i.e. that a complete recovery has
been done).
You may now open the database normally (i.e. without
resetlogs).
On the other hand, once you have started an incomplete
recovery (using an UNTIL clause), even if you point to
the online log and perform a complete recovery you
will have to open with resetlogs. I'm assuming this
is because once incomplete recovery is started, the
incomplete recovery scn is set in all the file headers
and this never gets unset during a recovery process.
HTH,
- Anita
- Winnie_Liu_at_infonet.com wrote:
>
> Exactly. That is why you always have to open
> resetlog if you are recovering
> from a backup controlfile.
>
> Winnie
>
>
>
>
>
> Jack Silvey <JSilvey_at_XOL.com> on 06/30/2000 02:56:25
> PM
>
> Please respond to ORACLE-L_at_fatcity.com
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> cc: (bcc: Winnie Liu/HQ/ISC)
>
>
>
>
>
> Recovery with backup controlfile bad!
>
> I think that after you have applied the last redo
> log you have to cancel
> the
> recovery and open resetlogs.
>
> Since you have a backup controlfile, Oracle cannot
> know what the last
> logfile number was, so just asks you for another. I
> think you gotta tell it
> there aint no more.
>
> Jack
> Senior @ xol
> ocp X 2
>
> -----Original Message-----
> Sent: Friday, June 30, 2000 4:26 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I am testing out my backup/recovery strategy. As
> noted
> in my previous posting, I am using the following to
> back up
> my database while it is on line:
>
> alter tablespace xxx begin backup;
>
> <copy data files for tablespace xxx>
>
> alter tablespace xxx end backup;
>
> .... ( for all tablespaces)
>
> alter system switch logfile;
>
> alter database backup controlfile to 'xxxx';
>
>
> To simulate a complete system failure, I then shut
> down the database,
> and deleted all data and control files, including my
> online redo logs.
>
> Then I copied my data files and backup control file
> back to their
> original locations and ran svrmgrl:
>
> SVRMGR> connect internal
> connected
> SVRMGR>startup mount
> ....
> Database mounted.
> SVRMGR> recover database using backup controlfile;
>
> SVRMGR responds:
>
> ORA-00279: change 124216483 generated at 06/30/00
> 13:01:49 needed for
> thread
> 1
> ORA-00289: suggestion :
> /u010/oradata/fiao3/arch.log1_10298.dbf
> ORA-00280: change 124216483 for thread 1 is in
> sequence #10298
> Specify log: {<RET>=suggested | filename | AUTO |
> CANCEL}
> AUTO
> Log applied.
> ORA-00279: change 124216530 generated at 06/30/00
> 13:13:45 needed for
> thread
> 1
> ORA-00289: suggestion :
> /u010/oradata/fiao3/arch.log1_10299.dbf
> ORA-00280: change 124216530 for thread 1 is in
> sequence #10299
> ORA-00278: log file
> '/u010/oradata/fiao3/arch.log1_10298.dbf' no longer
> needed for this recovery
> ORA-00308: cannot open archived log
> '/u010/oradata/fiao3/arch.log1_10299.dbf'
> ORA-27037: unable to obtain file status
> SVR4 Error: 2: No such file or directory
> Additional information: 3
>
>
> arch.log1_10299.dbf does not exist and, as far as I
> know, never did.
> I did not delete it, in any event.
>
> What am I doing wrong here?
>
> Why svrmgr think that there should be another
> archived log file?\
>
> BTW, I am doing this on a test instance for which I
> have a cold backup,
> so, if there is something missing from my backup I
> do have the option to
> put the whole thing back to the status quo ante and
> start over with the
> a revised online backup.
>
> thanks,
> Peter Schauss
> Parker Hannifin Corporation
> Smithtown, NY
>
>
> --
> Author:
> INET: pschauss_at_parker.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).
> --
> Author: Jack Silvey
> INET: JSilvey_at_XOL.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).
>
>
>
>
>
>
> --
> Author:
> INET: Winnie_Liu_at_infonet.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
Received on Sat Jul 01 2000 - 06:08:27 CDT
