物理Data Guard中哪個程式處理Redo GAP
物理Data Guard中哪個程式處理Redo GAP
在Oracle Data Guard中,Redo Gap的產生是由於一些網路或者其他問題導致redo的傳輸中斷。當故障消除後,這些沒有傳輸過去的redo檔案會由一些程式發現,並且將它們傳輸到備庫。
術語:
ARC:歸檔程式
MRP:Media Recovery Process,在備庫上負責應用redo
RFS:Remote File Server ,在備庫上接收傳送過來的redo檔案
FAL:Fetch Archive Log
測試目的:由於網路問題發生了gap後,確定哪個程式負責處理gap。
測試環境:Oracle 11.2.0.2 on Linux 5.
測試過程:
1.確保當前主庫和備庫是同步的:
Primary:
MAX(SEQUENCE#)
--------------
86
Standby:
MAX(SEQUENCE#)
--------------
86
2. 模擬網路中斷,導致gap:
在主庫將網路卡停掉: #ifconfig eth0 down
將主庫執行數次switch logfile:
SQL>alter system switch logfile;
SQL>alter system switch logfile;
...
Primary:
MAX(SEQUENCE#)
--------------
96
這時主庫alert log報出了與備庫連線不通的錯誤:
TNS-00513: Destination host unreachable
nt secondary err code: 101
nt OS err code: 0
Error 12543 received logging on to the standby
FAL[server, ARCp]: Error 12543 creating remote archivelog file 'STANDBY'
FAL[server, ARCp]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance orcl - Archival Error. Archiver continuing.
3.將主庫的這些歸檔臨時換個目錄,保證這些歸檔無法傳到備庫:
mv *.arc ../
4. 啟動主庫的網路卡:
#ifconfig eth0 up
5.這時,主庫的ARC並沒有把缺少的日誌傳到備庫。最終備庫的MRP發現了gap並把gap fetching.
備庫alert log:
Thu Mar 29 19:58:49 2012
Media Recovery Waiting for thread 1 sequence 87 (in transit) <==== 網路中斷時,等待87
...
Thu Mar 29 20:08:45 2012
...
Media Recovery Waiting for thread 1 sequence 94
Thu Mar 29 20:11:01 2012
RFS[61]: Assigned to RFS process 13643
RFS[61]: Opened log for thread 1 sequence 97 dbid 1285401128 branch 757620395
Archived Log entry 80 added for thread 1 sequence 97 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:11:02 2012
RFS[62]: Assigned to RFS process 13645
RFS[62]: Selected log 4 for thread 1 sequence 98 dbid 1285401128 branch 757620395
Thu Mar 29 20:11:02 2012
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 4 thread 1 sequence 98
Thu Mar 29 20:11:02 2012
Archived Log entry 81 added for thread 1 sequence 98 ID 0x4c9d8928 dest 1:
RFS[63]: Assigned to RFS process 13647
RFS[63]: Selected log 4 for thread 1 sequence 99 dbid 1285401128 branch 757620395
Thu Mar 29 20:11:05 2012
Fetching gap sequence in thread 1, gap sequence 94-96 <===========取gap
...
6.透過MRP的trace,可以確定是MRP 作了fetching gap:
MRP trace:
*** 2012-03-29 20:08:45.375 4265 krsh.c
Media Recovery Waiting for thread 1 sequence 94
*** 2012-03-29 20:11:05.543
*** 2012-03-29 20:11:05.543 4265 krsh.c
Fetching gap sequence in thread 1, gap sequence 94-96 <==========MRP取gap.
Redo shipping client performing standby login
*** 2012-03-29 20:11:05.593 4595 krsu.c
Logged on to standby successfully
Client logon and security negotiation successful!
7.將移走的歸檔日誌移回之後,備庫的RFS接收到了這些日誌, MRP 將這些日誌進行了apply.
Thu Mar 29 20:12:06 2012
RFS[64]: Assigned to RFS process 13649
RFS[64]: Opened log for thread 1 sequence 94 dbid 1285401128 branch 757620395
Archived Log entry 82 added for thread 1 sequence 94 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:12:06 2012
RFS[65]: Assigned to RFS process 13651
RFS[65]: Opened log for thread 1 sequence 95 dbid 1285401128 branch 757620395
Thu Mar 29 20:12:06 2012
RFS[66]: Assigned to RFS process 13653
RFS[66]: Opened log for thread 1 sequence 96 dbid 1285401128 branch 757620395
Archived Log entry 83 added for thread 1 sequence 95 rlc 757620395 ID 0x4c9d8928 dest 2:
Archived Log entry 84 added for thread 1 sequence 96 rlc 757620395 ID 0x4c9d8928 dest 2:
Thu Mar 29 20:12:16 2012
Media Recovery Log /home/oracle/arch1/standby/1_94_757620395.arc
Media Recovery Log /home/oracle/arch1/standby/1_95_757620395.arc
Media Recovery Log /home/oracle/arch1/standby/1_96_757620395.arc
Media Recovery Log /home/oracle/arch1/standby/1_97_757620395.arc
Media Recovery Log /home/oracle/arch1/standby/1_98_757620395.arc
測試結論:
透過這個例子說明,對於這種gap的處理,主庫的ARC程式對於以前產生的gap檔案,並沒有進行處理。是備庫的MRP程式在apply log的時候發現了gap,將這些檔案透過FAL程式取回。
注:在11g,理論上主庫的ARC程式和備庫的RFS、MRP程式在某些情況都有可能處理gap.
8. 為了進一步確定是MRP透過FAL取了gap檔案,我將主庫的密碼修改了一下,結果MRP的trace中報錯:FAL[client, MRP0],說明是透過FAL取的。
*** 2012-03-29 21:18:15.964 4265 krsh.c
Error 1031 received logging on to the standby
*** 2012-03-29 21:18:15.964 4265 krsh.c
FAL[client, MRP0]: Error 1031 connecting to PRIMARY for fetching gap sequence
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23490154/viewspace-1062164/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Data guard archive GAP 故障處理案例Hive
- Data Guard維護管理三之處理archivelog gapHive
- Redo Gap 處理與優化優化
- RedHat搭建物理Data GuardRedhat
- 批量處理物理備庫出現archive gapHive
- 物理data guard原理的理解(zt)
- [轉]物理data guard原理的理解
- data guard物理備份方式中的switchover轉換
- 總結11g 物理data guard
- oracle 10g物理data guard 操作Oracle 10g
- DATA GUARD物理STANDBY的 SWITCHOVER切換
- oracle10g data guard redo transport serviceOracle
- DATA GUARD 跨平臺支援(Redo Apply)APP
- Data guard 配置之搭建物理備庫
- 【DataGuard】物理Data Guard之Failover轉換AI
- 物理DG!Oracle 10G Data Guard DemoOracle 10g
- DATA GUARD物理STANDBY的FAILOVER切換AI
- DATA GUARD物理備庫的SWITCHOVER切換
- DATA GUARD物理STANDBY的 SWITCHOVER切換[zt]
- DATAGUARD中手工處理日誌GAP
- 使用Data Guard Broker進行Data Guard物理備用庫配置(Oracle 19c)Oracle
- 如何調優物理備庫的重作日誌應用速率_redo apply_dg_data guardAPP
- Oracle 11g RAC Data Guard 物理standby 建立Oracle
- 搭建Oracle Data Guard 11g(物理備用)Oracle
- Data Guard學習之物理standby建立步驟
- 【DG】 DataGuard 中處理archive gap的方法Hive
- 異常處理中,哪個部分可以省略?
- 【DataGuard】錯誤的log_file_name_convert引數導致物理Data Guard配置故障分析與處理
- Data Guard 之RMAN備份線上搭建物理standby
- 管理物理STANDBY資料庫——DATA GUARD概念和管理資料庫
- 建立物理STANDBY資料庫——DATA GUARD概念和管理資料庫
- 物理data guard備standby庫的時候報錯。
- Oracle Data Guard 理論知識Oracle
- oracle9i(9204)dg(data guard)_adding and dropping online redo logs_物理_physicalOracle
- 技術白皮書:Oracle Data Guard 11gOracle Data Guard 理論知識OracleGo
- DATA GUARD 中alter database 命令Database
- 在DATAGUARD中手工處理日誌GAP的方法
- Oracle 19C Data Guard基礎運維-05Failovers (GAP)Oracle運維AI