RE: Clarification on conventional backup

I'm not sure what question you are trying to answer, but I'll try to answer the two most likely questions which you might be trying to answer simultaneously instead of independently.  

If you're planning a complete recovery at some future point in time, then you likely have a current control file copy available.  

The trace backup is likely being provided in the current set up to provide a single set of files that is internally consistent that can actually be restored up to the point of the last archived redo log after the switch that takes place after the end backup of the last tablespace after all the data files have been copied to backup media. I hope they are definitely waiting for the archive to complete of that last switched log file to complete if that is the intent. If so then the backup set competantly copied would be recoverable to the point in time of the switch, and yes you would use reset logs. And additional archived redo logs also could be applied from additional future backup sets to get arbitrarily close to current.  

Conversely, if you recovered this set AND had additional future archived redo logs, AND online redo logs, AND a current control file complete recovery without reset logs should also work routinely.  

Other varieties of complete recovery are also possible with use of the keywords "USING BACKUP CONTROLFILE" but you may have to supply the names of the current online redo logs to be applied. That is why backing up the online redo logs (if they still exist) is the first step of physical recovery - so if something goes wrong you can try again. My preference is to not include online redo logs on backup sets for the reason that it is an easy trap for operations to step into to reload the old image of the online redo logs destroying the latest database updates that have indeed not yet been archived. Without resurrecting the quasi-religious war about inclusion of online redo logs in backups (a logical argument of arguable value can be made that the simplest thing to do for cold backups is just copy everything, including the control files and online redo logs), if you make an online copy to a special online location of the online redo logs as the first step of recovery, you add to the chances you'll never screw up irretrievably. Ditto a copy of the current control file.  

I hope that was not too long, nor too short.  

Regards,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Ram K
Sent: Thursday, January 03, 2008 11:23 AM To: oracle-l
Subject: Clarification on conventional backup  

Listers,    

I am on a new assigment where they are still using user managed recovery in 9i. Before I move to RMAN, I was looking at the scripts to see things are OK as is. The way it is set up now, it backs up the datafiles, arch logs after doing the switch and then the control file to trace. I thought the control file would have to be backed up in binary mode to perform a complete recovery. Would we not lose SCN information if control files are backed up to trace? With control file trace backup, I think that the database has to be opened with 'reset logs' losing any latest changes to the database.    

Can you please confirm. Thanks.    

--

Thanks,
Ram.

--

http://www.freelists.org/webpage/oracle-l Received on Thu Jan 03 2008 - 14:25:53 CST