9.1 Overview of Database Backup and RecoveryThe focus in Oracle Database backup and recovery is on the physical backup of database files, which permits you to reconstruct your database. Show
Oracle Recovery Manager (RMAN), a command-line tool, is the method preferred by Oracle for efficiently backing up and recovering your Oracle database. The files protected by the backup and recovery facilities built into RMAN include data files, control files, server parameter files, and archived redo log files. With these files you can reconstruct your database. RMAN is designed to work intimately with the server, providing block-level corruption detection during backup and restore. RMAN optimizes performance and space consumption during backup with file multiplexing and backup set compression, and integrates with leading tape and storage media products. The backup mechanisms work at the physical level to protect against file damage, such as the accidental deletion of a data file or the failure of a disk drive. RMAN can also be used to perform point-in-time recovery to recover from logical failures when other techniques such as flashback cannot be used. Logical backups, such as exporting database objects such as tables or tablespaces, are a useful supplement to physical backups, but cannot protect your whole database. An effective backup strategy must be based on physical backups. The Oracle Database flashback features provide a range of physical and logical data recovery tools as efficient, easy-to-use alternatives to physical and logical backups. The flashback features enable you to reverse the effects of unwanted database changes without restoring data files from backup. This section provides links to the following flashback features that are documented in Oracle Database Backup and Recovery User’s Guide:
The first two features operate at the logical level, whereas the last feature operates at the physical level. None of the preceding features requires advance preparation such as creating logical exports to allow for retrieval of your lost data, but Oracle Flashback Database requires the advance preparation of enabling the feature. You can use all of the features while your database is available. Oracle Database Backup and Recovery User’s Guide discusses the flashback features of Oracle Database at greater length. Note: Oracle Flashback Database does not recover missing data files.
9.1.1 Overview of Backing Up and Recovering CDBs and PDBsWhen 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:
About Connecting to CDBs and PDBs You can connect to the root in one of the following ways:
To connect as
9.1.1.1 Backup and Complete Recovery of CDBsTo perform backup and complete recovery operations on a whole multitenant container database (CDB), you connect as The connection must be established as a common user with the After you connect to the root, the same commands that are used to perform operations on non-CDBs are used to perform backup and complete recovery on the entire CDB. 9.1.1.2 Backup and Complete Recovery of PDBsYou can perform backup and complete recovery operations on a single pluggable database (PDB) or on multiple PDBs. Backups of PDBs When relocating a PDB or cloning a non-CDB as a PDB, you may want to retain the use of preplugin backups. For preplugin backups to be usable in the destination CDB, metadata about the preplugin backups must be exported to the RMAN repository of the destination CDB. The technique for making the backups usable depends on the type of operation:
Preplugin backups are usable only on the destination CDB into which you plug in the source non-CDB or PDB. Note:
Syntax for Backup Commands Although the Oracle Recovery Manager (RMAN) commands are the same, the syntax used to perform operations on multiple PDBs contains some modifications. To perform backup and complete recovery operations on a single PDB, you can connect as
9.1.1.3 Point-in-Time Recovery in a Multitenant EnvironmentYou can perform point-in-time recovery of the whole multitenant container database (CDB) or a particular pluggable database (PDB). Point-in-Time Recovery of a CDB To perform point-in-time recovery of a CDB, you must meet the following prerequisites:
When performing the recovery operation, use the same commands that you use for non-CDBs. Point-in-Time Recovery of a PDB When a PDB is closed in an open or closed CDB, you can recover the PDB to a past point in time. The technique depends on the undo mode of the CDB. The following table describes the differences. Table 9-1 Differences in Point-in-Time Recovery Techniques
9.1.1.4 Flashback Database in a Multitenant EnvironmentYou can perform a Flashback Database operation for a whole multitenant container database (CDB) or for a particular pluggable (PDB). RMAN uses an auxiliary destination to store temporary files created during point-in-time recovery. By default, the fast recovery area is used as the auxiliary
destination. You can explicitly specify an auxiliary destination using the Flashback of CDBs To perform Flashback Database for a CDB, you must meet the following prerequisites:
Specify the target point in time for the flashback operation using a CDB restore point, time expression, or SCN. A CDB restore point is accessible to every PDB within the CDB. However, the restore point does not reflect the PDB sub-incarnation of any of its PDBs. Flashback of PDBs When a PDB is closed and the CDB is open, you can perform a flashback database operation for this PDB using the
Table 9-2 Differences in Flashback Techniques
9.2 Database Backup and Recovery Concepts9.2.1 ARCHIVELOG and NOARCHIVELOG ModeOne of the important decisions you need to make as a DBA is to determine if the database must be run in In 9.2.2 RMAN RepositoryOracle Recovery Manager (RMAN) maintains a record of database files and backups for each database on which it performs operations. This metadata is called the RMAN repository. When you request recovery of a database, RMAN uses the repository metadata to choose the most efficient backups needed for this restore and recovery. 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. 9.2.3 Image Copies and Backup SetsDatabase 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 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. 9.2.4 Full Backups and Incremental BackupsA 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. 9.2.5 Consistent and Inconsistent BackupsA backup is either consistent or inconsistent. To make a consistent backup, your database must have been shut down cleanly and remain closed for the duration of the backup. All committed changes are written to the data files during the shut down process, so the data files are in a transaction-consistent state. When you restore your data files from a consistent backup, you can open the database immediately. If the database is in 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. 9.2.6 Media RecoveryIf you restore the archived redo log files and data files, then you must perform media recovery before you can open the database. Any database transactions in the archived redo log files not reflected in the data files are applied to the data files, bringing them to a transaction-consistent state before the database is opened. 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. See Also:
9.2.7 Fast Recovery AreaTo simplify the management of backup and recovery files, you can create a fast recovery area for your database. The fast recovery area is an Oracle-managed directory, file system, or Oracle Automatic Storage Management disk group that provides a centralized storage location for backup and recovery files. Oracle creates archived logs and flashback logs in the fast recovery area. Oracle Recovery Manager (RMAN) can store its backup sets and image copies in the fast recovery area, and it uses it when restoring files during media recovery. The fast recovery area also acts as a disk cache for tape. 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 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. See Also:
9.3 Configuring Your Database for Basic Backup and RecoveryThis section explains how to set up your database to take advantage of Oracle suggested backup strategies. To take maximum advantage of Oracle Database features that automatically manage backup and recovery files and operations, configure your database as follows:
You must also set several policies governing which files are backed up, what format is used to store backups on disk, and when files become eligible for deletion. In a multitenant environment, you must connect to the root and configure backup and recovery settings for the whole multitenant container database (CDB). These settings are applicable to the root and to all pluggable databases (PDBs) in the CDB. This section contains the following topics:
9.3.1 Planning Space Usage and Location for the Fast Recovery AreaOracle 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:
9.3.1.1 About the Backup Retention Policy and the Fast Recovery AreaSpace management in the fast recovery area is governed by a backup retention policy. A retention policy determines when files are obsolete, meaning that they are no longer needed to meet your data recovery objectives. Retention policies can be based on redundancy of backups or on a recovery window (period of time). When using a policy based on redundancy, you specify how many full or level 0 backups of each data file and control file that Oracle Recovery Manager (RMAN) keeps. If the number of full or level 0 backups for a specific data file or control file exceeds the redundancy setting, then RMAN considers the extra backups as obsolete. When using a recovery policy based on a period of time (or window), you specify a time interval in days. Files are obsolete only when they are no longer needed for complete recovery or point-in-time recovery to a system change number (SCN) within the window. Therefore, a recovery retention policy based on a window is recommended. The default retention policy is a redundancy of 1. Even after files in the fast recovery area are obsolete, they are typically not deleted until space is needed for new files. If space permits, files recently moved to tape remain on disk to avoid restoring them from tape for a recovery. The automatic deletion of obsolete files and files moved to tape from the fast recovery area makes it a convenient archiving destination. Other destinations require manual deletion of logs. See Also:
9.3.1.2 About the Fast Recovery Area SizeAs a general rule, the larger the fast recovery area, the more useful it is. Oracle Database Backup and Recovery User’s Guide explains how to size the fast recovery area. Ideally, the fast recovery area should be large enough for copies of the data files, control files, online redo log files, and archived redo log files needed to recover the database, and also the copies of these backup files that are kept based on the retention policy. If your backup strategy includes incremental backups, then add enough space to the fast recovery area for these files. If you can move some backups to tape, then you can reduce the size of the fast recovery area. Note that retrieving files from tape causes longer database restore operations and recovery times. 9.3.2 Configuring Users to Perform Backup and Recovery9.3.2.1 Credentials Required to Perform Backup and RecoveryTo perform backup and recovery tasks with Oracle Recovery Manager (RMAN), you must connect to the target database as a user with the The following types of users have the
For the Oracle suggested backup strategy described in this documentation, you use operation system authentication. Consult your operating system documentation for instructions for creating host users and adding them to the OSBACKUPDBA group. Note: In previous releases, you needed the Oracle recommends that you do not use the See Also:
9.3.2.2 Granting the SYSBACKUP PrivilegeAs a database administrator, you can grant the To grant the SYSBACKUP privilege to an existing user:
9.3.3 Connecting to the Target Database Using RMANTo perform backup or recovery operations or to configure backup and recovery settings, you must start the Oracle Recovery Manager (RMAN) client and connect to the target database. A target
database is the Oracle database that must be backed up or restored using RMAN. Connections to the target database require the To connect to the target database:
9.3.4 Configuring Recovery Settings9.3.4.1 Configuring the Fast Recovery AreaIf you did not specify a location for the fast recovery area during installation, the installation process automatically configures a fast recovery area in the Oracle base directory. Oracle recommends, however, that the fast recovery area be located on a separate storage device from the database files. You can modify the following initialization parameters to relocate the fast recovery area and to adjust its size:
The You can set these parameters without having to shut down and restart the database. In an Oracle Real Application Clusters (Oracle RAC) database, all instances must have the same values for these initialization parameters. The location must be on a cluster file system, Oracle ASM, or a shared directory. To configure the fast recovery area: Assume that you want to want to place the fast recovery area in the directory
9.3.4.2 Enabling Archiving of Redo Log FilesTo back up the database while it is open, or to be able to perform complete or point-in-time media recovery, you must enable the archiving of redo log files. To do so, you place the
database in SELECT LOG_MODE FROM V$DATABASE; If you do not specify a destination to which the database should write archived log files, the database writes them to the fast recovery area. You can specify a different destination, or you can specify that multiple copies of each archived log file be written, each to a different destination. Redundant copies help ensure that archived log files are always available in the event of a failure at one of the destinations. The following procedure assumes that you want to place archived log files in the directory WARNING: You must ensure that there is sufficient disk space at all times for archived log file destinations. If the database encounters a disk full error as it attempts to archive a log file, a fatal error occurs and the database stops responding. You can check the alert log for a disk full message. To enable archiving of redo log files:
9.3.4.3 Enabling Flashback DatabaseTo revert the entire database to a prior point in time, you can either revert the entire database to a prior point in time by restoring a backup and doing point-in-time recovery, or you can enable Flashback Database. When you enable Flashback Database, the database generates flashback logs in the fast recovery area. These logs are used to flash back the database to a specified time. During usual operation, the database occasionally logs images of data blocks to the flashback logs. The database automatically creates, deletes, and resizes flashback logs. Use the following command to check if Flashback Database is enabled for your target database: SELECT FLASHBACK_ON FROM V$DATABASE; To enable Flashback Database:
9.3.5 Configuring Backup Settings9.3.5.1 Configuring Backup Device SettingsFor disk-based backups, you can configure the default format for backups, the location on disk where backups are stored, whether backup tasks run in parallel, and whether backups are compressed. For tape backups, you can configure settings such as the number of tape drives and whether backups are compressed. On most platforms, you must integrate a media manager with the Oracle database to use sequential media for storage. You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager. Oracle Secure Backup provides the same services for Oracle Recovery Manager (RMAN) as other third-party SBT interfaces. This section assumes that you make only disk backups. Use the RMAN To configure backup device settings:
See Also:
9.3.5.2 Configuring Backup Policy SettingsYou can set the backup policies that govern control file and server parameter file backups, tablespaces to exclude from an entire database backup, and the backup retention policy. To configure the backup policy settings:
9.3.5.3 Configuring Automatic Backups for the Control File and Server Parameter FileYou can configure Oracle Recovery Manager (RMAN) to automatically backup the control file and server parameter file with every backup. This is referred to as an autobackup. The server parameter file and control file are critical to the database and RMAN. Creating automatic backups of the control file enables RMAN to recover the database even if the current control file and server parameter file are lost. The control file and server parameter file are relatively small compared to typical data files and, therefore, backing them up frequently results in relatively little storage overhead. If the database runs in Note: For multitenant container databases (CDBs), the control file and server parameter file autobackups are performed by default. To configure automatic backups for the control file and server parameter file:
RMAN uses a default format to assign names for these backups. 9.3.5.4 Enabling Block Change TrackingBlock changing tracking improves the performance of incremental backups by recording changed blocks in the block change tracking file. During an incremental backup, instead of scanning all data blocks to identify which blocks have changed, RMAN uses this file to identify the changed blocks that need to be backed up. You can enable block change tracking when the database is either open or mounted. This section assumes that you intend to create the block change tracking file as an Oracle Managed File in the database area, which is where the database maintains active database files such as data files, control files, and online redo log files. To determine if block change tracking is enabled, check the
To enable block change tracking:
See Also:
9.4 Backing Up Your Database9.4.1 Additional Backup Concepts9.4.1.1 Incrementally Updated Backups: Rolling Forward Image Copies of Data FilesOracle Recovery Manager (RMAN) enables you to apply level 1 incremental backups to an older image copy of your data files. You can roll forward the copy to the point in time of the most recent level 1 incremental backup. All blocks changed since the image copy was created are overwritten with their new contents as of the time of the last level 1 incremental backup. The effect is to roll forward the file in time, so that its contents are equivalent, for the purposes of database recovery, to an image copy of the data file made at the time of the last incremental level 1 backup. Incorporating incrementally updated backups into your backup strategy shortens expected recovery times. Media recovery to the present time or to a point in time in the recent past can begin at the time of the last level 1 backup applied, rather than at the time of the last full database backup. 9.4.1.2 Backup TagsA tag is a text string that identifies a backup, either uniquely or as part of a group of backups. All Oracle Recovery Manager (RMAN) backups, including incremental backups, are labeled with a tag. For example, if you performed a full database backup every Saturday,
then you could use the tag You can use tags to refer to specific backups in RMAN commands. For example, you could issue a command to move the latest Because you can use tags to refer to different groups of backups, you can create different routines in your backup strategy that do not interfere with each other. When you schedule a backup job and give the job a name, the job name is the tag. 9.4.2 Performing and Scheduling Backups Using RMAN9.4.2.1 Performing a Whole Database BackupWhole backups of a database include the complete contents of all data files of the database, plus the control file, archived redo log files, and server parameter file. With these files, you can perform a complete recovery. While whole database backups can be an important element in your overall backup strategy, they are also a required step in some situations, such as when you enable or disable To perform a whole database backup when the database is open:
This backup is created on the default device that you configured for storing backups. If you did not configure a default device, then the backup is created in the fast recovery area. RMAN uses a default format while naming the backup sets that comprise the backup. To perform a whole database backup when the database is closed:
See Also:
9.4.2.2 Using the Oracle Suggested Backup Strategy9.4.2.2.1 About the Oracle Suggested Backup Strategy The Oracle suggested backup strategy is based on incrementally updated backups. This strategy starts with an image copy of each data file and then rolls forward the image copies each day by applying an incremental level 1 backup. For each data file, the strategy calls for backups as follows:
In this Oracle suggested backup strategy, the data file image copies and the level 1 incremental backups share the same tag. You can safely implement other backup strategies without interfering with the Oracle suggested backup strategy. Oracle suggested backup strategies also use tape backups in addition to disk backups, but these are beyond the scope of this section. 9.4.2.2.2 Task 1 - Preparing to Use the Oracle Suggested Backup Strategy To use the Oracle suggested backup strategy, ensure that:
9.4.2.2.3 Task 2 - Creating the Backup Script—UNIX and Linux This backup script implements the Oracle suggested backup strategy, enabling quick recovery to any time in the preceding 24 hours. This script can be used to back up a non-CDB or a whole multitenant container database (CDB). To create the backup script for UNIX and Linux:
9.4.2.2.4 Task 3 - Testing the Backup Script It is recommended that you run the script manually, to check for errors, before scheduling it. Your manual run of the script will start day one of the strategy, creating an incremental level 0 image copy of all datafiles. To test the backup script:
The script starts Oracle Recovery Manager (RMAN), which starts the backup. The output from RMAN includes warning messages similar to the following: ... no copy of datafile 1 found to recover no copy of datafile 2 found to recover ... no parent backup or copy of datafile 1 found no parent backup or copy of datafile 2 found ... These messages are normal for the first run of the script. Note: For the second run of the script, the output includes only these warning messages: no copy of datafile 1 found to recover no copy of datafile 2 found to recover ... Again, these messages are normal. For the third and subsequent script runs, no further warning messages are output. 9.4.2.2.5 Task 4 - Scheduling the Daily Backup—UNIX and Linux The following procedure uses the To schedule the Oracle-suggested disk backup strategy:
See Also: Your operating system documentation for a description of the crontab command and crontab files 9.4.2.3 About the Oracle Suggested Backup Strategy and RetentionWhen using the Oracle suggested backup strategy, the retention is dictated by the recovery and not by the configured retention. In order to get retention beyond 24 hours, you must change the RECOVER statement to something like: RECOVER COPY OF DATABASE WITH TAG 'ORA_OEM_LEVEL_0' UNTIL TIME "SYSDATE-4"; The configured retention is not honored for either the retention or obsolete settings. So when using the Oracle suggested backup strategy, Oracle recommends that the default setting remains unchanged to avoid confusion: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default 9.4.2.4 Scheduling Miscellaneous Backup TasksIn addition to implementing the Oracle suggested backup strategy described in
"Using the Oracle Suggested Backup Strategy," you can use customized backup strategies that back up certain parts of your database. Customized strategies include backing up selected tablespaces, datafiles, and archived redo logs. Create a script that contains the commands required to implement your customized backup task and then schedule this backup task using the 9.4.3 Displaying Backups Stored in the RMAN RepositoryUse the To display all backups:
To display selected backups:
9.4.4 Validating Backups and Testing Your Backup StrategyAs part of your backup strategy, you should periodically check whether your backups are intact and can be used to meet your recoverability objectives. You can validate your backups in the following ways: You can validate your backups in the following ways:
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. 9.4.4.1 Validating Selected BackupsValidating specific backups checks whether these backups exist and can be restored. It does not test whether the set of available backups meet your recoverability goals. For example, image copies of data files for several tablespaces from your database may exist, each of which can be validated. If there are some tablespaces for which no valid backups exist, however, then you cannot restore and recover the database. To validate selected backups:
When you suspect that one or more backup pieces in a backup set are missing or have been damaged, use the 9.4.4.2 Validating Backups for Restore OperationsYou can test whether a sufficient set of backups exists that can be used to restore the specified database files. After you specify which tablespaces to restore and, possibly, a time as of which to restore them, Oracle Recovery Manager (RMAN) selects a set of backups that contain the needed data. RMAN reads the selected backups in their entirety to confirm that they are not corrupt, but does not produce output files. Validating the restoration of files tests whether the file can be restored given the available backups, but it does not test whether all backups of the specified object are valid. To verify whether specified database files can be restored:
See Also:
9.5 Displaying Backup ReportsBackup reports contain summary and detailed information about past backup jobs run by Oracle Recovery Manager (RMAN). The view To display backup reports: Use the following query to display the backup job history. SELECT SESSION_KEY,INPUT_TYPE,STATUS,START_TIME,END_TIME,ELAPSED_SECONDS/3600 hrs FROM V$RMAN_BACKUP_JOB_DETAILS; SESSION_KEY INPUT_TYPE STATUS START_TIM END_TIME HRS ----------- ------------- ----------------------- --------- --------- ---------- 8 DB FULL FAILED 27-MAR-12 27-MAR-12 1.64666666 50 DB FULL COMPLETED 28-MAR-12 28-MAR-12 .243055555 69 DB FULL COMPLETED 30-MAR-12 05-APR-12 147.176388
9.6 Managing BackupsAs part of a backup strategy, you must manage database backups. A related task is managing the record of those backups in the Oracle Recovery Manager (RMAN) repository. RMAN simplifies these tasks. In a multitenant environment, you can manage backups for the whole multitenant container database (CDB) or for one or more pluggable databases (PDBs). The steps in this section are applicable to CDBs and PDBs, with minor modifications. To manage backups for the whole CDB, connect to the root and use the steps described in
this section. To manage backups of a single PDB, connect to that PDB and use the steps described in this section. To manage backups of multiple PDBs using one command, connect to the root and use the This section contains the following topics:
9.6.1 About Backup ManagementAn 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:
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:
Note: If a backup no longer exists, then immediately delete the backup record from the RMAN repository. Without an accurate record of available backups, you may discover that you no longer have complete backups of your database when you must perform a recovery. 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. 9.6.2 Cross-Checking BackupsCross-checking a backup synchronizes the physical reality of backups with their logical records in the Oracle Recovery Manager (RMAN) repository. For example, if a backup on disk was deleted with an operating system command, then a cross-check detects this condition. After the cross-check, the RMAN repository correctly reflects the state of the backups. Backups to disk are listed as available if they are still on disk in the location listed in the RMAN repository, and if they have no corruption in the file header. Backups on tape are listed as available if they are still on tape. The file headers on tape are not checked for corruption. Backups that are missing or corrupt are listed as expired. To cross-check individual files:
To cross-check all files:
Note: Cross-checking all backups in the RMAN repository may take a long time, especially for tape backups. A cross-check of all files, unlike cross-checking individual files, is handled as a scheduled job. 9.6.3 Deleting Expired BackupsDeleting expired
backups removes from the Oracle Recovery Manager (RMAN) repository those backups that are listed as To delete expired backups:
9.6.4 Marking Backups as Available or UnavailableIf one or more specific backups are unavailable because of a temporary condition, such as a disk drive that is temporarily offline or a tape stored offsite, then you can mark those backups as unavailable. Oracle Recovery Manager (RMAN) does not use unavailable backups to restore or recover data. Note: Backups stored in the fast recovery area cannot be marked as unavailable. RMAN keeps the record of unavailable backups in the RMAN repository and does not delete backups listed as unavailable when you delete expired backups. If the unavailable backups become accessible again, then you can mark them as available. To mark backups as available or unavailable:
9.6.5 Deleting Obsolete BackupsThis section explains how to delete obsolete backups, which are those no longer needed by the configured retention policy. If you use a fast recovery area as your only disk-based backup destination, then you never have to delete obsolete backups from disk. The fast recovery area keeps files as specified by the retention policy, and deletes them only when space is needed. To delete obsolete backups:
9.6.6 Monitoring Fast Recovery Area Space UsageIt is important to monitor space usage in the fast recovery area to ensure that it is large enough to contain backups and other recovery-related files.
Oracle Database provides two views to monitor fast recovery area space usage, Use the SELECT * FROM V$RECOVERY_FILE_DEST; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES -------------- ----------- ---------- ----------------- --------------- /mydisk/rcva 5368709120 109240320 256000 28 The SELECT * FROM V$RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- --------------- CONTROLFILE 0 0 0 ONLINELOG 2 0 22 ARCHIVELOG 4.05 2.01 31 BACKUPPIECE 3.94 3.86 8 IMAGECOPY 15.64 10.43 66 FLASHBACKLOG .08 0 1 9.7 Performing Oracle Advised RecoveryThe Oracle advised recovery feature uses Data Recovery Advisor, which is an Oracle Database feature that automatically diagnoses data failures, determines and presents appropriate repair options, and performs repairs if requested by the user. By providing a centralized tool for automated data repair, Data Recovery Advisor improves the manageability and reliability of an Oracle database. Note: Data Recovery Advisor can only be used to diagnose and repair failures in multitenant container databases (CDBs). It is not supported for pluggable databases (PDBs). RMAN provides a command-line interface to the Data Recovery Advisor. You can use following RMAN commands to diagnose and repair data failures for the Oracle Database, including for Oracle RAC databases:
This section contains the following topics:
9.7.1 About Data Recovery AdvisorIn 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. 9.7.2 Using Data Recovery AdvisorThe recovery process begins when you either suspect or discover a failure. You can discover failures in many ways, including error messages, alerts, trace files, and health checks. You can then use Data Recovery Advisor to gain information and advice about failures and repair them automatically. This section describes a scenario in which you use Data Recovery Advisor to repair a corrupted block. To use the Oracle advised recovery strategy to automatically repair failures:
9.8 Performing User-Directed RecoveryUser-Directed Recovery enables you to use flashback features and perform restore operations and recovery procedures. For example, you can do the following:
You can determine which parts of the database must be restored and recovered, including detecting situations such as corrupted database files before they affect database operations. This section contains a few typical recovery examples so that you can become familiar with the performing whole database or object-level recovery using Oracle Recovery Manager (RMAN). Use the This section contains the following topics:
9.8.1 Rewinding a Table Using Oracle Flashback TableOracle Flashback Table enables you to rewind one or more tables back to their contents at a previous time without affecting other database objects. Thus, you can recover from logical data corruptions such as table rows added or deleted accidentally. Unlike point-in-time recovery, the database remains available during the flashback operation. For this example, you use Flashback Table on the This section contains the following topics:
9.8.1.1 Enabling Row Movement on a TableBefore you can use Flashback Table, you must ensure that row movement is enabled on the table to be flashed back, or returned to a previous state. Row movement indicates that rowids will change after the flashback occurs. This restriction exists because if rowids before the flashback were stored by an application, then there is no guarantee that the rowids will correspond to the same rows after the flashback. To enable row movement on a table:
9.8.1.2 Performing a Flashback Table OperationIn this example, you rewind the To perform the Flashback Table operation:
9.8.2 Recovering a Dropped Table Using Oracle Flashback DropOracle Flashback Drop enables you to reverse the effects of dropping (deleting) a table, returning the dropped table to the database along with dependent objects such as indexes and triggers. This feature stores dropped objects in a recycle bin, from which they can be retrieved until the recycle bin is purged, either explicitly or because space is needed. 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. Note: For a table to be recoverable using Flashback Drop, it must reside in a locally managed tablespace. Also, you cannot recover tables in the This section contains the following topics:
9.8.2.1 Dropping a TableFor the purpose of learning about Flashback Drop, you will create a new table named
To create and then drop a table:
9.8.2.2 Retrieving a Dropped TableThe following procedure retrieves To perform the Flashback Drop operation:
9.8.3 Rewinding a Database Using Oracle Flashback Database
Unlike the other flashback features, Oracle Flashback Database operates at a physical level. When you use Flashback Database, your current data files revert to their contents at a previous time. The result is similar to database point-in-time recovery, but Flashback Database can be much faster because it does not require you to restore and recover data files. Also, Flashback Database requires limited application of redo data as compared to media recovery. Flashback Database uses flashback logs to access previous versions of data blocks and also uses some data in the archived redo log files. To have the option of using Flashback Database to repair your database, you must have configured the database to generate flashback logs as explained in "Configuring Recovery Settings." Note: You can use the Oracle Recovery Manager (RMAN) To perform a Flashback Database operation:
9.8.4 Restoring and Recovering the DatabaseThis section demonstrates how to restore and recover the entire database using Oracle Recovery Manager (RMAN). This example assumes that you are restoring and recovering your database after the loss of one or more data files, but you still have a usable server parameter file and control file. You can also use RMAN to restore a lost server parameter file or control file. To restore and recover the entire database:
See Also:
9.9 Performing Backup and Recovery: Oracle By Example SeriesOracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE series steps you through the tasks in this section, and includes annotated screenshots. The series consists of the following tutorials:
What should a backup and recovery plan include?10 Things You Must Include in Your Disaster Recovery Plan Checklist. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) ... . Hardware and Software Inventory. ... . Identify Personnel Roles. ... . List of Disaster Recovery Sites. ... . Remote Storage of Physical Documents and Storage Media. ... . Disaster Response Procedures.. What are 4 types of backups?The most common backup types are a full backup, incremental backup and differential backup. Other backup types include synthetic full backups and mirroring. In the debate over cloud vs. local backup, there are some types of backup that are better in certain locations.
What are five major elements of a typical disaster recovery plan?Typical elements in a disaster recovery plan include the following:. Create a disaster recovery team. ... . Identify and assess disaster risks. ... . Determine critical applications, documents, and resources. ... . Determine critical applications, documents, and resources. ... . Specify backup and off-site storage procedures.. What are the components of a good backup plan?Elements of a Good Backup Strategy
A good backup strategy has three parts: backups and archiving, disaster recovery, and business continuity. Periodic backups and archiving should be your first line of defense. When data is created or changed, your organization should back it up on a regular basis.
|