Flash Recovery Area [FRA]

The Flash Recovery Area (FRA) is a unified storage location for all recovery related files and activities in an Oracle database. By defining one init.ora parameter, all RMAN backups, archive logs, control file autobackups, and datafile copies are automatically written to a specified file system or ASM Disk Group. This option is strongly recommended. In RAC environments, the location must be on a cluster file system or ASM.

The files that we save here are:

 PERMANENT (multiplexed copies of current controlfile and online redo logs, they can't be deleted)

 TRANSIENT (arch log files, dfiles copies, ctrl file copies, etc).

Ideally you would create this area big enough to save all backups copies, as a minimum it should be

large enough to contain archive log files that are not copied to tapes yet. You can query the
V$RECOVERY_FILE_DEST to identify that location.

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.

To enable Flash Recovery Area (FRA) you just need to specify 2 parameters in the following order:

- DB_RECOVERY_FILE_DEST_SIZE (specifies max space to use)

- DB_RECOVERY_FILE_DEST (Location)

You can specify those parameters in the init.ora file or by ALTER SYSTEM SET command with the scope=both option.

Examples:

For RAC Perform:

ALTER SYSTEM set db_recovery_file_dest_size=60G scope=both sid='*' ;

ALTER SYSTEM SET db_recovery_file_dest='+FLASH' sid='*';

1. How Oracle Manages Disk Space in the Flash Recovery Area ?

Flash recovery area is a fixed area in Hard Disk reserved for database backups. This area is largely self managing, some situations may require DBA intervention. Oracle Database and RMAN create files in the flash  recovery area until the space used reaches the recovery area disk limit. When it needs to make room for new files, Oracle Database deletes files from the flash recovery area that are obsolete, redundant, or backed up to  tertiary storage.

The following rules govern when files become eligible for deletion from the recovery area:

 

 Permanent files (files used by the database instance. Control file , Online Redo log files) are never

eligible for deletion.

 Files that are obsolete under the retention policy are eligible for deletion.



 

Transient files (All files that are not permanent are transient. Archived redo log, Foreign archived redo log,  Image copies of datafiles , Backup pieces, Flashback logs) that have been copied to tape are eligible for deletion.

 Archived redo logs are not eligible for deletion until all the consumers of the logs have satisfied their requirments.

In general, Oracle Database eventually deletes transient files after they become obsolete.

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.
 

Find Flash Recovery Area Details & Usage:

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

For example :

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

----------- ---------- ----------------- ---------------

D:\Oracle\flash_recovery_area 838860800 292490752 0 44

Query the V$FLASH_RECOVERY_AREA_USAGE view to find out the percentage of the total disk quota used by different types of files. Also, you can determine how much space for each type of file

can be reclaimed by deleting files that are obsolete, redundant, or already backed up to tape.
For example :

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

2. Flash Recovery area - Space management Warning & Alerts

 

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 Flash Recovery Area is completely full, the following error will be reported.

for example :

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim bytes disk space from limit

where is the number of bytes required and is the disk quota for the Flash Recovery Area.

The following Error would be reported in alert.log

ORA-19815: WARNING: db_recovery_file_dest_size of bytes is 100.00% used, and has 0 remaining bytes  available.

Issue the following query to see the message:

SQL> SELECT object_type, message_type, message_level,reason, suggested_action

FROM dba_outstanding_alerts;

The database handles a Flash Recovery Area with insufficient reclaimable space just as it handles a disk full condition.  Often, the result is a hang of the database.

 

3. Retention Policy / Obsolete Files in Flash Recovery Area

Correct use of a Flash Recovery Area, requires a retention policy. No retention policy will cause files in the Flash Recovery Area never become obsolete, causing major  issues on the database.

The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is either not needed for
recovery to a point within the recovery window, or it is redundant.

If a Flash Recovery Area is configured, then the database uses an internal algorithm to delete files from the  Flash Recovery Area that are no longer needed because they are redundant, orphaned, and so forth. The backups with status OBSOLETE form a subset of the files deemed eligible for deletion by the disk quota rules.

When space is required in the Flash Recovery Area, then the following files are deleted:

 

a) Any backups which have become obsolete as per the retention policy.

b) Any files in the Flash Recovery Area which has been already backed up to a tertiary device such as tape.

c) Flashback logs may be deleted from the Flash Recovery Area to make space available for other required files.

A safe and reliable way to control deletion of files from the Flash Recovery Area is to change the retention  policy.

4. Resolving a Full Flash Recovery Area Issues:

There are a number of choices on how to resolve a full Flash Recovery Area when there are NO files eligible for deletion:

- Add disk space to the Flash Recovery Area.

For example :

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE= ;

- Back up your files to a tertiary device.

 

RMAN> backup device type 'sbt_tape' recovery area;

 
- Delete the files from the Flash Recovery Area using RMAN.

- Changing RMAN retention policy.

RMAN> configure retention policy to recovery window of 5 days;