The following errors were seen in the ALERTLOG file of the STANDBY Database if the PRODUCTION Database suddenly shuts down.
(STANDBYDB)
Mon Dec 21 17:53:29 2015
RFS[18]: Assigned to RFS process 15600
RFS[18]: Possible network disconnect with primary database
Mon Dec 21 17:53:29 2015
RFS[16]: Possible network disconnect with primary database
Mon Dec 21 17:53:29 2015
RFS[14]: Possible network disconnect with primary database
Mon Dec 21 17:54:15 2015
Killing 1 processes with pids 15391 (idle RFS by thread/sequence) in order to retry receiving a log after reattaching. Requested by OS process 14652 on instance 2
Mon Dec 21 17:54:17 2015
RFS[11]: Selected log 12 for thread 1 sequence 9902 dbid 1853001179 branch 864558941
In this case, when I checked the database, archive logs were transferred succesfully, but the APPLY operation could not be performed.
(STANDBY DB)
1 2 3 4 5 6 7 8 9 | SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# APPLIED ---------- --------- 7813 NO 9898 NO 9897 NO 7812 NO 9899 NO |
1 | SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; |
1 2 3 4 5 6 7 8 9 10 11 | NODE1; SQL> shutdown immediate; NODE2; (This process took too long. We have to wait a little patiently.) SQL> shutdown immediate; NODE1; SQL> startup mount; NODE2; SQL> startup mount; |
1 | SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; |
With SQL Query;
1 2 3 4 5 6 7 8 9 10 | SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# APPLIED ---------- --------- 7664 YES 7665 YES 7666 YES 7667 YES 7668 YES 7669 YES |
From Alert Log;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | Mon Dec 28 23:04:43 2015 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process (mwdb1) Mon Dec 28 23:04:43 2015 MRP0 started with pid=75, OS id=12709 MRP0: Background Managed Standby Recovery process started (mwdb1) started logmerger process Mon Dec 28 23:04:48 2015 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 64 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Mon Dec 28 23:04:50 2015 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_1_seq_9897.597.899034735 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_2_seq_7810.594.899031565 Mon Dec 28 23:05:01 2015 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_2_seq_7811.595.899031583 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_2_seq_7812.599.899034789 Mon Dec 28 23:05:34 2015 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_1_seq_9898.598.899034735 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_2_seq_7813.596.899034733 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_2_seq_7814.602.899034937 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_1_seq_9899.600.899034933 Media Recovery Log +FRA/mwstdbydb/archivelog/2015_12_21/thread_1_seq_9900.601.899034933 |
In ALERT_LOG file above, after STANDBY DB is altered, the process flow is seen. The step of MEDIA RECOVERY shows that the ARCHIVE LOGS are applied.
1 | tail -1000f /u01/app/oracle/diag/rdbms/mystandby/mydbname1/trace/alert_mydbname1.log |