| Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) Part Number B14192-02 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) Part Number B14192-02 |
|
|
View PDF |
As explained in "Automatic Disk-Based Backup and Recovery: The Flash Recovery Area", the flash recovery area feature lets you set up a location on disk where the database can create and manage a variety of backup and recovery-related files on your behalf.
Using a flash recovery area simplifies the ongoing administration of your database by automatically naming recovery-related files, retaining them as long as they are needed for restore and recovery activities, and deleting them when they are no longer needed to restore your database and space is needed for some other backup and recovery-related purpose.
Your long-term backup and recovery administration can be greatly simplified by using a flash recovery area. Use of the flash recovery area is strongly recommended. You may want to set up a flash recovery area as one of the first steps in implemeting your backup strategy.
This section outlines the functions of the flash recovery area, identifies the files stored there, explains the rules for how files are managed there, and introduces the most important configuration options.
When setting up a flash recovery area, you must choose a location (a directory or Automatic Storage Management disk group) to hold the files. The flash recovery area cannot be stored on a raw file system.
You must also determine a disk quota for the flash recovery area, the maximum space to be used for all files stored there. You must choose a location large enough to accomodate the required disk quota. When the disk space limit is approached, Oracle can delete nonessential files to make room for new files, subject to the limitations of the retention policy.
The flash recovery area should be on a separate disk from the database area, where active database files such as datafiles, control files, and online redo logs are stored. Keeping the flash recovery area on the same disk as the database area exposes you to loss of both your live database files and backups in the event of a media failure.
|
Note: There are special considerations for choosing a location for the flash recovery area in a RAC environment. The location must be on a cluster file system, ASM or a shared directory configured through NFS. The location and disk quota must be the same on all instances. |
The flash recovery area is closely related to and can be used in conjunction with two other Oracle features: Oracle Managed Files and Automatic Storage Management.
Oracle Managed Files (OMF) is a service that automates naming, location, creation and deletion of database files such as control files, redo log files, datafiles and others, based on a few initialization parameters. It can simplify many aspects of the DBA's work by eliminating the need to devise your own policies for such details.
The flash recovery area is built on top of OMF, so the flash recovery area can be stored anywhere Oracle-managed files can. Oracle Managed Files can be used on top of a traditional file system supported by the host operating system (for example, VxFS or ODM).
The flash recovery area can also be used with Oracle's Automatic Storage Management (ASM). ASM consolidates storage devices into easily managed disk groups and provides benefits such as mirroring and striping without requiring a third-party logical volume manager.
Even if you choose not to set up the flash recovery area in ASM storage, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. You will lose one of the major benefits of the flash recovery area, the automatic deletion of files no longer needed to meet your recoverability goals as space is needed for more recent backups. However, the other automatic features of OMF will still function.
|
Note: When storing backup files, using OMF on top of Automatic Storage Management without using a flash recovery area is supported but discouraged. It is awkward to directly manipulate files under Automatic Storage Management. |
The files in the flash recovery area can be classified as permanent or transient. The only permanent files (assuming these are configured to be stored in the flash recovery area) are multiplexed copies of the current control file and online redo logs. These cannot be deleted without causing the instance to fail. All other files are transient, because Oracle will generally eventually delete these files, at some point after they become obsolete under the retention policy or have been backed up to tape. Transient files include archived redo logs, datafile copies, control file copies, control file autobackups, and backup pieces.
|
Note: The Oracle Flashback Database feature, which provides an convenient alternative to point-in-time recovery, generates flashback logs, which are also considered transient files and must be stored in the flash recovery area. However, unlike other transient files, flashback logs cannot be backed up to other media. They are automatically deleted as space is needed for other files in the flash recovery area. See Chapter 5, "Data Protection with Restore Points and Flashback Database" for more details about Oracle Flashback Database. |
The larger the flash recovery area is, the more useful it becomes. Ideally, the flash recovery area should be large enough to contain all of the following files:
A copy of all datafiles
Incremental backups, as used by your chosen backup strategy
Online redo logs
Archived redo logs not yet backed up to tape
Control files
Control file autobackups (which include copies of the control file and SPFILE)
If providing this much space is impractical, it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet copied to tape. At an absolute minimum, the flash recovery area must be large enough to contain the archived logs that have not been copied to tape.
To determine the disk quota and current disk usage in the flash recovery area, query the view V$RECOVERY_FILE_DEST.
Formulas for estimating a useful flash recovery area size depend upon several factors in your backup and recovery strategy:
Whether your database has a small or large number of data blocks that change frequently;
Whether you store backups only on disk, or on disk and tape;
Whether you use a redundancy-based retention policy, or a recovery window-based retention policy;
Whether you plan to use Flashback Database or guaranteed restore points as alternatives to point-in-time recovery to recover from logical errors.
Specific formulas are provided for many different backup scenarios in Appendix A, "RMAN-Based Disk and Tape Backup Strategies: Scenarios". If you want to use Flashback Database, you must add extra space to the flash recovery area, as discussed in "Sizing the Flash Recovery Area to Include Flashback Logs".
To enable the flash recovery area, you must set the two initialization parameters DB_RECOVERY_FILE_DEST_SIZE (which specifies the disk quota, or maximum space to use for flash recovery area files for this database) and DB_RECOVERY_FILE_DEST (which specifies the location of the flash recovery area).
|
Note: .
|
Initialization parameters can be specified by any of the following means:
Include them initialization parameter file of the target database
Specify them with the SQL statement ALTER SYSTEM SET
Use the Database Configuration Assistant to set them
|
See Also:
|
To find out the current flash recovery area location, query V$RECOVERY_FILE_DEST.
This initialization parameter specifies the maximum storage in bytes of data to be used by the flash recovery area for this database.
|
Note: The value specified does not include certain kinds of disk overhead:
|
This parameter specifies a valid disk location for file creation, which can be a directory on a file system, or Automatic Storage Management disk group.
Mutliple database can have the same value for DB_RECOVERY_FILE_DEST, if one of the following conditions is met:
No two databases for which DB_UNIQUE_NAME is specified have the same value for DB_UNIQUE_NAME.
For those databases where no DB_UNIQUE_NAME is provided, no two databases have the same value for DB_NAME.
For example, you might want to set up primary and standby databases to share the same DB_RECOVERY_FILE_DEST. These two databases will have the same DB_NAME but one of them must have a DB_UNIQUE_NAME different from DB_NAME.
When databases share a single flash recovery area in this fashion, the file system or ASM disk group holding the flash recovery area should be large enough to hold all of the recovery files for all of the databases. Add all the values for DB_RECOVERY_FILE_DEST_SIZE for the different databases, and then allow for any overhead such as mirroring or compression in allocating actual disk space, as described in "Flash Recovery Area Size: DB_RECOVERY_FILE_DEST_SIZE".
Using a flash recovery area has implications for some other initialization parameters:
You cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters to specify redo log archive destinations. You must instead use the newer LOG_ARCHIVE_DEST_n parameters. See Oracle Database Reference for details on the semantics of the LOG_ARCHIVE_DEST_n parameters.
LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST (meaning that archived redo log files will be sent to the flash recovery area) if you create a recovery area and do not set any other local archiving destinations.
Oracle Corporation recommends that DB_RECOVERY_FILE_DEST not be the same as DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n parameters. A warning will appear in the alert log if DB_RECOVERY_FILE_DEST is the same as any of the other parameters listed here.
To create a flash recovery area, you can set the necessary parameters in the initialization parameter file (PFILE) and restart the database. You can also set the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters using ALTER SYSTEM, to add a flash recovery area to an open database, as shown in this example.
|
Note: DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST. |
After you start SQL*Plus and connect to the database, set the size of the flash recovery area. For example, set it to 10 GB:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*';
Set SCOPE to BOTH make the change both in memory and the server parameter file. (Setting SID to "*" has no effect in a single-instance database; in a RAC database it causes the change to take effect across all instances.)
Set the location of the flash recovery area. For example, if the location is the file system directory /disk1/flash_recovery_area, then you can do the following:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/disk1/flash_recovery_area' SCOPE=BOTH SID='*';
If the flash recovery area location is an Automatic Storage Management disk group named disk1, for example, then you can do the following:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
The V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE views can help you determine whether you have allocated enough space for your flash recovery area.
Query the V$RECOVERY_FILE_DEST view to find out the current location, disk quota, space in use, space reclaimable by deleting files, and total number of files in the flash recovery area.
SQL> SELECT * FROM V$RECOVERY_FILE_DEST; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES -------------- ----------- ---------- ----------------- --------------- /mydisk/rcva 5368709120 109240320 256000 28
Query the V$FLASH_RECOVERY_AREA_USAGE view to find out the percentage of the total disk quota used by different types of files, and how much space for each type of file can be reclaimed by deleting files that are obsolete, redundant, or already backed up to tape.
SQL> SELECT * FROM V$FLASH_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
See the Oracle Database Reference for more details on the V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA views.
To disable the flash recovery area, set the DB_RECOVERY_FILE_DEST initialzation parameter to a null string. For example, use this SQL*Plus statement to change the parameter on a running database:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID="*";
The database will no longer provide the space management features of the flash recovery area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files will still be known to the RMAN repository, however, and available for backup and restore activities.
The backup retention policy specifies which backups must be retained to meet your data recovery requirements. This policy can be based on a recovery window (the maximum number of days into the past for which you can recover) or redundancy (how many copies of each backed-up file to keep).
Use the CONFIGURE command to set the retention policy.
The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN does not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting, then RMAN considers the extra backups as obsolete. The default retention policy is REDUNDANCY=1.
As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all archived logs and incremental backups that are needed to recover the nonobsolete backups.
Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
You can view the currently configured retention policy with the SHOW RETENTION POLICY command. Sample output follows:
RMAN> SHOW RETENTION POLICY; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
When you disable the retention policy, RMAN does not consider any backup as obsolete.
To disable the retention policy, run this command:
CONFIGURE RETENTION POLICY TO NONE;
Configuring the retention policy to NONE is not the same as clearing it. Clearing it returns it to its default setting of REDUNDANCY=1, whereas NONE disables it completely.
If you disable the retention policy and run REPORT OBSOLETE or DELETE OBSOLETE without passing a retention policy option to the command, RMAN issues an error because no retention policy exists to determine which backups are obsolete.
|
Note: If you are using a flash recovery area, then you should not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the flash recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. It is quite likely that all of the space in your recovery area will be used. This interferes with the normal operation of your database as described in "When Space is Not Available in the Flash Recovery Area". |
Oracle does not delete eligible files from the flash recovery area until the space must be reclaimed for some other purpose. The effect is that files recently moved to tape are often still available on disk for use in recovery. The recovery area can thus serve as a kind of cache for tape. Once the flash recovery area is full, Oracle automatically deletes eligible files to reclaim space in the flash recovery area as needed.
There are relatively simple rules governing when files become eligible for deleteion from the flash recovery area:
Permanent files are never eligible for deletion.
Files that are obsolete under the configured retention policy are eligible for deletion.
Transient files that have been copied to tape are eligible for deletion.
In a Data Guard environment, archived redo log deletion policy governs when archived redo log files can be deleted from the flash recovery area. See Oracle Data Guard Concepts and Administration for details on archived redo log deletion policy.
|
Note: Exactly which of the eligible files will be deleted to satisfy a space request is unpredictable. The rules governing the selection of specific files for deletion are likely to change between releases and are dependent upon your configuration. The safe and reliable way to control deletion of files from the flash recovery area is to change your retention policy. If you wish to increase the likelihood that files moved to tape are also retained on disk to minimize expected restore and recovery times, increase the flash recovery area quota. |
If, for instance, the RMAN retention policy requires keeping a set of backups larger than the flash recovery area disk quota, or if the retention policy is set to NONE, then the flash recovery area can fill completely with no reclaimable space.
The database issues a warning alert when reclaimable space is less than 15% and a critical alert when reclaimable space is less than 3%. To warn the DBA of this condition, an entry is added to the alert log and to the DBA_OUTSTANDING_ALERTS table (used by Enterprise Manager). However, the database continues to consume space in the flash recovery area until there is no reclaimable space left.
When the recovery area is completely full, the error you will receive is:
ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit
where nnnnn is the number of bytes required and mmmm is the disk quota for the flash recovery area.
The database handles a flash recovery area with insufficient reclaimable space just as it handles a disk full condition. Often, the result is an database hang, but not always. For example, if the flash recovery area is one of your mandatory redo log archiving destinations, and the database cannot archive a new log because the recovery area is full, then the archiver may, depending on your configuration, retry archiving periodically until space is freed in the recovery area. For information on how a particular feature of Oracle responds to a disk full condition, see the documentation for that feature.
|
See Also:
|
In this example the database is configured as follows:
Archived logs and RMAN backups are stored in the flash recovery area.
The control file and online redo log copies are stored in directories in the file system outside the flash recovery area.
Datafiles are expected to be no larger than 3GB in size. No more than 4GB of archived redo log files should be retained.
The backup strategy in this example is based on incremental backups. The control file will be automatically backed up to the flash recovery area.
The flash recovery area is sized to 10GB, room enough for control file autobackups, a whole database level 0 incremental backup (which consists of image copies of the 3GB of datafiles), plus several incremental level 1 backups.
To implement this strategy, the parameter file contains the following entries:
DB_NAME=sample # set location for current datafiles: DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' # set location for control files and online redo logs: DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area' # set flash recovery area location and size DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G
Because the parameter file does not set any of the LOG_ARCHIVE_DEST_n parameters, Oracle sends archived logs to the flash recovery area only.
Once the target database is started, the following RMAN commands configure the retention policy, backup optimization, and the control file autobackup:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1; RMAN> CONFIGURE BACKUP OPTIMIZATION ON; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Any disk-based backups are now directed to your flash recovery area.
|
See also: "Scripting Disk-Only Backups" for examples of backup jobs you could run in this environment. |
Assume that you want to create a database with the following properties:
The control files, datafiles, and online redo logs are stored as Oracle managed files in a single file system directory.
One multiplexed copy of the control file is kept in the flash recovery area
Multiplexed copies of the online redo logs are kept in the flash recovery area
Redo log files are archived both to the flash recovery area and another file system, separate from the work area
RMAN backups are directed to the flash recovery area by default
|
See Also: Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about file creation in the flash recovery area |
To create a database with a flash recovery area:
Create a PFILE for the database, including the initialization parameters required to use a flash recovery area and direct online and archived logs, a copy of the control file, . Assume that you set the following:
# set DB_NAME DB_NAME=sample # set destination for OMF datafiles, control file and online redo logs DB_CREATE_FILE_DEST = /u01/oradata/wrk_area/ # set log archiving destinations to a file system location # and the flash recovery area LOG_ARCHIVE_DEST_1 = 'LOCATION=/arc_dest1' LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' # multiplexed copies of control file and online logs in flash recovery area # rman backups also go here DB_RECOVERY_FILE_DEST = 'LOCATION=/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G
The DB_CREATE_FILE_DEST parameter sets the default directory for all datafiles, online logs, and control files. Another copy of the control file and online logs is created in the flash recovery area.
After you set the initialization parameters, create the database. For example, start SQL*Plus and enter:
SQL> CREATE DATABASE sample;
The preceding statement has the following effects:
Datafiles are created as Oracle managed files in DB_CREATE_FILE_DEST.
Because no LOGFILE clause was included, online log groups are created by default. Each group has two members, one in DB_CREATE_FILE_DEST, the other in DB_RECOVERY_FILE_DEST.
Because the CONTROL_FILES parameter was not set, Oracle creates a control file in DB_CREATE_FILE_DEST (primary) and DB_RECOVERY_FILE_DEST (multiplexed copy). On a Linux system, the filenames might look like the following:
/u02/oradata/wrk_area/SAMPLE/controlfile/o1_mf_3ajeikm_.ctl #primary ctlfile /u01/oradata/rcv_area/SAMPLE/controlfile/o1_mf_6adjkid_.ctl #ctl file copy /u02/oradata/wrk_area/SAMPLE/logfile/o1_mf_0_orrm31z_.log #log grp1, mem 1 /u01/oradata/rcv_area/SAMPLE/logfile/o1_mf_1_ixfvm8w9).log #log grp 1 mem 2 /u02/oradata/wrk_area/SAMPLE/logfile/o1_mf_2_2xyz16am_.log # log grp2, mem 1 /u01/oradata/rcv_area/SAMPLE/logfile/o1_mf_2_q89tmp28_.log #log grp 2, mem 2
Oracle uses LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2 as destinations for archiving the redo logs. Archived redo log files are created in the flash recovery area because LOG_ARCHIVE_DEST_2 is configured to be the flash recovery area.
Because you enabled a local redo log archiving destination, LOG_ARCHIVE_DEST_10 is not implicitly set to the flash recovery area.
The archived redo log files in the flash recovery area are given Oracle-managed filenames that are not based on the LOG_ARCHIVE_FORMAT parameter. For example, if you generate an archived log:
ALTER SYSTEM ARCHIVE LOG CURRENT;
An archived log file is created in the primary archiving location, as well as the following flash recovery area subdirectory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD
where YYYY_MM_DD is the creation date format.
You may want to create more online redo log groups for this database. To do so, use the ALTER DATABASE ADD LOGFILE statement in SQL*Plus. When no file name is specified, it creates another log file member in the destinations already specified for online logs, including the flash recovery area. For example,the following statement creates a new log group with two members: one in DB_CREATE_FILE_DEST and another in DB_RECOVERY_FILE_DEST:
ALTER DATABASE ADD LOGFILE;
Assume that you want to create a database in which the control files, datafiles, and online redo logs are Oracle managed files in a single file system directory. Additionally, you want to do the following:
Archive each redo log to the flash recovery area (and only to the flash recovery area)
Send RMAN backups to the flash recovery area by default.
|
See Also: Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about file creation in the flash recovery area |
To create a database with a flash recovery area:
Set the relevant initialization parameters. Assume that you set the following:
DB_NAME=sample DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G # if you set the following parameters, then the online redo logs *and* # current control file are located here DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area'
The DB_CREATE_FILE_DEST parameter sets the default file system directory for the datafiles. The DB_CREATE_ONLINE_LOG_DEST_n parameter sets the default file system directories for the online redo logs and control files. DB_RECOVERY_FILE_DEST sets the file system directory for archived logs.
After you set the initialization parameters, create the database. For example, start SQL*Plus and enter:
CREATE DATABASE sample;
No multiplexed copies of the online redo logs or control files are created in the flash recovery area.
Because you enabled a flash recovery area, Oracle automatically sets LOG_ARCHIVE_DEST_10 to the flash recovery area. The filenames in the flash recovery area are given Oracle managed filenames that are not based on the LOG_ARCHIVE_FORMAT parameter. For example, generate an archived log:
ALTER SYSTEM ARCHIVE LOG CURRENT;
On Linux, the preceding statement creates an archived log in a flash recovery area subdirectory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD, where YYYY_MM_DD is the creation date format.
If you need to add more online redo log groups, execute the ALTER DATABASE ADD LOGFILE statement. When no file name is specified, it creates another log file member in each DB_CREATE_ONLINE_LOG_DEST_n location (but not the flash recovery area). For example, enter the following:
ALTER DATABASE ADD LOGFILE;
On Linux, the preceding statement creates one member in /u03/oradata/wrk_area/SAMPLE/logfile and another member in /u04/oradata/wrk_area/SAMPLE/logfile. On other platforms, the specific file and directory names are platform-dependent.
