【DG】物理DG中LNSn、NSS、NSA程式

lhrbest發表於2016-07-07

【DG】物理DG中主庫的LNSn、NSS、NSA程式的比較


  1. BLOG文件結構圖


  1. 前言部分


  1. 導讀和注意事項

各位技術愛好者，看完本文後，你可以掌握如下的技能，也可以學到一些其它你所不知道的知識，~O(∩_∩)O~：

① 檢查物理DG是否正常的常用SQL

② 日誌傳輸程式LNSn、NSS、NSA的區別

③ 日誌傳輸的2種方式：lgwr和arch，10g和11g有了變化

④ dg的架構圖



Tips：

① 本文在ITpub（http://blog.itpub.net/26736162）和部落格園(http://www.cnblogs.com/lhrbest)有同步更新

② 文章中用到的所有程式碼，相關軟體，相關資料請前往小麥苗的雲盤下載（http://blog.itpub.net/26736162/viewspace-1624453/）

③ 若文章程式碼格式有錯亂，推薦使用搜狗、360或QQ瀏覽器，也可以下載pdf格式的文件來檢視，pdf文件下載地址：http://blog.itpub.net/26736162/viewspace-1624453/

④ 本篇BLOG中命令的輸出部分需要特別關注的地方我都用灰色背景和粉紅色字型來表示，比如下邊的例子中，thread 1的最大歸檔日誌號為33，thread 2的最大歸檔日誌號為43是需要特別關注的地方；而命令一般使用黃色背景和紅色字型標注；對程式碼或程式碼輸出部分的注釋一般採用藍色字型表示。


本文如有錯誤或不完善的地方請大家多多指正，ITPUB留言或QQ皆可，您的批評指正是我寫作的最大動力。



  1. 相關參考文章連結

關於dg的安裝和一些高階應用參考：

【DATAGUARD】 DG 系列

 

【推薦】 【故障處理】DG歸檔丟失的恢復

http://blog.itpub.net/26736162/viewspace-2087473/

【DG】主rac + 備rac dg 部署

http://blog.itpub.net/26736162/viewspace-1991449/

【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.4)--ora-16652 和 ora-16603錯誤

http://blog.itpub.net/26736162/viewspace-1811947/

【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.3)--客戶端TAF 配置

http://blog.itpub.net/26736162/viewspace-1811944/

【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.2)--Fast-Start Failover 的配置

http://blog.itpub.net/26736162/viewspace-1811936/

【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.1)--Data Guard Broker 的配置

http://blog.itpub.net/26736162/viewspace-1811839/

【推薦】 【DATAGUARD】物理dg在主庫丟失歸檔檔案的情況下的恢復(七)

http://blog.itpub.net/26736162/viewspace-1780863/

【DATAGUARD】物理dg的failover切換(六)

http://blog.itpub.net/26736162/viewspace-1753130/

【DATAGUARD】物理dg的switchover切換（五）

http://blog.itpub.net/26736162/viewspace-1753111/

【推薦】 【DATAGUARD】 將11g物理備庫轉換為Snapshot Standby

http://blog.itpub.net/26736162/viewspace-1525548/

【推薦】 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫 (四)--新增一個物理dg節點

http://blog.itpub.net/26736162/viewspace-1484878/

【推薦】 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫 (三)

http://blog.itpub.net/26736162/viewspace-1481972/

【推薦】 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫（二）

http://blog.itpub.net/26736162/viewspace-1448207/

【推薦】 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫（一）

http://blog.itpub.net/26736162/viewspace-1448197/



  1. 本文簡介

同事說dg不能同步，讓我幫忙看看，我用自己寫的2個檢視檢視了下，首先發現主庫沒有常見的LNSn程式，下意識的認為主庫這個程式沒有啟動，需要切換日誌喚醒LNSn程式，事實上也這樣做了，（alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;），切換後發現日誌可以正常傳輸了，但是主庫還是看不到LNSn這個程式，於是找找資料，深入的研究了一下這個問題。

在讀完整個文章後，大家就會了解我這裡碰到的問題，說明配置的時候不是採用的非同步方式，而小麥苗後來也的確去檢視了下，採用的是LGWR SYNC的方式，在讀完這篇文章後大家對這個問題就非常明朗了。

  1. 相關知識點掃盲(摘自網路+個人總結)

    1. DG架構圖

下圖是小麥苗繪製的dg結構圖，對於裡邊的redo buffer到底如何傳遞到LNSn，眾說紛紜，10g和11g也有不同，但這個不是我們今天討論的內容，詳細點的資料可以參考：http://www.itpub.net/thread-1841337-1-1.html，我們討論並實驗LNSn、NSS、NSA程式在10g和11g的中表現形式。


  1. DG日誌傳輸

DG架構可以按照功能分成3個部分：

1） 日誌傳送（Redo Send）

2） 日誌接收（Redo Receive）

3） 日誌應用（Redo Apply）


我們今天著重來講講這裡的日誌傳送的部分。

Primary Database 執行過程中，會源源不斷地產生Redo 日誌，這些日誌需要傳送到Standy Database。 這個傳送動作可以由Primary Database 的LGWR 或者ARCH程式完成， 不同的歸檔目的地可以使用不同的方法，但是對於一個目的地，只能選用一種方法。 選擇哪個程式對資料保護能力和系統可用性有很大區別。  

如果你配置一個目的地來使用 LGWR 程式， 但是由於某些原因 LGWR 程式變得無法歸到目的地了，則重做傳輸將會回覆到使用 ARCn 程式來完成歸檔操作。

alter system set log_archive_dest_2='SERVICE=tns_mydgwl LGWR ASYNC db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

若不寫傳輸程式和模式的話，11g下預設為LGWR ASYNC方式，10g為ARCH SYNC模式。


  1. 使用ARCH 程式

1）Primary Database 不斷產生Redo Log，這些日誌被LGWR程式寫到聯機日誌。

2）當一組聯機日誌被寫滿後，會發生日誌切換（Log Switch），並且會觸發本地歸檔，本地歸檔位置是採用 LOG_ARCHIVE_DEST_1='LOCATION=/path' 這種格式定義的。如：alter system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;

3）完成本地歸檔後，聯機日誌就可以被覆蓋重用。

4）ARCH 程式通過Net 把歸檔日誌傳送給Standby Database的RFS（Remote File Server） 程式。

5）Standby Database 端的RFS 程式把接收的日誌寫入到歸檔路徑中。

6）Standby Database 端的MRP(Managed Recovery Process)程式（Redo Apply）或者LSP 程式（SQL Apply）在Standby Database上應用這些日誌，進而同步資料。

說明：

邏輯Standby接收後將其轉換成SQL語句，在Standby資料庫上LSP程式執行SQL語句實現同步，這種方式叫SQL Apply。

物理Standby接收完Primary資料庫生成的REDO資料後，MRP程式以介質恢復的方式實現同步，這種方式也叫Redo Apply。 

  1. 使用LGWR 程式的SYNC 方式

1）Primary Database 產生的Redo日誌要同時寫到日誌檔案和網路。也就是說LGWR程式把日誌寫到本地日誌檔案的同時還要傳送給本地的LNSn程式（Network Server Process），再由LNSn（LGWR Network Server process）程式把日誌通過網路傳送給遠端的目的地，每個遠端目的地對應一個LNS程式，多個LNS程式能夠並行工作。

2）LGWR 必須等待寫入本地日誌檔案操作和通過LNSn程式的網路傳送都成功，Primary Database上的事務才能提交，這也是SYNC的含義所在。

3）Standby Database的RFS程式把接收到的日誌寫入到Standby Redo Log日誌中。

4） Primary Database的日誌切換也會觸發Standby Database 上的日誌切換，即Standby Database 對Standby Redo Log的歸檔，然後觸發Standby Database 的MRP或者LSP程式恢復歸檔日誌。 

  1. 使用LGWR程式的ASYNC 方式

使用LGWR SYNC方法的可能問題在於，如果日誌傳送給Standby Database過程失敗，LGWR程式就會報錯。也就是說Primary Database的LGWR 程式依賴於網路狀況，有時這種要求可能過於苛刻，這時就可以使用LGWR ASYNC方式。 它的工作機制如下：

1） Primary Database 一旦產生Redo日誌後，LGWR 把日誌同時提交給日誌檔案和本地LNS 程式，但是LGWR程式只需成功寫入日誌檔案就可以，不必等待LNSn程式的網路傳送成功。

2） LNSn程式非同步地把日誌內容傳送到Standby Database。多個LNSn程式可以併發傳送。

3） Primary Database的Online Redo Log 寫滿後發生Log Switch，觸發歸檔操作，也觸發Standby Database對Standby Redo Log 的歸檔；然後觸發MRP或者LSP 程式恢復歸檔日誌。



  1. 程式LNSn:LGWR Network Server process

On the primary database, the LGWR process submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in parallel to multiple remote destinations.



DG可以使用ARCH,LGWR來傳送日誌，但他們都是把日誌傳送給本地的LNS（如果有多個目標備庫，那會啟動相應數量的LNS程式，同時傳送資料）程式，然後備庫那邊的RFS程式接收資料，接收到的資料可以儲存在備庫的備用重做日誌檔案中或備庫的歸檔日誌中，然後再應用到備庫中。

主庫切換(alter system switch logfile;)可以啟動LNS程式， V$MANAGED_STANDBY檢視可以檢視LNS程式的具體情況：

col group# format a5

set line 9999 pagesize 9999

SELECT a.PROCESS,a.PID,a.STATUS,a.GROUP#,a.SEQUENCE#, a.DELAY_MINS, a.RESETLOG_ID FROM V$MANAGED_STANDBY a;


  1. 如何啟動LNS程式？

有3種方法：

  1. alter system switch logfile;
  2. 推薦： 備庫啟動實時應用後，主庫alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;
  3. 重啟備庫、主庫

    1. LNS程式的後臺表現形式

    經過小麥苗的研究，日誌傳輸若採用LGWR程式來傳輸，則在10g dg中是lns的形式，到了11g變為了nsa和nss的形式了，具體可以參考本文實驗部分的總結，不管10還是11g我們都可以用命令ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"來查詢後臺程式。





    ---------------------------------------------------------------------------------------------------------------------



    1. 實驗部分

    1. 實驗目標

    若採用lgwr程式傳輸日誌的話，分別找到10g和11g中，後臺程式的表現形式、切換日誌時後臺的告警日誌及V$MANAGED_STANDBY檢視展現的內容有何不同。


    1. 實驗過程

    以下所有試驗過程均在主庫操作。

    1. 10g

    實驗環境如下：


    1. LGWR SYNC(lgwr 同步)

    -----LGWR SYNC

    alter system set log_archive_dest_2='SERVICE=tns_mydgwl LGWR SYNC db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)';


    說明LGWR同步方式，後臺程式表現為lns，且檢視V$MANAGED_STANDBY中表現為LGWR。

    告警日誌：

    Sun Jun 14 18:45:58 BEIST 2020

    Thread 1 cannot allocate new log, sequence 31

    Checkpoint not complete

    Current log# 3 seq# 30 mem# 0: /cds/oradata/mydg/redo03.log

    Sun Jun 14 18:46:03 BEIST 2020

    Thread 1 advanced to log sequence 31 (LGWR switch)

    Current log# 1 seq# 31 mem# 0: /cds/oradata/mydg/redo01.log


    1. LGWR ASYNC(lgwr 非同步)

    說明LGWR非同步方式，後臺程式表現為lns，且檢視V$MANAGED_STANDBY中表現為LNS。


    告警日誌：

    Sun Jun 14 18:45:58 BEIST 2020

    Thread 1 cannot allocate new log, sequence 31

    Checkpoint not complete

    Current log# 3 seq# 30 mem# 0: /cds/oradata/mydg/redo03.log

    Sun Jun 14 18:46:03 BEIST 2020

    Thread 1 advanced to log sequence 31 (LGWR switch)

    Current log# 1 seq# 31 mem# 0: /cds/oradata/mydg/redo01.log



    1. ARCH（歸檔傳輸）

    說明arch程式傳輸日誌，後臺程式表現為arc，且檢視V$MANAGED_STANDBY中表現為ARCH。


    告警日誌輸出：

    Sun Jun 14 18:15:44 BEIST 2020

    Thread 1 advanced to log sequence 23 (LGWR switch)

    Current log# 2 seq# 23 mem# 0: /cds/oradata/mydg/redo02.log

    Sun Jun 14 18:15:44 BEIST 2020

    Shutting down archive processes

    Sun Jun 14 18:15:49 BEIST 2020

    ARCH shutting down

    ARC4: Archival stopped


    1. 預設傳輸模式測試


    可以看出10g中，預設情況下為ARCH的同步模式。


    1. 11g

    實驗環境如下：

    1. LGWR SYNC(lgwr 同步)


    說明LGWR程式同步傳輸日誌，後臺程式表現為nss，且檢視V$MANAGED_STANDBY中表現為LGWR，告警日誌中表現為LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 。


    告警日誌：

    Wed Jul 06 13:47:59 2016

    Thread 1 advanced to log sequence 98 (LGWR switch)

    Current log# 3 seq# 98 mem# 0: +DATA/oradesdb/onlinelog/group_3.387.916309939

    Wed Jul 06 13:47:59 2016

    LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2

    Wed Jul 06 13:47:59 2016

    Archived Log entry 219 added for thread 1 sequence 97 ID 0xffffffff8589c5d0 dest 1:

    Wed Jul 06 13:48:33 2016




    1. LGWR ASYNC(lgwr 非同步)

    預設為非同步。

    alter system set log_archive_dest_2='SERVICE=oraESKDB LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oraESKDB' sid='*';

    alter system set log_archive_dest_2='SERVICE=oraESKDB VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oraESKDB' sid='*';


    告警日誌：

    Wed Jul 06 19:24:34 2016

    Thread 1 advanced to log sequence 117 (LGWR switch)

    Current log# 1 seq# 117 mem# 0: +DATA/oradesdb/onlinelog/group_1.258.916309939

    Wed Jul 06 19:24:34 2016

    Archived Log entry 280 added for thread 1 sequence 116 ID 0xffffffff8589c5d0 dest 1:

    Wed Jul 06 19:24:34 2016

    LNS: Standby redo logfile selected for thread 1 sequence 117 for destination LOG_ARCHIVE_DEST_2



    說明LGWR程式非同步傳輸日誌，後臺程式表現為nsa，且檢視V$MANAGED_STANDBY中表現為LNS，告警日誌中表現為LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 。




    1. ARCH（歸檔傳輸）

    在備庫查詢：


    說明LGWR程式非同步傳輸日誌，後臺程式表現為nsa，且檢視V$MANAGED_STANDBY中表現為LNS，告警日誌中表現為LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 。

    1. 預設傳輸模式測試

    可以看出11g下，預設情況為LGWR的非同步模式。


    1. 實驗總結




    1. 實驗中用到的SQL總結

    1. 10g

      col group_# format a5

      col PROCESS format a8

      col CLIENT_PID format a8

      set line 9999 pagesize 9999

      SELECT a.INST_ID,

      a.PROCESS,

      a.client_process,

      a.client_pid,

      a.STATUS,

      a.GROUP# group_#,

      a.thread#,

      a.SEQUENCE#,

      a.DELAY_MINS,

      a.RESETLOG_ID,

      c.SID,

      c.SERIAL#,

      a.PID spid

      FROM gV$MANAGED_STANDBY a, gv$process b, gv$session c

      WHERE a.PID = b.SPID

      and b.ADDR = c.PADDR

      and a.INST_ID = b.INST_ID

      and b.INST_ID = c.INST_ID

      order by a.INST_ID;



      set line 9999

      col DEST_NAME format a20

      col DESTINATION format a15

      col GAP_STATUS format a10

      col DB_UNIQUE_NAME format a15

      col error format a10

      col APPLIED_SCN for 999999999999999

      SELECT al.thread#,

      ads.dest_id,

      ads.DEST_NAME,

      (SELECT ads.TYPE || ' ' || ad.TARGET

      FROM v$archive_dest AD

      WHERE AD.DEST_ID = ADS.DEST_ID) TARGET,

      ADS.DATABASE_MODE,

      ads.STATUS,

      ads.error,

      ads.RECOVERY_MODE,

      ads.DB_UNIQUE_NAME,

      ads.DESTINATION,

      (SELECT MAX(sequence#) FROM v$log na WHERE na.thread# = al.thread#) Current_Seq#,

      MAX(sequence#) Last_Archived,

      max(CASE

      WHEN al.APPLIED = 'YES' AND ads.TYPE <> 'LOCAL' THEN

      al.sequence#

      end) APPLIED_SEQ#

      FROM (SELECT *

      FROM v$archived_log V

      WHERE V.resetlogs_change# =

      (SELECT d.RESETLOGS_CHANGE# FROM v$database d)) al,

      v$archive_dest_status ads

      WHERE al.dest_id(+) = ads.dest_id

      AND ads.STATUS != 'INACTIVE'

      GROUP BY al.thread#,

      ads.dest_id,

      ads.DEST_NAME,

      ads.STATUS,

      ads.error,

      ads.TYPE,

      ADS.DATABASE_MODE,

      ads.RECOVERY_MODE,

      ads.DB_UNIQUE_NAME,

      ads.DESTINATION

      ORDER BY al.thread#, ads.dest_id;



      col name for a100

      set linesize 9999 pagesize 9999

      col NEXT_CHANGE# for 999999999999999

      SELECT THREAD#,

      NAME,

      sequence#,

      archived,

      applied,

      a.NEXT_CHANGE#

      FROM v$archived_log a

      WHERE a.sequence# >= (select max(b.sequence#)-5 from v$log b where b.THREAD#=a.THREAD# )

      AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

      ORDER BY a.THREAD#,

      a.sequence#;



      SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

      SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

      alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

      SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

      SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';





    1. 11g


    col group_# format a5

    col PROCESS format a8

    col CLIENT_PID format a8

    set line 9999 pagesize 9999

    SELECT a.INST_ID,

    a.PROCESS,

    a.client_process,

    a.client_pid,

    a.STATUS,

    a.GROUP# group_#,

    a.thread#,

    a.SEQUENCE#,

    a.DELAY_MINS,

    a.RESETLOG_ID,

    c.SID,

    c.SERIAL#,

    a.PID spid,

    b.PNAME

    FROM gV$MANAGED_STANDBY a, gv$process b, gv$session c

    WHERE a.PID = b.SPID

    and b.ADDR = c.PADDR

    and a.INST_ID = b.INST_ID

    and b.INST_ID = c.INST_ID

    order by a.INST_ID,b.PNAME;



    set line 9999

    col DEST_NAME format a20

    col DESTINATION format a15

    col GAP_STATUS format a10

    col DB_UNIQUE_NAME format a15

    col error format a10

    col APPLIED_SCN for 999999999999999

    SELECT al.thread#,

    ads.dest_id,

    ads.DEST_NAME,

    (SELECT ads.TYPE || ' ' || ad.TARGET

    FROM v$archive_dest AD

    WHERE AD.DEST_ID = ADS.DEST_ID) TARGET,

    ADS.DATABASE_MODE,

    ads.STATUS,

    ads.error,

    ads.RECOVERY_MODE,

    ads.DB_UNIQUE_NAME,

    ads.DESTINATION,

    ads.GAP_STATUS,

    (SELECT MAX(sequence#) FROM v$log na WHERE na.thread# = al.thread#) Current_Seq#,

    MAX(sequence#) Last_Archived,

    max(CASE

    WHEN al.APPLIED = 'YES' AND ads.TYPE <> 'LOCAL' THEN

    al.sequence#

    end) APPLIED_SEQ#,

    (SELECT ad.applied_scn

    FROM v$archive_dest AD

    WHERE AD.DEST_ID = ADS.DEST_ID) applied_scn

    FROM (SELECT *

    FROM v$archived_log V

    WHERE V.resetlogs_change# =

    (SELECT d.RESETLOGS_CHANGE# FROM v$database d)) al,

    v$archive_dest_status ads

    WHERE al.dest_id(+) = ads.dest_id

    AND ads.STATUS != 'INACTIVE'

    GROUP BY al.thread#,

    ads.dest_id,

    ads.DEST_NAME,

    ads.STATUS,

    ads.error,

    ads.TYPE,

    ADS.DATABASE_MODE,

    ads.RECOVERY_MODE,

    ads.DB_UNIQUE_NAME,

    ads.DESTINATION,

    ads.GAP_STATUS

    ORDER BY al.thread#, ads.dest_id;





    ------------物理dg日誌應用情況(備庫查詢為準)

    col name for a100

    set linesize 9999 pagesize 9999

    col NEXT_CHANGE# for 999999999999999

    SELECT THREAD#,

    NAME,

    sequence#,

    archived,

    applied,

    a.NEXT_CHANGE#

    FROM v$archived_log a

    WHERE a.sequence# >= (select max(b.sequence#)-3 from v$log b where b.THREAD#=a.THREAD# )

    AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

    ORDER BY a.THREAD#,

    a.sequence#;


    ----物理備庫應用程式日誌

    --select * from gv$dataguard_status d order by d.inst_id,d.timestamp,d.message_num;

    set line 9999 pagesize 9999

    col message format a85

    SELECT inst_id, severity, FACILITY, TIMESTAMP, MESSAGE

    FROM (select d.inst_id,

    FACILITY,

    SEVERITY,

    TIMESTAMP,

    MESSAGE,

    rank() over(partition by d.inst_id ORDER BY d.message_num desc) rank_order

    from gv$dataguard_status d)

    where rank_order <= 5

    order by inst_id, rank_order desc;



    ---是否啟用實時應用

    ps -ef|grep ora_mrp

    --通用：select RECOVERY_MODE from v$archive_dest_status;


    alter database recover managed standby database using current logfile disconnect from session;

    alter database recover managed standby database cancel;


    select thread#,low_sequence#,high_sequence# from v$archive_gap;



    SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

    SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

    alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

    SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

    SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';


    ---------------------------------------------------------------------------------------------------------------------





    About Me

    ..........................................................................................................................................................................................................

    本文作者：小麥苗，只專注於資料庫的技術，更注重技術的運用

    本文在ITpub（http://blog.itpub.net/26736162）和部落格園(http://www.cnblogs.com/lhrbest)有同步更新

    本文地址：http://blog.itpub.net/26736162/viewspace-2121688/

    本文pdf版：http://yunpan.cn/cdEQedhCs2kFz （提取碼：ed9b） 

    小麥苗分享的其它資料：http://blog.itpub.net/26736162/viewspace-1624453/

    聯絡我請加QQ好友(642808185)，註明新增緣由

    於 2016-07-06 10:00~ 2016-07-07 19:00 在中行完成

    【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】

    ..........................................................................................................................................................................................................

    拿起手機掃描下邊的圖片來關注小麥苗的微信公眾號：xiaomaimiaolhr,學習最實用的資料庫技術。


     

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2121688/，如需轉載，請註明出處，否則將追究法律責任。

相關文章