Yes, I believe there is a better way.

1) Get the current SCN
2) Update a record in the DB with SCN# & COMMIT;
3) Get the current SCN;
4) While #1 SCN <> #3 SCN go to #1
5) switch logfile
6) Write #3 SCN out to a file which can be used to decide when to stop
applying redo logfiles.
7) After the DB gets opened, you can verify the SCN# in the datafile
matches the DB.



                                                                                       
                                                  
                      "Schauss, Peter"                                                 
                                                  
                      <[EMAIL PROTECTED]        To:       Multiple recipients of list 
ORACLE-L <[EMAIL PROTECTED]>                   
                      rumman.com>                cc:                                   
                                                  
                      Sent by:                   Subject:  Hot backups                 
                                                  
                      [EMAIL PROTECTED]                                                
                                                   
                                                                                       
                                                  
                                                                                       
                                                  
                      03/10/2003 12:36 PM                                              
                                                  
                      Please respond to                                                
                                                  
                      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: 
  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