During the RECOVER restoration process of RMAN, the RMAN interface is normal, but the alarm log is checked and refreshed. It is found that there is ORA-279 in the alarm log, as follows:
alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arc'Thu Feb 21 08:49:48 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arcThu Feb 21 08:50:58 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arc'...Thu Feb 21 08:50:59 CST 2019alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arc'Thu Feb 21 08:50:59 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arcThu Feb 21 08:51:12 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arc'...Thu Feb 21 08:51:12 CST 2019alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arc'Thu Feb 21 08:51:12 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arcThu Feb 21 08:51:39 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arc'...Thu Feb 21 08:51:39 CST 2019alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arc'Thu Feb 21 08:51:39 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arcThu Feb 21 08:51:54 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arc'...Thu Feb 21 08:51:54 CST 2019alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arc'Thu Feb 21 08:51:54 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arcThu Feb 21 08:52:13 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arc'...Thu Feb 21 08:52:13 CST 2019alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arc'Thu Feb 21 08:52:13 CST 2019Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arcThu Feb 21 08:52:46 CST 2019ORA-279 signalled during: alter database recover logfile '/u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arc'...Thu Feb 21 08:52:46 CST 2019alter database recover cancelThu Feb 21 08:52:46 CST 2019Media Recovery CanceledCompleted: alter database recover cancel
In fact, in this scenario, ORA-279 in the alarm log is more like an "output message" than an "error message", which is a reminder that the requested archive log can continue to recover. This detail has not been noticed before when using RMAN for RECOVER. By the way, record it. In order to avoid the first time encounter this prompt information, but also think that there are any abnormalities or errors.
[root@DB-Server 2019_02_16]$ oerr ora 279
00279, 00000, "change %s generated at %s needed for thread %s"
// *Cause: The requested log is required to proceed with recovery.
// *Action: Please supply the requested log with "ALTER DATABASE RECOVER
// LOGFILE <file_name>" or cancel recovery with "ALTER DATABASE
// RECOVER CANCEL".
Yes, you can ignore the ORA-279s. Treat them as "messages" rather then "errors".
You need to ensure that all archivelogs are being applied by the recovery process.
Reference material: