Re: RMAN: restoring autobackup spfile and controlfile

From: Jared Still <jkstill_at_gmail.com>
Date: Thu, 2 Aug 2007 09:02:33 -0700
Message-ID: <bf46380708020902t529f257bxbdb29fddf4f85986@mail.gmail.com>

On 8/2/07, Niall Litchfield <niall.litchfield_at_gmail.com> 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: @#$*!

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Aug 02 2007 - 11:02:33 CDT