This chapter explains how to use RMAN to return your database to normal operation after the loss of one or more data files. This chapter contains the following topics:
This section explains the purpose of complete restore and recovery of the database and specifies the scope of the chapter.
This section contains the following topics:
This chapter assumes that some or all of your data files are lost or damaged. Typically, this situation is caused by a media failure or accidental deletion. Your goal is to return the database to normal operation by restoring the damaged files from RMAN backups and recovering all database changes.
This chapter explains how to use complete recovery to fix the most common database problems. This chapter makes the following assumptions:
You have lost some or all data files and your goal is to recover all changes, but you have not lost all current control files or an entire online redo log group.
Performing Flashback and Database Point-in-Time Recovery explains how to recover some but not all database changes. Performing User-Managed Recovery: Advanced Scenarios explains how to respond when some but not all current control files or members of an online redo log group are lost. "Performing Recovery with a Backup Control File" explains how to recover the database when all control files are lost.
Your database is using the current server parameter file.
To restore a backup server parameter file, see "Restoring the Server Parameter File".
You have the complete set of archived redo logs and incremental backups needed for recovery of your data file backups. Every data file either has a backup, or a complete set of online and archived redo logs goes back to the creation of a data file with no backup.
RMAN can handle lost data files without user intervention during restore and recovery. When a data file is lost, the possible cases can be classified as follows:
The control file knows about the data file, that is, you backed up the control file after data file creation, but the data file itself is not backed up. If the data file record is in the control file, then RESTORE creates the data file in the original location or in a user-specified location. The RECOVER command can then apply the necessary logs to the data file.
The control file does not have the data file record, that is, you did not back up the control file after data file creation. During recovery, the database detects the missing data file and reports it to RMAN, which creates a data file and continues recovery by applying the remaining logs. If the data file was created in a parent incarnation, then it is created during the restore or recovery phase as appropriate.
You are not restoring and recovering an encrypted tablespace.
If you perform media recovery on an encrypted tablespace, then the Oracle keystore must be open when performing media recovery of this tablespace. See Oracle Database Administrator's Guide to learn about encrypted tablespaces.
Your database runs in a single-instance configuration.
Although RMAN can restore and recover databases in Oracle RAC and Data Guard configurations, these scenarios are beyond the scope of this manual.
You are using the RMAN client rather than Oracle Enterprise Manager.
See Also:
Oracle Real Application Clusters Administration and Deployment Guide for more information about using RMAN with Oracle RAC
Oracle Data Guard Concepts and Administration for more information about using RMAN with Data Guard
With Zero Data Loss Recovery Appliance (Recovery Appliance), the window of potential data loss that exists between successive archived log backups can be substantially reduced. Real-time redo transport enables you to recover target databases up to within a few seconds of a database failure.
Note:
Real-time redo transport can be used only with Recovery Appliance.
When real-time redo transport is configured for a target database, redo data from the current redo log groups is written asynchronously to Recovery Appliance as it is generated. As the redo stream is received, it is stored as a complete RMAN archived redo log. If the target database crashes, the redo data received from the current redo log group, until the time of the crash, is used during restore and recovery operations.
You must perform certain configuration steps to enable real-time redo transport for the target database.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration Guide for the steps to configure real-time redo transport
Although RMAN simplifies most database restore and recovery tasks, you must still plan your database restore and recovery strategy based on which database files have been lost and your recovery goal. This section contains the following topics:
The techniques for determining which files require restore or recovery depend upon the type of file that is lost.
This section contains the following topics:
It is usually obvious when the control file of your database is lost. The database shuts down immediately when any of the multiplexed control files become inaccessible. Also, the database reports an error if you try to start it without a valid control file at each location specified in the CONTROL_FILES initialization parameter.
Loss of some but not all copies of your control file does not require you to restore a control file from backup. If at least one control file remains intact, then you can either copy an intact copy of the control file over the damaged or missing control file, or update the initialization parameter file so that it does not refer to the damaged or missing control file. After the CONTROL_FILES parameter references only present, intact copies of the control file, you can restart your database.
If you restore the control file from backup, then you must perform media recovery of the whole database and then open it with the OPEN RESETLOGS option, even if no data files must be restored. This technique is described in "Performing Recovery with a Backup Control File".
When and how to recover depends on the state of the database and the location of its data files.
This section contains the following topics:
An easy technique for determining which data files are missing is to run a VALIDATE DATABASE command, which attempts to read all specified data files. Example 17-1 validates the database (sample output included).
Example 17-1 VALIDATE DATABASE
RMAN> VALIDATE DATABASE; Starting validate at 20-OCT-13 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=90 device type=DISK could not read file header for datafile 7 error reason 4 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 10/20/2013 13:05:43 RMAN-06056: could not access datafile 7
REPORT SCHEMA command to obtain the tablespace name and file name for data file 7 as follows (sample output included):
RMAN> REPORT SCHEMA; Report of database schema for database with db_unique_name RDBMS List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 450 SYSTEM *** +DATAFILE/tbs_01.f 2 86 SYSAUX *** +DATAFILE/tbs_ax1.f 3 15 UD1 *** +DATAFILE/tbs_undo1.f 4 2 SYSTEM *** +DATAFILE/tbs_02.f 5 2 TBS_1 *** +DATAFILE/tbs_11.f 6 2 TBS_1 *** +DATAFILE/tbs_12.f 7 2 TBS_2 *** +DATAFILE/tbs_21.f List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name ---- -------- -------------------- ----------- -------------------- 1 40 TEMP 32767 +DATAFILE/tbs_tmp1.f
Although VALIDATE DATABASE is a good technique for determining whether files are inaccessible, you may want to use SQL queries to obtain more detailed information.
To determine whether data files require media recovery:
See Also:
Oracle Database Reference for information about the V$ views
In situations requiring the recovery of your server parameter file or control file from autobackup, you must know the DBID. Be sure to record the DBID along with other basic information about your database.
If you do not have a record of the DBID of your database, then you can find it in the following places without opening your database:
The DBID is used in forming the file name for the control file autobackup. Locate this file, and then refer to "Configuring the Control File Autobackup Format" to determine where the DBID appears in the file name.
If you have any text files that preserve the output from an RMAN session, then the DBID is displayed by the RMAN client when it starts up and connects to your database. Typical output follows:
% rman TARGET /
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Jan 16 17:51:30 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
connected to target database: PROD (DBID=36508508)
You can apply RESTORE ... PREVIEW to any RESTORE operation to create a detailed list of every backup to be used in the requested RESTORE operation, and the necessary target SCN for recovery after the RESTORE operation is complete. This command accesses the RMAN repository to query the backup metadata, but does not actually read the backup files to ensure that they can be restored.
As an alternative to RESTORE ... PREVIEW, you can use the RESTORE ... VALIDATE HEADER command. In addition to listing the files needed for restore and recovery, the RESTORE ... VALIDATE HEADER command validates the backup file headers to determine whether the files on disk or in the media management catalog correspond to the metadata in the RMAN repository.
When planning your restore and recovery operation, use RESTORE ... PREVIEW or RESTORE ... VALIDATE HEADER to ensure that all required backups are available or to identify situations in which you may want to direct RMAN to use or avoid specific backups.
To preview backups to be used in a restore operation:
See Also:
Oracle Database Backup and Recovery Reference for details on interpreting RESTORE ... PREVIEW output, which is in the same format as the output of the LIST command
Some media managers provide status information to RMAN about which backups are off-site. An offsite backup is stored in a remote location, such as a secure storage facility, and cannot be restored unless the media manager retrieves the media.
Off-site backups are marked as AVAILABLE in the RMAN repository even though the media must be retrieved from storage before the backup can be restored. If RMAN attempts to restore an off-site backup, then the restore job fails.
To recall offsite backups:
Although the procedures in "Previewing Backups Used in Restore Operations" indicate which backups will be restored, they do not verify that the backups are actually usable. You can run RMAN commands to test the availability of usable backups for any RESTORE operation, or test the contents of a specific backup for use in RESTORE operations. The contents of the backups are actually read and checked for corruption. You have the following validation options:
RESTORE ... VALIDATE tests whether RMAN can restore a specific object from a backup. RMAN chooses which backups to use.
VALIDATE BACKUPSET tests the validity of a backup set that you specify.
See Also:
RMAN restores archived redo log files from backup automatically as needed to perform recovery. You can also restore archived redo logs manually to save the time needed to restore these files later during the RECOVER command, or if you want to store the restored archived redo log files in some new location. RMAN also gives you the flexibility of restoring all archive redo log files, the current ones, or archive redo log files from a specified previous incarnation of the database.
By default, RMAN restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and the highest LOG_ARCHIVE_DEST_n parameters of the target database. These parameters are combined in a platform-specific fashion to form the name of the restored archived log.
This section contains the following topics:
You can override the default location for restored archived redo logs with the SET ARCHIVELOG DESTINATION command. This command manually stages archived logs to different locations while a database restore operation is occurring. During recovery, RMAN knows where to find the newly restored archived logs; it does not require them to be in the location specified in the initialization parameter file.
To restore archived redo logs to a new location:
Start RMAN and connect to a target database.
See Also:
Ensure that the database is mounted or open.
Perform the following operations within a RUN command:
Specify the new location for the restored archived redo logs using SET ARCHIVELOG DESTINATION.
Either explicitly restore the archived redo logs or execute commands that automatically restore the logs.
The following sample RUN command explicitly restores all backup archived logs to a new location:
RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE ARCHIVELOG ALL;
# restore and recover data files as needed
.
.
.
}
The following example sets the archived log destination and then uses RECOVER DATABASE to restore archived logs from this destination automatically:
RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE DATABASE;
RECOVER DATABASE; # restores and recovers logs automatically
}
You can specify restore destinations for archived logs multiple times in one RUN block, to distribute restored logs among several destinations. (You cannot, however specify multiple destinations simultaneously to produce multiple copies of the same log during the restore operation.) You can use this feature to manage disk space used to contain the restored logs.
This example restores 300 archived redo logs from backup, distributing them across the directories /fs1/tmp, /fs2/tmp, and /fs3/tmp:
RUN
{
# Set a new location for logs 1 through 100.
SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
# Set a new location for logs 101 through 200.
SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
# Set a new location for logs 201 through 300.
SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
# restore and recover data files as needed
.
.
.
}
When you issue a RECOVER command, RMAN finds the needed restored archived logs automatically across the destinations to which they were restored, and applies them to the data files.
If backups are encrypted, then RMAN automatically decrypts these backups while restoring their contents. Depending on the encryption mode used to create encrypted backups, you may need to perform additional steps before restoring encrypted backups.
Backups that were encrypted using transparent encryption with an auto-login keystore require no intervention to restore, if the keystore is available. For backups encrypted with a password-based software keystore, in addition to requiring the keystore to be available, the keystore password to be provided. The keystore password is used to open the keystore and must be provided before the restore operation is performed. Use the SET command with the DECRYPTION WALLET OPEN IDENTIFIED BY option to specify the password that must be used to open the keystore.
The following command sets the keystore password for a password-based software keystore to my_wallet_pswd:
SET DECRYPTION WALLET OPEN IDENTIFIED BY my_wallet_pswd;
Backups created using password-mode encryption require the correct password to be entered before they can be restored. Use the SET DECRYPTION command to specify the password used to decrypt the backups. If you are restoring from a group of backups that were created with different passwords, then specify all of the required passwords on the SET DECRYPTION command. RMAN automatically uses the correct password with each backup set. The SET command must be used before executing the RESTORE and RECOVER commands.
The following command sets the password used to decrypt backups to my_pswd:
SET DECRYPTION IDENTIFIED BY my_pswd;
See Also:
Oracle Database Backup and Recovery Reference for additional information about performing restore operations using encrypted backups
This section assumes that you have performed the tasks in "Preparing for Complete Database Recovery". This section describes the basic outline of complete database recovery, which is intended to encompass a wide range of different scenarios.
Scope of This Chapter describes some of the assumptions used in the recovery procedures.
This section contains the following topics:
You use the RESTORE and RECOVER commands to restore and recover the database. During the recovery, RMAN automatically restores backups of any needed archived redo logs. If backups are stored on a media manager, then channels must be configured in advance or a RUN block with ALLOCATE CHANNEL commands must be used to enable access to backups stored there.
If RMAN restores archived redo logs to the fast recovery area during a recovery, then it automatically deletes the restored logs after applying them to the data files. Otherwise, you can use the DELETE ARCHIVELOG command to delete restored archived redo logs from disk when they are no longer needed for recovery. For example, you can enter the following command:
RECOVER DATABASE DELETE ARCHIVELOG;
If you cannot restore data files to their default locations, then you must update the control file to reflect the new locations of the data files. Use the RMAN SET NEWNAME command within a RUN command to specify the new file name. Afterward, use a SWITCH command, which is equivalent to using the SQL statement ALTER DATABASE RENAME FILE, to update the names of the data files in the control file. SWITCH DATAFILE ALL updates the control file to reflect the new names for all data files for which a SET NEWNAME has been issued in a RUN command.
See Also:
Oracle Database Backup and Recovery Reference for SWITCH syntax
This scenario assumes that database trgt has lost most or all of its data files. It also assumes that the database uses a fast recovery area.
After restore and recovery of a whole database, when the database is open, missing temporary tablespaces that were recorded in the control file are re-created with their previous creation size, AUTOEXTEND, and MAXSIZE attributes. Only temporary tablespaces that are missing are re-created. If a temp file exists at the location recorded in the RMAN repository but has an invalid header, then RMAN does not re-create the temp file.
If the temp files were created as Oracle-managed files, then they are re-created in the current DB_CREATE_FILE_DEST location. Otherwise, they are re-created at their previous locations. If RMAN cannot re-create the file due to an I/O error or some other cause, then the error is reported in the alert log and the database open operation continues.
See Also:
Scope of This Chapter for some of the assumptions used in the recovery procedures
To restore and recover the whole database:
In the basic scenario, the database is open, and some but not all of the data files are damaged. You want to restore and recover the damaged tablespace while leaving the database open so that the rest of the database remains available. This scenario assumes that database TRGT has lost tablespace USERS.
See Also:
Scope of This Chapter for some of the assumptions used in the recovery procedures
To restore and recover a tablespace:
If you have image copies of the inaccessible data files in the fast recovery area, then you can use the SWITCH DATAFILE ... TO COPY command to point the control file at the data file copy and then use RECOVER to recover lost changes. You can also use the SWITCH DATABASE TO COPY command to point the control file at a copy of the whole database. Because you do not need to restore backups, this recovery technique takes less time than traditional restore and recovery.
Note:
A SWITCH TABLESPACE ... TO COPY command is also supported for cases when all data files in a tablespace are lost and copies of all data files exist. The same restriction exists for SWITCH DATABASE TO COPY.
This section contains the following topics:
In the basic scenario, the database is open, and some but not all of the data files are damaged. During the course of the day, a data file goes missing due to storage failure. You must repair this file, but cannot afford the time to do a restore and recovery from a backup. You decide to use a recent image copy backup as the new file, thus eliminating restore time. This scenario assumes that database trgt has lost data file 4.
To switch to a data file copy and perform recovery:
In this scenario, the database is shut down, and all of the data files are damaged. You have image copies of all the damaged data files. You decide to use the existing image copies as the new data files, thus eliminating restore time.
To switch to a database copy and perform recovery:
RMAN and Oracle Enterprise Manager Cloud Control (Cloud Control) provide full support for backup and recovery in a multitenant environment. You can back up and recover a whole multitenant container database (CDB), root only, or one or more pluggable databases (PDBs).
The section contains the following topics:
When you recover a whole CDB, you recover the root and all PDBs in a single operation.
To recover a whole CDB:
Follow the instructions in "Performing Complete Recovery of the Whole Database", connecting to the root as a common user with the SYSDBA or SYSBACKUP privilege.
When recovering a whole CDB, you use the non-CDB syntax for the RESTORE and RECOVER commands.
RESTORE DATABASE; RECOVER DATABASE;
See Also:
You might consider recovering only the root if a data corruption or user error occurs that affects only the root. However, Oracle strongly recommends that you recover all PDBs after recovering the root to prevent metadata inconsistencies among the root and the PDBs. In this case, it might be preferable to perform a complete recovery of the whole CDB.
See Also:
Scope of This Chapter for some of the assumptions used in the recovery procedures
To recover the root:
Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
See Also:
Place the CDB in mounted mode.
SHUTDOWN IMMEDIATE STARTUP MOUNT
(Optional) Use the CONFIGURE command to configure the default device type and automatic channels.
Restore and recover the root with the following commands:
RESTORE DATABASE ROOT; RECOVER DATABASE ROOT;
Examine the output to see if media recovery was successful. If so, proceed to the next step.
(Strongly recommended) Recover all PDBs, including the seed PDB.
Issue the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE commands.
The following example recovers the PDBs sales and hr:
RESTORE PLUGGABLE DATABASE 'PDB$SEED', sales, hr; RECOVER PLUGGABLE DATABASE 'PDB$SEED', sales, hr;
Examine the output to see if media recovery was successful. If so, proceed to the next step.
Open the CDB and all PDBs.
ALTER DATABASE OPEN; ALTER PLUGGABLE DATABASE ALL OPEN;
See Also:
"Performing Complete Recovery of the Whole Database" for more options when recovering
You can perform complete recovery of one or more PDBs without affecting operations of other open PDBs.
See Also:
Scope of This Chapter for some of the assumptions used in the recovery procedures
There are two approaches to recovering a PDB with RMAN:
Connect to the root and then use the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE commands. This approach enables you to recover multiple PDBs with a single command.
Connect to the PDB and use the RESTORE DATABASE and RECOVER DATABASE commands. This approach recovers only a single PDB and enables you to use the same commands used for recovering non-CDB databases.
To recover one or more PDBs while connected to the root:
Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
See Also:
Close the PDBs that you want to recover.
ALTER PLUGGABLE DATABASE sales, hr CLOSE;
If any data files are missing, an error occurs and you cannot close a PDB. You must then connect to the PDB to which the missing data file belongs, take the missing data file offline, and then close the PDB.
The following command takes the data file 12 offline:
ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;
Note:
If the data files that store the SYSTEM tablespace of a PDB are missing, then follow the recovery steps described in Performing Complete Recovery of Tablespaces or Data Files in a PDB with RMAN.
(Optional) Use the CONFIGURE command to configure the default device type and automatic channels.
Issue the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE commands.
The following example recovers the seed database PDB$SEED and the PDBs sales and hr:
RESTORE PLUGGABLE DATABASE 'pdb$seed', sales, hr; RECOVER PLUGGABLE DATABASE 'pdb$seed', sales, hr;
If any data files were taken offline in Step 2, make these data files online.
Connect to the PDB to which the missing data file belongs and then make the data file online. The following command makes the data file 12 online:
ALTER DATABASE DATAFILE 12 ONLINE;
Examine the output to see if media recovery was successful. If so, open the PDBs.
ALTER PLUGGABLE DATABASE sales, hr OPEN;
To connect to and recover one PDB:
To recover one or more PDBs with Oracle Enterprise Manager Cloud Control (Cloud Control), complete these steps:
From the Database Home page, select Backup & Recovery from the Availability menu, and then select Perform Recovery.
If you have not logged in to the database previously, the Database Login page is displayed. Log in to the database using Named or New credentials and then click Login.
Cloud Control displays the Perform Recovery page.
From the User Directed Recovery section, select Pluggable Databases from the Recovery Scope drop-down list, and then click Recover.
The Perform Pluggable Database Recovery Wizard appears and displays the Pluggable Databases page.
Select the PDBs that you want to recover by following these steps:
Click Add to display the Available Pluggable Databases page.
From the list of PDBs shown, click in the Select column to designate the PDBs that you want to recover. Optionally, you can click Select All to turn on the Select option for all available PDBs. Click Select None to deselect all PDBs.
Click the Select button to return to the Pluggable Databases page.
Optionally, you can remove PDBs from the table by clicking in the Select column for each PDB that you want to remove and then clicking Remove.
Complete the wizard by navigating through the remainder of the pages to recover the PDBs. For more information about each page of the wizard, click Help.
Because tablespaces in different PDBs can have the same name, to eliminate ambiguity you must connect directly to a PDB to recover one or more of its tablespaces. In contrast, because data file numbers and paths are unique across the CDB, you can connect to either the root or a PDB to recover PDB data files. If you connect to the root, you can recover data files from multiple PDBs with a single command. If you connect to a PDB, you can recover only data files in that PDB.
To recover a non-SYSTEM tablespace in a PDB:
Follow the instructions in "Performing Complete Recovery of a Tablespace", connecting as target to the PDB as a local user with the SYSDBA privilege.
To recover the SYSTEM tablespace in a PDB:
connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
Shut down the CDB and restart it in mount mode.
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
Restore and recover the data files that store the SYSTEM tablespace of the affected PDB.
RESTORE DATAFILE 2,3; RECOVER DATAFILE 2,3;
Open all the PDBs in the CDB.
ALTER PLUGGABLE DATABASE ALL OPEN READ WRITE;
To recover non-SYSTEM data files in a PDB:
To perform complete recovery of tablespaces in a PDB with Oracle Enterprise Manager Cloud Control (Cloud Control), complete these steps:
From the Database Home page, select Backup & Recovery from the Availability menu, and then select Perform Recovery.
If you have not logged in to the database previously, the Database Login page is displayed. Log in to the database using Named or New credentials and then click Login.
Cloud Control displays the Perform Recovery page.
From the User Directed Recovery section, select Tablespaces from the Recovery Scope drop-down list, and then click Recover.
On the Perform Object Level Recovery:Point-in-time page, ensure that Recover to the current time is selected, and click Next.
On the Perform Object Level Recovery: Tablespaces page, select the tablespaces that you want to recover by completing these steps:
Click Add to display the Available Tablespaces page.
The Search Results table shows all available tablespaces and includes the name of the PDB to which each tablespace belongs.
Click Select to designate the tablespaces that you want to recover. Optionally, you can click Select All to turn on the Select option for all available tablespaces. Click Select None to deselect all tablespaces.
Click the Select button to return to the Perform Object Level Recovery: Tablespaces page.
Optionally, you can remove tablespaces from the table by turning on the Select option for each tablespace that you want to remove and then clicking Remove.
Click Next to move to the next step in the wizard.
Complete the wizard by navigating through the remainder of the pages to recover the PDB tablespace. For more information about each page of the wizard, click Help.
If you have image copies of the inaccessible data files in your CDB or PDB, then you can recover lost changes by using the SWITCH command to point the control file at the data file copies. The information in "Performing Complete Recovery After Switching to a Copy" applies to CDBs and PDBs with the following differences.
See Also:
Scope of This Chapter for some of the assumptions used in the recovery procedures
To switch a data file in a CDB, connect to the root and use the same steps that you would use for a non-CDB as described in Switching to a Data File Copy.
To switch a data file in a PDB, use one of the following techniques:
Connect to the root and use the SWITCH ... PLUGGABLE DATABASE or SWITCH DATAFILE command. This enables you to switch the data files for one or more PDBs.
Connect to the PDB and use the SWITCH DATABASE or SWITCH DATAFILE command to switch data files in that PDB.
See Also: