rne017 Document 1240568.1
Adding an new Standby fails with error Ora-12154: TNS:could not resolve the connect
identifier specified (Doc ID 1240558.1)
In this Document
APPLIES TO:
Oracle Database - Enterprise Edition - Version 9.0.1.0 to 1.2.0.1 [Release 9.0.1 to 11.2]
Information in this document applies to any platform.
SYMPTOMS
** checked for relevance '23-Nov-2015' **
When adding or changing the parameter log_archive_dest_ to point to a newly created standby database, the
archiver process for the new destination reports the following error in the alert log
Exror 12514 received logging on to the standby
Errors in file /u0l/diag/rders/prod/PROD/trace/PROD_arcd_2596.tre:
ORA-12524: TNS:listener does not currently know of Service requested in connect descriptor
Corresponding archiver trace file may show:
Redo shipping client performing standby login
ociServerattach failed -1
Detailed OCI error val is 12514 and erensg is ‘ORA~12514: TNS:listener does not cu
know of service requested in connect descriptor
ocIServerattach faited -1
Detailed OcI error val is 12514 and errmsg is ‘ORA~12514: TNS:1istener does not
know of service requested descriptor
ocIServerhttach failed -1
Detailed OCI error val is 12514 and ermmsg is '0RA~12514: TNS: Listener does not
know of service requested in connect descriptor
s+ 2010-12-08 08:50:39.219 1127 krsh
Error 12514 received logging on to the standby
Exzor 12514 connecting to destination L0G_ARCEIVE_D=S7_2 standby host 'renote_dest_new’
Query on V§ARCHIVE_DEST shows the following:
SQL> select dest_id,status,error from vSa:
DEST_ID STATUS ERROR
1 INACTIVE
2 ERROR —ORA~12514: TNS: Listener does not currently know of service requested in
connect descriptor
3 INACTIVE
hitps:/supportoracle.convepmosifaces/DocumentDisplay?_adf ctr-state=18w90zc2mn_48id=1240558.1 19rne017 Document 1240558.1
Please note that this behavior seems to have changed in 11.2, the tnsnames.ora is now being read by the ARC
processes when a new remote destination is added. It is unclear when exactly this was changed.
‘Added a new standby database and updated the tnsnames.ora with 2 new TNS alias for the new standby.
‘The same error can happen on a existing standby database when tns-alias/log_archive_dest_x is changed:
Example:
log_archive_dest_2="service=ORCL2 ...' and ORCL2 has been defined in
‘TNSNAMES,ORA
+ edit TNSNAMES.ORA and copy or rename the ORCL2 entry to ORCL22
- run alter system set log_archive_dest_2="service=ORCL22 ...
- TNS-12154 will be written to the alert file of the primary
After adding a new standby database, a corresponding new TNS alias entry was added to the tnsnames.ora on the primary
node, but neither the instance nor the archiver processes were restarted,
‘The ARC processes read the tnsnames.ora only once during process initialization, any updates to the tnsnames.ora after
startup will not be known to the ARC process and hence the error
‘ORA-12154: TNS:could not resolve the connect identifier specified
is reported when the ARC processes try to resolve the (new) value for the ‘service’ attribute.
1. Shutdown and restart the primary database instance.
This will cause a (short) outage of the primary database and may not be feasible for this reason.
2, Use a connect descriptor for the ‘service’ parameter.
Instead of using a TNS alias for the service parameter (which requires a lookup of the tnsnames.ora file) one can use the
connect descriptor itself.
‘Assume the following (new) entry in the tnsnames.ora on the primary node:
REMOTE _| TON = (ADDRESS = (PROTOCOL =
de) (PORT = 1521)) (6
NEW = (DESCRr!
‘The corresponding ‘alter system’ command would then be:
(SERVICE_NAME
ive_dest_2~ ‘ser
22d) 4
cone re)
7B
alter system set log_ar.
(osT=standbynode) (Fi
Please note that there's a length limit for the log_archive_dest_ parameter, so this will only work ifthe length of the
connect string plus the length of other attributes specified does not exceed this limit.
3. Kill the ARC processes of the primary instance.
With RDBMS releases <= 9.2 it was possible to stop and restart the archiver processes by issuing ‘archive log stop!
hitps:/supportoracle.convepmosifaces/DocumentDisplay?_adf ctr-state=18w90zc2mn_48id=1240558.1 28.mot Document 1240568.1
followed by ‘archive log start’
However these commands are no longer valid with 10g and above, so to cause a respawn of the archiver processes they
must be killed, they will be restarted immediately by the instance.
This solution requires due care to avoid accidentally killing other vital background processes.
‘The following script (ksh,bash) may assist in identifying the correct ARC processes that need to be killed:
4 ${ORACLE_SID}*[grep -v grep [hile read user pid june
cho “KiN1 -9 $pid
done
Didnt find what you are ooking for?
hitps:/supportoracle.convepmosifaces/DocumentDisplay?_adf ctr-state=18w90zc2mn_48id=1240558.1 38