Hi,

George Sinclair schrieb:

> The problem we see is that while we can recover the production
> database for any given time, including the control file (the catalog
> gives us this capability), we can only recover the control file for
> the catalog database itself from the most recent backup. We are
> unable to go back to any previous versions. 

You do not need a catalog to restore to previous versions.
If you loose your catalog db including the current controlfile
you can either restore the controlfile from autobackup
(of course controlfile autobackup has to be enabled for this)
or you can use dbms_backup_restore.

Restoring from autobackup is much easier, so you should enable
controlfile autobackup at least on the catalog db. After restoring
the cf, you can do something like:  

RUN
{ 
  SET UNTIL TIME 'Nov 15 2002 09:00:00';
  # SET UNTIL SCN 1000;       # alternatively, specify SCN
  # SET UNTIL SEQUENCE 9923;  # alternatively, specify log sequence 
number
  RESTORE DATABASE;
  RECOVER DATABASE;
}

> But there could be a situation 
> wherein we needed to recover some previous version of the
> production database using the catalog, but maybe for whatever
> reasons, we experience problems with recovering the most recent
> version of the control file for the catalog. e.g. bad area on tape,
> maybe the clone wasn't successful, whatever.  

If using controlfile autobackup, RMAN will look for a good 
controlfile backuppiece in it's default location or on the channel
you specified. By default it looks back seven days and takes the most 
recent readable cf it finds. By changing the MAXDAYS parameter
you can influence how many days RMAN will go back to find a cf.

Alternatively, if you know the Networker name of the saveset that
includes the controlfile you want to restore, you can just restore
this saveset somewhere on disk and tell RMAN to  'restore controlfile
from 'filename''.

> In this case, we'd 
> be stuck.  so we we thinking maybe it would be prudent to also make a
> cold backup of the catalog database as an additional precaution.
>
> o A script would run on the Oracle server as a cron job wherein it
> would shut down the catalog database, copy all the files to a
> separate location and the restart the database. That location would
> then be a specified saveset for another NSR client resource that
> would then run daily fulls against that path. This way, we can always
> recover the catalog database from any point in time if necessary, but
> under normal circumstances, the most recent copy (using rman) would
> be used, of course.

If you are really paranoid about your catalog db, you should rather make 
an export of the catalog schema user every day, instead of a cold 
backup. You could than import the this into any surviving db, if you 
loose the orginal db.

Regards,
uwe   

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER