If you are responsible for managing backups in an Oracle Data Guard environment and have decided to offload the backup workload to the Standby database, you may encounter the following warning during your first attempts:
RMAN-06820: warning: failed to archive current log at primary database
Seeing this warning usually concerns database administrators. In this practical article, based on a real-world Oracle Database 19c scenario, we examine why this warning occurs, how it affects your backup, and how you can permanently resolve it by correctly configuring the Recovery Catalog and network connections.
Our Test Scenario and Environment
In this implementation, our architecture consisted of the following components:
- Standby server (named
dc1- IP:192.168.56.31): Our backup target database, with the unique nameDB_UNIQUE_NAME = vahiddb. - Primary server (named
dc2- IP:192.168.56.32): The primary database, with the unique nameDB_UNIQUE_NAME = vahiddbdc2. - Catalog server (named
oracle26ai- IP:192.168.56.33): Hosting thePDB26catalog database for storing RMAN metadata.
The Technical Root Cause: RMAN Cannot Reach the Primary Database
When you issue a backup command—especially an archived redo log backup—on the Standby database, RMAN automatically attempts to connect to the Primary database and execute ALTER SYSTEM ARCHIVE LOG CURRENT there. The purpose is to force the latest redo logs generated on the Primary database to be archived, shipped to the Standby database, and included in the backup, ensuring that the backup is as current and complete as possible.
However, if RMAN cannot connect to the Primary database—because no catalog is configured, network connection information is missing, or authentication fails—it issues the RMAN-06820 warning.
An important point: This message is a warning, not an error. Your backup does not stop, and RMAN backs up the archived logs that already exist on the Standby database; however, the log switch on the Primary database will not be performed.
Practical Steps for a Permanent Resolution
To resolve this scenario, we completed the following five steps in order:
1. Set Up a Recovery Catalog on the Catalog Database (oracle26ai)
First, we created space for storing RMAN information in the catalog database:
-- Connect to PDB26
ALTER SESSION SET CONTAINER=PDB26;
-- Create a dedicated tablespace for the catalog
CREATE TABLESPACE RMANCAT_TS;
-- Create the RMAN user and grant the required privileges
CREATE USER RMAN IDENTIFIED BY "StrongPasswordHere"
DEFAULT TABLESPACE RMANCAT_TS
QUOTA UNLIMITED ON RMANCAT_TS;
GRANT recovery_catalog_owner TO RMAN;
GRANT connect, resource TO RMAN;
Next, we connected to this catalog using the RMAN utility and created the catalog schema:
rman catalog rman/StrongPasswordHere@CATDB_PDB26
After connecting, run the following command:
RMAN> create catalog;
recovery catalog created
2. Configure the Network File (tnsnames.ora) on Both Servers
To allow the servers to communicate with each other, we added the following TNS definitions to the network configuration file. It is recommended to use dedicated and distinct names for this purpose:
VAHID_PRI =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.32)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = vahiddb))
)
VAHID_STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.31)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = vahiddb))
)
CATDB_PDB26 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.33)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = PDB26))
)
3. Version Compatibility Challenge (RMAN-06429 Error)
During the implementation, we found that running an RMAN client version 23ai or 26ai from the catalog server against a 19c target database resulted in a compatibility error:
RMAN-06429: TARGET database is not compatible with this version of RMAN
Technical experience: Always run the RMAN client from a server whose version matches the Target database version—in this case, 19c. Therefore, we executed all RMAN commands from the dc1 and dc2 servers.
4. Register the Database and Configure Connection Mappings
To make the catalog aware of our databases, we first registered the database from the Primary server (dc2):
rman target / catalog rman/StrongPasswordHere@CATDB_PDB26
In RMAN:
RMAN> register database;
Next, through the catalog, we told RMAN which TNS connection it should use for each Data Guard member. This configuration is essential for resolving the RMAN-06820 warning:
CONFIGURE DB_UNIQUE_NAME 'vahiddbdc2' CONNECT IDENTIFIER 'VAHID_PRI';
CONFIGURE DB_UNIQUE_NAME 'vahiddb' CONNECT IDENTIFIER 'VAHID_STBY';
5. Final Backup Test Without Any Warning
A common mistake at this stage is connecting to RMAN locally using target /. When you connect through the operating system user, RMAN has no credentials available for logging in to the remote database (the Primary), and the RMAN-06820 warning occurs again.
The correct method is to connect using network authentication with the SYS password:
rman target sys@VAHID_STBY catalog rman/StrongPasswordHere@CATDB_PDB26
Now run the backup command:
RMAN> backup archivelog all;
Result:
current log archived at primary database
...
Finished backup
RMAN successfully connected to the Primary database without any warning, performed the log switch, shipped the new redo logs to the Standby database, and completed the backup successfully.