Tablespace, Control File and Archived Log Recovery in Oracle 26ai

A storage failure does not always require restoring an entire database. If the damage is confined to the datafiles of a permanent application tablespace, Recovery Manager can restore those files and apply the changes needed to make them usable again. Other incidents require restoring the control file that describes the database, or retrieving archived redo logs needed by recovery. These operations share the RMAN command-line interface, but their connection scope, database state and completion steps differ.

This lesson develops three separate examples for Oracle AI Database 26ai. The tablespace example targets an open application PDB; control-file recovery and explicit archived-log staging use a connection to the CDB root. They assume a single-instance database and an authorized administrator. The names, services, paths and sequence numbers are examples to replace with verified values. The commands illustrate procedures, rather than report a recovery already performed.

Choose the Recovery Scope Before Restoring Files

RESTORE copies a backup or image copy to a destination. RECOVER applies incremental backups and redo to bring restored datafiles to a consistent recovery target. A successful restore therefore does not establish that a tablespace can be placed online. Complete recovery requires the usable backups and subsequent redo needed to recover all committed changes, including relevant online redo when applicable.

Before selecting commands, establish whether the problem is a missing file, damaged blocks, unavailable storage, an interrupted instance, or unwanted application changes. Correcting a temporary storage-access problem may avoid an unnecessary restore. A logical error may call for a different recovery target. Record the affected container, file numbers, incident time and error messages, and compare them with the backup inventory.

The tablespace procedure assumes ARCHIVELOG mode, an intact current control file, sufficient backup and redo coverage, and accessible storage. Backups encrypted with a keystore require the appropriate keys; password-encrypted backups require their supported decryption procedure. Tape or cloud backup pieces require the corresponding media-management channels and configuration. RAC, standby role changes and recovery of critical system files need their applicable procedures.

Connect to the Correct PDB for Tablespace Recovery

Different PDBs can contain tablespaces with the same name. Use a service that resolves to the intended PDB when restoring its named tablespace. Oracle's direct-PDB connection procedure documents a local or common administrative user with SYSDBA. The following example assumes that backup_admin has that privilege in the PDB reached through APPPDB.

Start the executable at the operating-system prompt:

rman

Then connect at the RMAN prompt and enter the password when requested:

CONNECT TARGET "backup_admin@APPPDB AS SYSDBA";

Confirm the connected container before working with USERS. Do not assume that a successful login reached the intended PDB merely because the CDB name looks familiar. For CDB-level operations, a common user can connect to the root with SYSBACKUP or SYSDBA. Local rman TARGET / uses operating-system authentication and defaults to SYSDBA; verify the Oracle home, instance identifier and operating-system group membership first.

A recovery catalog is optional. If used, connect before issuing commands that establish a no-catalog repository session:

CONNECT CATALOG rman_catalog@RCAT;

The catalog account and service are placeholders. Its schema stores backup metadata; the actual backup pieces remain on disk, tape or other configured storage. Keep target and catalog credentials distinct and avoid embedding passwords in command files or command-line arguments. Oracle's RMAN connection guide explains container scope, authentication and PDB restrictions.

Restore a Permanent Tablespace to Its Original Location

Use a permanent application tablespace such as USERS for this example. Modern temporary tablespaces contain tempfiles, which RMAN does not back up, restore or recover. RMAN records tempfile names and can recreate missing tempfiles during appropriate database recovery operations. Diagnose a temporary-file incident and use the supported tempfile recreation procedure; do not substitute TEMP in the following permanent-datafile recovery example.

Inspect the Backup and Channel Configuration

Review the schema and backup inventory before taking the application tablespace offline:

SHOW ALL;
REPORT SCHEMA;
LIST BACKUP OF TABLESPACE users;
RESTORE TABLESPACE users PREVIEW;

Match the reported file names to the affected permanent tablespace. Check that the selected backups are accessible from the database server through the required device type. A restore preview selects backups using repository metadata; it does not read every backup block. Backup records marked available do not, by themselves, prove that a tape is loaded or that a storage mount is reachable.

When practical, validate the selected backups before the actual restore:

RESTORE TABLESPACE users VALIDATE;

Validation reads the selected backup contents without replacing the target datafiles. It can expose inaccessible pieces or corruption, but it does not prove that the complete redo chain or application recovery goal is satisfied. Account for its I/O cost and time during incident planning. Ensure that any validation channels can access the same storage intended for restoration.

Take the Tablespace Offline, Restore and Recover

The PDB is open, USERS is a permanent non-system application tablespace, and its current control-file metadata remains valid. Coordinate its outage with application owners. In ARCHIVELOG mode, OFFLINE IMMEDIATE takes it offline without a normal checkpoint and requires media recovery before it can be brought online.

For accessible disk backups, the following RUN block provides one explicit channel. If suitable automatic channels are already configured, manual allocation is optional.

RUN {
  SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  RESTORE TABLESPACE users;
  RECOVER TABLESPACE users;
  RELEASE CHANNEL c1;
}

Read the RMAN output and resolve errors before proceeding. RESTORE places the tablespace datafiles at their recorded locations; RECOVER makes them consistent by applying the available changes. RMAN can retrieve archived logs needed by recovery automatically, including while connected to the PDB. A failed recovery leaves an unfinished procedure even if every backup piece was successfully copied.

After complete recovery succeeds, issue the following separately:

SQL 'ALTER TABLESPACE users ONLINE';

The PDB remained open throughout this example, so there is no separate whole-database OPEN command. Recovering this tablespace with the current control file does not require OPEN RESETLOGS. Verify its state and test the affected application objects before restoring normal traffic.

If the original storage location cannot be used, plan relocation explicitly. RMAN SET NEWNAME identifies replacement paths, and SWITCH updates the recorded datafile names before recovery. A different backup-piece directory is not automatically a different datafile destination. Likewise, SYSTEM and active undo are not interchangeable with USERS: use the documented mounted or closed-state procedure for the affected CDB/PDB and file type.

Complete Recovery and Tablespace Point-in-Time Recovery

This procedure recovers a damaged tablespace to the current consistent state. Recovering it to an earlier point is tablespace point-in-time recovery, or TSPITR. That operation uses an auxiliary database and requires checks on the recovery set, object dependencies and the selected target. Adding SET UNTIL to the simple restore example does not create a complete TSPITR procedure. Consult the Oracle 26ai TSPITR guide when the requirement is to undo later changes.

Restore a Lost Control File at the CDB Root

A control file describes the database structure and contains RMAN repository information. Its loss is a CDB-level incident. Finish or exit the PDB session and establish a separate root connection before following this scenario. Check every configured control-file location first. If an intact current multiplexed copy survives, repair the damaged copy or correct the configuration using the supported current-copy procedure, rather than automatically restoring an older backup.

The following example assumes all current copies are lost, the existing SPFILE is usable, the datafiles remain intact, and the recovery catalog contains the correct database and accessible disk backups. The instance must be stopped before STARTUP NOMOUNT. If the SPFILE is also missing, restore or reconstruct its required configuration through the separate parameter-file recovery procedure first.

At the operating-system prompt on the database host, start a root session:

rman TARGET /

At the RMAN prompt, connect to the catalog and restore the control file:

CONNECT CATALOG rman_catalog@RCAT;
STARTUP NOMOUNT;
RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  RESTORE CONTROLFILE;
  RELEASE CHANNEL c1;
}
ALTER DATABASE MOUNT;

Check the database identity in the catalog. If multiple registered databases have the same name, set the verified DBID before selecting the control-file backup. NOMOUNT means the instance has initialized without mounting a control file; MOUNT reads the restored control file but does not open the database.

Without a TO destination, RMAN restores the control file to the configured CONTROL_FILES locations. Confirm those paths and their server-side write permissions. Restoring a control file does not restore missing datafiles. After mounting, inspect the database and restore any damaged datafiles if the original assumption of intact files was incorrect.

For the stated intact-datafile scenario, recover at the RMAN prompt:

RECOVER DATABASE;

Only after recovery completes successfully, open with:

ALTER DATABASE OPEN RESETLOGS;

A control file restored from backup requires database media recovery and OPEN RESETLOGS, even when no datafiles needed restoration. RESETLOGS establishes a new incarnation; it is not an error-clearing shortcut for missing redo. Review recovery messages, inspect PDB states after opening the CDB and open the intended application PDBs as required. Preserve the recovery evidence and take a fresh backup under the recovery policy.

Alternative: Restore a Control-File Autobackup Without a Catalog

For a separate no-catalog session, identify the real database DBID and an accessible control-file autobackup. The following fragment assumes a stopped instance, usable startup parameters and a disk autobackup discoverable with the configured search format. The number is an illustrative placeholder:

SET DBID 123456789;
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;

If the autobackup used a nondefault format or directory, supply its correct format and search settings before the restore. SBT backups need an appropriately allocated media-management channel. After mounting, reconcile usable backups absent from the older repository, restore damaged datafiles where necessary, and perform the same recovery and RESETLOGS completion steps. Use this as an alternative to the catalog restore, rather than running both consecutively.

Do not choose an old control file merely to bypass a restore error. A deliberate historical recovery needs a consistent whole recovery target and corresponding datafile backups and redo. Oracle's backup-control-file recovery guide provides the catalog, autobackup and missing-metadata procedures.

Restore Archived Redo Logs to a Staging Directory

Archived redo logs preserve changes needed to advance restored datafiles. RMAN RECOVER normally restores needed logs from backup automatically. Explicit staging is useful when preparing a recovery location or retrieving a known range ahead of time; RESTORE ARCHIVELOG ALL is not a required preliminary step for every tablespace recovery.

Use a separate RMAN connection to the CDB root for explicit archived-log restoration. The database can be mounted or open, so an otherwise healthy open database does not need to be shut down solely to stage logs. Direct PDB connections cannot explicitly restore archived logs, although PDB media recovery can retrieve the logs it needs.

The directory below is an example on the database server, not the workstation running the RMAN client. Create and authorize it beforehand, and check capacity. Select the actual incarnation, thread and log range from the incident requirements and backup inventory.

RUN {
  SET ARCHIVELOG DESTINATION TO '/u02/rman_stage';
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  RESTORE ARCHIVELOG FROM SEQUENCE 100
    UNTIL SEQUENCE 150 THREAD 1;
  RELEASE CHANNEL c1;
}

This archived-log selection includes sequences 100 through 150 for thread 1 when available in the applicable repository context. It differs from a recovery stop condition: RECOVER UNTIL SEQUENCE stops before applying its specified terminating sequence. Sequence numbers alone do not identify logs across threads and database incarnations. Oracle's archived-log record specifier documents the selection boundaries.

SET ARCHIVELOG DESTINATION directs restored copies for that RUN block; it does not change the database's normal archiving configuration. Staging copies also does not apply their redo. Continue with the required RECOVER command for the damaged files, and examine its result. If the plan actually requires all available archived-log backups, use RESTORE ARCHIVELOG ALL in the intended destination block after checking space and scope. Retain staged logs until their recovery and retention requirements have been satisfied.

Understand the Limited Role of END BACKUP

RMAN backups do not place tablespaces in BEGIN BACKUP mode. END BACKUP is therefore not a normal final step after an RMAN restore. It applies to an interrupted user-managed online backup that left current datafiles in backup mode.

For that separate incident, mount the database and inspect the backup-mode state with SQL*Plus:

SELECT FILE#, STATUS, CHANGE#, TIME, CON_ID
FROM V$BACKUP
WHERE STATUS = 'ACTIVE';

Only when the files are verified current originals and no affected file has been restored from backup, the mounted-database procedure can use:

ALTER DATABASE END BACKUP;

For an open database, use the documented per-tablespace or per-datafile form instead. Ending backup mode does not replace media recovery, reconstruct missing blocks or supply absent redo. If file provenance is uncertain, investigate it and follow the recovery procedure rather than assuming END BACKUP makes the database consistent. Oracle's user-managed backup guide describes these conditions.

Verify the Recovered Service

Preserve RMAN output and review every restore and recovery error. From a SQL session in the recovered PDB, confirm the permanent tablespace status:

SELECT TABLESPACE_NAME, STATUS, CONTENTS
FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = 'USERS';

Check the affected datafiles and application objects, then perform an application-level read and write test appropriate to the service. A tablespace marked ONLINE is useful evidence, but does not establish that every application dependency is healthy. Record the files restored, backup pieces used, recovery outcome and any remaining limitations. Review backup coverage after control-file or structural recovery and retain the material needed for another recovery attempt.

Perform Tablespace Recovery: Exercise