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.
Excellent Article. helped to resolve live issue. Thanks
ReplyDeleteThanks for kind words. Kind words fill me with pleasure.
Delete