Introduction
In today’s data-driven world, safeguarding data is crucial. Organizations must be equipped to handle potential failures by implementing strong disaster recovery (DR) strategies. For those managing critical data, a DR site is essential. Oracle Data Guard provides a robust solution for database disaster recovery, ensuring data protection and continuous availability.
Recently, I encountered an issue while creating a standby database from an ExaCS environment. These databases were manually created in ExaCS, and we also manually registered them in the OCI console.
After configuring Data Guard, the RFS process transfers the latest archive to the standby database but then automatically transitions to a disabled state with the message "Disable RFS client." The process keeps failing because the primary database reports the error:
ORA-12154: TNS: could not resolve the connect identifier specified.
Here is the alert log information we gathered from the standby database:
ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH SID='*';
2024-12-17T05:34:15.663557+00:00
rfs (PID:5936): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is ASYNC (PID:336925)
rfs (PID:5936): Primary database is in MAXIMUM PERFORMANCE mode
rfs (PID:5936): Enable RFS client [krsr.c:5782]
rfs (PID:5936): Disable RFS client [kcrlc.c:1531]
2024-12-17T05:34:15.699574+00:00
rfs (PID:5936): Selected LNO:21 for T-1.S-1255 dbid 4130507393 branch 1187061775
2024-12-17T05:34:18.286167+00:00
rfs (PID:6076): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is ASYNC (PID:239908)
Interestingly, SQL*Plus connections from the primary to the standby database are working fine. This makes the issue even more puzzling, as there are no apparent connectivity problems. However, the primary database alert log continues to report ORA-12154, and even the Data Guard Broker configuration is failing.
After hours of troubleshooting, we accidentally found the relevant My Oracle Support note:
"RFS is not coming up on standby due to ORA-12154 on transport (primary side)" (Doc ID 2196182.1).
In our Exadata database, the TNS_ADMIN parameter was missing in the cluster configuration. We had to add the TNS_ADMIN parameter and restart the database to resolve the issue. Only then did it correctly pick up the TNS location.
srvctl getenv database -d -db unique name- -t "TNS_ADMIN"
srvctl setenv database -d -db_unique_name- -T "TNS_ADMIN=-path of directory holding the tnsnames.ora-"
Sample output
[oracle@exaprd01-node01 ]$ srvctl setenv database -d TEST2_EXA -T "TNS_ADMIN=/u02/app/oracle/product/19.0.0.0/dbhome_4/network/admin/TEST2"
[oracle@exaprd01-node01 ]$ srvctl getenv database -d TEST2_EXA -t "TNS_ADMIN"
TEST2_EXA:
TNS_ADMIN=/u02/app/oracle/product/19.0.0.0/dbhome_4/network/admin/TEST2
[oracle@exaprd01-node01 ]$
Conclusion
The issue arose while setting up a standby database in an ExaCS environment, where the databases were manually created and registered in the OCI console. Despite successful SQL*Plus connections between the primary and standby databases, the RFS process repeatedly failed with ORA-12154 errors on the primary side, preventing archive log transfer.
After extensive troubleshooting, we discovered that the root cause was a missing TNS_ADMIN parameter in the cluster configuration. This prevented the database from correctly resolving TNS names. The issue was resolved by adding the TNS_ADMIN parameter and restarting the database, allowing Data Guard to function properly.
