结论
1.主库操作redo log或standby redo log的信息不会同步到备库
2.Physical Stand by Databases模式下备库不是Real-Time Apply，也没建立任何standby redo log，备库failover后会自动生成一个standby redo log
3.备库failover成主库后，自动生成的standby redo log，使用linux drop没啥影响
4.备库failover成主库后，自动生成的standby redo log，再利用这个主库搭建备库2，有没有拷贝这个standby redo log到备库2都不影响这个备库2的failover，如果没有拷贝，则备库2会按自己v$logfile中信息生成一个standby redo log（和主库的一模一样），如果已经拷贝了，则备库2 failover后还是这个standby redo log不会又生成一个standby redo log。
ORACLE官方技术支持的解答：
这里虽然说的是standby redo logfile 4 created，但实际上是归档日志/iso/db/oradata/TDB/archivelog/1_0_946491907.dbf。
归档日志是对应于online redo的，所以redo log里打印archivelog created肯定不合适。
failover和switchover的行为不同：
switchover的End-Of-Redo是从主库得来的，而failover的End-Of-Redo就是来自它自己的standby redo log中的最后一条redo，所以failover时这个redo被recover到数据文件，而相应的最后一个standby redo log也要归档才行（不然闪回和reinstate也无从谈起）。
这类似于RMAN备份时，如果没有使用backup database plus archivelog，也没有在backup database前后各跑个ALTER SYSTEM ARCHIVE LOG CURRENT再去backup archivelog all，那么备份期间产生的redo仍然在online log里。没有被备份进来，使用这个备份集去recover时会发生找不到归档的情况。
个人理解：
failover必须依赖自身的一个redo，所以alert日志里也有End-Of-Redo关键字，但是实际standby 的online redo是空的，因为standby 不能write所以online redo是空，所以是standby failover就必须要一个standby redo，就算没有，也会自动创建。虽然备库failover会自动创建了这么一个standby redo log，但不代表主库已经commit但是没有archive传输过来的最后一个online redo的信息会同步到备库。（以下实验仅为个人理解不一定正确，备库提前生成的sequence#为28的归档日志感觉就是起一个standby redo log的作用，一旦主库连接不上了，这个sequence#为28的归档日志就是消失了应该是存放到RFS里面了，备库一旦failover了，这些sequence#为28存放到RFS就生成了一个sequence#为0的standby redo log，这也就是解释了为什么备库创建了standby redo log并real-time apply时备库查询v$standby_log只能看到一条记录，只有最近的一个sequence#）
以下为实验观察到的：
在不是real-time apply情况下，备库比主库预先生成一个archivelog log，比如主库和备库的archive log都是到27，但是备库已经提前生成了一个sequence#为28的归档日志，但是当主库shutdown 后，备库这个sequence#为28的归档日志就消失了
SQL> select sequence# from v$archived_log order by 1; SEQUENCE# ---------- 19 20 21 22 23 24 25 26 27 9 rows selected.
[oracle@DMT-Oracle-server archivelog]$ ll
total 20688
-rw-r----- 1 oracle dba 16719360 Jun 16 14:29 1_19_946491907.dbf
-rw-r----- 1 oracle dba 532992 Jun 16 14:29 1_20_946491907.dbf
-rw-r----- 1 oracle dba 2335744 Jun 16 14:29 1_21_946491907.dbf
-rw-r----- 1 oracle dba 302592 Jun 16 14:29 1_22_946491907.dbf
-rw-r----- 1 oracle dba 116736 Jun 16 14:29 1_23_946491907.dbf
-rw-r----- 1 oracle dba 355328 Jun 16 14:29 1_24_946491907.dbf
-rw-r----- 1 oracle dba 75264 Jun 16 14:31 1_25_946491907.dbf
-rw-r----- 1 oracle dba 644096 Jun 16 14:36 1_26_946491907.dbf
-rw-r----- 1 oracle dba 80896 Jun 16 14:36 1_27_946491907.dbf
-rw-r----- 1 oracle dba 52429312 Jun 16 14:36 1_28_946491907.dbf
备库执行failover的日志
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Attempt to do a Terminal Recovery (TDB)
Media Recovery Start: Managed Standby Recovery (TDB)
started logmerger process
Fri Jun 16 14:57:54 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Media Recovery Waiting for thread 1 sequence 28
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '06/16/2017 14:57:55'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 28 redo required
Media Recovery Waiting for thread 1 sequence 28
Terminal Recovery: End-Of-Redo log allocation
Terminal Recovery: standby redo logfile 4 created '/iso/db/oradata/TDB/archivelog/1_0_946491907.dbf'
This standby redo logfile is being created as part of the
failover operation. This standby redo logfile should be
deleted after the switchover to primary operation completes.
Physical Standby Databases模式下，备库不是Real-Time Apply，也没建立任何standby redo log，备库failover后发现自动生成一个standby redo log，
一般归档日志的s都是1开始的，但该standby redo log很奇怪，默认放在归档日志路径下，命名方式占用LOG_ARCHIVE_FORMAT中s为0的编号，具体如下
/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf
备库1切换后成主库1后，主库1自动生成一个standby redo log（/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf）
利用该主库1搭建备库2，这个备库2的v$logfile也有一个standby redo log，没有从主库1拷贝/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf这个standby
redo log至备库2
1.备库2可以接受主库归档日志吗
2.备库2可以open read only吗
可以，不过open过程中有如下报错
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
3.备库2可以failover吗
4.备库2变成主库2后，standby redo log（/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf）怎么办？
参照主库1的路径名称和大小（其实是参照自己v$logfile中信息
），生成了一个一样的standby redo log（/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf）
5.主库2直接linux命令drop该文件，有什么问题吗
直接linux drop后，发现每什么影响，也可以正常shutdown 并open
不过建议执行alter database drop standby logfile group 4
备库1切换后成主库1后，主库1自动生成一个standby redo log（/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf）
利用该主库1搭建备库2，这个备库2的v$logfile也有一个standby redo log，从主库1拷贝/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf这个standby
redo log至备库2
1.备库2可以接受主库归档日志吗
2.备库2可以open read only吗
可以，不再报错（不再提示说丢失了这个standby redo log）
3.备库2可以failover吗
3.备库2 failover成主库2后，主库2直接linux命令drop该文件，有什么问题吗
直接linux drop后，发现每什么影响，也可以正常shutdown 并open
不过建议执行alter database drop standby logfile group 4
备库1切换后成主库1后，主库1自动生成一个standby redo log（/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf）
利用该主库1搭建备库2，这个备库2的v$logfile也有一个standby redo log，从主库1拷贝/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf这个standby
redo log至备库2
1.主库1删除这个standby，备库2也会自动删除吗(备库2应用了主库1删除动作之后的归档日志)
主库1查询select * from v$logfile;没有这个standby redo log
备库2查询select * from v$logfile;有这个standby redo log
Physical Standby Databases模式下，备库1不是Real-Time Apply，也没建立任何standby redo log，备库1 failover成主库1后，发现主库1自动生成一个
standby redo log，以下为failover的过程和alert日志
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ---------- -------------------- ------------------------------------------------------------ ---
3 ONLINE /iso/db/oradata/TDB/redo03.log NO
2 ONLINE /iso/db/oradata/TDB/redo02.log NO
1 ONLINE /iso/db/oradata/TDB/redo01.log NO
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ---------- -------------------- ------------------------------------------------------------ ---
3 ONLINE /iso/db/oradata/TDB/redo03.log NO
2 ONLINE /iso/db/oradata/TDB/redo02.log NO
1 ONLINE /iso/db/oradata/TDB/redo01.log NO
4 STANDBY /iso/db/oradata/TDB/archivelog/1_0_946491907.dbf NO
Using STANDBY_ARCHIVE_DEST parameter default value as /iso/db/oradata/TDB/archivelog
....
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Tue Jun 13 14:23:52 2017
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /iso/db/diag/rdbms/tdg/TDB/trace/TDB_pr00_3564.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Tue Jun 13 14:23:53 2017
MRP0: Background Media Recovery process shutdown (TDB)
Managed Standby Recovery Canceled (TDB)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Tue Jun 13 14:24:24 2017
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Attempt to do a Terminal Recovery (TDB)
Media Recovery Start: Managed Standby Recovery (TDB)
started logmerger process
Tue Jun 13 14:24:25 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Media Recovery Waiting for thread 1 sequence 6 (in transit)
Killing 3 processes with pids 3572,3546,3548 (all RFS, wait for I/O) in order to disallow current and future RFS connections. Requested by OS
process 3630
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '06/13/2017 14:24:29'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 6 redo required
Media Recovery Waiting for thread 1 sequence 6
Terminal Recovery: End-Of-Redo log allocation
Terminal Recovery: standby redo logfile 4 created '/iso/db/oradata/TDB/archivelog/1_0_946491907.dbf'
This standby redo logfile is being created as part of the
failover operation. This standby redo logfile should be
deleted after the switchover to primary operation completes.
Media Recovery Log /iso/db/oradata/TDB/archivelog/1_0_946491907.dbf
Terminal Recovery: log 4 reserved for thread 1 sequence 6
Recovery of Online Redo Log: Thread 1 Group 4 Seq 6 Reading mem 0
Mem# 0: /iso/db/oradata/TDB/archivelog/1_0_946491907.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 6 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 32430264 time 06/13/2017 12:45:16
Media Recovery Complete (TDB)
Terminal Recovery: successful completion
Forcing ARSCN to IRSCN for TR 0:32430264
Attempt to set limbo arscn 0:32430264 irscn 0:32430264
Resetting standby activation ID 2573949769 (0x996b5b49)
Tue Jun 13 14:24:30 2017
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance TDB - Archival Error
ORA-16014: log 4 sequence# 6 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/iso/db/oradata/TDB/archivelog/1_0_946491907.dbf'
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE SWITCHOVER TO PRIMARY (TDB)
Maximum wait for role transition is 15 minutes.
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Tue Jun 13 14:24:32 2017
SMON: disabling cache recovery
Backup controlfile written to trace file /iso/db/diag/rdbms/tdg/TDB/trace/TDB_ora_3553.trc
Standby terminal recovery start SCN: 32430263
RESETLOGS after incomplete recovery UNTIL CHANGE 32430264
Online logfile pre-clearing operation disabled by switchover
Tue Jun 13 14:24:35 2017
Standby became primary SCN: 32430262
Tue Jun 13 14:24:35 2017
Setting recovery target incarnation to 5
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
Switchover: Complete - Database mounted as primary
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE OPEN
QMNC started with pid=20, OS id=3654
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: ALTER DATABASE OPEN
备库1切换成主库1后产生standby redo log，这个主库1再搭建备库2，这个备库2的v$logfile也有一个standby redo log，没有从主库1拷贝了这个standby redo
log到备库2的目录下，备库2 failover过程中的alert日志
Mon Jun 12 15:18:12 2017
Media Recovery Log /iso/db/oradata/TDB/archivelog/1_3_946479586.dbf
Media Recovery Waiting for thread 1 sequence 4 (in transit)
Mon Jun 12 15:24:03 2017
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Mon Jun 12 15:24:04 2017
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /iso/db/diag/rdbms/tdb/TDB/trace/TDB_pr00_30812.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Mon Jun 12 15:24:04 2017
MRP0: Background Media Recovery process shutdown (TDB)
Managed Standby Recovery Canceled (TDB)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Attempt to do a Terminal Recovery (TDB)
Media Recovery Start: Managed Standby Recovery (TDB)
started logmerger process
Mon Jun 12 15:24:10 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 8 slaves
Media Recovery Waiting for thread 1 sequence 4 (in transit)
Killing 3 processes with pids 30724,30708,30710 (all RFS, wait for I/O) in order to disallow current and future RFS connections. Requested by
OS process 30907
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '06/12/2017 15:24:13'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 4 redo required
Media Recovery Waiting for thread 1 sequence 4
Terminal Recovery: End-Of-Redo log allocation
MRP: Validating standby redo logfile 4
Errors in file /iso/db/diag/rdbms/tdb/TDB/trace/TDB_pr00_30907.trc:
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
MRP: Unable to open standby log 4: 313
Terminal Recovery: standby redo logfile 4 created '/iso/db/oradata/TDB/archivelog/1_0_946479586.dbf'
This standby redo logfile is being created as part of the
failover operation. This standby redo logfile should be
deleted after the switchover to primary operation completes.
Media Recovery Log /iso/db/oradata/TDB/archivelog/1_0_946479586.dbf
Terminal Recovery: log 4 reserved for thread 1 sequence 4
Recovery of Online Redo Log: Thread 1 Group 4 Seq 4 Reading mem 0
Mem# 0: /iso/db/oradata/TDB/archivelog/1_0_946479586.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 4 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 32352145 time 06/12/2017 16:49:02
Mon Jun 12 15:24:14 2017
Media Recovery Complete (TDB)
Terminal Recovery: successful completion
Forcing ARSCN to IRSCN for TR 0:32352145
Attempt to set limbo arscn 0:32352145 irscn 0:32352145
Resetting standby activation ID 2573898088 (0x996a9168)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Mon Jun 12 15:24:14 2017
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance TDB - Archival Error
ORA-16014: log 4 sequence# 4 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/iso/db/oradata/TDB/archivelog/1_0_946479586.dbf'
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE SWITCHOVER TO PRIMARY (TDB)
Maximum wait for role transition is 15 minutes.
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Mon Jun 12 15:24:17 2017
SMON: disabling cache recovery
Backup controlfile written to trace file /iso/db/diag/rdbms/tdb/TDB/trace/TDB_ora_30904.trc
Standby terminal recovery start SCN: 32352144
RESETLOGS after incomplete recovery UNTIL CHANGE 32352145
Online logfile pre-clearing operation disabled by switchover
Mon Jun 12 15:24:25 2017
Standby became primary SCN: 32352143
Mon Jun 12 15:24:25 2017
Setting recovery target incarnation to 4
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
Switchover: Complete - Database mounted as primary
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE OPEN
Mon Jun 12 15:24:27 2017
Assigning activation ID 2573928053 (0x996b0675)
Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0: /iso/db/oradata/TDB/redo01.log
Successful open of redo thread 1
Mon Jun 12 15:24:27 2017
ARC3: Becoming the 'no SRL' ARCH
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Jun 12 15:24:27 2017
ARC0: Becoming the 'no SRL' ARCH
Archiver process freed from errors. No longer stopped
Mon Jun 12 15:24:27 2017
SMON: enabling cache recovery
[30904] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:3046044424 end:3046044904 diff:480 (4 seconds)
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Starting background process SMCO
Mon Jun 12 15:24:28 2017
SMCO started with pid=18, OS id=30939
Database Characterset is AL32UTF8
Mon Jun 12 15:24:28 2017
idle dispatcher 'D000' terminated, pid = (17, 1)
No Resource Manager plan active
Starting background process QMNC
Mon Jun 12 15:24:30 2017
QMNC started with pid=20, OS id=30943
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: ALTER DATABASE OPEN
备库1切换成主库1后产生standby redo log，这个主库1再搭建备库2，这个备库2的v$logfile也有一个standby redo log并从主库1拷贝了这个standby redo log
到备库2的目录下，这个备库2 failover成主库2后，不会再增加一个standby redo log，备库2 failover的alert日志
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (TDB)
Tue Jun 13 11:55:26 2017
MRP0 started with pid=27, OS id=1640
MRP0: Background Managed Standby Recovery process started (TDB)
started logmerger process
Tue Jun 13 11:55:31 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /iso/db/oradata/TDB/redo01.log
Clearing online log 1 of thread 1 sequence number 4
Tue Jun 13 11:55:36 2017
Completed: alter database recover managed standby database disconnect from session
Tue Jun 13 11:55:39 2017
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /iso/db/oradata/TDB/redo02.log
Clearing online log 2 of thread 1 sequence number 5
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /iso/db/oradata/TDB/redo03.log
Clearing online log 3 of thread 1 sequence number 3
Clearing online redo logfile 3 complete
Media Recovery Log /iso/db/oradata/TDB/archivelog/1_4_946491907.dbf
Tue Jun 13 11:55:43 2017
Media Recovery Waiting for thread 1 sequence 5 (in transit)
Tue Jun 13 11:56:37 2017
db_recovery_file_dest_size of 4182 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Tue Jun 13 12:00:38 2017
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Tue Jun 13 12:00:38 2017
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /iso/db/diag/rdbms/tdg/TDB/trace/TDB_pr00_1642.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Tue Jun 13 12:00:39 2017
MRP0: Background Media Recovery process shutdown (TDB)
Managed Standby Recovery Canceled (TDB)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Attempt to do a Terminal Recovery (TDB)
Media Recovery Start: Managed Standby Recovery (TDB)
started logmerger process
Tue Jun 13 12:00:45 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Media Recovery Waiting for thread 1 sequence 5 (in transit)
Killing 3 processes with pids 1621,1636,1624 (all RFS, wait for I/O) in order to disallow current and future RFS connections. Requested by OS
process 1702
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '06/13/2017 12:00:49'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 5 redo required
Media Recovery Waiting for thread 1 sequence 5
Terminal Recovery: End-Of-Redo log allocation
MRP: Validating standby redo logfile 4
Media Recovery Log /iso/db/oradata/TDB/archivelog/1_0_927473683.dbf
Terminal Recovery: log 4 reserved for thread 1 sequence 5
Recovery of Online Redo Log: Thread 1 Group 4 Seq 5 Reading mem 0
Mem# 0: /iso/db/oradata/TDB/archivelog/1_0_927473683.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 5 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 32419210 time 06/13/2017 10:23:15
Tue Jun 13 12:00:49 2017
Media Recovery Complete (TDB)
Terminal Recovery: successful completion
Forcing ARSCN to IRSCN for TR 0:32419210
Attempt to set limbo arscn 0:32419210 irscn 0:32419210
Resetting standby activation ID 2573949769 (0x996b5b49)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Tue Jun 13 12:00:49 2017
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance TDB - Archival Error
ORA-16014: log 4 sequence# 5 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/iso/db/oradata/TDB/archivelog/1_0_927473683.dbf'
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE SWITCHOVER TO PRIMARY (TDB)
Maximum wait for role transition is 15 minutes.
Backup controlfile written to trace file /iso/db/diag/rdbms/tdg/TDB/trace/TDB_ora_1630.trc
Standby terminal recovery start SCN: 32419209
RESETLOGS after incomplete recovery UNTIL CHANGE 32419210
Online logfile pre-clearing operation disabled by switchover
Standby became primary SCN: 32419208
Tue Jun 13 12:00:58 2017
Setting recovery target incarnation to 5
Switchover: Complete - Database mounted as primary
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
Tue Jun 13 12:01:00 2017
ALTER DATABASE OPEN
Tue Jun 13 12:01:00 2017
Assigning activation ID 2574016012 (0x996c5e0c)
Tue Jun 13 12:01:00 2017
ARC3: Becoming the 'no SRL' ARCH
Archiver process freed from errors. No longer stopped
Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0: /iso/db/oradata/TDB/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Jun 13 12:01:00 2017
ARC0: Becoming the 'no SRL' ARCH
Tue Jun 13 12:01:00 2017
SMON: enabling cache recovery
[1630] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:3196174274 end:3196175194 diff:920 (9 seconds)
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Tue Jun 13 12:01:08 2017
QMNC started with pid=19, OS id=1736
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Tue Jun 13 12:01:14 2017
Completed: ALTER DATABASE OPEN
Tue Jun 13 12:01:14 2017
Starting background process CJQ0
Tue Jun 13 12:01:14 2017
CJQ0 started with pid=20, OS id=1752
Tue Jun 13 12:01:17 2017
ARC1: STARTING ARCH PROCESSES
Tue Jun 13 12:01:17 2017
ARC4 started with pid=21, OS id=1754
ARC4: Archival started
ARC1: STARTING ARCH PROCESSES COMPLETE
ARC1: Becoming the 'no SRL' ARCH
krsk_srl_archive_int: Enabling archival of deferred physical standby SRLs
Archived Log entry 2 added for thread 1 sequence 5 ID 0x996b5b49 dest 1:
Shutting down archive processes
ARCH shutting down
ARC4: Archival stopped
发起投票
技术讨论
加好友
发消息
2019-9-18 14:05:13 |
赞(
操作
