Archived Redo Log Backup Sets

Create an archived redo log backup set

The basic command backs up all archived redo logs selected by RMAN to the configured backup destination:

BACKUP ARCHIVELOG ALL;

If the same thread and sequence exists in multiple archive destinations, RMAN backs up one copy of that distinct archived redo log. The word ALL does not inherently mean only logs that have never been backed up. Backup optimization, an archived-log deletion policy, or an explicit command operand can cause RMAN to skip logs that already satisfy the configured requirements.

Use NOT BACKED UP when the job must select logs without the required number of backups on the relevant device type:

BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;

Create binary-compressed backup sets when storage or network savings justify the additional CPU cost:

BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL;

Test compression against both backup and restore performance. A smaller backup is useful only when it continues to satisfy the recovery-time objective and does not create unacceptable CPU contention.

Database state and multitenant requirements

The target database must be mounted or open for an RMAN archived redo log backup. A database described as closed for this operation should be mounted but not open. An idle instance is not sufficient.

In a multitenant database, connect to the CDB root as a common user with the SYSBACKUP or SYSDBA privilege. An RMAN session connected directly to a PDB cannot include archived redo logs in a backup.

When local operating-system authentication is configured, start RMAN without placing a password in the command:

rman target /

For remote administration, use an Oracle Net service and the approved credential-management process for the environment. Do not embed production credentials in scripts or instructional examples.

Identify archived redo log sets with RMAN LIST

The RMAN LIST command is the recommended first check because it presents repository information in an operational format:

LIST BACKUP OF ARCHIVELOG ALL;
LIST BACKUP OF ARCHIVELOG ALL SUMMARY;
LIST BACKUP SUMMARY;

Detailed output for an archived redo log backup set contains a heading similar to List of Archived Logs in backup set 227. The rows below that heading identify the thread, sequence, SCN range, and time range of each archived redo log in the set.

Important fields include:

• BS Key: The backup-set identifier. With a recovery catalog, this is the catalog's BS_KEY. In NOCATALOG mode, RMAN derives the displayed key from control-file metadata.
• Thrd: The redo thread number. This is especially important in Oracle RAC environments.
• Seq: The archived redo log sequence number.
• Low SCN and Low Time: The beginning of the redo range represented by the log.
• Next SCN and Next Time: The upper boundary represented by the next log in the thread.
• Piece Name/Handle: The physical disk path or media-manager handle for the backup piece.

In LIST BACKUP SUMMARY, an LV value of A identifies an archived redo log backup set. Data file sets use F, 0, or 1.

Filter the listing when the repository contains many logs:

LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 100;

LIST BACKUP OF ARCHIVELOG
  FROM SCN 853145
  UNTIL SCN 854039;

LIST BACKUP OF ARCHIVELOG LIKE '/archive/%';

LIST BACKUP TAG 'ARCH_WEEKLY';

Select archived redo logs for backup

BACKUP ARCHIVELOG
  FROM TIME 'SYSDATE-1'
  UNTIL TIME 'SYSDATE';

BACKUP ARCHIVELOG
  FROM SCN 850000
  UNTIL SCN 900000;

BACKUP ARCHIVELOG
  FROM SEQUENCE 100
  UNTIL SEQUENCE 150
  THREAD 1;

BACKUP ARCHIVELOG LIKE '/archive/%';

Identify sets with control-file views

Use the target database's dynamic-performance views for local scripted inventories. The amount of history available depends on the backup records still retained in the control file.

Query backup-set headers

SELECT recid,
       set_stamp,
       set_count,
       backup_type,
       pieces,
       start_time,
       completion_time,
       con_id
FROM   v$backup_set
WHERE  backup_type = 'L'
ORDER BY completion_time DESC;

SET_STAMP and SET_COUNT together identify one backup set across the control-file views. V$BACKUP_SET contains successfully completed set records, but it does not contain a STATUS column. Inspect the backup pieces or a reporting view when availability status is required.

List the archived redo logs in each set

SELECT s.recid              AS bs_recid,
       s.set_stamp,
       s.set_count,
       r.thread#,
       r.sequence#,
       r.first_change#,
       r.next_change#,
       r.first_time,
       r.next_time
FROM   v$backup_set     s
JOIN   v$backup_redolog r
       ON  r.set_stamp = s.set_stamp
       AND r.set_count = s.set_count
WHERE  s.backup_type = 'L'
ORDER BY s.completion_time DESC,
         r.thread#,
         r.sequence#;

V$BACKUP_REDOLOG contains one row for each archived redo log represented in a backup set. The thread, sequence, and resetlogs information together distinguish the log and its database-incarnation context.

Find the physical backup pieces

SELECT p.set_stamp,
       p.set_count,
       p.piece#,
       p.copy#,
       p.handle,
       p.device_type,
       p.status,
       p.bytes,
       p.completion_time
FROM   v$backup_piece p
WHERE  EXISTS (
         SELECT 1
         FROM   v$backup_set s
         WHERE  s.set_stamp = p.set_stamp
           AND  s.set_count = p.set_count
           AND  s.backup_type = 'L'
       )
ORDER BY p.set_stamp DESC,
         p.set_count DESC,
         p.piece#,
         p.copy#;

Piece-level status shows whether the physical backup is available to RMAN. Run CROSSCHECK BACKUP according to the maintenance policy so repository status reflects the files or media objects that are actually accessible.

Use the archived-log details view

V$BACKUP_ARCHIVELOG_DETAILS combines useful information about restorable archived redo logs. It can include backup-set and proxy-copy records, so filter the container type:

SELECT btype,
       btype_key,
       id1                AS set_stamp,
       id2                AS set_count,
       thread#,
       sequence#,
       first_change#,
       next_change#,
       completion_time,
       con_id
FROM   v$backup_archivelog_details
WHERE  btype = 'BACKUPSET'
ORDER BY completion_time DESC,
         thread#,
         sequence#;

Identify sets with recovery-catalog views

A recovery catalog preserves metadata independently of the target control file. Use it for longer history, Data Guard environments, multiple incarnations, and centralized reporting across registered databases.

Query archived redo log backup-set headers:

SELECT db_key,
       db_id,
       bs_key,
       backup_type,
       pieces,
       start_time,
       completion_time,
       status,
       site_key
FROM   rc_backup_set
WHERE  backup_type = 'L'
ORDER BY completion_time DESC;

BS_KEY is the recovery-catalog primary key for a set. The STATUS value is A when all pieces are available, D when all pieces are deleted, or O when only some pieces are available and the set is unusable.

Join each set to its archived redo log records:

SELECT r.db_name,
       s.db_key,
       s.bs_key,
       r.brl_key,
       r.thread#,
       r.sequence#,
       r.first_change#,
       r.next_change#,
       r.first_time,
       r.next_time
FROM   rc_backup_set     s
JOIN   rc_backup_redolog r
       ON r.bs_key = s.bs_key
WHERE  s.backup_type = 'L'
ORDER BY s.completion_time DESC,
         r.thread#,
         r.sequence#;

RC_BACKUP_ARCHIVELOG_DETAILS and RC_BACKUP_ARCHIVELOG_SUMMARY provide denormalized information for RMAN and Enterprise Manager reporting. Filter BTYPE = 'BACKUPSET' when a report must exclude proxy copies.

Parallel archived redo log backups

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
  ALLOCATE CHANNEL c3 DEVICE TYPE DISK;

  BACKUP ARCHIVELOG ALL FILESPERSET 2;
}

Additional channels do not guarantee a proportional reduction in backup time. Disk throughput, tape drives, media-manager capacity, CPU, and network bandwidth can become bottlenecks. Monitor job output and views such as V$SESSION_LONGOPS, then tune parallelism using measured backup and restore performance.

DELETE INPUT and archived-log retention

RMAN can remove archived redo log files after a successful backup:

BACKUP ARCHIVELOG ALL DELETE INPUT;

DELETE INPUT deletes the specific archived redo log copy that RMAN backed up. If the same thread and sequence exists in several archive destinations, other copies can remain.

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

DELETE ALL INPUT deletes all copies of each selected archived redo log from all archive destinations after the backup succeeds. Use this option only when the backup and deletion policies satisfy the recovery, retention, and standby requirements.

In a Data Guard environment, configure an archived-log deletion policy that accounts for whether logs have been shipped or applied to the required standby databases. Do not use deletion clauses solely to reclaim space without first confirming that recoverability and standby requirements remain protected.

Practical identification checklist

Begin with RMAN LIST for operational checks. Use control-file and recovery-catalog views for automated inventory, sequence-range analysis, piece-level reporting, historical retention, and multi-database reports.

Parallelism Backup Sets - Quiz

Parallelism Backup Sets - Quiz