Oracle RMAN Backups and Recovery

Oracle RMAN: What It Is and Why It Matters

Recovery Manager (RMAN) is Oracle's built-in backup and recovery tool. It connects directly to an Oracle database, understands its internal structure, and automates tasks that would be error-prone if done manually. RMAN is the standard method for protecting Oracle databases in production environments, and it is central to the Oracle DBA CA and Microsoft DP-300 exam objectives that overlap with backup strategy concepts. Understanding RMAN is also directly tested in the DAMA CDMP framework under data operations and continuity planning.

Core Concepts Before You Type a Command

Target database – the Oracle database instance RMAN is backing up or recovering. You must connect to it with a user who has the SYSDBA or SYSBACKUP privilege.

Recovery catalog – an optional but highly recommended separate Oracle schema that stores RMAN metadata: backup history, datafile locations, and archived log information. Without a catalog, RMAN stores metadata only in the target's control file, which is lost if the control file is lost. Registering your target in a recovery catalog with `REGISTER DATABASE` protects that metadata.

Fast Recovery Area (FRA) – a disk location configured with `DB_RECOVERY_FILE_DEST` and `DB_RECOVERY_FILE_DEST_SIZE` where Oracle automatically manages backup files, archived redo logs, and flashback logs. Always confirm the FRA has sufficient space before running a backup.

Archived redo logs – copies of the online redo logs written when the database runs in ARCHIVELOG mode. Without archived logs you cannot perform media recovery. Always verify ARCHIVELOG mode is enabled before relying on RMAN for point-in-time recovery.

Backup Types: Full and Incremental

RMAN supports two primary backup types:

• Full backup – copies every used data block in every datafile. It is the foundation for recovery but takes the most time and space.
• Incremental backup – copies only blocks that changed since a reference backup. RMAN uses a level system:
• Level 0 – functionally identical to a full backup but qualifies as the base for subsequent incremental backups. A full backup does NOT serve as a level 0 parent.
• Level 1 differential – backs up blocks changed since the most recent level 0 or level 1 backup.
• Level 1 cumulative – backs up blocks changed since the most recent level 0 backup only. Cumulative backups are larger than differential backups but simplify recovery because you only need the last cumulative plus the level 0.

A common production strategy: run a level 0 on Sunday, level 1 cumulative Monday through Saturday, and back up archived logs frequently throughout the day.

Connecting RMAN and Running a Full Backup

From the OS command line, connect RMAN to the target database:

```

rman TARGET /

```

This connects using OS authentication. To connect to a recovery catalog simultaneously:

```

rman TARGET / CATALOG rman_user/password@catalog_db

```

Register the target database in the catalog once:

```

REGISTER DATABASE;

```

Run a full backup including archived logs:

```

BACKUP DATABASE PLUS ARCHIVELOG;

```

Verify the backup completed and review its contents:

```

LIST BACKUP SUMMARY;

```

Always run `CROSSCHECK BACKUP` after any backup to confirm that the backup pieces on disk match what RMAN recorded in the catalog or control file. Backups listed as EXPIRED are no longer accessible and must be addressed before you depend on them for recovery.

Incremental Backup Scripts

Level 0 (run on day 1):

```

BACKUP INCREMENTAL LEVEL 0 DATABASE;

```

Level 1 cumulative (run on subsequent days):

```

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

```

After either run, use:

```

REPORT SCHEMA;

```

This lists all datafiles registered for the target database and is useful for confirming RMAN sees the current database structure before and after structural changes.

Simulating and Recovering from a Media Failure

A media failure occurs when a datafile becomes inaccessible — for example, when a disk fails or a file is accidentally deleted. The recovery sequence in RMAN is straightforward:

1. RMAN (or Oracle) takes the datafile offline automatically when it detects the error, or you take it offline manually using SQL: `ALTER DATABASE DATAFILE '/path/to/file.dbf' OFFLINE;`

2. Remove or rename the file at the OS level to simulate the failure.

3. In RMAN, restore the physical file from backup:

```

RESTORE DATAFILE '/path/to/file.dbf';

```

4. Apply archived redo logs to bring the file current:

```

RECOVER DATAFILE '/path/to/file.dbf';

```

5. Bring the datafile back online:

```sql

ALTER DATABASE DATAFILE '/path/to/file.dbf' ONLINE;

```

6. Open the database if it was shut: `ALTER DATABASE OPEN;`

Document every command and its output in your lab log. Recovery exercises are only valid if they are repeatable and documented.

Safety and Access Control Considerations

Database backup work does not involve physical electrical hazards, but it carries significant data safety responsibilities:

• Always work on the designated lab instance, never on any production system without explicit authorization.
• Backup credentials (SYSDBA passwords, catalog passwords) must be stored securely and never shared in lab logs submitted to instructors.
• Removing a datafile at the OS level during the simulation exercise must be done only on the lab instance with instructor confirmation. Deleting the wrong file on a shared server can cause data loss for others.
• Confirm with your instructor which Oracle user account and which database SID you are authorized to use before connecting RMAN.