Flash Recovery Area Basics

Flash Recovery Area

The Flash Recovery Area (FRA) is used to contain – regular backup sets, image copies, and archivelogs and in addition it can also optionally store online redo log files, archived redo log files and control files.

Since, the flash recovery area is generally used for backup files, it should be considered as a candidate to be isolated from the other sets of database disks – its own filesystem, ASM Disk Group, etc.

You can designate the FRA as the location for one of the control files and/or redo log groups to limit the exposure in case of disk failure, etc.

The biggest issue in regards to FRA is calculating what size it should be! First you need to decide where to locate it and then how big to make it.

The issues of location and size are key to creating a flash recovery area. The location issue is straightforward and if you are dealing with a single-instance database the location as long as it is a directory or filesystem should be find. If you use ASM, you can use a disk group for the FRA and I would suggest dedicating an ASM Disk Group to the FRA. Avoid putting the flash recovery area and the database files on the same mount point (if it is a filesystem) or disk group in the case of ASM. This way you spread out the I/O and you work to eliminate an underlaying disk failure at the same time.

You can always define a different location for archive redo logs, if you use a different location, then you can’t 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_1 was set to ‘+pshr_disk3′, you can use log_archive_dest_1 to specify the same location for the archived redo logs.

First, query the parameter to verify its current setting (value):

show parameter log_archive_dest
show parameter log_archive_dest_1

Note: show parameter log_archive_dest will display the all of the initialization parameters that contain this string so there really isn’t a need to enter in the second value above. It is shown for illustration purposes only.

alter system set log_archive_dest_1=’location=+pshr_disk3′ scope=both;
alter system set log_archive_dest=” scope=both;

Some Notes on OMF (Oracle Managed Files):

Oracle uses the following directories for managing its OMF files:

backupset – subdirectory for regular backups
datafile – RMAN image copies
autobackup – control file autobackups
flashback – if the database is running in archivelog mode then you’ll see the flashback logs in this directory
archivelog – archived redo logs can optionally be stored in the FRA and if that is the case they will go here
controlfile – if configured to the flash recovery area they will go here
onlinelog – online redo logs can be made to go here as well and this is the directory will go to if configured

Even if you see that the flash recovery area is filled up close to the size you specified in the initialization parameter db_recovery_file_dest_size don’t manually remove files unless you absolutely have to and in the event that you do remove files you need to understand there are additional steps that need to taken (depending on the type of files, etc.) to alleviate the space pressure and free up the archiver if it has stopped.

In the event that the archiver has stopped and you have to take action you can set the size of the db_recovery_file_dest_size to a high value to free up the archive and then start addressing the problem once the database has started processing transactions again and the user community has ceased screaming at you for the time being.

Then you can decide if you want to drop restore points if you have set flashback restore points, especially older guaranteed restore points. Doing so will instruct Oracle to clean up the FRA. You may find yourself in a situation where you have to temporarily disable flashback in order to free up valuable disk space and get past a problem. However, you have to shutdown Oracle in order to turn flashback recovery off as follows:

shutdown immediate;
startup mount;
alter database flashback off;
alter database open;

You can use RMAN to remove old archivelog:

rman target=/
RMAN> delete noprompt archivelog all;
RMAN> delete noprompt backup of database;
RMNA> delete noprompt copy of database;

The above offers the various choices you have for freeing up disk space.

Checking Space in the FRA

The data dictionary view V$RECOVERY_FILE_DEST shows the sum of various types of files in the flash recovery area in terms of percentages of the total space. It only has one row.

SQL> select * from v$recovery_file_dest;

To see the space used by different type of files in the flash recovery area, you need to query the view V$FLASH_RECOVERY_AREA_USAGE. Here’s an example of the output:

V$FLASH_RECOVERY_AREA_USAGE shows the percentages of the total space consumed, not the space itself. You can join it to V$RECOVERY_FILE_DEST to see the total space occupied by each type of file as show below:

The report generated above may be useful to you to review the space occupied in the flash recovery area compared to the information in the view V$FLASH_RECOVERY_AREA_USAGE. You need to understand how much space is reclaimable as that is the key to figuring out how much space is necessary to hold one day’s backup. If you don’t have that much space to allocate to the FRA and you go with this method you could run out of space before the day is over plus you need to actively monitor the space in order to prevent any service interruptions.