网络中断又恢复后的DG自动恢复传输日志

总结 ：在备库dg2上停掉网络。此时主库日志中有出错提示。将备库网络恢复正常，过几分钟，ORACLE自动恢复归档的传递。

1.关闭备库网络，在主库进行日志切换

[oracle@dg1 ~]$ sqlplus / as sysdba                  

SYS@dg1>alter system switch logfile;
System altered.
SYS@dg1>alter system switch logfile;
System altered.
SYS@dg1>exit
日志：
[oracle@dg1 ~]$ cat alert_dg.log
Sun Aug 04 19:19:21 2013
ORA-16198: LGWR received timedout error from KSR
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Errors in file /u01/diag/rdbms/dg1/dg/trace/dg_lgwr_2852.trc:
ORA-16198: Timeout incurred on internal channel during remote archival
Error 16198 for archive log file 1 to 'dg2'
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: Failed to archive log 1 thread 1 sequence 127 (16198)
Thread 1 advanced to log sequence 128 (LGWR switch)
  Current log# 2 seq# 128 mem# 0: /u01/oradata/dg/redo02.log
Sun Aug 04 19:19:26 2013
Archived Log entry 245 added for thread 1 sequence 127 ID 0x6776473b dest 1:
Thread 1 advanced to log sequence 129 (LGWR switch)
  Current log# 3 seq# 129 mem# 0: /u01/oradata/dg/redo03.log
Sun Aug 04 19:19:30 2013
Archived Log entry 246 added for thread 1 sequence 128 ID 0x6776473b dest 1:

2.备库网络恢复后：主备重连成功，备库接收到日志并应用

SYS@dg1>select sequence#,status,thread#,block# from v$managed_standby;
 SEQUENCE# STATUS          THREAD#     BLOCK#
---------- ------------ ---------- ----------
       129 CLOSING               1          1
       128 CLOSING               1          1
         0 CONNECTED             0          0
       130 CLOSING               1          1
        131 WRITING               1        140
SYS@dg2>select sequence#,status,thread#,block# from v$managed_standby;
 SEQUENCE# STATUS          THREAD#     BLOCK#
---------- ------------ ---------- ----------
       130 CLOSING               1          1
       126 CLOSING               1          1
         0 CONNECTED             0          0
       129 CLOSING               1          1
         0 IDLE                  0          0
         0 IDLE                  0          0
         0 IDLE                  0          0
       131 IDLE                  1         14
       131 APPLYING_LOG          1         14

主库日志：
[oracle@dg1 ~]$ cat alert_dg.log
Sun Aug 04 19:25:04 2013
ARC3: Standby redo logfile selected for thread 1 sequence 127 for destination LOG_ARCHIVE_DEST_2
Sun Aug 04 19:25:05 2013
NSS2 started with pid=29, OS id=3373
Sun Aug 04 19:25:08 2013
LGWR: Standby redo logfile selected to archive thread 1 sequence 130
LGWR: Standby redo logfile selected for thread 1 sequence 130 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 130 (LGWR switch)
  Current log# 1 seq# 130 mem# 0: /u01/oradata/dg/redo01.log
Archived Log entry 249 added for thread 1 sequence 129 ID 0x6776473b dest 1:
Sun Aug 04 19:25:08 2013
ARC0: Standby redo logfile selected for thread 1 sequence 129 for destination LOG_ARCHIVE_DEST_2
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Standby redo logfile selected to archive thread 1 sequence 131
LGWR: Standby redo logfile selected for thread 1 sequence 131 for destination LOG_ARCHIVE_DEST_2   ---当前是131号归档
Thread 1 advanced to log sequence 131 (LGWR switch)
  Current log# 2 seq# 131 mem# 0: /u01/oradata/dg/redo02.log
Archived Log entry 252 added for thread 1 sequence 130 ID 0x6776473b dest 1:    ---130号已经归档

备库日志：
[oracle@dg2 ~]$ cat alert_dg.log

Sun Aug 04 19:25:02 2013
RFS[5]: Assigned to RFS process 3584
RFS[5]: Identified database type as 'physical standby': Client is ARCH pid 2936
krsv_proc_kill: Killing 1 processes (idle RFS by thread/sequence)
Sun Aug 04 19:25:04 2013
RFS[6]: Assigned to RFS process 3588
RFS[6]: Identified database type as 'physical standby': Client is ARCH pid 2928
Sun Aug 04 19:25:04 2013
RFS[7]: Assigned to RFS process 3590
RFS[7]: Identified database type as 'physical standby': Client is ARCH pid 2940
RFS[6]: Opened log for thread 1 sequence 128 dbid 1735160627 branch 821829622
Archived Log entry 134 added for thread 1 sequence 128 rlc 821829622 ID 0x6776473b dest 2:
RFS[7]: Selected log 4 for thread 1 sequence 127 dbid 1735160627 branch 821829622
Sun Aug 04 19:25:04 2013
Media Recovery Log /u01/archivelog/arc_1_128_821829622.arc
Media Recovery Waiting for thread 1 sequence 129   -----到这里，断网期间未传到备库的日志已经 接收并应用恢复完成。
Sun Aug 04 19:25:04 2013
Archived Log entry 135 added for thread 1 sequence 127 ID 0x6776473b dest 1:
Sun Aug 04 19:25:08 2013
RFS[8]: Assigned to RFS process 3597
RFS[8]: Identified database type as 'physical standby': Client is LGWR SYNC pid 2852
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
RFS[8]: Selected log 4 for thread 1 sequence 130 dbid 1735160627 branch 821829622
RFS[6]: Selected log 5 for thread 1 sequence 129 dbid 1735160627 branch 821829622
Sun Aug 04 19:25:08 2013
Archived Log entry 136 added for thread 1 sequence 129 ID 0x6776473b dest 1:
Media Recovery Log /u01/archivelog/arc_1_129_821829622.arc
Media Recovery Waiting for thread 1 sequence 130 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 130 Reading mem 0
  Mem# 0: /u01/oradata/dg/standbyredo04.log
Archived Log entry 137 added for thread 1 sequence 130 ID 0x6776473b dest 1:
Changing standby controlfile to MAXIMUM AVAILABILITY level
Media Recovery Waiting for thread 1 sequence 131 (in transit)
RFS[8]: Selected log 4 for thread 1 sequence 131 dbid 1735160627 branch 821829622
Recovery of Online Redo Log: Thread 1 Group 4 Seq 131 Reading mem 0                     ----------------正在应用恢复在线STANDBY REDO LOG
  Mem# 0: /u01/oradata/dg/standbyredo04.log

最后

以上就是虚拟蚂蚁为你收集整理的网络中断又恢复后的DG自动恢复传输日志的全部内容，希望文章能够帮你解决网络中断又恢复后的DG自动恢复传输日志所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。