I tried it both ways and got the same result.

According to my notes from the Oracle Backup and Recovery course
when you apply your redo logs, the control file gets rolled forward
along with the data files.  I believe that the only time you would get
into trouble here is if you had made structural changes after the
control file was backed up.  This should not be an issue in my
application.

Peter Schauss
Northrop Grumman Corporation

-----Original Message-----
Sent: Monday, March 10, 2003 4:08 PM
To: Multiple recipients of list ORACLE-L


Peter - Shouldn't you backup the controlfile AFTER completing tablespace
backups?

Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 


-----Original Message-----
Sent: Monday, March 10, 2003 2:37 PM
To: Multiple recipients of list ORACLE-L


I am implementing hot backups on a small development database
using the following approach:

1.  From sqlplus:  backup controlfile to '<filename>';
2.  For each tablespace
    - sqlplus:  alter tablespace <name> begin backup;
    - shell:  copy files for that tablespace
    - sqlplus:  alter tablespace <name> end backup;
    - sqlplus:  alter system switch logfile;
3.  tar and gzip the tablespace copies and backup control file;

As a test, I am restoring the files to another system by
doing the following:

1.  Copied the init.ora file from the backed up database.
2.  Restore the copied tablespaces and control files.
3.  Copy the archived redo logs to the directory specified
    in the init.ora file.
4.  Note the number on the most recent redo log.
5.  sqlplus internal
    startup mount
    recover database until cancel using backup controlfile;
        (hit return when prompted for the next file until
         the last redo log noted in step 4 has been processed,
         then type CANCEL in response to the prompt for the next
         file.)
    alter database open reset logs;

The above steps work, but I am wondering is there a better way to
handle the control files so that I do not have to use the "until
cancel" option.

Thanks,
Peter Schauss
Northrop Grumman Corporation
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Schauss, Peter
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Schauss, Peter
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).

Reply via email to