Flash/Fast Recovery Area (FRA) in Oracle: Oracle 10g Oracle 11g Release2
Flash/Fast Recovery Area (FRA) in Oracle: Oracle 10g Oracle 11g Release2
Flash/Fast Recovery Area (FRA) in Oracle: Oracle 10g Oracle 11g Release2
Control files: During database creation, a copy of the control file is created in the flash
recovery area.
Archived log files: During the configuration of the FRA, the LOG_ARCHIVE_DEST_10
parameter in init.ora file is automatically set to the flash recovery area location. Archived log files are
created by ARCn processes in the flash recovery area location and the location defined by
LOG_ARCHIVE_DEST_n.
Flashback logs: Flashback logs are kept in the flash recovery area when flashback database is
enabled.
Control file and SPFILE backups: The flash recovery area also keeps the control file and SPFILE
backups, which is automatically generated by Recovery Manager (RMAN) only if RMAN has been
configured for control file autobackup.
Datafile copies: The flash recovery area also keeps the datafile copies.
RMAN backup sets: The default destination of backup sets and image copies generated by
RMAN is the flash recovery area.
Notes:
The FRA is shared among databases in order to optimize the usage of disk space for database
recovery operations.
Before any backup and recovery activity can take place, the Flash Recovery Area must be set
up. The flash recovery area is a specific area of disk storage that is set aside exclusively for retention
of backup components such as datafile image copies, archived redo logs, and control file auto backup
copies.
RMAN also transfers the restored archive files from tape to the flash recovery area in order to
perform recovery operations.
Configuring FRA
o
o
o
Following are the three initialization parameters that should be defined in order to set up the flash
recovery area:
DB_RECOVERY_FILE_DEST_SIZE
DB_RECOVERY_FILE_DEST
DB_FLASHBACK_RETENTION_TARGET
DB_RECOVERY_FILE_DEST_SIZE specifies the total size of all files that can be stored in the Flash
Recovery Area. The size of the flash recovery area should be large enough to hold a copy of all data
files, all incremental backups, online redo logs, archived redo log not yet backed up on tape, control
files, and control file auto backups.
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 10g SCOPE =
BOTH;DB_RECOVERY_FILE_DEST parameter is to specify the physical location where all the flash
recovery files are to be stored. Oracle recommends that this be a separate location from the datafiles,
control files, and redo logs.
SQL> ALTER SYSTEM SET db_recovery_file_dest = '/OFR1' SCOPE = BOTH;
If the database is using Automatic Storage Management (ASM) feature, then the shared disk area
that ASM manages can be targeted for the Flashback Recovery Area.
SQL> ALTER SYSTEM SET db_recovery_file_dest = '+dgroup1' SCOPE = BOTH;The
DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST are defined to make the flash
recovery area usable without shutting down and restarting the database instance i.e. these two
parameters are dynamic.
Enabling Flashback
SQL> alter database flashback on;
are automatically managed by the database. Whatever archiving scheme you choose, it is always
advisable to create multiple copies of archived logs.
You can always define a different location for archive redo logs, if you use a different location, then
you cant just erase the values of the parameters for LOG_ARCHIVE_DEST and
LOG_ARCHIVE_DUPLEX_DEST in order to specify the location of the FRA.
To place your log files somewhere else other than the FRA you should use a different parameter to
specify the archived redo log locations: use LOG_ARCHIVE_DEST_1 instead of LOG_ARCHIVE_DEST.
Suppose log_archive_dest was set to +arc_disk3, you can use LOG_ARCHIVE_DEST_1 to specify the
same location for the archived redologs.
Query the parameter to verify its current value:
SQL> show parameter log_archive_dest
SQL> show parameter log_archive_dest_1
SQL> alter system set log_archive_dest_1=location=+arc_disk3 scope=both;
SQL> alter system set log_archive_dest= scope=both;
Managing Flash/Fast Recovery Area
As the DB_RECOVERY_FILE_DEST_SIZE parameter specifies the space for the flash recovery area. In
a situation when the space does not prove enough for all flash recovery files, then in such a case
Oracle itself keeps track of those files that are not required on the disk. These unnecessary files are
then deleted to resolve the space issue in the flash recovery area.
Whenever a file is deleted from the flash recovery area, a message is written in the alert log.
There are various other circumstances in which messages are written in the alert log:
1. When none of the files are deleted.
2. When the used space in the FRA is 85 percentage (a warning).
3. When the used space in the FRA is 97 percentage (a critical warning).
4. The warning messages issued can be viewed in the DBA_OUTSTANDING_ALERTS data dictionary
view and are also available in the OEM Database Control main window.
To recover from these alerts, a number of steps can be taken as remedial options:
1. Adjust the retention policy to keep fewer copies of data files.
In case the retention policy is sounds good, then the steps taken to recover from the alerts are:
Backup some of the flash recovery files to another destination such as another disk or tape
drive.
2. Reduce the number of days in the recovery window
RMAN files creation in the Flash Recovery Area
This section describes RMAN commands or implicit actions (such as control file auto backup) that can
create files in the flash recovery area, and how to control whether a specific command creates files
there or in some other destination. The assumption in all cases is that a flash recovery area has
You have a number of choices on how to resolve full flash/fast recovery area when there are no files
eligible for deletion:
Make more disk space available, and increase DB_RECOVERY_FILE_DEST_SIZE to reflect the
new space.
Move backups from the flash recovery area to a tertiary device such as tape. One convenient
way to back up all of your flash recovery area files to tape at once is the BACKUP RECOVERY AREA
command.
After you transfer backups from the flash recovery area to tape, you can resolve the full recovery area
condition by deleting files from the flash recovery area, using forms of the RMAN DELETE command.
Note:
Flashback logs cannot be backed up outside the flash recovery area. Therefore, in a BACKUP
RECOVERY AREA operation the flashback logs are not backed up to tape.
Flashback logs are deleted automatically to satisfy the need for space for other files in the
flash recovery area. However, a guaranteed restore point can force the retention of flashback logs
required to perform Flashback Database to the restore point SCN. See
Delete unnecessary files from the flash recovery area using the RMAN DELETE command.
(Note that if you use host operating system commands to delete files, then the database will not be
aware of the resulting free space. You can run the RMAN CROSSCHECK command to have RMAN recheck the contents of the flash recovery area and identify expired files, and then use the DELETE
EXPIRED command to remove missing files from the RMAN repository.)
You may also need to consider changing your backup retention policy and, if using Data Guard,
consider changing your archivelog deletion policy.
Changing the Flash Recovery Area to a new location
If you need to move the flash recovery area of your database to a new location, you can follow this
procedure:
1. Change the DB_RECOVERY_FILE_DEST initialization parameter.
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
2. After you change this parameter, all new flash recovery area files will be created in the new
location.
3. The permanent files (control files and online redo log files), flashback logs and transient files can be
left in the old flash recovery area location. The database will delete the transient files from the old
flash recovery area location as they become eligible for deletion.
Oracle will clean up transient files remaining in the old flash recovery area location as they become
eligible for deletion.
In Oracle Database 11g, a new feature introduced i.e. Flashback Data Archive - flashback will
make use of flashback logs, explicitly created for that table, in FRA, will not use undo. Flashback data
archives can be defined on any table/tablespace. Flashback data archives are written by a
dedicatedbackground process called FBDA so there is less impact on performance. Can be purged at
regular intervals automatically.
Related views
V$RECOVERY_FILE_DEST
V$FLASH_RECOVERY_AREA_USAGE
V$DBA_OUTSTANDING_ALERTS
V$FLASHBACK_DATABASE_LOGFILE