【DG】物理DG中LNSn、NSS、NSA程式
【DG】物理DG中主庫的LNSn、NSS、NSA程式的比較
-
BLOG文件結構圖
-
前言部分
-
導讀和注意事項
各位技術愛好者,看完本文後,你可以掌握如下的技能,也可以學到一些其它你所不知道的知識,~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皆可,您的批評指正是我寫作的最大動力。
-
相關參考文章連結
關於dg的安裝和一些高階應用參考:
【DATAGUARD】 DG 系列 |
|
http://blog.itpub.net/26736162/viewspace-2087473/ |
|
http://blog.itpub.net/26736162/viewspace-1991449/ |
|
【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.4)--ora-16652 和 ora-16603錯誤 |
http://blog.itpub.net/26736162/viewspace-1811947/ |
http://blog.itpub.net/26736162/viewspace-1811944/ |
|
【推薦】 【DATAGUARD】物理dg配置客戶端無縫切換 (八.2)--Fast-Start Failover 的配置 |
http://blog.itpub.net/26736162/viewspace-1811936/ |
http://blog.itpub.net/26736162/viewspace-1811839/ |
|
http://blog.itpub.net/26736162/viewspace-1780863/ |
|
http://blog.itpub.net/26736162/viewspace-1753130/ |
|
http://blog.itpub.net/26736162/viewspace-1753111/ |
|
http://blog.itpub.net/26736162/viewspace-1525548/ |
|
http://blog.itpub.net/26736162/viewspace-1484878/ |
|
http://blog.itpub.net/26736162/viewspace-1481972/ |
|
http://blog.itpub.net/26736162/viewspace-1448207/ |
|
http://blog.itpub.net/26736162/viewspace-1448197/ |
-
本文簡介
同事說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的方式,在讀完這篇文章後大家對這個問題就非常明朗了。
-
相關知識點掃盲(摘自網路+個人總結)
-
DG架構圖
-
下圖是小麥苗繪製的dg結構圖,對於裡邊的redo buffer到底如何傳遞到LNSn,眾說紛紜,10g和11g也有不同,但這個不是我們今天討論的內容,詳細點的資料可以參考:http://www.itpub.net/thread-1841337-1-1.html,我們討論並實驗LNSn、NSS、NSA程式在10g和11g的中表現形式。
-
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模式。
-
使用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。
-
使用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程式恢復歸檔日誌。
-
使用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 程式恢復歸檔日誌。
-
程式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;
-
如何啟動LNS程式?
有3種方法:
- alter system switch logfile;
- 推薦: 備庫啟動實時應用後,主庫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;
-
重啟備庫、主庫
-
LNS程式的後臺表現形式
經過小麥苗的研究,日誌傳輸若採用LGWR程式來傳輸,則在10g dg中是lns的形式,到了11g變為了nsa和nss的形式了,具體可以參考本文實驗部分的總結,不管10還是11g我們都可以用命令ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"來查詢後臺程式。
---------------------------------------------------------------------------------------------------------------------
-
實驗部分
-
實驗目標
若採用lgwr程式傳輸日誌的話,分別找到10g和11g中,後臺程式的表現形式、切換日誌時後臺的告警日誌及V$MANAGED_STANDBY檢視展現的內容有何不同。
-
實驗過程
以下所有試驗過程均在主庫操作。
-
10g
實驗環境如下:
-
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
-
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
-
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
-
預設傳輸模式測試
可以看出10g中,預設情況下為ARCH的同步模式。
-
11g
實驗環境如下:
-
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
-
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 。
-
ARCH(歸檔傳輸)
在備庫查詢:
說明LGWR程式非同步傳輸日誌,後臺程式表現為nsa,且檢視V$MANAGED_STANDBY中表現為LNS,告警日誌中表現為LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 。
-
預設傳輸模式測試
可以看出11g下,預設情況為LGWR的非同步模式。
-
實驗總結
-
實驗中用到的SQL總結
-
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';
-
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版: (提取碼: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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 物理DG、邏輯DG和快照DG的搭建(視訊講解)
- DG物理standby,Failover之後原primary重回DGAI
- 【DG】Oracle 19c使用dbca來搭建物理DGOracle
- 物理DG角色轉換:switchover
- 主庫不停做物理dg
- DG物理standby,switchover步驟
- 物理DG與邏輯DG的區別與邏輯DG同步異常處理方法
- oracle物理dg狀態檢查Oracle
- 物理DG角色轉換: failoverAI
- DG物理standby,failover步驟AI
- 物理DG刪除歸檔測試
- 【DATAGUARD】物理dg的switchover切換(五)
- 【DG】dg中如何配置多個後臺observerServer
- 【DG】Oracle 19c使用dbca來搭建物理DG--主rac備racOracle
- DG -- READ ONLY模式開啟物理Standby模式
- RAC DG 物理standby ASM無法啟動ASM
- CentOS 5.8上搭建10g物理DGCentOS
- 物理DG從庫損壞後的重建
- 物理DG!Oracle 10G Data Guard DemoOracle 10g
- 【DATAGUARD】物理dg的failover切換(六)AI
- Oracle 11g單主搭建物理DGOracle
- Oracle物理DG自動切換——Dataguard Broker配置Oracle
- 【DATAGUARD】DG系列之RACtoONE物理備庫的搭建
- 【DG】DG概念原理詳解
- 【DG】怎麼使用Data Pump備份物理備庫
- 【DG】DG的3種保護模式模式
- DG搭建
- 【DATAGUARD】DG系列之11g物理備庫的搭建
- 使用DG_broker工具管理DG之switchover
- 【DG】Oracle之級聯DG--(cascade dg) --(一主一備一級聯)Oracle
- RMAN遠端複製搭建物理DG過程小結
- Oracle10g物理DG詳細配置方法及步驟Oracle
- 【DG】DG之Switchover和Failover的區別AI
- ora11_node_dg(1)DG搭建過程
- 【DG】搭建(一)
- oracle 11gR2 對CRS dg做映象dgOracle
- Oracle 11g RAC如何把物理DG變成只讀庫Oracle
- DG環境下重新構建物理備庫oracle12COracle