DG處理的問題還是蠻多的，但這次遇到一個比較奇葩的事情，表面配置、網路都沒啥問題，但主備的同步始終有問題，經過多次調整引數、重新部署問題依舊，最終還是求助mos問題得以解決，現將處理過程記錄如下：
一、問題現象
偶爾發現一個主備資料庫同步有問題，檢查備庫發現除了無法完成同步，其他無錯誤資訊，檢查主庫發現錯誤資訊如下：
set line 200; set pagesize 2000; select dest_id,status,error from v$archive_dest;
ORA-12154: TNS:could not resolve the connect identifier specified
alert日誌內容如下：
Error 12154 received logging on to the standby
trace內容如下：
*** 2018-07-02 09:37:36.230 OCIServerAttach failed -1 .. Detailed OCI error val is 12154 and errmsg is 'ORA-12154: TNS:could not resolve the connect identifier specified ' OCIServerAttach failed -1 .. Detailed OCI error val is 12154 and errmsg is 'ORA-12154: TNS:could not resolve the connect identifier specified ' OCIServerAttach failed -1 .. Detailed OCI error val is 12154 and errmsg is 'ORA-12154: TNS:could not resolve the connect identifier specified ' OCIServerAttach failed -1 .. Detailed OCI error val is 12154 and errmsg is 'ORA-12154: TNS:could not resolve the connect identifier specified ' *** 2018-07-02 09:37:36.246 4329 krsh.c Error 12154 received logging on to the standby
二、問題原因
一般遇到ora-12154的錯誤，首先我們想到的肯定是監聽配置和tnsnames.ora配置是否一致，然後看dg的服務名配置是否一致，然後還會檢查本地監聽（local_listener ）是否配置正確，通過上述檢查發現都沒問題，然後又通過服務名使用者名稱密碼連線也沒問題。那為什麼還是會報服務名無法解析導致歸檔無法完成的錯誤呢？
最奇葩的是有些歸檔是可以傳輸過去，有些歸檔是無法傳輸。這裡實在沒招了，只能求助mos，在mos上找到了解決方案。（）
Cause 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.
大致意思是說新的tns別名在主庫被新增，例項和歸檔程式都沒有被重啟，導致歸檔程式讀取的tnsnames.ora還是初始化啟動的時候的內容，所以無法識別新的tnsnames.ora配置的伺服器名。
三、解決方案
mos提供了3中解決方案，重啟主資料庫例項、指定歸檔服務串、重啟歸檔程式，我這裡採用的是第三種，重啟歸檔程式
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_DEST_NEW = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standbynode)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = STDBY) ) ) The corresponding 'alter system' command would then be: alter system set log_archive_dest_2 = 'service="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standbynode)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=STDBY)))"' ; Please note that there's a length limit for the log_archive_dest_<n> parameter, so this will only work if the 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' 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: ps -ef|egrep "ora_arc.*_${ORACLE_SID}"|grep -v grep |while read user pid junk do echo "kill -9 $pid" done
通過kill 掉主庫的歸檔程式，然後完成alter system switch logfile ;發現資料庫資料同步正常。
四、問題總結
查詢從庫日誌應用情況： select sequence#,archived,applied from v$archived_log order by sequence#; 改變歸檔路徑： alter system set LOG_ARCHIVE_DEST_STATE_3=defer scope=both; alter system set LOG_ARCHIVE_DEST_3='SERVICE=dbs ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbs' scope=both; alter system set log_archive_dest_1='location=/oracle/oradata/db/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db' scope=both;