FreeLists / oracle-l / Re: RMAN: restoring autobackup spfile and controlfile

["Jared Still" <jkstill@xxxxxxxxx>]

On 8/2/07, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote:
>
>
> The only - but rather good in principle - reason that I can see is to
> make reporting easier and consistent.


I used to believe that.


> I don't really see how? Most RMAN tasks have exactly the same syntax
> whether  connected to a catalog or not.



Definitely not true.  I have documented a few things I have run across, seen
at the end of this post.


> Oracle docs claim that everything possible with a recovery catalog is
> > also possible using only the controlfile.  There is a long list of
> caveats
> > to go with that statement.
>
> For example? Most tasks (with the exception of things like recovery
> through resetlogs which really ought to be pretty rare) are just as
> possible without a catalog.


"Ought  to be".  Well yes, I agree.

When I first started using RMAN here, I put most databases into the Recovery
Catalog.

Then I thought that that really wasn't necessary, and started using only the
controfile.

Following that, there started appearing many scenarios where recovery with
only the
controlfile is possible, but much easier with the RC.

So now I'm back to using the RC.

YMMV.

Jared


RMAN - Limitations Without a Recovery Catalog Database


From ML Note 304305.1

Limitations of TSPITR Without a Recovery Catalog
====================================
•    The undo segments at the time of the TSPITR must be part of the
auxiliary set. Because RMAN has no historical record of the undo in the
control file, RMAN assumes that the current rollback or undo segments were
the same segments present at the time to which recovery is performed. If the
undo segments have changed since that time, then TSPITR will fail.
•    TSPITR to a time that is too old may not succeed if Oracle has reused
the control file records for needed backups. (In planning your database, set
the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter to a value large
enough to ensure that control file records needed for TSPITR are kept.)
•    When not using a recovery catalog, the current control file has no
record of the older incarnation of the recovered tablespace. Thus, recovery
with a current control file that involves this tablespace can no longer use
a backup taken prior to time t. You can, however, perform incomplete
recovery of the whole database to any time less than or equal to t, if you
can restore a backup control file from before time t.
====================================
Stored scripts require a recovery catalog.
====================================
From ML Note 360416.1 on 10g

Except for stored scripts, all of RMAN's features work equally well with or
without a recovery catalog.
====================================

From 9i Recovery Manager Users  Guide, Chapter 16:
If you choose not to use a recovery catalog, then you can still use RMAN
very effectively. RMAN obtains the information it needs from the control
file of the target database. Nevertheless, some commands are not available
when you use the control file as the sole repository of RMAN metadata. The
following commands are only available when you use a recovery catalog:
•    CREATE CATALOG, UPGRADE CATALOG, DROP CATALOG
•    CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT, PRINT SCRIPT
•    LIST INCARNATION
•    REGISTER DATABASE
•    REPORT SCHEMA AT TIME
•    RESET DATABASE
•    RESYNC CATALOG
====================================


     Doc ID:
Note:274420.1    Type:     PROBLEM
     Last Revision Date:     04-JUN-2004    Status:     MODERATED
The information in this article applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.4
This problem can occur on any platform.
Errors
RMAN 6053 unable to perform media recovery because of missing log
RMAN 6025 no backup of log thread %d seq %d scn %s found to restore
Symptoms
RMAN Duplication fails with :
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 85 scn 22757474 found to restore

The target database has been opened with RESETLOGS
Backup of archived redologs shows :
skipping archive log file /archive/kpbm/1_147.dbf; already backed up 1
time(s)
Cause
This issue is caused by
bug 2825248 RESETLOGS DATA IGNORED IN BACKUP OPTIMIZATION CHECKS

Symtomps of bug 2825248 :

- BACKUP OPTIMIZATION is set to ON.
- Database has been opened with RESETLOGS

The skipped archived redologs belong to an OLDER incarnation of the
database.
As they are skipped during the backup, but deleted due to the DELETE
INPUT-clause,
there will be NO backup available of this archive to restore, causing the
DUPLICATE
to fails with RMAN-6053.
Fix
- Upgrade to 10G

OR use the workarounds
- CONFIGURE BACKUP OPTIMIZATION OFF
or
- Use an RMAN-catalog.

====================================

Restoring an autobackup controlfile

When using a Recovery catalog it is only necessary to issue the RESTORE
CONTROLFILE command.

RMAN> restore controlfiles from autobackup;


When using just the controlfile as a catalog, you do not have a catalog if
the controlfiles are lost.  So that RMAN knows which controlfile to restore,
you must then use the SET DBID command.

This is a problem if you don't know the DBID.
====================================
Restoring a previous incarnation of the database.

If the database has been opened with RESETLOGS, RMAN will not normally
restore a previous version of the database.

If needed, this can be done by using the LIST INCARNATION command to see
previous incarnations of the database, and the SET INCARNATION command to
set the RMAN catalog to a previous version of the database prior to
restoring.

This only works however if a recovery catalog database is being used.
These commands will not work without the recovery catalog database. Previous
incarnations of the database can be restored using only the controlfile, but
is difficult and involved.
====================================
Retrieving the DBID of a database.

With a recovery catalog:

select * from rc_database
where lower(name) = 'pr09'
/

Without a recovery catalog:  @#$*!

====================================