Failover過程涉及standby redo log的實驗和理解
結論
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
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
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30126024/viewspace-2140688/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- standby redo log的理解
- Oracle Standby Redo Log實驗兩則Oracle
- Oracle Dataguard Standby Redo Log的兩個實驗Oracle
- Dataguard環境修改主庫和standby庫online redo log&standby redo log大小
- DataGuard:Logical Standby FailoverAI
- Redo Log之一：理解Oracle redo logOracle Redo
- （轉）老白的理解REDO LOG
- 邏輯 rac standby和物理 rac standby的switchover 和 failoverAI
- RAC環境LOGICAL STANDBY的FAILOVER切換AI
- [zt]Logical standby同步故障的處理過程
- stream不能實時傳送standby redo log問題的解決
- 深入理解MySQL系列之redo log、undo log和binlogMySql
- DG學習筆記(5)_Standby Redo Log筆記
- undo log和redo log
- Oracle RAC+DG 調整redo/standby log fileOracle
- MySQL中的redo log和undo logMySql
- oracle實驗記錄 （flashback,physical standby resetlogs）Oracle
- Usage, Benefits and Limitations of Standby Redo Logs (SRL) [ID 219344.1]MIT
- redo的等待log file sync和log file parallel write和redo size設定Parallel
- DataGuard:Physical Standby FailoverAI
- Alert.log shows No Standby Redo Logfiles Of Size 153600 Blocks AvailableBloCAI
- 我理解的OAuth 1.0a 的驗證過程OAuth
- MySQL中的redo log和checkpointMySql
- Online Redo Log損壞處理實驗（上）
- Online Redo Log損壞處理實驗（中）
- Online Redo Log損壞處理實驗（下）
- oracle Physical Standby failover stepOracleAI
- standby 資料庫的建立過程資料庫
- 使用rman建立standby database的過程Database
- MySQL Undo Log和Redo Log介紹MySql
- How to Add/Drop/Resize Redo Log with Physical Standby in place. [ID 473442.1]
- MySQL binlog和redo的組提交MySql
- redo log 和 binlog 的一些總結
- RAC環境STANDBY的FAILOVER切換AI
- DATA GUARD物理STANDBY的FAILOVER切換AI
- Performing a Failover to a Physical Standby DatabaseORMAIDatabase
- DG物理standby，failover步驟AI
- 建立一個standby database的全過程Database