Database Tutorials MSSQL, Oracle, PostgreSQL, MySQL, MariaDB, DB2, Sybase, Teradata, Big Data, NOSQL, MongoDB, Couchbase, Cassandra, Windows, Linux 
Whether the ARCHIVE Logs are transferred to Standby can be seen from the ALERT LOGs as follows.
1 2 3 4 5 6 7 | Thu Oct 03 16:18:27 2019 Thread 1 advanced to log sequence 105672 (LGWR switch)-->Log Switch operation performed. Current Redo Log Sequence number reported. Current log# 1 seq# 105672 mem# 0: +DATA/mhrs/onlinelog/group_1.261.922153509 Thu Oct 03 16:18:33 2019 Archived Log entry 291716 added for thread 1 sequence 105671 ID 0x59914531 dest 1:--><strong>Archived Redo Log information reported.</strong> Thu Oct 03 16:18:33 2019 ARC7: Standby redo logfile selected for thread 1 sequence 105671 for destination LOG_ARCHIVE_DEST_2 -->This line means that it has started writing to Standby Redo Log Files. |
After the archives are created, sometimes writing to Standby Redo logs cannot begin.
1 2 3 4 5 | Thu Oct 03 16:31:55 2019 Thread 1 advanced to log sequence 105673 (LGWR switch) Current log# 2 seq# 105673 mem# 0: +DATA/mhrs/onlinelog/group_2.266.922153515 Thu Oct 03 16:32:00 2019 Archived Log entry 291720 added for thread 1 sequence 105672 ID 0x59914531 dest 1: |
After a while, the following error appears in the ALERT LOG.
1 2 3 4 5 6 7 8 9 10 11 | Thu Oct 03 16:38:50 2019 Killing 1 processes with pids 28800 (Process by index) in order to remove hung processes. Requested by OS process 8357 on instance 1 Thu Oct 03 16:38:50 2019 ARC1: Detected ARCH process failure ARC1: STARTING ARCH PROCESSES Thu Oct 03 16:38:50 2019 ARC9 started with pid=365, OS id=30582 ARC9: Archival started ARC1: STARTING ARCH PROCESSES COMPLETE Reclaiming FAL entry from dead process [pid 28800] FAL[server, ARC9]: FAL archive failed, see trace file. |
This can also be seen in the following screenshot. Although the archive of sequence 105672 has been created, the DEST_ID is not visible. In other words, writing to Standby Redos cannot be started.
1 2 | SELECT SYSDATE, v.* FROM V$ARCHIVED_LOG v WHERE (THREAD#, SEQUENCE#) IN ( SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#) ORDER BY THREAD#, DEST_ID; |
A similar situation can be seen on the following screen. Although it was 16:47, writing to standby redos has not started yet. However, the archives were created in PROD at 16:32 and 16:45.
While these situations occur, the system’s active connection graph is as follows.
ALERT LOG has the following information.
1 2 3 4 5 6 7 8 9 10 | Thu Oct 03 16:52:12 2019 Killing 1 processes with pids 19203 (Process by index) in order to remove hung processes. Requested by OS process 38173 on instance 2 ARC9: Detected ARCH process failure ARC9: STARTING ARCH PROCESSES Thu Oct 03 16:52:14 2019 ARC7 started with pid=645, OS id=55249 ARC7: Archival started ARC9: STARTING ARCH PROCESSES COMPLETE Reclaiming FAL entry from dead process [pid 19203] ARC9: Standby redo logfile selected for thread 2 sequence 127910 for destination LOG_ARCHIVE_DEST_2 |
