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/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-1408219/
本文详细记录了Oracle数据库中归档进程启动、归档开始、日志文件归档及同步等过程。描述了归档日志的具体操作,包括归档进程的启动、归档状态的确认以及归档日志的生成情况。
1053

被折叠的 条评论
为什么被折叠?



