The following is the AlertLog content of the Standby terminal when Failover, unplug the Primary network cable, and simulates the PRIMARY database network environment suddenly damaged.
- Downlink means Standby Redo Log at the Standby side is enabled
RFS: Successfully opened standby logfile 4: '/global/oradata/ctsdb/stdby_redo04.log'Tue Aug 31 19:54:30 2004Media Recovery Log /global/oradata/ctsdb/archive/arch1_8389.logMedia Recovery Waiting for thread 1 seq # 8390 (in transit) Tue Aug 31 19:54:57 2004Restarting dead background process QMN0QMN0 Started with pid = 12tue aug 31 19:55:19 2004
- Start Failover, First Step Alter Database Recover Managed Standby Database Finishtue Aug 31 19:55:19 2004Terminal Recovery: Request PostedTue Aug 31 19:55:48 2004
- finish SQLPLUS command in the end there is no error, normal end, but the following lines show standby redo file has not been properly recoverWarning: log 4 of thread 1 is being archived or modifiedMRP0: Background Media Recovery terminated with error 261Tue Aug 31 19:55 : 48 2004erroS in file /export/HOME/Oracle/app/oracle/admin/ctsdb/BDUMP/CTSDB_MRP0_2201.TRC: 00261: log 4 of thread 1 is being archived or modifiedora-00312: Online log 4 thread 1: ' /global/oradata/ctsdb/stdby_redo04.log'Recovery interrupted.MRP0: Background Media Recovery process shutdownTue Aug 31 19:55:48 2004Terminal Recovery: completion detectedCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FI
--failover second step, the implementation of switchoverTue Aug 31 19:56:01 2004ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYTue Aug 31 19:56:01 2004ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYDatabase not recovered through End-Of-REDODatabase not recovered through End- Of-redo
--Switchover error, unable to convert Standby to PrimarySwitchover: Media Recovery Required - Standby Not in Limbora-16139 Signalled Database: Alter Database Commit To Switchover To Primary ...
- Try to use ACTIVATE command, same newspaper ORA-00261 error Tue aug 31 19:57:16 2004alter Database Activate Standby Databaseetue aug 31 19:57:16 2004alter Database ActiVate [Physical] Standby Databaseetue Aug 31 19:57:31 2004Warning: log 4 of thread 1 is being archived or modifiedActivate standby database received error 261ORA-261 signalled during: ALTER DATABASE ACTIVATE STANDBY DATABASE ... Tue Aug 31 19:58:18 2004ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYTue Aug 31 19:58:18 2004ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYDatabase not recovered through End-Of-REDODatabase not recovered through End-Of-REDOSwitchover: Media recovery required - standby not in limboORA-16139 signalled during: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY ...
- Re-set to the standby mode management resume Tue Aug 31 20:04:18 2004ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSIONAttempt to start background Managed Standby Recovery processMRP0 started with pid = 12MRP0: Background Managed Standby Recovery process startedTue Aug 31 20: 04:22 2004RFS: Possible network disconnect with primary databaseTue Aug 31 20:04:24 2004Starting datafile 1 recovery in thread 1 sequence 8390Datafile 1: '/global/oradata/ctsdb/system01.dbf'Starting datafile 2 recovery in thread 1 sequence 8390Datafile 2: '/global/oradata/ctsdb/undotbs01.dbf'Starting datafile 3 recovery in thread 1 sequence 8390Datafile 3:' /global/oradata/ctsdb/indx01.dbf'Starting datafile 4 recovery in thread 1 sequence 8390Datafile 4: '/ global / oradata / ctsdb / tools01.dbf'Starting datafile 5 recovery in thread 1 sequence 8390Datafile 5: '/global/oradata/ctsdb/users01.dbf'Starting datafile 6 recovery in thread 1 sequence 8390Datafile 6:' / global / oradata / CTSDB / Perfstat.dbf'Starting DataFile 7 Recovery In T hread 1 sequence 8390Datafile 7: '/global/oradata/ctsdb/stk_his_data1_01.dbf'Starting datafile 8 recovery in thread 1 sequence 8390Datafile 8:' /global/oradata/ctsdb/stk_his_data2_01.dbf'Starting datafile 9 recovery in thread 1 sequence 8390Datafile 9: '/global/oradata/ctsdb/stk_his_data3_01.dbf'Starting datafile 10 recovery in thread 1 sequence 8390Datafile 10:' /global/oradata/ctsdb/stk_his_data4_01.dbf'Starting datafile 11 recovery in thread 1 sequence 8390Datafile 11: '/ Global / ORADATA / CTSDB / STK_HIS_IND_TS01.DBF'Starting DataFile 12 Recovery In Thread 1 SEQUENCE 8390DataFile 12: '/global/oradata/ctsdb/stk_his_ind_ts03.dbf'
Starting datafile 13 recovery in thread 1 sequence 8390Datafile 13: '/global/oradata/ctsdb/stk_his_ind_data1_01.dbf'Starting datafile 14 recovery in thread 1 sequence 8390Datafile 14:' /global/oradata/ctsdb/stk_his_ind_data2_01.dbf'Starting datafile 15 recovery in thread 1 sequence 8390Datafile 15: '/global/oradata/ctsdb/stk_his_ind_data3_01.dbf'Starting datafile 16 recovery in thread 1 sequence 8390Datafile 16:' /global/oradata/ctsdb/stk_his_ind_data4_01.dbf'Starting datafile 17 recovery in thread 1 sequence 8390Datafile 17: '/global/oradata/ctsdb/stk_his_ts01.dbf'Starting datafile 18 recovery in thread 1 sequence 8390Datafile 18:' /global/oradata/ctsdb/stk_his_ts02.dbf'Starting datafile 19 recovery in thread 1 sequence 8390Datafile 19: ' /global/oradata/ctsdb/stk_inx_ts01.dbf'Starting datafile 20 recovery in thread 1 sequence 8390Datafile 20: '/global/oradata/ctsdb/stk_inx_ts02.dbf'Starting datafile 21 recovery in thread 1 sequence 8390Datafile 21:' / global / oradata /ctsdb/stk_ts01.dbf ' Starting datafile 22 recovery in thread 1 sequence 8390Datafile 22: '/global/oradata/ctsdb/stk_ts02.dbf'Starting datafile 23 recovery in thread 1 sequence 8390Datafile 23:' /global/oradata/ctsdb/logmnrts01.dbf'Starting datafile 24 recovery in thread 1 sequence 8390Datafile 24: '/global/oradata/ctsdb/ts_test01.dbf'Starting datafile 25 recovery in thread 1 sequence 8390Datafile 25:' /global/oradata/ctsdb/ts_test02.dbf'Starting datafile 26 recovery in thread 1 sequence 8390Datafile 26: '/global/oradata/ctsdb/stk_his_ind_ts02.dbf'Starting DataFile 27 Recovery In Thread 1 SEQUENCE 8390DataFile 27:'
/global/oradata/ctsdb/stk_ts03.dbf'Media Recovery Waiting for thread 1 seq # 8390Tue Aug 31 20:04:24 2004Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DI-- with skip standby logfile option for failoverTue Aug 31 20:04 : 40 2004ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILETue Aug 31 20:04:40 2004Database not recovered through End-Of-REDOTerminal Incomplete Recovery: request postedTue Aug 31 20:04:54 2004Terminal Incomplete Recovery: UNTIL CHANGE 3592753Terminal Incomplete Recovery: End-Of-Redo log allocationTerminal Incomplete Recovery: log 4 reserved for thread 1 seq # 8390TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0Switching logfile format version from 8.0.0.0.0 to 9.0.0.0. 0Terminal Incomplete Recovery: clearing standby redo logs.Terminal Incomplete Recovery: thread 1 seq # 8390 redo requiredTerminal Incomplete Recovery: End-of-Redo log /global/oradata/ctsdb/stdby_redo04.logIdentified end-of-REDO for thread 1 sequence 8390Termi nal Incomplete Recovery: end checkpoint SCN 3592754MRP0: Media Recovery CompleteSwitching logfile format version from 9.0.0.0.0 to 8.0.0.0.0Terminal Incomplete Recovery: successful completionBegin: Wait for standby logfiles to be archivedTue Aug 31 20:04:55 2004ARC0: Evaluating archive ?? log 4 thread 1 sequence 8390ARC0: Beginning to archive log 4 thread 1 sequence 8390Tue Aug 31 20:04:55 2004ARC1: Evaluating archive ?? log 4 thread 1 sequence 8390Tue Aug 31 20:04:55 2004Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oradata/ctsdb/archive/arch1_8390.log'
Tue Aug 31 20:04:55 2004ARC1: Unable to archive log 4 thread 1 sequence 8390 ????? Log actively being archived by another processTue Aug 31 20:04:55 2004ARC0:? Completed archiving log 4 thread 1 sequence 8390Tue Aug 31 20:05:10 2004End: All standby logfiles have been archivedResetting standby activation ID 4038461969 (0xf0b60a11) MRP0: Background Media Recovery process shutdownTue Aug 31 20:05:10 2004Terminal Incomplete Recovery: completion detectedCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FI- -failover is successful, but you can see that the database is replandlogs, which is not what we hope, and because Skip has current Standby Redo Log, there is definitely a considerable data loss. Tue Aug 31 20:05:12 2004ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYRESETLOGS after incomplete recovery UNTIL CHANGE 3592754Resetting resetlogs activation ID 0 (0x0) Online log 3 of thread 1 was previously clearedOnline log 5 of thread 0 was previously clearedOnline log 6 of thread 0 was previously clearedOnline log 7 of thread 0 was previously clearedRESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0Switchover: Complete - Database shutdown requiredCompleted: ALTER DATABASE COMMIT tO SWITCHOVER tO PRIMARY
Check Metalink, just saying that this is possible because Standby Redo log is not enabled, but the situation here is obviously enabled.
