<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      Oracle案例09——ORA-12154: TNS:could not resolve the connect identifier specified

      DG處理的問題還是蠻多的,但這次遇到一個比較奇葩的事情,表面配置、網(wǎng)絡都沒啥問題,但主備的同步始終有問題,經(jīng)過多次調(diào)整參數(shù)、重新部署問題依舊,最終還是求助mos問題得以解決,現(xiàn)將處理過程記錄如下:

      一、問題現(xiàn)象

      偶爾發(fā)現(xiàn)一個主備數(shù)據(jù)庫同步有問題,檢查備庫發(fā)現(xiàn)除了無法完成同步,其他無錯誤信息,檢查主庫發(fā)現(xiàn)錯誤信息如下:

      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日志內(nèi)容如下:

      Error 12154 received logging on to the standby
      trace內(nèi)容如下:

      *** 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的錯誤,首先我們想到的肯定是監(jiān)聽配置和tnsnames.ora配置是否一致,然后看dg的服務名配置是否一致,然后還會檢查本地監(jiān)聽(local_listener )是否配置正確,通過上述檢查發(fā)現(xiàn)都沒問題,然后又通過服務名用戶名密碼連接也沒問題。那為什么還是會報服務名無法解析導致歸檔無法完成的錯誤呢?

      最奇葩的是有些歸檔是可以傳輸過去,有些歸檔是無法傳輸。這里實在沒招了,只能求助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還是初始化啟動的時候的內(nèi)容,所以無法識別新的tnsnames.ora配置的服務器名。

      三、解決方案

      mos提供了3中解決方案,重啟主數(shù)據(jù)庫實例、指定歸檔服務串、重啟歸檔進程,我這里采用的是第三種,重啟歸檔進程

      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 ;發(fā)現(xiàn)數(shù)據(jù)庫數(shù)據(jù)同步正常。

      四、問題總結(jié)

      查詢從庫日志應用情況:
      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;

       

      posted @ 2018-07-02 10:04  Rangle  閱讀(11929)  評論(1)    收藏  舉報
      主站蜘蛛池模板: 国精产品999国精产| 亚洲 中文 欧美 日韩 在线 | 亚洲中文字幕精品第三区| 亚洲国产欧美一区二区好看电影| 国产97人人超碰caoprom| 亚洲国产精品午夜福利| 国产成人精品一区二区不卡| 国产国产乱老熟女视频网站97| 午夜福利国产精品视频| www国产精品内射熟女| 亚洲国产精久久久久久久春色| 99久久精品费精品国产一区二 | 蜜臀av黑人亚洲精品| 精品人妻一区二区三区蜜臀| 亚洲欧美日韩精品久久亚洲区色播| 中文字幕日韩人妻一区| 色综合久久精品中文字幕| 2021国产在线视频| 国产精品亚洲二区在线播放 | 欧美国产日产一区二区| 精品国产成人一区二区| 无码人妻精品一区二区三区下载| 国产超高清麻豆精品传媒麻豆精品| 日本三级香港三级三级人!妇久 | 人人澡人人妻人人爽人人蜜桃| 国内少妇人妻偷人精品| 被黑人巨大一区二区三区| 久久永久视频| 亚洲av无码专区在线亚| 成年人尤物视频在线观看| 狠狠色婷婷久久综合频道日韩| 精品国产综合成人亚洲区| 国产成人亚洲欧美二区综合| 牡丹江市| 日本熟妇人妻一区二区三区| 亚洲综合一区国产精品| 国产精品无码制服丝袜| 九九色这里只有精品国产| 久久精品无码鲁网中文电影| 中文字幕日韩国产精品| 国内偷自第一区二区三区|