When running media recovery with RMAN, the alert log may show repeated lines like "ORA-279 signalled during: alter database recover logfile …". Despite the ORA prefix, this is not necessarily an error. ORA-00279 indicates that the database is requesting the next archived redo log needed to continue recovery. RMAN typically handles this automatically when all required logs are available.

Example alert log excerpts

The alert log may look similar to the following while RMAN is applying archived logs:

Wed Mar 27 11:03:21 UTC 2024
alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24581_j4abc123_.arc'
Media Recovery Log /u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24581_j4abc123_.arc
Wed Mar 27 11:04:02 UTC 2024
ORA-279 signalled during: alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24581_j4abc123_.arc'...

Wed Mar 27 11:04:02 UTC 2024
alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24582_j4abd9xk_.arc'
Media Recovery Log /u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24582_j4abd9xk_.arc
Wed Mar 27 11:04:29 UTC 2024
ORA-279 signalled during: alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24582_j4abd9xk_.arc'...

Wed Mar 27 11:04:29 UTC 2024
alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24583_j4abej2t_.arc'
Media Recovery Log /u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24583_j4abej2t_.arc
Wed Mar 27 11:05:04 UTC 2024
ORA-279 signalled during: alter database recover logfile '/u01/fra/ORCL/archivelog/2024_03_27/o1_mf_1_24583_j4abej2t_.arc'...

These "ORA-279 signalled during" lines show the internal ALTER DATABASE RECOVER LOGFILE commands that the instance is executing while applying each archived log. They are informational and expected as recovery progresses from one log to the next.

What ORA-00279 means

ORA-00279: "change %s generated at %s needed for thread %s" is raised to request the next redo to continue recovery. It does not mean recovery has failed. If the requested archived log is present where the recovery process can read it, RMAN or SQL*Plus will proceed with out user input.

You can verify the message text with oerr:

$ 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".

Typical RMAN flow that triggers these messages

RMAN> connect target /
RMAN> startup mount;
RMAN> restore database;
RMAN> recover database;  -- internally issues ALTER DATABASE RECOVER LOGFILE ...

As each archived log is applied, the alert log records the corresponding ALTER DATABASE RECOVER LOGFILE invocation and may note ORA-00279 as the next change is requested.

Supplying or locating required archived logs

If recovery pauses because a specific archived log is missing, you have options:

• Provide the exact file requested

  • Place the file where the database expects it (log_archive_dest or FRA), or

  • Manually direct recovery to it:

    SQL> alter database recover logfile '/path/to/archivelog/o1_mf_1_24584_xxx_.arc';
    

• Let SQL*Plus prompt for each log, or use automatic progression:

  SQL> recover database until cancel;
  SQL> auto;  -- if all logs are accessible, applies them automatically
  

• Cancel if you intentionally want to stop at the current point-in-time:

  SQL> alter database recover cancel;
  

Verifying coverage and continuity of archived logs

Before or during recovery, ensure that the set of required archived logs is complete and reachable:

• List archived logs known to the control file:

  SQL> select thread#, sequence#, first_time, next_time, name
       from v$archived_log
       order by thread#, sequence#;
  

• Check for gaps in sequences per thread:

  SQL> select thread#, min(sequence#) as start_seq, max(sequence#) as end_seq,
              count(*) as cnt
       from v$archived_log
       group by thread#;
  

• From RMAN, list backups of archived logs and their availability:

  RMAN> list archivelog all;
  RMAN> list backup of archivelog all;
  

• If using FRA, confirm space and presence of files:

  SQL> show parameter db_recovery_file_dest;
  SQL> show parameter db_recovery_file_dest_size;
  $ ls -l $ORACLE_BASE/fast_recovery_area/<DB_UNIQUE_NAME>/archivelog/
  

When to treat ORA-00279 as actionable

• The same archived log is requested repeatedly and recovery does not advance in sequence.
• The alert log requests a sequence that is not present on disk or in backups.
• RMAN reports additional errors (e.g., ORA-00308, ORA-00310) indicating the file cannot be opened or is corrupt.

In those cases, locate and restore the missing archived redo log from backup, recreate it from upstream (e.g., primary in a Data Guard context), or adjust your recovery target (e.g., UNTIL SCN/TIME before the missing sequence).

In normal, continuous recovery where all required logs exist, ORA-00279 in the alert log can be treated as an informational prompt indicating the next archived log is being requested and applied.