Thursday, August 15, 2019

PING[ARC1]: Heartbeat failed to connect to standby 'my_standby'. Error is 12154


If your primary database is not able to ship archived logs to the standby database with error ORA-12154, there is something wrong with the TNS entry you are using in LOG_ARCHIVE_DEST_n parameter that points to your standby database. If you check the alert log file of the primary database you will see error messages similar to the following.


Error 12154 received logging on to the standby
FAL[server, ARC1]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance mydb - Archival Error. Archiver continuing.
Fri Jun 30 17:27:27 2017
Error 12154 received logging on to the standby
FAL[server, ARC1]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance opera - Archival Error. Archiver continuing.
Error 12154 received logging on to the standby
PING[ARC1]: Heartbeat failed to connect to standby my_standby'. Error is 12154.
Fri Jun 30 17:29:48 2017
Archived Log entry 319106 added for thread 1 sequence 5506 ID 0x9d298439 dest 1:

In order to investigate and resolve the issue, check following.

1. Execute “tnsping” using service name you are using in LOG_ARCHIVE_DEST_n parameter pointing to the standby database. Resolve if you see any problem.
2. After tnsping, also try connecting with the standby database using SQLPLUS form the primary database server using SYS user. It must also succeed.
3. Kill all “arc” processes. Use “kill -9” command to kill all arc processes and oracle would automatically spawn new archive processes. Check if it resolves your problem.

# ps –ef |grep arc

-- Above command would return all arc processes including their PID. Use “kill -9” to kill the arch processes by specifying PID.
# kill -9 <PID>


4. If CRS is configured (Oracle restart or RAC environment) and you have used “srvctl” command to start your primary database, you need to make sure that TNS_ADMIN is set properly for the database resource registered with the CRS.
$ srvctl getenv database -d <db unique name> -t "TNS_ADMIN"

--Set the correct value using following command

$ srvctl setenv database -d <db_unique_name> -T "TNS_ADMIN=<TNSNAMES.ORA directory path>"

You would need to restart the database after above change is made. Alternatively you can also copy TNSNAMES.ORA file under Grid Infrastructure home if TNS_ADMIN is pointing to the GRID_HOME/networkin/admin because there is a chance that DB was started using TNS_ADMIN settings of GI home.  

2 comments:

  1. Excellent Article. helped to resolve live issue. Thanks

    ReplyDelete
    Replies
    1. Thanks for kind words. Kind words fill me with pleasure.

      Delete

Popular Posts - All Times