Introduction

Oracle Recovery Manager (RMAN) is Oracle’s built-in utility for backing up, restoring, and recovering Oracle databases. It helps DBAs protect critical database files and recover databases after disk failures, accidental file deletion, database corruption, or user errors.

In Oracle Database 19c, RMAN supports full and incremental backups, compressed backup sets, archived redo log backups, control file backups, SPFILE backups, and point-in-time recovery (PITR).

In this tutorial, we will cover the most commonly used RMAN commands with practical examples suitable for Oracle DBAs working in development, testing, and production environments.

1. Prerequisites for RMAN Backup

Before running RMAN backups, verify the following requirements:

• Oracle Database 19c is installed and configured.
• The database is running or mounted, depending on the backup operation.
• The operating system has sufficient space for backup files.
• The backup destination exists and is writable by the Oracle software owner.
• The required administrative privileges are available.
• The database is in ARCHIVELOG mode if online backups and point-in-time recovery are required.

For a production database, it is recommended to configure a Fast Recovery Area (FRA), establish a backup retention policy, and regularly test database recovery.

Check the database status

Connect to SQL*Plus:

sqlplus / as sysdba

Check the database status:

SELECT name, open_mode, log_mode
FROM v$database;

Check the instance status:

SELECT instance_name, status
FROM v$instance;

These commands help confirm whether the database is open and whether ARCHIVELOG mode is enabled.

2. Enable ARCHIVELOG Mode

ARCHIVELOG mode allows Oracle to preserve redo information in archived redo log files. These files are essential for recovering database changes made after a backup.

Important: Enabling ARCHIVELOG mode requires a planned database restart. Perform this operation during an approved maintenance window.

Step 1: Shut down the database

SHUTDOWN IMMEDIATE;

Step 2: Start the database in mount mode

STARTUP MOUNT;

Step 3: Enable ARCHIVELOG mode

ALTER DATABASE ARCHIVELOG;

Step 4: Open the database

ALTER DATABASE OPEN;

Step 5: Verify ARCHIVELOG mode

ARCHIVE LOG LIST;

You can also verify the setting with:

SELECT log_mode FROM v$database;
LOG_MODE
------------
ARCHIVELOG

Once ARCHIVELOG mode is enabled, RMAN can perform online database backups and use archived redo logs for recovery.

3. Configure RMAN Backup Location

First, create a backup directory on the database server. For example:

mkdir -p /u01/backup/rman
chown oracle:oinstall /u01/backup/rman
chmod 750 /u01/backup/rman

Run these operating system commands as an appropriately privileged administrator, adjusting the ownership and permissions to match your environment.

Start RMAN and connect to the target database:

rman target /

Configure disk as the default backup device:

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

Configure a backup format:

CONFIGURE CHANNEL DEVICE TYPE DISK
FORMAT '/u01/backup/rman/%U';

Here, %U generates a unique name for each backup piece.

Display the current RMAN configuration:

SHOW ALL;

Note: If a Fast Recovery Area is configured, RMAN can use it as the backup destination when no other destination is specified. A configured channel format can override the default destination.

4. Perform a Full Database Backup

A full RMAN backup copies all selected data blocks in the database files. It is commonly used as part of a database protection strategy.

Connect to RMAN:

rman target /

Run the backup:

BACKUP AS COMPRESSED BACKUPSET
DATABASE
TAG 'FULL_DB_BKP';

This command creates a compressed backup set and assigns the tag FULL_DB_BKP.

To back up the database along with its archived redo logs, use:

BACKUP AS COMPRESSED BACKUPSET
DATABASE PLUS ARCHIVELOG
TAG 'FULL_DB_BKP';

The second command is useful for an online backup when the database is in ARCHIVELOG mode.

Why use compressed backup sets?

Compressed backup sets can reduce the amount of storage needed for backups. However, compression consumes CPU resources, so test its performance impact before enabling it for large production databases.

5. Perform a Level 0 Incremental Backup

A Level 0 incremental backup is the baseline for an incremental backup strategy. It backs up the database blocks needed to establish a Level 0 baseline.

Example:

BACKUP INCREMENTAL LEVEL 0
DATABASE
TAG 'LEVEL0_BKP';

For a compressed Level 0 backup:

BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
DATABASE
TAG 'LEVEL0_BKP';

To include archived redo logs:

BACKUP INCREMENTAL LEVEL 0
DATABASE PLUS ARCHIVELOG
TAG 'LEVEL0_BKP';

Difference between a full backup and a Level 0 backup

A conventional full backup is not the same as a Level 0 incremental backup for RMAN incremental backup processing. A Level 0 backup can serve as the baseline for subsequent Level 1 incremental backups.

6. Perform a Level 1 Incremental Backup

A Level 1 incremental backup backs up blocks changed since an applicable earlier incremental backup.

There are two main types:

• Differential Level 1: Backs up blocks changed since the most recent Level 0 or Level 1 incremental backup.
• Cumulative Level 1: Backs up blocks changed since the most recent Level 0 backup.

Differential Level 1 backup

BACKUP INCREMENTAL LEVEL 1
DATABASE
TAG 'LEVEL1_DIFF_BKP';

Cumulative Level 1 backup

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE
DATABASE
TAG 'LEVEL1_CUM_BKP';

Back up archived redo logs

BACKUP ARCHIVELOG ALL
TAG 'ARCH_BKP';

Archived redo logs are important because they contain changes required to recover a restored database to a later point.

A common strategy is to take a Level 0 backup periodically and Level 1 backups more frequently. The exact schedule depends on the recovery time objective (RTO), recovery point objective (RPO), database size, and available storage.

7. Back Up the Control File and SPFILE

The control file contains important database metadata, including information about database structure and RMAN backup records. The SPFILE stores server initialization parameters.

Back up the current control file

BACKUP CURRENT CONTROLFILE
TAG 'CTL_BKP';

Back up the SPFILE

BACKUP SPFILE
TAG 'SPFILE_BKP';

Enable control file and SPFILE autobackups

CONFIGURE CONTROLFILE AUTOBACKUP ON;

With control file autobackup enabled, RMAN automatically creates control file backups during applicable backup operations and also backs up the SPFILE when one is used.

Autobackup is particularly important if the current control file is lost or damaged.

8. List and Validate RMAN Backups

A successful backup job does not eliminate the need to verify backup availability and integrity.

Display backup information

LIST BACKUP;

Display a summary of backups

LIST SUMMARY;

Crosscheck backup records against physical files

CROSSCHECK BACKUP;

The CROSSCHECK command checks whether recorded backup pieces are available at their expected storage locations. It does not perform a full restore test.

Validate the database backup

RESTORE DATABASE VALIDATE;

This command checks whether RMAN can read the required backup data for a database restore without actually restoring the database files.

Delete expired backup records

DELETE EXPIRED BACKUP;

Delete obsolete backups

REPORT OBSOLETE;

After reviewing the report, obsolete backups can be removed according to the configured retention policy:

DELETE OBSOLETE;

Production precaution: Never delete backups manually or remove archived redo logs without understanding the retention policy and recovery requirements. An expired backup record is not the same as an obsolete backup.

9. Complete Database Restore and Recovery

Complete recovery restores the required database files from backups and applies the available redo changes to recover the database to the latest recoverable point.

The procedure depends on which files were lost and whether the control file is still available.

The following example illustrates recovery after losing the database files and control file.

Step 1: Start the database in NOMOUNT mode

Connect to SQL*Plus:

sqlplus / as sysdba

Start the instance:

Step 2: Restore the control file

If a control file autobackup is available, RMAN can search for it when the database identifier and autobackup configuration are known.

For example:

rman target /

Then:

SET DBID 1234567890;
RESTORE CONTROLFILE FROM AUTOBACKUP;

Replace 1234567890 with the actual database identifier.

Alternatively, if the exact control file backup piece is known:

RESTORE CONTROLFILE
FROM '/u01/backup/rman/controlfile_backup_piece';

The path must point to an actual backup piece accessible to the database server.

Step 3: Mount the database

ALTER DATABASE MOUNT;

Step 4: Catalog backups if necessary

If backup pieces are available but are not recorded in the restored control file or recovery catalog, register the backup files:

CATALOG START WITH '/u01/backup/rman/';

Confirm the available backups:

LIST BACKUP;

Step 5: Restore the database files

RESTORE DATABASE;

RMAN restores the required data files from the selected backups.

Step 6: Recover the database

RECOVER DATABASE;

RMAN applies the required redo information available from the archived and online redo logs, as applicable.

Step 7: Open the database

For a complete recovery using the current control file, the usual command is:

ALTER DATABASE OPEN;

If the control file was restored from a backup, recovery was incomplete, or the recovery procedure otherwise requires a new incarnation, the database may need to be opened with RESETLOGS.

ALTER DATABASE OPEN RESETLOGS;

Important: Do not use RESETLOGS automatically after every recovery. Follow the specific recovery scenario and Oracle’s documented procedure. Opening with RESETLOGS creates a new database incarnation.

10. Point-in-Time Recovery (PITR)

Point-in-time recovery restores the database to a specified time, SCN, or restore point. It is useful when a user accidentally drops a table, deletes important data, or performs an incorrect application deployment that changes database contents.

Whole-database PITR generally discards database changes made after the selected recovery target.

Example: Recover to a specific time

Assume the recovery target is 28 September 2026 at 10:00 AM.

First, ensure that the database is mounted and that the required backups and archived redo logs are available.

Start RMAN:

rman target /

Run:

RUN
{
    SET UNTIL TIME
        "TO_DATE('2026-09-28 10:00:00',
                 'YYYY-MM-DD HH24:MI:SS')";
    RESTORE DATABASE;
    RECOVER DATABASE;
}

After successful recovery, open the database:

ALTER DATABASE OPEN RESETLOGS;

The example assumes a whole-database recovery scenario that requires opening with RESETLOGS. If the database is being recovered from a backup control file or to an earlier point, follow the appropriate documented recovery procedure.

Important PITR precautions

• Confirm the exact target time or SCN before starting.
• Ensure the necessary archived redo logs are available.
• Confirm that the backup predates the target time.
• Use an isolated auxiliary database or another approved recovery method when you need to inspect recovered data without rolling back the production database.
• After PITR and RESETLOGS, take a new backup according to your backup strategy.

11. Commonly Used RMAN Commands