When using the multitenant architecture, you can perform backup and recovery operations on a whole multitenant container database (CDB), the root, or one or more pluggable databases (PDBs).

The Oracle Recovery Manager (RMAN) commands used to backup and recover CDBs and PDBs are the same as those used for non-CDBs, with minor variations in the syntax. The backup and recovery operations performed on non-CDBs can also be performed on CDBs and PDBs. This includes the following:

• Full and incremental backups

• Complete and point-in-time recovery (PITR)

• Flashback Database

• Reporting operations (such as listing backups and cross-checking backups)

In NOARCHIVELOG mode, the filled redo log groups that become inactive can be reused. This mode protects the database against instance failure, but not against media failure. In ARCHIVELOG mode, filled groups of redo logs are archived. This mode protects the database from both instance and media failure, but may require additional hardware resources.

The primary location for the RMAN repository for a database is its control file. The importance of this metadata for RMAN is one more reason why protecting your control file is a vital part of your backup strategy. In some installations, a second copy of the RMAN repository is stored in a schema called the recovery catalog. The recovery catalog is located in a separate database and can store metadata for multiple target databases.

It is recommended that you use a recovery catalog. Because a recovery catalog stores metadata history for longer than the control file, you can perform a recovery that goes further back in time than the history in the control file. Also, if the target control file and all backups are lost, then the RMAN metadata in the recovery catalog can be used.

Database backups created by Oracle Recovery Manager (RMAN) are stored as image copies or backup sets.

Image copies are exact byte-for-byte copies of files. You can create an image copy by copying a file at the operating system level. Unlike copying files at the operating system level, however, image copies created through RMAN are recorded in the RMAN repository so that RMAN can use these copies during database restore operations and recovery. RMAN can restore files only if they are recorded in the RMAN repository. RMAN can create image copies only on disk.

Backup sets are logical entities produced by the RMAN BACKUP command. This command can produce one or more backup sets on disk or tape devices. Although image copies cannot use all RMAN features, their advantages are that you can apply incremental backups to them (synthetic full backups) and you can use them directly in place without first copying them, for very fast restores.

Each backup set contains one or more physical files called backup pieces. A backup piece stores the backup of one or more database files in a compact RMAN-specific format. One advantage of backup sets is that RMAN uses unused block compression to save space in backing up data files. Only those blocks in the data files that have been used to store data are included in the backup set. Backup sets can also be compressed, encrypted, sent to tape, and use advanced unused-space compression that is not available with datafile copies.

A full backup of a data file includes all used blocks of the data file. A full backup can be either an image copy or backup set.

An incremental backup copies only those blocks in a data file that change between backups. A level 0 incremental backup, which copies all blocks in the data file, is used as a starting point for an incremental backup strategy.

A level 1 incremental backup copies only images of blocks that have changed since the previous level 0 or level 1 incremental backup. Level 1 backups can be cumulative, in which case all blocks changed since the most recent level 0 backup are included, or differential, in which case only blocks changed since the most recent level 0 or level 1 incremental backup are included.

Incremental backups at level 0 can be either backup sets or image copies, but incremental backups at level 1 can only be backup sets.

A typical incremental strategy makes level 1 backups at regular intervals such as once each day.

During recovery, Oracle Recovery Manager (RMAN) will automatically apply both incremental backups and redo logs as required, to recover the database to the exact point in time desired.

If the database is in ARCHIVELOG mode, then you can make inconsistent backups that are recoverable using archived redo log files. Open database backups are inconsistent because the online redo log files contain changes not yet applied to the data files. The online redo log files must be archived and then backed up with the data files to ensure recoverability.

Despite the name, an inconsistent backup is as robust a form of backup as a consistent backup. The advantage of making inconsistent backups is that you can back up your database while the database is open for updates.

Media recovery requires a control file, data files (typically restored from backup), and online and archived redo log files containing changes since the time the data files were backed up. Media recovery is most often used to recover from media failure, such as the loss of a file or disk, or a user error, such as the deletion of the contents of a table.

Media recovery can be a complete recovery or a point-in-time recovery. Complete recovery can apply to individual datafiles, tablespaces, or the entire database. Point-in-time recovery applies to the whole database (and also sometimes to individual tablespaces, with automation help from Oracle Recover Manager (RMAN)).

In a complete recovery, you restore backup data files and apply all changes from the archived and online redo log files to the data files. The database is returned to its state at the time of failure and can be opened with no loss of data.

In a point-in-time recovery, you return a database to its contents at a user-selected time in the past. You restore a backup of data files created before the target time and a complete set of archived redo log files from backup creation through the target time. Recovery applies changes between the backup time and the target time to the data files. All changes after the target time are discarded.

RMAN enables you to perform both a complete and a point-in-time recovery of your database. However, this documentation focuses on complete recovery.

Oracle Database automatically manages this storage, deleting files that are no longer needed. Periodically copying backups to tape frees space in the fast recovery area for other files.

When you issue the RMAN BACKUP command without specifying a backup destination, RMAN automatically backs up to the fast recovery area if it is configured.

Oracle recommends that you configure a fast recovery area to simplify backup management. Except as noted, this documentation assumes the use of a recovery area.

Oracle recommends placing the fast recovery area on a separate storage device from the working set of database files. Otherwise, the storage device becomes a single point of failure for your database.

The amount of storage space to allocate for the fast recovery area depends on the size and activity levels of your database and on your recovery objectives. Your objectives dictate what kinds of backups you use, when you make them, and how long to keep them.

This section contains the following topics:

• About the Backup Retention Policy and the Fast Recovery Area

• About the Fast Recovery Area Size

This section describes the credentials required to perform backup and recovery and how to grant the SYSBACKUP privilege to database users.

• Credentials Required to Perform Backup and Recovery

• Granting the SYSBACKUP Privilege

1. Open a command window.
2. Ensure that the ORACLE_SID environment variable is set to the system identifier (SID) of the database.

   $ ORACLE_SID=prod; export ORACLE_SID
   

3. Do one of the following:

   • To connect as a database user who was granted the SYSBACKUP privilege, enter the following command:

     rman target '"username as sysbackup"'
     

     The single and double quotes are required. Enter the user's password when prompted.

   • To connect with operating system authentication, ensure that you are logged in to the database host as a user who is in the OSBACKUPDBA group (typically the backupdba group on UNIX and Linux systems), and enter the following command:

     rman target /
     

     When you do not explicitly specify SYSDBA or SYSBACKUP, you are connected to the target database with the SYSDBA privilege.

This section explains how to configure settings used for instance recovery, media recovery, and fast recovery. It includes the following topics:

• Configuring the Fast Recovery Area

• Enabling Archiving of Redo Log Files

• Enabling Flashback Database

This section contains the following topics:

• Configuring Backup Device Settings

• Configuring Backup Policy Settings

• Configuring Automatic Backups for the Control File and Server Parameter File

• Enabling Block Change Tracking

This section includes topics about incrementally updated backups and backup tags.

• Incrementally Updated Backups: Rolling Forward Image Copies of Data Files

• Backup Tags

Oracle Recovery Manager (RMAN) enables you to perform the different types of backups that are required by your backup strategy. This section discusses creating a whole database backup.

You can also individually back up data files, control files, and archived redo log files. You can use some advanced RMAN features such as encrypting backups. For more information about these topics, see Oracle Database Backup and Recovery User’s Guide.

This section contains the following topics:

• Performing a Whole Database Backup

• Using the Oracle Suggested Backup Strategy

• About the Oracle Suggested Backup Strategy and Retention

• Scheduling Miscellaneous Backup Tasks

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Use the LIST BACKUP or LIST COPY command to display the specified backups, both backup sets and image copies.

   • For example, to list the backups of a particular datafile:

     LIST BACKUP OF DATAFILE 3;
     LIST COPY OF DATAFILE '/orcl/oradata/trgt/system01.dbf';
     

   • To display backups sorted by the type of database file:

     LIST BACKUP BY FILE;
     
     List of Datafile Backups
     ========================
     File Key     TY LV S Ckp SCN    Ckp Time  #Pieces #Copies Compressed Tag
     ---- ------- -  -- - ---------- --------- ------- ------- ---------- ---
     1    14      B  F  A 723546     28-MAR-12 1       1       NO         TAG20120328T051921
     2    14      B  F  A 723546     28-MAR-12 1       1       NO         TAG20120328T051921
     3    14      B  F  A 723546     28-MAR-12 1       1       NO         TAG20120328T051921
     4    14      B  F  A 723546     28-MAR-12 1       1       NO         TAG20120328T051921
     5    14      B  F  A 723546     28-MAR-12 1       1       NO         TAG20120328T051921
     
     List of Control File Backups
     ===========================
     CF Ckp SCN Ckp Time  BS Key  S #Pieces #Copies Compressed Tag
     ---------- --------- ------- - ------- ------- ---------- ---
     723835     28-MAR-12 16      A 1       1       NO         TAG20120328T052241
     723557     28-MAR-12 15      A 1       1       NO         TAG20120328T051936
     723490     28-MAR-12 13      A 1       1       NO         TAG20120328T051811
     

You can validate your backups in the following ways:

• Select specific backup sets or image copies in Oracle Recovery Manager (RMAN) and validate them. This technique indicates if a backup exists and can be restored. For this form of validation, use the steps described in "Validating Selected Backups."

• Specify database files and let RMAN select backups to use when restoring those files, as it would for an actual restore operation. This technique ensures that your available backups are sufficient to restore the database. For this form of validation, use the steps described in "Validating Backups for Restore Operations."

  Note:

  Validating backups stored on tape can be time-consuming because the entire backup is read from tape.

You can perform both forms of validation using RMAN. You should incorporate both forms of validation into your backup strategy to ensure that your recoverability goals are met by your available backups.

An essential part of a backup and recovery strategy is managing backups after you create them. Backup management includes deleting obsolete backups and performing periodic checks to ensure that backups are available and usable.

A backup recorded in the Oracle Recovery Manager (RMAN) repository has one of the following status values:

• Available, meaning that the backup is still present on disk or tape, as recorded in the repository

• Expired, meaning that the backup no longer exists on disk or tape, but is still listed in the repository

• Unavailable, meaning that the backup is temporarily not available for data recovery operations (because, for example, it is stored on a tape that is stored offsite or on a disk that is currently not mounted)

Backups can also be obsolete. An obsolete backup is, based on the currently configured retention policy, no longer needed to satisfy data recovery goals.

Maintenance tasks that you can perform in RMAN include the following:

• Viewing details about your backups

• Cross-checking your repository, which means checking whether backups listed in the repository exist and are accessible, and marking as expired any backups not accessible at the time of the cross-check

• Deleting the record of expired backups from your RMAN repository

• Deleting obsolete backups from the repository and from the backup media

• Validating backups to ensure that a given backup is available and not corrupted

Some tasks, such as periodic cross-checks of your backups, should be among the regularly scheduled components of your backup strategy.

If you use a fast recovery area for backup storage, then many maintenance activities are reduced or eliminated. The automatic storage space management mechanisms delete backups and other files as needed, thereby satisfying storage space demands for ongoing database operations without compromising the retention policy. However, you must monitor space usage in the fast recovery area to ensure that it is large enough to contain backups and other recovery-related files.

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. To crosscheck all backup sets, use the following command:

   CROSSCHECK BACKUP;
   

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Optionally, cross-check backup sets by using the following command:

   CROSSCHECK BACKUPSET;
   

   Cross-checking backups before you delete expired backups provides RMAN with up-to-date information about which backups are expired.

3. Delete expired backups using the following command:

   DELETE EXPIRED BACKUP;
   

   The expired backup sets and image copies are deleted from the RMAN repository.

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Optionally, cross-check backup sets by using the following command:

   CROSSCHECK BACKUP;
   

   Cross-checking backups before you delete expired backups provides RMAN with up-to-date information about which backups are expired.

3. Display a summary of the available backups.

   LIST BACKUP SUMMARY;
   
   List of Backups
   ===============
   Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
   ------- -- -- - ----------- --------------- ------- ------- ---------- ---
   1 B A A DISK 24-FEB-07 1 1 NO TAG20070427T115348
   3 B A A DISK 24-MAR-07 1 1 NO TAG20070427T115452
   4 B F A DISK 24-APR-07 1 1 NO TAG20070427T115456
   

4. From the output of the LIST command, identify the backup that you want to make available or unavailable. Use the value displayed in the Key column to identify a backup set.
5. Change the status of the identified backup to unavailable by using the CHANGE command.

   The following command marks the backup set 4 unavailable:

   CHANGE BACKUPSET 4 UNAVAILABLE;
   
   changed backup piece available
   backup piece handle=/ade/b/191802369/oracle/work/orcva/RDBMS/backupset/2012_04_05/o1_mf_annnn_TAG20120405T075520_7qvdlrsl_.bkp RECID=23 STAMP=779788520
   Changed 1 objects to AVAILABLE status
   

   To mark the backup set 4 available, use the following command:

   CHANGE BACKUPSET 4 AVAILABLE;
   

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Delete all obsolete backups, including backup sets and image copies, using the following command:

   DELETE OBSOLETE;
   

   RMAN displays the list of obsolete backups and asks for confirmation about deleting the listed backups.

In the context of Data Recovery Advisor, a health check is a diagnostic procedure run by the Health Monitor to assess the state of the database or its components. Health checks are invoked reactively when an error occurs. You can also invoke checks manually.

A failure is a persistent data corruption detected by a health check. Failures are usually detected reactively. A database operation involving corrupted data results in an error, which automatically invokes a health check in the database. The check searches the database for failures related to the error. If failures are diagnosed, then they are recorded in the Automatic Diagnostic Repository (ADR).

You can use Data Recovery Advisor to generate repair advice and repair failures only after failures have been detected by the database and stored in ADR. Data Recovery Advisor can report on and repair failures such as inaccessible files, physical and logical block corruptions, and I/O failures. Every failure has a failure priority: CRITICAL, HIGH, or LOW. Every failure also has a failure status of OPEN or CLOSED.

You can also use Data Recovery Advisor to view repair options. A repair is an action that fixes one or more failures. Examples of repairs include block media recovery, data file media recovery, and Oracle Flashback Database. Typically, Data Recovery Advisor presents both automated and manual repair options. If appropriate, you can choose an automated repair option in order to perform a repair. In this case, Data Recovery Advisor verifies the repair success, and closes the relevant repaired failures.

1. Connect Oracle Recovery Manager (RMAN) to the target database as described in "Connecting to the Target Database Using RMAN."

   In a multitenant environment, connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.

2. List all the failures know to the Data Recovery Advisor by running the following command:

   LIST FAILURE;
   
   List of Database Failures
   =========================
   Failure ID Priority Status Time Detected Summary
   ---------- -------- ------ ------------- --------
   142        HIGH     OPEN   23-APR-07     One or more non-system datafiles are
                                            missing
   101        HIGH     OPEN   23-APR-07     Datafile 1: '/disk1/oradata/prod/
                                            system01.dbf' contains one or more  
                                            corrupt blocks
   

   Wherever possible, RMAN consolidates failures while displaying the result of the LIST FAILURE command. For example, if a data file contains multiple block failures, the LIST FAILURE command consolidates and displays the repair options.

   See Also:

   Oracle Database Backup and Recovery User’s Guide for information about using the LIST FAILURE ... DETAIL command to display failures individually

3. If you suspect that some failures that have not been automatically diagnosed by the database exist, then check for corrupt blocks and missing data files by using the following command:

   VALIDATE DATABASE;
   

   If a problem is detected during the validation, then RMAN triggers the execution of a failure assessment

4. Determine repair options, both automatic and manual, by using the following command:

   ADVISE FAILURE;
   

5. Fix the failures by using the following command:

   REPAIR FAILURE;
   

   Automated repairs are performed by the Data Recovery Advisor. In certain cases, such as when no backups exist for a lost control file, the only repair option possible is the manual option.

For this example, you use Flashback Table on the employees table in the hr schema. Assume that an erroneous update shortly after October 23, 2005 at 15:30:00 has changed the lastname column for all employees to an empty string, and you must return the original lastname values to the table.

This section contains the following topics:

• Enabling Row Movement on a Table

• Performing a Flashback Table Operation

As with Flashback Table, you can use Flashback Drop while the database is open. Also, you can perform the flashback without undoing changes in objects not affected by the Flashback Drop operation. Flashback Table is more convenient than forms of media recovery that require taking the database offline and restoring files from backup.

This section contains the following topics:

• Dropping a Table

• Retrieving a Dropped Table

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Identify the desired SCN, restore point, or point in time to which the flashback database must be performed. This example rewinds the database to a specified point in time.

   See Also:

   Oracle Database Backup and Recovery User’s Guide for information about how to determine the SCN and then flashback the database to this SCN

3. Shut down the database consistently, ensure that it is not opened by any instance, and then mount the database.

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

4. Flash back the database to the desired time.

   In this example, you need to flashback the entire database to the time specified in the TIME clause.

   FLASHBACK DATABASE to TIME "TO_DATE('03/20/12','MM/DD/YY')";
   

5. Open the database read-only and run some queries to verify the database contents.

   The following command opens the database in read-only mode:

   ALTER DATABASE OPEN READ ONLY;
   

6. After confirming that the state of the database is as expected, make the database available for updates by opening it with the RESETLOGS option.

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   ALTER DATABASE OPEN RESETLOGS;
   

1. Connect RMAN to the target database as described in "Connecting to the Target Database Using RMAN."
2. Ensure that the database is mounted, but not open.

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

3. Restore the database using the following command:

   RESTORE DATABASE;
   

   The data files from the RMAN backup are restored to their default locations.

4. Recover the database using the RECOVER command.

   RECOVER DATABASE;
   

5. Open the database using the following command:

   ALTER DATABASE OPEN;