Lesson 6	Restoring files to an alternative location
Objective	Restore files to a different location after media failure.

Restore Oracle 26ai Datafiles to a New Location with RMAN

When a file system, volume, or ASM disk group fails, Oracle AI Database 26ai can restore data files to healthy storage instead of their recorded locations. Recovery Manager, or RMAN, coordinates the restore, updates the control file with the replacement names, and applies the redo required to make the restored files consistent.

The central sequence is SET NEWNAME, RESTORE, SWITCH, and RECOVER. SET NEWNAME defines where restored data files will be written. RESTORE retrieves them from backup. SWITCH changes the control-file records so the restored copies become the current data files. RECOVER applies the available redo.

An alternate-location restore does not change the database recovery point objective. An ARCHIVELOG database can perform complete recovery when every required redo record is available. A NOARCHIVELOG database remains limited to a consistent whole-database backup, optionally advanced with consistent incremental backups. A new path cannot compensate for missing redo.

Determine the Failure Scope Before Restoring

Preserve diagnostic evidence and verify that the original storage is truly unavailable before overwriting or switching file names. A mount-point problem, ASM disk-group dismount, permissions change, or incorrect parameter can resemble a lost data file. Repairing access to an intact file is usually safer and faster than restoring it unnecessarily.

Collect the information that controls the recovery plan:

the CDB name, DBID, database incarnation, and current LOG_MODE;
the affected data-file numbers, tablespaces, and PDB containers;
whether the SPFILE and every control-file member remain available;
the backup pieces, image copies, and archived redo required for the selected recovery point;
the current RMAN channel and media-manager configuration;
the destination type, such as a file system, ASM disk group, or Oracle Managed Files location;
available capacity, permissions, and expected restore throughput; and
the required TDE keystore and backup-storage credentials.

Use RMAN to review the recorded structure and preview the selected backups before the restore:

RMAN> REPORT SCHEMA;
RMAN> LIST BACKUP SUMMARY;
RMAN> RESTORE DATABASE PREVIEW SUMMARY;
RMAN> RESTORE DATABASE VALIDATE;

RESTORE DATABASE PREVIEW reports which backups RMAN expects to use. RESTORE DATABASE VALIDATE reads the selected backups without creating restored data files. Neither command replaces a complete restore and recovery rehearsal in an isolated environment.

How SET NEWNAME and SWITCH Work

SET NEWNAME is valid only inside an RMAN RUN block. It can name one data file, all data files in a tablespace, or the database. The new name can be a file-system path, an ASM disk group, or NEW when RMAN should create an Oracle-managed file in the location specified by DB_CREATE_FILE_DEST.

When one template names multiple files, include a supported substitution variable that prevents collisions. %b retains the original base name and is readable, but it is safe only when every base name is unique in the new directory. %f includes the absolute data-file number, while %U creates a system-generated unique name.

After RMAN restores a file under its new name, SWITCH DATAFILE ALL updates the control file for all data files that received new names in that RUN block. It does not move bytes by itself. If the restore fails before the switch, the control file continues to identify the old current files. If the switch succeeds, subsequent recovery and database access use the new locations.

Choose the Destination and Naming Strategy

The destination syntax should match the storage technology. A file-system destination needs an absolute path and a collision-safe name. An ASM destination can be specified as a disk-group name so ASM generates the remainder of the file name. An OMF destination uses DB_CREATE_FILE_DEST together with TO NEW. Do not paste an ASM alias, OMF name, or file-system path from another database without checking its ownership and naming rules.

Destination	Typical SET NEWNAME form	Important check
File system	`SET NEWNAME FOR DATABASE TO '/u02/oradata/PRODCDB/%U';`	Create the directory, confirm Oracle permissions, and prevent name collisions.
ASM disk group	`SET NEWNAME FOR DATAFILE 7 TO '+DATA2';`	Confirm that the disk group is mounted, writable, and has adequate usable capacity.
Oracle Managed Files	`SET NEWNAME FOR DATABASE TO NEW;`	Verify that `DB_CREATE_FILE_DEST` identifies the intended healthy destination.
Mixed layout	Use database or tablespace defaults, then override selected files by number.	Review every effective new name before the switch.

More specific SET NEWNAME commands override broader defaults. A run block can set a database-wide template, another template for a tablespace, and an explicit destination for one data file. This is useful when high-use tablespaces belong on separate storage, but it also makes the runbook easier to misread. Print or review the intended mapping and verify free space before starting a long restore.

Distinguish Recovery from a Planned File Move

This lesson addresses unavailable or damaged storage. If the source data file is healthy and the objective is a planned storage migration, a restore may not be necessary. Oracle supports ALTER DATABASE MOVE DATAFILE for eligible online data-file moves. That operation copies the current file under database control and updates the control file without restoring an older backup.

The online move has its own restrictions involving file status, encryption, storage type, standby databases, and concurrent operations. Use the Oracle 26ai SQL Language Reference and Administrator's Guide to plan it. Do not substitute an online move for recovery when the source file is unreadable, and do not perform a backup-based restore merely to relocate a healthy file when a supported move meets the requirement.

Restore a Whole CDB to a New File-System Location

A whole-CDB restore requires the database to be mounted but not open. Connect RMAN to the CDB root with a common account that has SYSBACKUP or SYSDBA. Confirm that the new directory exists, has sufficient capacity, and is writable by the Oracle software owner.

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;

RMAN> RUN {
2>   SET NEWNAME FOR DATABASE TO '/u02/oradata/PRODCDB/%U';
3>   RESTORE DATABASE;
4>   SWITCH DATAFILE ALL;
5>   RECOVER DATABASE;
6> }

The example uses %U to avoid duplicate file names. If preserving unique base names is operationally important and every source base name is known to be unique, a template such as /u02/oradata/PRODCDB/%b can be used instead. File naming must follow the organization's storage and monitoring standards.

After RMAN reports complete media recovery, review its output before opening the database:

RMAN> ALTER DATABASE OPEN;

A normal open is appropriate after complete recovery with a current control file. If the operation used a backup control file or performed incomplete recovery, the documented procedure normally requires ALTER DATABASE OPEN RESETLOGS. Do not add RESETLOGS merely because file locations changed.

Restore Datafiles as Oracle Managed Files

Oracle Managed Files can remove the need to invent individual file names. Set DB_CREATE_FILE_DEST to the healthy file-system directory or ASM disk group, and explicitly direct RMAN to create new OMF files:

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+DATA2' SCOPE=SPFILE;

RMAN> STARTUP FORCE MOUNT;
RMAN> RUN {
2>   SET NEWNAME FOR DATABASE TO NEW;
3>   RESTORE DATABASE;
4>   SWITCH DATAFILE ALL;
5>   RECOVER DATABASE;
6> }

The parameter-change scope and restart requirement depend on the existing configuration, so validate them before using the example. A target ASM disk group can also be supplied directly for an individual data file:

RMAN> RUN {
2>   SET NEWNAME FOR DATAFILE 7 TO '+DATA2';
3>   RESTORE DATAFILE 7;
4>   SWITCH DATAFILE 7;
5>   RECOVER DATAFILE 7;
6> }

Do not assume that setting DB_CREATE_FILE_DEST silently redirects every restore. Without SET NEWNAME, RMAN normally restores an existing data file to the location recorded in the control file. Use TO NEW or an explicit ASM destination when relocation is intended.

Restore One Datafile or Tablespace

In an ARCHIVELOG database with a complete recovery chain, restoring only the damaged data file can reduce downtime. If the database remains open, take the affected tablespace or data file offline as required by the recovery procedure. The SYSTEM and active undo tablespaces have stricter availability requirements and can require a mounted whole-database operation.

SQL> SELECT file#, name, status, con_id
  2  FROM   v$datafile
  3  ORDER  BY con_id, file#;

SQL> ALTER TABLESPACE sales OFFLINE IMMEDIATE;

RMAN> RUN {
2>   SET NEWNAME FOR DATAFILE 7
3>     TO '/u02/oradata/PRODCDB/sales01.dbf';
4>   RESTORE DATAFILE 7;
5>   SWITCH DATAFILE 7;
6>   RECOVER DATAFILE 7;
7> }

RMAN> ALTER TABLESPACE sales ONLINE;

Verify that file 7 actually belongs to the intended tablespace and container before running the block. File numbers and paths are environment-specific. The restored file must be recovered through the current SCN before the tablespace can return online.

This targeted procedure is not the normal answer for a NOARCHIVELOG database. Without the archived redo needed to advance the old file, the DBA generally must restore the complete latest usable consistent database backup. If consistent incrementals exist, RMAN can apply them with RECOVER DATABASE NOREDO, but the result still stops at the latest captured consistent checkpoint.

Relocate Datafiles for a PDB

Oracle AI Database 26ai uses the multitenant architecture. RMAN can recover one or more PDBs without restoring every open PDB when the backup and redo prerequisites are satisfied. Connect to the CDB root to coordinate a PDB restore and close the affected PDB:

SQL> ALTER PLUGGABLE DATABASE salespdb CLOSE IMMEDIATE;

Use SET NEWNAME FOR DATAFILE or SET NEWNAME FOR TABLESPACE for the data files that belong to that PDB, then restore and recover the PDB:

RMAN> RUN {
2>   SET NEWNAME FOR DATAFILE 21 TO '+DATA2';
3>   SET NEWNAME FOR DATAFILE 22 TO '+DATA2';
4>   RESTORE PLUGGABLE DATABASE salespdb;
5>   SWITCH DATAFILE ALL;
6>   RECOVER PLUGGABLE DATABASE salespdb;
7> }

RMAN> ALTER PLUGGABLE DATABASE salespdb OPEN;

Confirm the PDB's file numbers through CDB-aware views and include CON_ID in inventory queries. Do not open the PDB read only or restricted merely as a ritual before restoring it. Close it, perform the required restore and recovery, verify its state, and then open it using the mode required by the application.

Control Files Require a Separate Decision

Multiplex control files across independent storage locations. If one member is lost and another current member survives, shut down the instance as required, copy or recreate the missing member from the valid current copy, and correct CONTROL_FILES when the destination changes. A full control-file restore is unnecessary in that case.

If every current control-file member is lost, start the instance in NOMOUNT and restore an autobackup or selected control-file backup. Without a recovery catalog, RMAN may also need the DBID and the autobackup format:

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

A restored backup control file must be followed by recovery and normally OPEN RESETLOGS. If the restored control file still records failed data-file locations, issue the necessary SET NEWNAME commands before restoring, then switch the recovered files to their new locations.

Do Not Treat Online Redo Logs Like Datafiles

Online redo loss is a different recovery scenario. Do not include CLEAR UNARCHIVED LOGFILE in a general data-file relocation procedure. Clearing an unarchived group can destroy redo needed for recovery and can make backups unrecoverable. The response depends on whether a valid multiplexed member survives and whether the lost group is current, active, or inactive.

If a valid member of each group survives but its path changes, update the redo configuration using the documented procedure for the database state and storage type. If required redo is lost, the database may need incomplete recovery followed by OPEN RESETLOGS. Analyze that failure separately instead of assuming that an alternate data-file location also solves redo loss.

Likewise, the Fast Recovery Area is not the normal destination for database data files. DB_RECOVERY_FILE_DEST defines storage for recovery-related files such as backups, archived redo, and flashback logs. DB_CREATE_FILE_DEST supplies the default OMF destination for data files. Keep those responsibilities distinct.

Handle Tempfiles After Recovery

RMAN does not back up tempfiles because they contain temporary data that can be recreated. After whole-CDB restore and recovery, Oracle attempts to re-create missing temporary tablespaces recorded in the control file with their previous creation size, AUTOEXTEND, and MAXSIZE attributes.

A missing OMF tempfile is created in the current DB_CREATE_FILE_DEST. A non-OMF tempfile is normally recreated at its recorded path. If that old path is unavailable, or if a file remains at the path with an invalid header, inspect the alert log and explicitly drop and recreate the tempfile at an approved destination. Confirm temporary tablespace availability before returning application workloads to service.

Alternate Locations During Point-in-Time Recovery

SET NEWNAME can also redirect files during database point-in-time recovery, but relocation and recovery endpoint are separate decisions. A DBPITR requires an ARCHIVELOG database, backups from before the target SCN, and all required redo through the target. The database is then opened with RESETLOGS.

Do not use a hard-coded calendar date copied from a lesson. Choose the target SCN, time, restore point, or log sequence through incident analysis, set the recovery limit before RESTORE and RECOVER, and confirm the expected data loss with the application owner. An alternate destination is especially useful for a trial restore or for examining a recovered copy without overwriting surviving production files.

Validate the New File Locations

After recovery and the appropriate database open, verify that Oracle is using the intended files:

SQL> SELECT con_id, file#, name, status
  2  FROM   v$datafile
  3  ORDER  BY con_id, file#;

SQL> SELECT name
  2  FROM   v$controlfile;

SQL> SELECT group#, member
  2  FROM   v$logfile
  3  ORDER  BY group#, member;

Review the alert log for recovery, file-header, and tempfile errors. Open the expected PDBs, validate application schemas and services, and compare the actual recovery endpoint with the approved objective. Check that no control-file, online-redo, archive, audit, or diagnostic destination still depends on the failed storage.

VALIDATE DATABASE reads the current data files and checks their physical integrity. It does not prove that backup pieces remain restorable. Continue to use RESTORE ... VALIDATE, crosschecks, and isolated restore drills to test the backup recovery chain.

Operational Practices for Predictable Relocation

Configure control-file and SPFILE autobackups, and store the DBID and recovery instructions outside the target database.
Use at least one recoverable backup copy outside the storage failure domain that contains the primary data files.
Protect TDE keystores, password files, SBT configuration, and destination credentials as separate disaster-recovery dependencies.
Use consistent naming templates and validate that substitutions cannot create collisions.
Measure restore throughput and available capacity before setting a recovery time objective.
Test whole-CDB, PDB, tablespace, and individual-data-file scenarios that are part of the approved recovery plan.
Use block media recovery for isolated corrupt blocks only when its ARCHIVELOG and redo prerequisites are satisfied.
Update the recovery runbook whenever storage, file names, PDBs, encryption, or backup destinations change.

Restoring to an alternate location is successful only when RMAN has written the files, the control file identifies the new current locations, the required recovery has completed, and the database and application pass validation. The next lesson continues with the backup validation and recovery preparation needed to make this procedure dependable under pressure.