RE: Clarification on conventional backup
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <lambu999@xxxxxxxxx>, "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 3 Jan 2008 15:25:53 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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.
Other related posts:
