data guard failover時最小化資料丟失 - 11g flush redo - 2
alert log :
ALTER SYSTEM FLUSH REDO TO ‘PRODA’ CONFIRM APPLY
ALTER SYSTEM FLUSH REDO TO PRODA CONFIRM APPLY [Process Id: 27807] (proda)
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=24, OS id=27885
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
ARC1 started with pid=25, OS id=27887
ARC2 started with pid=26, OS id=27889
ARC3 started with pid=27, OS id=27891
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the ‘no FAL’ ARCH
ARC1: Becoming the ‘no SRL’ ARCH
Flush redo: No wait for non-current ORLs to be archived
Waiting for all FAL entries to be archived…
All FAL entries have been archived.
Waiting for dest_id 2 to become synchronized…
ARC2: Becoming the heartbeat ARCH
2012-02-07 10:39:44.948000 +01:00
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Active, synchronized flush redo target has been identified
Managed Real Time Apply recovery running at physical standby ‘LOG_ARCHIVE_DEST_2′
Flush End-Of-Redo Log thread 1 sequence 607 has been fixed
Flush Redo: Primary highest seen SCN set to 0x0.0x9d05c1
ARCH: Noswitch archival of thread 1, sequence 607
ARCH: End-Of-Redo Branch archival of thread 1 sequence 607
ARCH: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch
ARCH: Standby redo logfile selected for thread 1 sequence 607 for destination LOG_ARCHIVE_DEST_2
Flush End-Of-Redo Log thread 1 sequence 607
Archived Log entry 1038 added for thread 1 sequence 607 ID 0x7943e1d0 dest 1:
ARCH: Archiving is disabled due to current logfile archival
Primary will wait for PRODA standby to have applied all redo
Final check for a target standby that has recovered all redo. Check will be made a few times.
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 has also applied all redo from primary
Active, synchronized target has been identified that has applied all the redo from the primary.
Flush Redo: Primary redo moved to standby
翻譯自:
http://blog.grid-it.nl/index.php/2012/03/07/minimize-data-loss-during-failover/
ALTER SYSTEM FLUSH REDO TO ‘PRODA’ CONFIRM APPLY
ALTER SYSTEM FLUSH REDO TO PRODA CONFIRM APPLY [Process Id: 27807] (proda)
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=24, OS id=27885
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
ARC1 started with pid=25, OS id=27887
ARC2 started with pid=26, OS id=27889
ARC3 started with pid=27, OS id=27891
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the ‘no FAL’ ARCH
ARC1: Becoming the ‘no SRL’ ARCH
Flush redo: No wait for non-current ORLs to be archived
Waiting for all FAL entries to be archived…
All FAL entries have been archived.
Waiting for dest_id 2 to become synchronized…
ARC2: Becoming the heartbeat ARCH
2012-02-07 10:39:44.948000 +01:00
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Active, synchronized flush redo target has been identified
Managed Real Time Apply recovery running at physical standby ‘LOG_ARCHIVE_DEST_2′
Flush End-Of-Redo Log thread 1 sequence 607 has been fixed
Flush Redo: Primary highest seen SCN set to 0x0.0x9d05c1
ARCH: Noswitch archival of thread 1, sequence 607
ARCH: End-Of-Redo Branch archival of thread 1 sequence 607
ARCH: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch
ARCH: Standby redo logfile selected for thread 1 sequence 607 for destination LOG_ARCHIVE_DEST_2
Flush End-Of-Redo Log thread 1 sequence 607
Archived Log entry 1038 added for thread 1 sequence 607 ID 0x7943e1d0 dest 1:
ARCH: Archiving is disabled due to current logfile archival
Primary will wait for PRODA standby to have applied all redo
Final check for a target standby that has recovered all redo. Check will be made a few times.
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 has also applied all redo from primary
Active, synchronized target has been identified that has applied all the redo from the primary.
Flush Redo: Primary redo moved to standby
翻譯自:
http://blog.grid-it.nl/index.php/2012/03/07/minimize-data-loss-during-failover/
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-1408219/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- data guard failover時最小化資料丟失 - 11g flush redo - 1AI
- DATA GUARD主庫丟失資料檔案的恢復(2)
- DATA GUARD主庫丟失資料檔案的恢復(3)
- DATA GUARD主庫丟失資料檔案的恢復(1)
- Oracle Data Guard Failover(activate)OracleAI
- In Data Guard,choose switchover or failover?AI
- data guard failover on solaris 10AI
- 20160223Oracle 11G Data Guard Failover2OracleAI
- Data Guard Switchover and Failover Best PracticesAI
- 恢復REDO Log丟失的Oracle資料庫Oracle資料庫
- [20160222]Oracle 11G Data Guard FailoverOracleAI
- Oracle 11g Data guard 物理備庫應急切換(failover)流程OracleAI
- 【DataGuard】物理Data Guard之Failover轉換AI
- DATA GUARD物理STANDBY的FAILOVER切換AI
- Oracle 11g Data GuardOracle
- Oracle 11g Data Guard Enabling Active Data GuardOracle
- oracle10g data guard redo transport serviceOracle
- DATA GUARD 跨平臺支援(Redo Apply)APP
- 盛哥學習 Data Guard 第四篇《物理standby之failover 丟棄切換》AI
- Oracle Redo丟失恢復方案Oracle
- 11g data guard 新特性
- Data Guard Broker系列之六:Fast-Start FailoverASTAI
- redo log 丟失(非歸檔模式,資料庫正常關閉,redo log 被誤刪除!)模式資料庫
- oracle 11g data guard維護Oracle
- 總結11g 物理data guard
- How to configure Client Failover after Data Guard Switchover or Failover [ID 316740.1]clientAI
- 物理Data Guard中哪個程式處理Redo GAP
- 【DataGuard】Oracle 11g物理Data Guard之Snapshot Standby資料庫功能Oracle資料庫
- redo log檔案丟失處理措施
- 非OMF管理下ORACLE 11G R2 Data Guard配置Oracle
- DATA GUARD手工管理資料檔案
- Data Guard中快速Switchover,Failover的一些建議AI
- 為什麼使用Socket接收時丟失資料?
- ORACLE 11G Data Guard 角色轉換Oracle
- 【DataGuard】11g 新特性:Active Data Guard
- 實戰11g active data guard on rac
- 2 Oracle Data Guard 安裝Oracle
- 【轉】【DataGuard】Oracle 11g物理Data Guard之Snapshot Standby資料庫功能Oracle資料庫