Lesson 1

Oracle Recovery Manager, commonly called RMAN, is Oracle's recommended framework for protecting the physical files of an Oracle AI Database. It helps a database administrator create backups, restore files, apply recovery data, validate database files and backups, and duplicate databases. RMAN is important because the goal is not merely to produce backup files. The goal is to return a database to an acceptable point in an acceptable amount of time after a failure.

That distinction changes how backup work is evaluated. A completed backup job is evidence that data was written to a destination; it is not proof that the organization can recover from every anticipated failure. Recoverability also depends on archived redo, control-file and server-parameter-file protection, retention settings, encryption material, storage availability, repository metadata, documented procedures, and repeated recovery testing.

This module introduces RMAN in the Oracle AI Database 26ai environment. It replaces release-specific Oracle 8i, 11g, and 12c instructions with a current model that applies to customer-managed databases on premises, in cloud infrastructure, and in hybrid environments. Managed database services can automate or restrict parts of backup administration, so the exact division of responsibility must always be verified for the selected service.

A DBA should begin with business requirements and failure scenarios, not with a favorite RMAN command. Four terms provide a practical foundation:

Requirement	Question it answers
Recovery point objective (RPO)	How much recent data can the business afford to lose, measured as time?
Recovery time objective (RTO)	How long can the service remain unavailable while restoration and recovery occur?
Retention	How far back must usable recovery points remain available?
Failure scope	Which file, media, corruption, user-error, site, and service failures must the design address?

These requirements influence backup frequency, archived redo handling, storage placement, redundancy, network capacity, encryption, and testing. For example, a low RPO may require frequent archived-log protection or a service that provides continuous protection. A demanding RTO may require backups near the target database, incrementally updated copies, a standby architecture, or another design that reduces the amount of data that must be restored and recovered.

Validation and recovery exercises are separate controls. RMAN can examine database files and backup contents, but a restore-and-recovery rehearsal also tests access to storage, credentials, keys, documentation, personnel, capacity, and elapsed time. A technically valid backup can still fail an operational RTO if the surrounding process is incomplete or too slow.

RMAN is an Oracle client that coordinates work performed by database server sessions. Because RMAN understands Oracle file structures and records its own operations, it can manage physical protection more effectively than a collection of uncoordinated operating-system copy commands.

Operation	Meaning
Back up	Create an RMAN-managed backup set or image copy of the files or recovery-related content selected by the command.
Restore	Retrieve files from backup sets or copies and place them at their original or alternate locations.
Recover	Apply redo or incremental changes so restored files reach the required consistent point.
Validate	Check selected database files or backups without claiming that the operation is a complete disaster-recovery test.
Duplicate	Create an auxiliary database through a supported active-database or backup-based workflow.

RMAN provides physical protection. Oracle Data Pump serves a different purpose: it exports and imports logical data and metadata for supported objects. Data Pump is valuable for migrations, schema movement, selective object re-creation, and development or test refreshes, but its dump files do not substitute for RMAN backups of data files, control files, the SPFILE, and archived redo. A mature data-protection strategy may use both technologies.

Only two components are required for the basic RMAN environment:

1. The target database is the Oracle database on which RMAN performs backup or recovery operations. Its control file stores metadata about RMAN configurations, backups, copies, archived redo logs, and related operations.
2. The RMAN client is the executable that reads RMAN commands, establishes database connections, directs server sessions, and records activity. It is installed with Oracle Database and can connect to a target through Oracle Net.

The client coordinates the operation, but the target database server sessions perform the principal backup and recovery work. This server-integrated model also means that a dump or backup destination must be accessible in the way required by the database host, media manager, or supported service.

Additional components are selected when the architecture requires them:

• Fast recovery area (FRA): an Oracle-managed disk location for recovery-related files. It can contain archived redo logs, flashback logs, control-file and online-redo copies, and RMAN backups.
• Recovery catalog: a separate database schema that stores RMAN metadata for one or more target databases.
• Auxiliary database: an instance used for duplication and selected point-in-time or recovery workflows.
• Physical standby database: a redo-maintained copy that can participate in an RMAN and Oracle Data Guard design.
• Media management software or an SBT library: the integration layer used for tape systems and supported cloud or appliance destinations.
• Oracle Enterprise Manager: an optional browser-based interface that can orchestrate RMAN operations.

The older term Backup Manager should not be treated as the name of a current standalone Oracle backup product. Students should understand RMAN at the command and architecture level even when Enterprise Manager or a database service provides a graphical workflow.

A target or auxiliary database connection requires the SYSBACKUP or SYSDBA administrative privilege. Oracle recommends creating a designated account and granting it SYSBACKUP instead of routinely connecting as SYS or using the default SYSBACKUP account. In 26ai, dictionary protection is enabled for the SYSBACKUP administrative privilege as an additional security control.

The following introductory session omits the password so that RMAN can request it rather than exposing it in an operating-system command history:

$ rman

RMAN> CONNECT TARGET 'backup_admin@prod AS SYSBACKUP';
RMAN> SHOW ALL;

The connect identifier and authentication method are examples, not universal values. An approved wallet, external authentication, or another protected credential design may be more appropriate. SHOW ALL displays persistent RMAN configuration; it neither creates nor validates a backup. In a pure unified-auditing environment, RMAN operations are audited by default, but auditing is not a replacement for restricting administrative access.

The RMAN repository is the collection of metadata RMAN uses to understand the target database and the backups associated with it. The target control file always contains repository records. Control-file space is finite, however, and older reusable records can eventually be overwritten according to the database's record-retention behavior.

A recovery catalog is a separate schema in another Oracle database. It receives RMAN metadata from one or more targets, provides centralized and longer-lived history, and supports stored scripts and other catalog capabilities. It is not the location of the backup pieces. Losing a recovery catalog does not erase backup files, although loss of catalog metadata can make them more difficult to identify and manage.

The catalog is optional in many basic environments, but it is not optional in every architecture. Oracle requires a recovery catalog when RMAN is used to back up a physical standby database. A DBA should therefore decide from the topology and operational requirements rather than applying a universal rule.

Catalog Resynchronization

Resynchronization copies new or changed RMAN metadata from the target control file into the recovery catalog. Most RMAN commands perform this work automatically when RMAN is connected to the target and an available catalog. The current RESYNC CATALOG command forces a full resynchronization and remains useful in documented cases, such as after catalog unavailability or before important control-file records can age out.

Oracle AI Database 26ai adds predefined savepoints to the resynchronization transaction. If a long resynchronization encounters an unexpected failure, RMAN can roll back to a recent savepoint instead of necessarily discarding all completed work. This enhancement does not make catalog maintenance an on-premises- only concern, nor does using a cloud platform prove that a customer-managed catalog is synchronized automatically.

RMAN produces two principal physical backup forms. Their differences affect storage, transport, incremental strategies, and recovery preparation.

Form	Characteristics
Backup set	The default RMAN output. It contains one or more backup pieces in an RMAN-specific format and can be written to disk or SBT.
Image copy	A bit-for-bit copy of a selected database file, created on disk and recorded in the RMAN repository.

An image copy is not automatically a copy of the entire database; it represents the files selected by the operation. A level 0 incremental backup can be a backup set or an image copy, while a level 1 incremental backup is a backup set. Later lessons can evaluate compression, multiplexing, incremental updates, channels, and restore behavior without assuming that either form is always superior.

A frequently seen introductory backup command is:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

This command is a starting point, not a complete production strategy. Its result depends on database mode, RMAN configuration, retention, destination, available space, control-file and SPFILE settings, archived-log policy, encryption, and the recoveries the organization must support. Test the corresponding restore and recovery rather than treating successful completion as proof that an RTO can be met.

Disk is RMAN's default device type. If an FRA is configured and no conflicting format is supplied, RMAN can place disk backups there and manage them with other recovery-related files. An FRA is useful, but it is not unlimited storage and it should not be confused with failure-domain separation. Capacity, retention, deletion policies, and the consequences of losing the database host or storage system still require deliberate design.

RMAN communicates with tape and other supported external storage through the System Backup to Tape interface, usually abbreviated SBT. A media manager can be Oracle-supplied or provided by a certified third party; therefore, it is inaccurate to say that tape always requires third-party assistance.

Starting with Oracle AI Database 26ai, native SBT libraries are included with the target database release for Oracle Cloud Infrastructure, Zero Data Loss Recovery Appliance, Amazon S3, and Microsoft Azure Blob Storage. A predefined alias such as oracle.oci identifies the appropriate library during configuration. Native packaging simplifies library deployment, but credentials, destination configuration, network access, compatibility, monitoring, and recovery testing remain necessary.

Oracle Secure Backup can integrate RMAN with tape, but its current lifecycle matters when planning new deployments. Oracle announced desupport of Oracle Secure Backup 19.1 on May 1, 2026, with Premier Support ending September 30, 2027. Current Oracle guidance recommends Zero Data Loss Cloud Protect, using Autonomous Recovery Service in OCI, for applicable cloud-protection requirements. A third-party media manager can remain appropriate when it is certified for the database version and platform.

The important boundary is not simply "on premises versus cloud." It is which party controls the database host, RMAN configuration, backup destination, retention, monitoring, validation, and recovery workflow.

Deployment model	RMAN responsibility
Customer-managed database	The organization directly administers RMAN whether the database runs locally or on hosted infrastructure.
OCI database service	Oracle may automate or integrate parts of protection; the exact customer duties depend on the service and backup option.
Autonomous service	Backup and recovery are exposed through service policies and interfaces rather than assumed host-level RMAN administration.

Always consult the documentation for the exact service before specifying retention, restore targets, customer access to RMAN, or recovery-catalog behavior. A managed backup feature is not automatically equivalent to a customer-managed RMAN catalog, and no single cloud statement accurately describes every Oracle database service.

Oracle AI Database 26ai uses the multitenant architecture. RMAN can protect an entire container database and supports documented pluggable-database backup and recovery workflows. The available operation depends on the connection container, administrative privilege, database state, backup metadata, and intended recovery point.

A PDB-level backup does not by itself represent every dependency needed to protect the CDB. A complete design must consider the root, control files, SPFILE, archived redo, encryption keys or wallets, and service-specific configuration in addition to application PDB data. Later procedural examples should identify their CDB or PDB scope instead of silently assuming the pre-multitenant database model.

Several current details prevent legacy RMAN material from being carried forward unchanged:

• SYSBACKUP has dictionary protection enabled in 26ai. Preserve that protection except during a documented exceptional procedure.
• Native SBT libraries for supported Oracle, OCI, Amazon S3, and Azure destinations are packaged with the target database release.
• Recovery-catalog resynchronization uses predefined savepoints to limit rollback after an unexpected failure during a long transaction.
• Data Recovery Advisor is desupported. Its LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE commands are also desupported, and Oracle identifies no replacement feature.

Validation, monitoring, restore testing, and diagnostic work remain essential, but they should not be labeled as a feature-for-feature replacement for Data Recovery Advisor. Examples in this module must use supported RMAN commands and current recovery procedures.

A durable RMAN strategy is a repeating lifecycle rather than a one-time backup project. The DBA first translates RPO, RTO, retention, and failure scenarios into an architecture. That design identifies the files and containers to protect, the required archived redo, the backup form, storage destinations, encryption controls, repository design, and responsible operators.

Execution then creates backups according to that design, but operational work continues after each job. Administrators monitor job status and duration, investigate errors, track destination capacity, and confirm that backup and archived-log policies behave as intended. Repository maintenance reconciles RMAN records with physical storage, identifies expired or obsolete backups under the applicable definitions, and removes data only through controlled policy.

Recovery rehearsal closes the loop. A representative test should restore the required files into an isolated environment, apply the necessary recovery data, open or otherwise verify the recovered database as appropriate, and record elapsed time. The exercise should also prove that credentials, wallets, encryption keys, network paths, catalog access, and operator instructions are available when the primary environment is impaired.

Finally, review the strategy whenever the database grows, PDBs are added or relocated, application criticality changes, storage or cloud services change, retention obligations are revised, or an Oracle update changes supported behavior. Monitoring explains whether jobs ran; validation examines selected data; recovery testing demonstrates whether the complete procedure can satisfy the business objective. None of those controls should be silently substituted for another.

By the end of this module, you should be able to:

1. Explain RMAN's role in a physical backup-and-recovery strategy.
2. Distinguish backup, restore, recovery, validation, and duplication.
3. Identify required and optional components of an RMAN environment.
4. Connect securely with a designated account that has SYSBACKUP.
5. Inspect and prepare persistent RMAN configuration and backup destinations.
6. Compare backup sets with image copies.
7. Explain the purpose and synchronization of a recovery catalog.
8. Describe RMAN integration with disk, SBT, tape, Recovery Appliance, and cloud storage.
9. Apply RMAN concepts to CDB and PDB protection.
10. Relate validation and recovery exercises to the required RPO and RTO.

The next lesson examines RMAN's features and architecture in more detail. As the module progresses, judge every configuration and command by the recoveries it enables, the risks it leaves unresolved, and the evidence that the recovery process has been tested.