Moving a database to a new server while attempting to use the old remote catalog

As part of a hardware upgrade, I moved a database to a new RAC. I was attempting to use my backup scripts from the old RAC. The scripts contained connections to a remote catalog that I wanted to reuse. On the new RAC, I attempted to register and resync the catalog and got the below error messages:

[new_server-DBNAME2] rman catalog=rman_cat/rman_password@remote_catalog target=/ 

Recovery Manager: Release 11.2.0.4.0 - Production on Fri Sep 8 10:47:33 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DBNAME (DBID=599767446)
connected to recovery catalog database

RMAN> register database;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of register command on default channel at 09/08/2017 10:47:44
RMAN-20002: target database already registered in recovery catalog

RMAN> RESYNC CATALOG;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync command on default channel at 09/08/2017 10:47:51
RMAN-20020: database incarnation not set

To resolve this issue, I executed the commands:

RMAN> unregister database;

database name is "DBNAME" and DBID is 599767446

Do you really want to unregister the database (enter YES or NO)? yes
database unregistered from the recovery catalog

After the database was unregistered, I was able to register the database:

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

RMAN> RESYNC CATALOG;

starting full resync of recovery catalog
full resync complete

The resync catalog command may be redundant, but it never hurts to make sure.

Author: Dean Capps

Database consultant at Amazon Web Services.