搭建dataguard環境,主庫的歸檔日誌就是傳送不到備庫上
用select dest_name,error from v$archive_dest;
總是報錯:
ORA-12154: TNS:could not resolve the connect identifier specified
並且在主庫的alert日誌中有如下錯誤信息:
error 12514 received logging on to the standby
--------------------------------------------------------------------------------------------
由於最近幾個月搭建dataguard環境特別多,總會遇到這個問題,但我仔細檢查過配置,tnsnames.ora,log_archive_dest_2等信息都是正確的。
但是,歸檔日誌就是傳送不過去。之前遇到這種類似情況(太多了,記不清了),有使用過alter system set log_archive_dest_state_2=defer;
然後switch logfile,接着再改成enable:alter system set log_archive_dest_state_2=enable;解決過相關問題,但今天就是不行。
以前遇到這樣的情況,只好重啓數據庫,立馬就可以將歸檔日誌傳輸過去。但今天由於主庫已經上生產,不能隨便重啓,導致我也無計可施了。
-------------------------------------------------------------------------------------------
試着在metalink上搜了下(最近好幾個月都很懶,不思進取,就想着天上掉餡餅),發現瞭如下一篇文章,算是對這個問題有深入的瞭解了:
歸檔進程在數據庫啓動後,只會在初始化過程中讀取一次tnsnames.ora的信息,以後tnsnames.ora發生變化等情況,arch進程並不知曉。
這也就會導致當實例中log_archive_dest_2參數發生變化,arch識別不出相關tns別名,進而導致報錯ora-12154
文章中提供的解決辦法有:
1、kill掉歸檔進程(10g版本後不適用)
2、重啓數據庫(這招萬能)
3、log_archive_dest_2參數不要用別名,寫成連接字符串
比如:
alter system set log_archive_dest_2 = 'service="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standbynode)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=STDBY)))"' ;
-------------------------------
我還是想想,怎麼找機會重啓數據庫吧
-----------------------------------------------
ps:20180614
使用了修改og_archive_dest_2的方法,可以解決掉問題:
alter system set log_archive_dest_2 = 'service="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=32.114.111.11)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=test_dg)))" LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMAY_ROLE) DB_UNIQUE_NAME=test_dg' ;
--------------------------------------------------------------------------------------
Adding an new Standby fails with error Ora-12154: TNS:could not resolve the connect identifier specified (文檔 ID 1240558.1) | 轉到底部 |
In this Document
APPLIES TO:Oracle Database - Enterprise Edition - Version 9.0.1.0 to 11.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_<n> to point to a newly created standby database, the archiver process for the new destination reports the following error in the alert log Error 12514 received logging on to the standby Errors in file /u01/diag/rdbms/prod/PROD/trace/PROD_arc0_2596.trc: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Redo shipping client performing standby login OCIServerAttach failed -1 .. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor ' OCIServerAttach failed -1 .. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor ' OCIServerAttach failed -1 .. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor ' *** 2010-11-05 08:50:39.219 1117 krsh.c Error 12514 received logging on to the standby Error 12514 connecting to destination LOG_ARCHIVE_DEST_2 standby host 'remote_dest_new'
SQL> select dest_id,status,error from v$archive_dest; DEST_ID STATUS ERROR ---------- --------- ----------------------------------------------------------------- 1 INACTIVE 2 ERROR ORA-12514: TNS:listener does not currently know of service requested in connect descriptor 3 INACTIVE ...
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.
CHANGESAdded a new standby database and updated the tnsnames.ora with a 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 CAUSEAfter 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. SOLUTION1. Shutdown and restart the primary database instance. REMOTE_DEST_NEW = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standbynode)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = STDBY) ) )
alter system set log_archive_dest_2 = 'service="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standbynode)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=STDBY)))"' ;
|