ASSIGNMENT

Oracle Database Administration

Topics: Backup, Recovery, RMAN and Data Guard

Subject Oracle Database Administration

Topics Backup, Recovery, RMAN, Data Guard
Date 11 April 2026
Reference Oracle Documentation 19c/21c

Introduction
Oracle Database is one of the most widely used relational database management systems
(RDBMS) in enterprise environments. Ensuring data availability, integrity, and recoverability
is a critical responsibility of every Database Administrator (DBA). This assignment covers
four core topics essential to Oracle database administration:

• Backup – Creating copies of database data to protect against data loss

• Recovery – Restoring the database to a consistent state after failure
• RMAN (Recovery Manager) – Oracle's built-in tool for backup and recovery
operations
• Data Guard – Oracle's solution for high availability and disaster recovery

1. Oracle Database Backup

1.1 What is a Database Backup?
A database backup is a copy of data from a database that can be used to reconstruct that
data. Backups compensate for data loss caused by hardware failure, user error, software
corruption, or natural disasters. Without proper backup strategies, organizations risk
permanent data loss.

1.2 Types of Oracle Backups

A. Physical Backup
Physical backups are copies of the physical files that store database data. These include:
• Datafiles (.dbf) – Store actual table and index data
• Control files – Record database structure and status
• Redo log files – Record all changes made to the database
• Archived log files – Copies of filled online redo logs

B. Logical Backup
Logical backups contain logical data (e.g., tables, procedures) extracted using Oracle
utilities such as Data Pump (expdp/impdp) or the older exp/imp utilities. They are useful for
selective data export and migration.

1.3 Backup Strategies

Backup Type Description When to Use

Full Backup Complete copy of the entire Weekly or monthly
database
Incremental Backup Only blocks changed since last Daily (faster, saves
backup space)
Cumulative Incremental All changes since last full backup Reduces recovery time
Differential Incremental Only changes since last incremental Saves storage space
Logical (Data Pump) Exports selected tables/schemas Migration, archiving

1.4 ARCHIVELOG vs NOARCHIVELOG Mode

Oracle databases can operate in two modes:
• ARCHIVELOG mode – Redo log files are archived before being overwritten. This
enables full recovery to any point in time. Recommended for production databases.
• NOARCHIVELOG mode – Redo logs are overwritten without archiving. Only
complete database backups (cold backups) are possible. Used for development/test
environments.
 -- Check current archive log mode
SQL> SELECT LOG_MODE FROM V$DATABASE;

-- Switch to ARCHIVELOG mode

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

1.5 Cold Backup vs Hot Backup

• Cold Backup (Offline Backup): Database is shut down before backup. All files are in
a consistent state. Simple but causes downtime.
• Hot Backup (Online Backup): Backup taken while the database is running. Requires
ARCHIVELOG mode. No downtime – ideal for 24/7 production systems.

2. Oracle Database Recovery

2.1 What is Database Recovery?
Database recovery is the process of restoring a database to a consistent, usable state after
a failure. Oracle provides comprehensive recovery mechanisms to minimize data loss and
downtime. Recovery involves two main operations:
• Restore: Physically copying backup files back to the correct location
• Recover: Applying redo logs (archived and online) to bring the database to a
consistent state

2.2 Types of Failures Requiring Recovery

Failure Type Cause Recovery Action

Statement Failure Invalid SQL, constraint violation Automatic – statement rolled
back
User Process Failure Program crash, disconnection Automatic – PMON process
recovers
Instance Failure Power loss, OS crash Automatic – crash recovery on
restart
Media Failure Disk crash, file corruption Manual – DBA must restore &
recover
User Error Accidental DROP/DELETE Manual – Point-in-time recovery
2.3 Types of Recovery
A. Complete Recovery
All committed transactions are recovered. No data is lost. Requires all archived log files
from the time of backup to the present.

-- Complete recovery example (RMAN)

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

B. Incomplete Recovery (Point-in-Time Recovery - PITR)

Recovery to a point before the failure. Used when complete recovery is not possible (e.g.,
missing log file) or to undo user errors. The database must be opened with RESETLOGS
after incomplete recovery.

-- Recover to a specific time

RMAN> RUN {
SET UNTIL TIME "TO_DATE('2024-11-15 10:00:00','YYYY-MM-DD HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;

C. Tablespace Point-in-Time Recovery (TSPITR)

Recovers a specific tablespace to a point in time without affecting the rest of the database.
Useful for recovering dropped or corrupted tables within a specific tablespace.

2.4 Oracle Recovery Architecture

Oracle's recovery process relies on several key components:
• SMON (System Monitor Process): Performs instance recovery automatically on
startup after a crash
• Redo Log Files: Record all changes (DML/DDL) to the database
• Archived Log Files: Enable media recovery beyond what online redo logs contain
• Undo Segments: Used to roll back uncommitted transactions during recovery
• Control File: Maintains SCN (System Change Number) tracking for recovery
synchronization
3. RMAN (Recovery Manager)
3.1 What is RMAN?
RMAN (Recovery Manager) is Oracle's built-in utility for efficiently backing up, restoring,
and recovering Oracle databases. It is the preferred backup and recovery tool
recommended by Oracle for all production environments.

3.2 Key Advantages of RMAN

• Automated management of backup files and retention policies
• Block-level incremental backups (only changed blocks are backed up)
• Built-in verification and validation of backups
• Compression and encryption of backup sets
• Integration with Oracle Recovery Catalog for centralized management
• Automatic detection and skipping of unused database blocks
• Supports backup directly to tape, disk, or cloud storage

3.3 RMAN Architecture

RMAN consists of the following key components:

Component Role
RMAN Client Command-line interface; sends commands to server
Target Database The database being backed up or recovered
Recovery Catalog Optional repository storing RMAN metadata (separate
DB)
Media Management Layer (MML) Interface for tape backup (e.g., Veritas NetBackup)
Flash Recovery Area (FRA) Disk location for backup files, archived logs, flashback
logs
Control File Stores RMAN repository info when no catalog is used

3.4 RMAN Essential Commands

Connecting to RMAN
$ rman TARGET / -- Connect to local database
$ rman TARGET sys/password@ORCL -- Connect to remote database
$ rman TARGET / CATALOG rman/rman@RCAT -- Connect with Recovery Catalog
Performing Backups
-- Full database backup
RMAN> BACKUP DATABASE;

-- Full database backup with archived logs

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

-- Incremental backup (Level 0 = full baseline)

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

-- Incremental backup (Level 1 = changed blocks)

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

-- Backup specific tablespace

RMAN> BACKUP TABLESPACE users, system;

-- Backup datafile
RMAN> BACKUP DATAFILE '/u01/app/oracle/oradata/ORCL/[Link]';

Restoring and Recovering

-- Restore and recover entire database
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

-- Restore specific tablespace

RMAN> SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;
RMAN> SQL 'ALTER TABLESPACE users ONLINE';

Maintenance Commands
-- List all backups
RMAN> LIST BACKUP;
RMAN> LIST BACKUP SUMMARY;

-- Validate backup integrity

RMAN> VALIDATE DATABASE;
RMAN> VALIDATE BACKUPSET <backup_set_key>;
 -- Cross-check backups (verify physical existence)
RMAN> CROSSCHECK BACKUP;

-- Delete obsolete backups

RMAN> DELETE OBSOLETE;
RMAN> DELETE EXPIRED BACKUP;

3.5 RMAN Retention Policy

Retention policies define how long backups are kept:
-- Retain backups for 7 days
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

-- Keep 3 full backup copies

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

3.6 Flash Recovery Area (FRA)

The Flash Recovery Area (also called Fast Recovery Area) is a disk location that Oracle
uses to store and manage backup-related files. It simplifies backup management by
providing a single unified storage location.
-- Configure Flash Recovery Area
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u01/FRA' SCOPE=BOTH;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 50G SCOPE=BOTH;

-- Check FRA usage

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

4. Oracle Data Guard

4.1 What is Data Guard?
Oracle Data Guard is a high availability, data protection, and disaster recovery solution for
Oracle databases. It creates and maintains one or more standby databases as copies of
the primary database. If the primary database becomes unavailable due to a planned or
unplanned outage, Data Guard can switch any standby database to the primary role,
minimizing downtime and data loss.

4.2 Data Guard Architecture

A Data Guard configuration consists of:
 • Primary Database: The production database that receives all application updates
• Standby Database(s): One or more copies of the primary database maintained
through redo log shipping
• Redo Log Shipping: The process of transmitting redo data from primary to standby
• Log Apply Services: Services that apply received redo data to the standby database
• Data Guard Broker: Optional management framework for automating Data Guard
operations

A simplified Data Guard architecture:

Component Location Role

Primary DB Primary Site (e.g., Data Center Production; handles all read-write
A) operations
Physical Standby Standby Site (e.g., Data Center Exact block-for-block copy; fast
B) switchover
Logical Standby Standby Site SQL-applied copy; supports read-
write queries
Snapshot Standby Standby Site / Dev Converted for testing; receives
but defers redo
DG Broker Either Site Automates switchover/failover
operations
Observer Third Site Monitors and enables fast-start
failover

4.3 Types of Standby Databases

A. Physical Standby Database
A physical standby is an exact, block-for-block copy of the primary database. It is
maintained by applying archived redo logs or real-time redo using Redo Apply (Media
Recovery). Physical standby is the most common and recommended type. It can be
opened read-only for reporting (Active Data Guard option).

B. Logical Standby Database

A logical standby contains the same logical information as the primary but may be stored
differently. It uses SQL Apply to apply changes. It supports read-write access and can have
additional indexes or materialized views for reporting performance.
C. Snapshot Standby Database
A snapshot standby receives redo data but doesn't apply it. It can be opened read-write for
testing. When testing is complete, it can be converted back to a physical standby and the
deferred redo logs are applied. Useful for development and QA testing.

4.4 Data Guard Protection Modes

Protection Mode Redo Shipping Data Loss Risk Performance

Impact
Maximum Protection SYNC – no data loss Zero data loss Highest – primary
allowed stops if standby
unavailable
Maximum Availability SYNC – falls back to Zero (normally) Moderate – best
async balance
Maximum ASYNC – default Possible (seconds) Minimal –
Performance mode production first

4.5 Redo Transport Services

Data Guard uses two methods to ship redo data to standby databases:
• SYNC (Synchronous): Primary waits for acknowledgment before committing.
Ensures zero data loss. Used with Maximum Protection and Maximum Availability
modes.
• ASYNC (Asynchronous): Primary does not wait for standby acknowledgment. Better
performance but potential data loss. Used with Maximum Performance mode.

4.6 Switchover vs Failover

Operation Description Primary Status Data Loss

Switchover Planned role reversal; Gracefully transitions None – fully
orderly transition to standby role controlled
Failover Unplanned; primary is Primary is offline or Possible
unavailable/failed failed (depends on
protection
mode)

-- DGMGRL (Data Guard Manager CLI) commands

DGMGRL> CONNECT sys/password@primary_db
 DGMGRL> SHOW CONFIGURATION;

-- Switchover to standby
DGMGRL> SWITCHOVER TO standby_db;

-- Failover to standby (emergency)

DGMGRL> FAILOVER TO standby_db;

4.7 Setting Up Data Guard (High-Level Steps)

Setting up Oracle Data Guard involves the following major steps:
1. Enable ARCHIVELOG mode on primary database
2. Enable Forced Logging on primary: ALTER DATABASE FORCE LOGGING;
3. Create a password file on primary and copy to standby server
4. Configure primary [Link] parameters (LOG_ARCHIVE_DEST_2, etc.)
5. Create standby using RMAN DUPLICATE command
6. Configure standby [Link] parameters
7. Start Redo Apply on standby: ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE DISCONNECT;
8. Verify configuration using DGMGRL or V$DATAGUARD_STATUS

4.8 Monitoring Data Guard

-- Check Data Guard status
SQL> SELECT DB_UNIQUE_NAME, DATABASE_ROLE, SWITCHOVER_STATUS FROM
V$DATABASE;

-- Check redo transport lag

SQL> SELECT * FROM V$DATAGUARD_STATS;

-- Check archive log gaps

SQL> SELECT * FROM V$ARCHIVE_GAP;

-- Check managed recovery status

SQL> SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY;

5. Summary Comparison

Feature Backup RMAN Data Guard

 Primary Purpose Data protection Backup/restore tool High availability & DR
copies
Scope File-level copies Manages all backup Real-time standby DB
ops
Data Loss Risk Depends on backup Depends on schedule Near-zero to zero
frequency
Recovery Time Hours (manual Faster (automated) Minutes (switchover)
restore)
Downtime Required Cold backup: yes Hot backup: no Failover: minimal
Best Use Case Long-term archival Production backup Continuous
mgmt availability
Oracle Integration Manual or scripted Native Oracle tool Native Oracle feature

6. Conclusion
Oracle Database provides a comprehensive suite of tools and features to protect data and
ensure continuous availability. A well-designed data protection strategy combines multiple
layers:

• Regular RMAN backups (incremental daily, full weekly) with proper retention policies
protect against hardware failures and data corruption
• Operating in ARCHIVELOG mode enables point-in-time recovery and minimizes
data loss
• Oracle Data Guard provides real-time replication to a standby database, enabling
rapid recovery from site-wide disasters
• RMAN and Data Guard complement each other – RMAN handles backup/recovery
while Data Guard ensures continuous availability

Together, these technologies help organizations meet Recovery Time Objectives (RTO)
and Recovery Point Objectives (RPO) required by business continuity plans. Every
production Oracle Database should implement RMAN-based backups alongside Data
Guard for comprehensive protection.

References
• Oracle Database Backup and Recovery User's Guide, 19c – [Link]
• Oracle Data Guard Concepts and Administration, 19c – [Link]
• Oracle Recovery Manager Reference, 19c – [Link]
• Oracle Database High Availability Overview, 19c – [Link]
• Oracle DBA Handbook, Kevin Loney – Oracle Press
• Oracle Database 19c: Backup and Recovery Workshop (Oracle University)