Oracle Backup and Recovery in OCI

Choose the tool by the recovery requirement

Begin with the incident or business requirement, then choose the method. The following comparison separates activities that are sometimes grouped under the broad label of backup.

These are complementary capabilities. For example, a team may use a logical copy to compare a damaged application's records with an earlier exported state, while preserving its normal physical recovery plan. Choosing a selective repair still requires understanding dependencies and the effects of restoring older business data. A customer record, its orders, and its payment history cannot safely be treated as unrelated simply because they occupy different tables.

What changed from legacy export/import?

Data Pump predates Oracle Database 12c. The important change for a modern lesson is to teach its server-based architecture and current migration options instead of treating the original exp and imp programs as the normal workflow. Oracle's 26ai documentation lists original Export as desupported for all uses. Original Import remains relevant when reading dump files produced by original Export. See Oracle's utility and compatibility guidance.

The formats are different: impdp does not read original Export dump files, and original imp does not read Data Pump dump files. Data Pump's legacy mode translates supported older parameter names into corresponding Data Pump behavior. It does not turn one dump format into the other. Therefore, identifying the utility that produced an inherited dump is a practical first step before planning its import.

The 12c era added important consolidation and migration capabilities, including full transportable operations associated with multitenant environments. Transportable methods combine metadata movement with movement of data files, subject to their documented requirements. They are not simply another name for a conventional table export. Oracle's 12c new-features documentation provides the historical context; a current migration must follow the source and target releases' supported procedures.

A short history of the cloud context

Database release names and cloud platform milestones describe different timelines. It is misleading to say that OCI began with the introduction of 12c. Four milestones are enough to explain why modern export/import teaching includes cloud services:

• The 12c era: multitenant databases and full transportable data movement expanded the options for consolidation and migration.
• October 2016: Oracle announced the availability of Bare Metal Cloud Services, a milestone in the development of its infrastructure platform.
• March 2018: Autonomous Data Warehouse became available in Oracle Cloud, adding a managed approach to operating database workloads.
• October 2025: Oracle announced Oracle AI Database 26ai. Oracle describes the transition from 23ai through the October 2025 release update.

These milestones are documented in Oracle's Bare Metal Cloud announcement, 18c technical paper, and 26ai announcement. They do not imply that every service, region, or deployment changed on the same date. For operational decisions, identify the actual database release and service configuration rather than relying on the marketing name alone.

Plan a Data Pump workflow in OCI

A logical transfer can be understood as five connected stages: select the source, export the intended content, protect the dump files, import into the target, and validate the result. Each stage should have an owner and an observable completion condition. A file appearing in a bucket is only one intermediate event.

1. Identify the source and scope. Record the database service, intended pluggable database (PDB), schemas or tables, and the business purpose of the copy.
2. Plan a consistent transfer. Decide how application activity and related data will be handled while the export runs. A migration plan must address changes made after the selected export point.
3. Choose supported storage. Determine whether the procedure uses server-side files, Object Storage, or a supported transfer between them.
4. Prepare the target. Resolve object ownership, storage requirements, privileges, and existing objects before importing.
5. Validate and retain evidence. Review logs, reconcile important data, test application behavior, and retain the approved migration record.

For example, suppose a team exports a sales schema on Friday and imports it on Monday. If the source application continued accepting orders over the weekend, the imported result needs an explicit reconciliation or cutover strategy. Merely repeating that the export completed successfully does not resolve the missing business interval. The transfer schedule and application write policy belong in the migration plan.

Connect to the intended PDB

In a multitenant environment, the service used for the connection matters. For application data, identify the intended PDB rather than assuming that a connection to the CDB root selects every application. A full Data Pump export is not a physical backup of every CDB file, nor does it automatically collect every PDB. Oracle's Data Pump overview explains the utility's architecture and multitenant considerations.

A useful transfer record names the source service and target service explicitly. It also records who approved the scope and how the result will be tested. This makes an accidental import into the wrong environment easier to detect before application users encounter it.

Understand files, directory objects, and buckets

For filesystem-based Data Pump jobs, DIRECTORY names a database directory object referring to server-side storage. It does not identify an arbitrary folder on the laptop running the client. Access to the directory object and access to the underlying location must support the chosen operation.

Object Storage uses a different access model. The documented cloud export options include DUMPFILE URIs and CREDENTIAL for authorized access. A bucket name is not a substitute for a database directory object. Dump-file storage and log-file storage must both be considered. Consult the 26ai export parameter reference for the chosen configuration.

OCI is a platform, not one identical database environment. A database administered on compute infrastructure, a managed database service, and an Autonomous service may expose different controls and supported procedures. Confirm service-specific instructions before adapting a filesystem example to a cloud environment. Oracle provides a separate Autonomous Data Pump cloud export procedure.

Check compatibility and protect the exported data

Record source and target versions, required object types, character-set considerations, and time-zone data compatibility. The VERSION parameter helps control compatibility of exported metadata; it does not make every newer feature available on an older target. Treat any unsupported feature as a migration design issue, not an error to ignore until the final import.

Exported application data remains sensitive outside the database. Restrict access to dump files and buckets, use approved encryption and credential handling, and define how long the transfer artifacts should remain available. Avoid embedding passwords in examples or shared command histories. Where compression or encryption features are selected, check the applicable service capabilities and licensing requirements.

Validation should answer business questions as well as technical ones. Can a user retrieve a known customer? Do important totals reconcile? Are scheduled processes and application permissions appropriate for the target? Record expected differences, such as deliberately excluded test data, so that reviewers can distinguish a planned omission from an incomplete migration.

Keep physical recovery independent of logical exports

Imagine two failures. In the first, an analyst needs a copy of a small set of historical records. A suitable export might help, subject to its scope and consistency. In the second, storage containing database files fails. The recovery team needs the physical recovery resources and procedure for that database. The existence of the same export does not establish that those resources are available.

For administrator-managed databases, RMAN restore and recovery depend on the relevant backup and redo chain. A managed cloud service supplies its own supported recovery controls. In either environment, define the acceptable data-loss interval and restoration time, then test the procedure against those requirements. Keep evidence of which environment was restored, which recovery point was reached, and which application checks passed.

Detect corruption and choose an appropriate response

Corruption handling involves detection, diagnosis, and a supported recovery or salvage method. These should not be collapsed into a promise that one package repairs every damaged block. RMAN validation can identify problems, and V$DATABASE_BLOCK_CORRUPTION records corruption detected by supported database components. The appropriate response depends on the affected object and available recovery resources.

RMAN block media recovery can recover eligible corrupt blocks when its prerequisites are satisfied. By contrast, DBMS_REPAIR includes procedures that mark corrupt blocks and permit affected blocks to be skipped for salvage. Skipping inaccessible data does not reconstruct its contents. Oracle documents these distinctions in block media recovery and the DBMS_REPAIR reference.

Use LogMiner and reporting to understand the evidence

LogMiner exposes information from redo through SQL. It can help investigate recorded changes, with interpretation depending on the selected redo, dictionary information, privileges, and supported data types. V$LOGMNR_CONTENTS is central to examining the results. LogMiner is not a substitute for a backup, and reconstructed statements should not be applied blindly. Review Oracle's LogMiner guidance before designing an investigation.

RMAN reporting answers another question: what does the recovery repository say about the database's backups? The following illustrative commands inspect recorded information; they do not create backups or prove a restoration has succeeded:

LIST BACKUP SUMMARY;
REPORT NEED BACKUP;

LIST presents backup information, while REPORT NEED BACKUP identifies files needing backup according to the applicable policy. Interpret these results alongside storage availability, validation, and recovery tests. Oracle's RMAN guide explains their use. Later lessons also examine recovery-related dynamic performance views, with attention to privileges and container scope.

Turn the overview into a practical recovery record

Before choosing detailed commands, create a short record for one application. Name its database and PDB, the business owner, the approved transfer or recovery point, and the person responsible for deciding whether the result is usable. This record connects technical work with the decision to resume service. Without it, two teams can complete different procedures successfully while assuming they have solved the same problem.

For a training example, use a sales application with customer, order, and order-line tables. The logical transfer team might compare the number of orders and their totals for a closed accounting period, then test representative customer searches. The physical recovery team would separately demonstrate restoration to its planned recovery point and run the agreed application checks. Both teams should record failures and exceptions, including differences that are intentional.

Keep the acceptance criteria concrete. A statement such as "the database is available" is less useful than "the application connected to the intended recovered PDB, retrieved the agreed sample records, and completed the approved business checks." Likewise, "the export exists" is weaker evidence than a completed test import whose logs and reconciliation results have been reviewed.

Finally, identify what changes would invalidate the plan. A new PDB, a changed storage location, a different cloud service, or a new application dependency may require the procedure to be reviewed. Assign that review to normal change management instead of waiting for the next incident. The purpose of this module is to help you ask those questions and interpret the tools' evidence before relying on a recovery claim.