oracle11R2雙機(jī)熱備v$archived_log中sequence重復(fù)的問題，請高手解惑！

nicolas37

oracle版本是11R2，雙機(jī)熱備是DG模式，之前使用時(shí)一直都是正常的，昨天再做主備庫切換后，查詢v$archived_log視圖，發(fā)現(xiàn)原主庫現(xiàn)備庫shpri中sequence71重復(fù)了，在本地的archive log應(yīng)用了，傳到原備庫的沒有應(yīng)用�，F(xiàn)主庫原備庫shdg從sequence72開始重復(fù)出現(xiàn)記錄，本地的archive log沒有被應(yīng)用，傳到shpri上的log被apply了。

昨天是在log sequence為71的時(shí)候做的主備切換，從shpri切換到shdg，數(shù)據(jù)是完整的，不影響使用，但是不知道為什么會(huì)出現(xiàn)這種記錄。

截取了一部分日志信息：
切換時(shí)原主庫現(xiàn)備庫shdg的日志：
Sun Jun 24 19:48:03 2012
Thread 1 cannot allocate new log, sequence 71
Checkpoint not complete
  Current log# 1 seq# 70 mem# 0: /home/app/oracle/oradata/shpri/redo01.log
Thread 1 closed at log sequence 71
Successful close of redo thread 1
ARCH: Noswitch archival of thread 1, sequence 71
ARCH: End-Of-Redo Branch archival of thread 1 sequence 71
Archived Log entry 231 added for thread 1 sequence 71 ID 0x47d384ac dest 1:
ARCH: Archiving is disabled due to current logfile archival
Primary will check for some target standby to have received all redo
Final check for a synchronized target standby. Check will be made once.
LOG_ARCHIVE_DEST_2 is a potential Physical Standby  switchover target
Active, synchronized target has been identified
Target has also applied all redo
Backup controlfile written to trace file /home/app/oracle/diag/rdbms/shpri/shpri/trace/shpri_ora_1334.trc
Clearing standby activation ID 1205044396 (0x47d384ac)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Archivelog for thread 1 sequence 71 required for standby recovery
Switchover: Primary controlfile converted to standby controlfile succesfully.
Sun Jun 24 19:50:13 2012
MRP0 started with pid=17, OS id=6632
MRP0: Background Managed Standby Recovery process started (shpri)
Serial Media Recovery started
Managed Standby Recovery not using Real Time Apply
Online logfile pre-clearing operation disabled by switchover
Media Recovery Log /home/app/oracle/archive/1_71_786222847.arc
Identified End-Of-Redo for thread 1 sequence 71
Resetting standby activation ID 0 (0x0)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change 1253528
MRP0: Media Recovery Complete: End-Of-REDO (shpri)
MRP0: Background Media Recovery process shutdown (shpri)
Sun Jun 24 19:50:27 2012
Waiting for MRP0 pid 6632 to terminate
Switchover: Complete - Database shutdown required (shpri)
Sun Jun 24 19:50:27 2012
idle dispatcher 'D000' terminated, pid = (17, 1)
Completed: alter database commit to switchover to physical standby with session shutdown
日志中顯示檢測原備庫shdg已經(jīng)apply全部日志了

當(dāng)時(shí)原備庫現(xiàn)主庫shdg的日志：
Sun Jun 24 19:48:13 2012
Media Recovery Log /home/app/oracle/archive/1_70_786222847.arc
Media Recovery Waiting for thread 1 sequence 71
Sun Jun 24 19:49:09 2012
RFS[6]: Assigned to RFS process 14196
RFS[6]: Identified database type as 'physical standby': Client is ARCH pid 28183
Sun Jun 24 19:50:12 2012
RFS[7]: Assigned to RFS process 14227
RFS[7]: Identified database type as 'physical standby': Client is Foreground pid 1334
RFS[7]: Opened log for thread 1 sequence 71 dbid 1201613339 branch 786222847
Archived Log entry 45 added for thread 1 sequence 71 rlc 786222847 ID 0x47d384ac dest 2:
Sun Jun 24 19:50:13 2012
RFS[8]: Assigned to RFS process 14229
RFS[8]: Identified database type as 'physical standby': Client is Foreground pid 1334
Sun Jun 24 19:50:24 2012
Media Recovery Log /home/app/oracle/archive/1_71_786222847.arc
Identified End-Of-Redo for thread 1 sequence 71
Resetting standby activation ID 1205044396 (0x47d384ac)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change 1253528
Sun Jun 24 19:50:24 2012
MRP0: Media Recovery Complete: End-Of-REDO (shdg)
MRP0: Background Media Recovery process shutdown (shdg)
Sun Jun 24 20:07:37 2012
alter database commit to switchover to primary
ALTER DATABASE SWITCHOVER TO PRIMARY (shdg)
Maximum wait for role transition is 15 minutes.
Backup controlfile written to trace file /home/app/oracle/diag/rdbms/shdg/shdg/trace/shdg_ora_13730.trc
SwitchOver after complete recovery through change 1253528
Online log /home/app/oracle/oradata/shdg/redo01.log: Thread 1 Group 1 was previously cleared
Online log /home/app/oracle/oradata/shdg/redo02.log: Thread 1 Group 2 was previously cleared
Online log /home/app/oracle/oradata/shdg/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 1253526
Switchover: Complete - Database mounted as primary
原備庫現(xiàn)主庫shdg在切換時(shí)也用sequence為71的log做完recover了，并且兩個(gè)庫的scn是同步的。

切換都正常，數(shù)據(jù)也完整，但是不明白為什么v$archived_log里會(huì)有sequence重復(fù)的記錄，麻煩高手解答一下，謝謝！
原備庫現(xiàn)主庫shdg的v$archived_log


原主庫現(xiàn)備庫shpri的v$archived_log

帥哥露小縫

回復(fù) 1# nicolas37


    如何創(chuàng)建DG的啊 ？ 語句是什么？在哪里執(zhí)行 ？