RMAN-06429: RCVCAT database is not compatible with this version of RMAN

While trying to register 19c database into RMAN catalog, the following errors occur:

$ rman target / catalog rman/xxxxxxxx@rman

Recovery Manager: Release 19.0.0.0.0 - Production on Wed Sep 28 09:43:02 2022
Version 19.10.0.0.0

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

connected to target database: TESTDB (DBID=9998108000)
recovery catalog database Password:
connected to recovery catalog database
PL/SQL package RMAN.DBMS_RCVCAT version 12.02.00.01. in RCVCAT database is too old

RMAN> register database;

PL/SQL package RMAN.DBMS_RCVCAT version 12.02.00.01. in RCVCAT database is too old
PL/SQL package RMAN.DBMS_RCVCAT version 12.02.00.01. in RCVCAT database is too old
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of register command at 09/28/2022 09:43:21
RMAN-06429: RCVCAT database is not compatible with this version of RMAN

SOLUTION

In this situation, The RMAN Oracle database version is 12.1.0.2, the catalog version is 12.02.00.01, and target database to be registered version is 19.10.0.0.0. Since the catalog version must be equal to or greater than the target version, so upgrade catalog is required.

SQL> select * from rman.rcver;

VERSION
---------------
VERSION
------------
12.02.00.01
RMAN> upgrade  catalog;

recovery catalog owner is RMAN
enter UPGRADE CATALOG command again to confirm catalog upgrade

RMAN>  UPGRADE CATALOG;

recovery catalog upgraded to version 19.10.00.00.00
DBMS_RCVMAN package upgraded to version 19.10.00.00
DBMS_RCVCAT package upgraded to version 19.10.00.00.

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
SQL> sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Wed Sep 28 11:22:41 2022

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> select distinct status from dba_objects where owner='RMAN';

STATUS
-------
VALID

SQL> select * from rman.rcver;

VERSION
---------------
19.10.00.00.00

ORA-00904: “DC”.”GUID”: invalid identifier

Some RMAN commands raise the following errors:

RMAN> list backup of database;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 02/28/2022 14:18:45
ORA-00904: "DC"."GUID": invalid identifier

RMAN>

Subscribe to get access

Read more of this content when you subscribe today.

RMAN-06091: no channel allocated for maintenance

After Oracle databases migrated to different versions, the following errors occur from a couple of RMAN backups, which have been working find in old version databases.

It happens for some Oracle databases applied the latest RU/RUR/BP, etc.

...
..
.
RMAN-03002: failure of crosscheck command at 08/04/2021 13:51:11
RMAN-06091: no channel allocated for maintenance (of an appropriate type)

CAUSE & WORKAROUND

It is a known bug for all database versions until 19c.

Subscribe to get access

Read more of this content when you subscribe today.

RMAN Register Database : RMAN-03014 RMAN-03009 ORA-01403

The following errors occur while registering the database in RMAN into RMAN catalog:

RMAN> register database;

starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of register command at 07/16/2021 15:39:33
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 07/16/2021 15:
ORA-01403: no data found


INVESTIGATIONS AND SOLUTION

Subscribe to get access

Read more of this content when you subscribe today.

Accidentally Deleted Oracle Database Datafile on Linux Server

Sysadmin accidentally deleted an Oracle database datafile on Linux server. There are a couple of ways to recover this database datafile, like restoring the deleted datafile from RMAN backup, etc.

In this special situation, sysadmin has just deleted the dbf file, and then realized it immediately. So we can try a different way to recover this datafile from OS file descriptor, which is still open in memory by Oracle database background process.

IDENTIFY which datafile has been wrongly deleted

...
..
.
ORA-63999: data file suffered media failure
ORA-01116: error in opening database file 13
ORA-01110: data file 13: '/u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
...
.
.

Do not offline the deleted file in database until recovering datafile, otherwise file descriptor ( FD) of the deleted file will be lost and unavailable for the rest steps.

Check which OS process still have File Descriptor open for the deleted file

[oracle@oemnode1 trace]$ lsof |grep hr.dbf
ora_dbw0_ 9885 oracle 272uW REG 252,0 104865792 235862719 /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf (deleted)
...
..
.

We can see the file descriptor is 272 by Oracle db writer background process 9885.

Recover datafile from file descriptor

[oracle@oemnode1 proc]$ cd /proc/9885/fd

[oracle@oemnode1 fd]$ ls -ltr 272
lrwx------ 1 oracle oinstall 64 Aug 5 22:33 272 -> /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf (deleted)

[oracle@oemnode1 fd]$ cat 272 > /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf

[oracle@oemnode1 fd]$ ls -ltr /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf
-rw-r--r-- 1 oracle oinstall 104865792 Aug 5 22:38 /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf
SQL> alter database datafile 13 offline;

Database altered.

SQL> recover datafile 13;

Media recovery complete.

SQL> alter database datafile 13 online;

Database altered.

Check and confirm datafile is restored and Recovered successfully

[oracle@oemnode1 fd]$ lsof |grep hr.dbf
oracle_46 4606 oracle 269u REG 252,0 104865792 235862728 /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf
ora_dbw0_ 9885 oracle 272uW REG 252,0 104865792 235862728 /u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf
SQL>select FILE_NAME, TABLESPACE_NAME, STATUS  from dba_data_files where file_id=13

FILE_NAME                                      TABLESPACE_NAME  STATUS
----------------------------------------------- ---------------- -------
/u01/app/oracle/oradata/CUMDB/CUMDBPDB1/hr.dbf     HR            AVAILABLE

Please note this method works only when database is still up running after the datafile accidentally being deleted.