Fix "PL/SQL package SYS.DBMS_RCVMAN version is too old" After an Oracle 19c Patch

You have just applied a 19c Release Update, the database is up, and everything looks fine. Then the alert log starts filling with "PL/SQL package SYS.DBMS_RCVMAN version … is too old", and RMAN complains.

The quick fix is well known: reload four scripts. But the reason it happens decides which fix is right. Running scripts on a standby, for example, does nothing, and a recovery catalog needs its own step. This post walks through it the way I troubleshoot it: symptom → cause → diagnose → fix → verify → prevent.

SYMPTOM

What you see in the alert log

After applying a Release Update (for example 19.3 → 19.22), messages like these start appearing in the database alert log, often whenever RMAN connects (backups, archive log deletion, or a Data Guard standby fetching gaps):

ARC3 (PID:3646): Archived Log entry 3829 added for T-1.S-6 ...

2024-06-27T06:12:14.930888+02:00

PL/SQL package SYS.DBMS_BACKUP_RESTORE version is not current

PL/SQL package SYS.DBMS_RCVMAN version 19.03.00.00 is too old

RMAN itself may also fail with errors such as RMAN-06618: RMAN client and database version mismatch or ORA-06508: could not find program unit being called: "SYS.DBMS_RCVMAN".

CAUSE

Why it happens

RMAN talks to the database through two PL/SQL packages owned by SYS: DBMS_RCVMAN and DBMS_BACKUP_RESTORE. They live in the data dictionary, not in the Oracle Home. The message means: the RMAN binaries are at the new RU, but the packages in the dictionary are still from the old one.

That happens when the binaries were patched but the dictionary was not, typically because:

Situation	What went wrong
datapatch was not run, or failed part-way	opatch apply updated the binaries; the SQL part of the RU never reached the dictionary
Physical standby on a newer home	A standby cannot run datapatch. Its dictionary only changes when redo arrives from the primary
Database duplicated or restored into a newer home	The dictionary still carries the source database's RU level
PDB plugged in from an older CDB	That PDB's dictionary is behind the CDB's RU

DIAGNOSE

Confirm before you fix

1. Binary level vs dictionary level: these two should report the same RU.

shell

$ORACLE_HOME/OPatch/opatch lspatches

SQL*Plus (in CDB$ROOT and each PDB)

SQL> SELECT patch_id, action, status, action_time, description
     FROM   dba_registry_sqlpatch
     ORDER  BY action_time;

If the latest RU is missing from dba_registry_sqlpatch, or shows WITH ERRORS, datapatch is the problem.

2. Is this a standby?

SQL*Plus

SQL> SELECT database_role, open_mode FROM v$database;

3. Invalid objects: RMAN packages and any recovery catalog objects.

SQL*Plus

SQL> SELECT owner, object_type, object_name, status
     FROM   dba_objects
     WHERE  status = 'INVALID'
     ORDER  BY owner, object_type, object_name;

FIX A

Finish the patch: run datapatch (preferred)

If the RU's SQL changes never reached the dictionary, complete the patch properly. This reloads the RMAN packages along with everything else in the RU.

shell / SQL*Plus on the PRIMARY

-- the database (and all PDBs) must be open
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;      -- CDB only

$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose

SQL> @?/rdbms/admin/utlrp.sql

Check the end of the datapatch output and the logs under $ORACLE_BASE/cfgtoollogs/sqlpatch/. Every patch must report success, then dba_registry_sqlpatch should show the new RU with status SUCCESS.

Standby? Run datapatch on the primary only. The dictionary changes travel to the standby through redo, and the messages on the standby stop once that redo has been applied.

FIX B

Reload only the RMAN packages (MOS 2741760.1)

If datapatch reports success but the messages remain, or you need a quick, targeted fix, Oracle's note Doc ID 2741760.1 describes reloading just the two RMAN packages from the current Oracle Home. Run as SYS, on the primary, in this order (specification before body):

SQL*Plus as SYSDBA

SQL> @?/rdbms/admin/dbmsrman.sql      -- DBMS_RCVMAN specification
SQL> @?/rdbms/admin/dbmsbkrs.sql      -- DBMS_BACKUP_RESTORE specification
SQL> @?/rdbms/admin/prvtrmns.plb      -- DBMS_RCVMAN body
SQL> @?/rdbms/admin/prvtbkrs.plb      -- DBMS_BACKUP_RESTORE body

SQL> @?/rdbms/admin/utlrp.sql         -- recompile anything invalidated

Use the scripts from the database's own (new) Oracle Home. ? expands to the current ORACLE_HOME, so check that your environment points to the patched home first. In a multitenant database, follow the MOS note for running the scripts in every container (Oracle's catcon.pl utility does this).

Why utlrp instead of generated ALTER … COMPILE statements? utlrp.sql recompiles everything in dependency order and in parallel. Hand-built compile lists are easy to get wrong, and they miss objects that become invalid only after their dependencies are recompiled.

FIX C

Using a recovery catalog? Upgrade it

If invalid objects belong to a recovery catalog schema (views such as RMAN_BACKUP_JOB_DETAILS in a catalog owner's schema), the catalog itself must be upgraded to match the newer RMAN client. Recompiling the views alone does not do that.

RMAN

$ rman TARGET / CATALOG rcat_owner@rcatdb

RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;        -- RMAN asks you to enter it a second time to confirm

Without this, RMAN connected to the catalog fails with a "recovery catalog version is not compatible" error even after the target is fixed.

VERIFY

Make sure it is really fixed

SQL*Plus

SQL> SELECT patch_id, status, description FROM dba_registry_sqlpatch ORDER BY action_time;
SQL> SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';

RMAN

$ rman target /
RMAN> SHOW ALL;
RMAN> LIST BACKUP SUMMARY;
RMAN> CROSSCHECK ARCHIVELOG ALL;

Then force a log switch (ALTER SYSTEM ARCHIVE LOG CURRENT;) and watch the alert log on the primary and the standby. The "too old" and "not current" messages should no longer appear.

PREVENT

Avoid it next time

• Treat opatch apply + datapatch as one change. A patch is not finished until dba_registry_sqlpatch shows SUCCESS for every container.
• Open all PDBs before running datapatch, and check the sqlpatch logs, not just the last line of the console.
• After building a standby from an older source, or plugging in a PDB, compare opatch lspatches with dba_registry_sqlpatch straight away.
• If you use a recovery catalog, add UPGRADE CATALOG to your patching runbook.
• Run RMAN from the same Oracle Home as the target database.

Summary

If…	Then…
The RU is missing or failed in dba_registry_sqlpatch	Run datapatch -verbose on the primary, then utlrp
The database is a physical standby	Fix the primary; let redo carry it over
datapatch shows SUCCESS but messages remain	Reload the RMAN packages (MOS 2741760.1), then utlrp
Recovery catalog objects are invalid	UPGRADE CATALOG from the new RMAN client

References

• My Oracle Support: PL/SQL package SYS.DBMS_BACKUP_RESTORE Version is Not Current (Doc ID 2741760.1)
• RMAN-06618: RMAN client and database version mismatch (Oracle Error Help)

Tamilselvan Perumal · Oracle ACE Apprentice · Lead Product Engineer & Senior DBA