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:

Although the output of a restore preview operation indicates which backups will be restored, the usability of the backups is not actually verified. 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.

Use one of the following validation options:

• RESTORE ... VALIDATE to test whether RMAN can restore a specific object from a backup. RMAN chooses which backups to use.

• VALIDATE BACKUPSET to test the validity of a backup set that you specify.

  See Also:

  Validating Database Files and Backups

• Backups that were encrypted using transparent encryption with an auto-login keystore require no intervention to restore, if the keystore is available. RMAN decrypts these backups while restoring their contents.

• For backups that were encrypted using transparent encryption with a password-based software keystore, the keystore must be available and the keystore password 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 password-based software keystore.

  The following command sets the keystore password for a password-based software keystore (where password is a placeholder for the actual password that you enter):

  SET DECRYPTION WALLET OPEN IDENTIFIED BY password;
  

• 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 (where password is a placeholder for the actual password that you enter):

  SET DECRYPTION IDENTIFIED BY password;
  

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.

To restore and recover the whole database:

To restore and recover a tablespace:

To recover a whole CDB:

1. Complete the preparation steps that are required for your scenario, as described in "Preparing for Complete Database Recovery"

2. Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege and to a recovery catalog (if used), as described in "Connecting as Target to the Root".

3. If the database is not mounted, then mount but do not open the database. Use the following g command:

   STARTUP MOUNT;
   

4. Use the SHOW command to see which channels are preconfigured.

   If the necessary devices and channels are configured, then no action is necessary. Otherwise, you can use the CONFIGURE command to configure automatic channels, or include ALLOCATE CHANNEL commands within a RUN block.

5. Restore and recover the database. Do one of the following:

   • If you are restoring all data files to their original locations, then execute RESTORE DATABASE and RECOVER DATABASE sequentially at the RMAN prompt.

     For example, enter the following commands if automatic channels are configured:

     RESTORE DATABASE;
     RECOVER DATABASE;

     If you manually allocate channels, then you must issue the RESTORE and RECOVER commands together within a RUN block as shown in the following example:

     RUN
     {
       ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
       RESTORE DATABASE;
       RECOVER DATABASE;
     }
     

   • If you are restoring some data files to new locations, then execute RESTORE DATABASE and RECOVER DATABASE sequentially in a RUN command. Use the SET NEWNAME command to rename data files.

     The following example restores the database, specifying new names for three of the data files, and then recovers the database:

     RUN
     {  
       SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
       SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
       SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
       RESTORE DATABASE;
       SWITCH DATAFILE ALL;
       RECOVER DATABASE;
     }
     

6. Examine the output to see if media recovery was successful. If so, open the database.

   For example, enter the following command:

   ALTER DATABASE OPEN;

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.

To recover the root:

1. Complete the preparation steps that are required for your recovery scenario, as described in "Preparing for Complete Database Recovery".

2. Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege, as described in "Connecting as Target to the Root".

3. Place the CDB in mounted mode.

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

4. (Optional) Use the CONFIGURE command to configure the default device type and automatic channels.

5. Restore and recover the root with the following commands:

   RESTORE DATABASE ROOT;
   RECOVER DATABASE ROOT;
   

6. Examine the output to see if media recovery was successful. If so, proceed to the next step.

7. (Strongly recommended) Recover all PDBs, including the CDB seed.

   1. 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;
      

   2. Examine the output to see if media recovery was successful. If so, proceed to the next step.

8. Open the CDB and all PDBs.

   ALTER DATABASE OPEN;
   ALTER PLUGGABLE DATABASE ALL OPEN;

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:

1. Complete the preparation steps that are required for your recovery scenario, as described in "Preparing for Complete Database Recovery".

2. Start RMAN. Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege and to a recovery catalog (if used), as described in "Connecting as Target to the Root".

3. 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 that are described in "Performing Complete Recovery of Tablespaces or Data Files in a PDB with RMAN".

4. (Optional) Use the CONFIGURE command to configure the default device type and automatic channels.

5. Issue the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE commands.

   The following example recovers the CDB seed, PDB$SEED, and the PDBs sales and hr:

   RESTORE PLUGGABLE DATABASE 'pdb$seed', sales, hr;
   RECOVER PLUGGABLE DATABASE 'pdb$seed', sales, hr;
   

6. 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;
   

7. 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 Cloud Control:

1. From the Database Home page, select Backup & Recovery from the Availability menu, and then select Perform Recovery.

2. 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.

3. 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.

4. Select the PDBs that you want to recover by following these steps:

   1. Click Add to display the Available Pluggable Databases page.

   2. 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.

   3. Click the Select button to return to the Pluggable Databases page.

   4. 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.

5. 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.

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 restore and recover a non-SYSTEM tablespace in a PDB:

1. Complete the preparation steps that are required for your recovery scenario, as described in "Preparing for Complete Database Recovery".

2. Start RMAN. Connect to a target database and to a recovery catalog (if used), as described in "Making Database Connections with RMAN."

3. If the database is open, then take the tablespace requiring recovery offline.

   For example, enter the following command to take the USERS tablespace offline:

   ALTER TABLESPACE users OFFLINE IMMEDIATE;
   

4. Use the SHOW command to see which channels are preconfigured.

   If the necessary devices and channels are configured, then no action is necessary. Otherwise, you can use the CONFIGURE command to configure automatic channels, or include ALLOCATE CHANNEL commands within a RUN block.

5. Restore and recover the tablespace. Do one of the following:

   • If you are restoring data files to their original locations, then run the RESTORE TABLESPACE and RECOVER TABLESPACE commands at the RMAN prompt.

     For example, enter the following commands if automatic channels are configured:

     RMAN> RESTORE TABLESPACE users;
     RMAN> RECOVER TABLESPACE users;

   • If you are restoring some data files to new locations, then execute RESTORE TABLESPACE and RECOVER TABLESPACE in a RUN command. Use the SET NEWNAME command to rename data files.

6. Examine the output to see if recovery was successful. If so, bring the recovered tablespace back online.

   For example, enter the following command:

   ALTER TABLESPACE users ONLINE;

To restore and recover the SYSTEM tablespace in a PDB:

1. Complete the preparation steps that are required for your recovery scenario, as described in "Preparing for Complete Database Recovery".

2. Start RMAN. Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege and to a recovery catalog (if used), as described in "Connecting as Target to the Root".

3. Shut down the CDB and restart it in mount mode.

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;

4. Restore and recover the data files that store the SYSTEM tablespace of the affected PDB.

   RESTORE DATAFILE 2,3;
   RECOVER DATAFILE 2,3;

5. 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 Cloud Control:

1. From the Database Home page, select Backup & Recovery from the Availability menu, and then select Perform Recovery.

2. 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.

3. From the User Directed Recovery section, select Tablespaces from the Recovery Scope drop-down list, and then click Recover.

4. On the Perform Object Level Recovery:Point-in-time page, ensure that Recover to the current time is selected, and click Next.

5. On the Perform Object Level Recovery: Tablespaces page, select the tablespaces that you want to recover by completing these steps:

   1. 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.

   2. 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.

   3. Click the Select button to return to the Perform Object Level Recovery: Tablespaces page.

   4. 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.

6. Click Next to move to the next step in the wizard.

7. 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.

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 "Performing Recovery After 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.