The Fast Recovery Area (FRA) is not a requirement for using RMAN, but it should be. The FRA was introduced in Oracle Database version 10g. It was first called the Flash Recovery Area but was then renamed to the Fast Recovery Area.
The term recovery files refers to all files that might be required for a media recovery operation: full datafile backups, incremental backups, datafile copies, backup control files, and archive logs.
The FRA also functions as a repository for mirrored copies of online redo log files, the blockchange tracking file, and for a current control file. If set up, flashback logs for using the flashback database option also live in the FRA.
The concept behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and
RMAN can then micromanage, while the DBA moves on to other important duties. The FRA really is part of an overall backup and recovery architecture strategy that is designed to ensure that the database is recoverable, with a minimum of work on the part of the DBA.
The FRA that you set up can be either a directory on a normal disk volume or an Automatic Storage Management (ASM) disk group.
The FRA is determined by two initialization parameters: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. The first determines the location; the second, the size. These can be set in your init.ora file,
if you still use one, or in the SPFILE via an alter system set command.
With an FRA configured, you are not required to set any other LOG_ARCHIVE_DEST_n parameter for archive logs; by default, with an FRA, Oracle will default the setting for LOG_ARCHIVE_DEST_10 to use the FRA.
There may be some cases where you will want to set other log archived destination directories for example, with standby databases.
It should also be noted that with an FRA in use, the parameters
- LOG_ARCHIVE_DEST or
are mutually exclusive, but you certainly rid yourself of these outdated parameters long ago, right? The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates when the files are generated.
The files themselves are named according to the Oracle Managed Files (OMF) format. Significant internal directory structures exist for file management. However, the point of an FRA is that you do not need
to spend much time worrying about the files. The same FRA can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM
disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes.