RMAN Quick Ref‎ > ‎

Flash Recovery Area

posted Jul 13, 2011, 8:14 AM by Sachchida Ojha   [ updated Jul 13, 2011, 9:28 AM ]

The Flash R ecovery Area: The flash recovery area (FRA) is not a requirement for using RMAN, but it should be. New in 10g, the FRA is a specific location on disk that you set up to house all the Oracle recovery files.
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 block-change tracking file, and for a current control file. If set up, flashback logs for using the flashback database option also live in the FRA. (We discuss flashback technologies in Chapter 1 3.)
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. This simplification is based on some underlying principles of a solid backup strategy that focuses on availability:

  1. At least one copy of important datafiles, if not the entire database, should be kept on disks that are locally accessible to the database.
  2. Backups past a certain age should be moved to tape based on storage pressure on local disks.
  3. Long-term backup management should be almost completely automatic, based on business rules.

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 and the second, the size. These can be set 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 LOG_ARCHIVE_DEST_10 to the FRA. It should also be noted that with an FRA in use, you cannot use LOG_ARCH IVE_DEST or LOG_ARCH IVE_DUPLEX_DEST—but, of course, you 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 the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format. As such, the files are hard to decipher (except for archive logs, which still maintain the structure you give them with the LOG_ARCHIVE_FORMAT parameter). Significant internal directory structures exist for file management. However, the point of an FRA is that you don’t need to spend much time worrying about the files. That being said, it’s worth taking note of the internal structure and familiarizing yourself with where the files go. Sooner or later, you will end up digging for a particular file manually. Trust us.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. Here’s the catch: all the databases that share the FRA either have a different value for DB_NAME or have a different name for the value DB_UNIQUE_NAME.

Setting Up the Flash Recovery Area
To set up the FRA, you will want to configure the following parameters:

Parameter DB_RECOVERY_FILE_DEST_SIZE DB_RECOVERY_FILE_DEST

Example
Alter system set db_recovery_file_dest_size=20G scope=both;

Purpose  Sets the allocated size of the FRA, in bytes, and must be defined in order to enable the FRA. This allows you to control how much disk space is allocated to the FRA.
You should not set this value to a size greater than the total amount of available disk space.

Alter system set db_recovery_file_dest=' /u01/oracle/flash_recovery' scope=both;

Specifies the location of the FRA. This can be a file system, an ASM disk location, or an OMF location.

Note that you must specify the DB_RECOVERY_FILE_DEST_SIZE parameter before you specify the DB_RECOVERY_FILE_DEST parameter. Failure to do so will result in an ORA-32 001 error message. In a similar fashion, you must disable the DB_RECOVERY_FILE_DEST parameter before you reset the DB_RECOVERY_FILE_DEST_SIZE parameter. Leaving DB_RECOVERY_FILE_DEST empty will disable the FRA. Here is an example of disabling the FRA by resetting the DB_
RECOVERY_FILE_DEST parameter:

alter system set db_recovery_file_dest=' ' scope=both;

Oracle allows you to archive to both the FRA and to one or more additional locations through the use of the LOG_ARCHIVE_DEST_n parameters. One case when you would want to do this is if you were configuring standby databases and you still wanted to take advantage of the features of the FRA.

To configure both FRA and archive log destination directories, you set the standard FRA parameter DB_RECOVERY_FILE_DEST, defining the location of the FRA. You will also define the various LOG_ARCHIVE_DEST_n parameters that are required. By default, when a LOG_ARCHIVE_DEST_n parameter is defined, that location will be used instead of the FRA. To get Oracle to use the FRA when a LOG_ARCHIVE_DEST_n parameter is set, you need to define an additional LOG_ARCHIVE_DEST_n parameter for the FRA. Typically, this will be LOG_ARCHIVE_DEST_1 0, and you will use the Oracle-supplied constant USE_DB_RECOVERY_FILE_DEST to indicate that this destination is the FRA. Here is an example where we configure Oracle to use the FRA and a regular archive log destination directory:

alter system set log_archive_dest_10=' LOCATION=USE_DB_RECOVERY_FILE_DEST' ;
alter system set log_archive_dest_1=' location=c: \oracle\oraarc\beta1 mandatory' ;


In this example, the ARCH process will now create archived redo logs in both LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_10, which is the FRA.

Flash Recovery Area Views
Several views are available to help you manage the FRA. These views include the following:
  1. DBA_OUTSTANDING_ALERTS
  2. V$RECOVERY_FILE_DEST
  3. V$FLASH_RECOVERY_AREA_USAGE
Also, columns are available in several other views that help you to manage the FRA. Let’s look at each of these views and columns in more detail. The DBA_OUTSTANDING_ALERTS View As files are added or removed from the FRA, records of these events are logged in the database alert log. You can check the new DBA view, DBA_OUTSTANDING_ALERTS, for information on outstanding issues with the FRA. Note that there is somewhat of a lag between the time a space-related issue occurs and when the warning appears in the DBA_OU TSTANDING_ALERTS view. The following is an example where the FRA has run out of space and is posting an alert to the DBA_OUTSTANDING_ALERTS view. You would need to deal with this situation quickly or risk the database coming to a complete halt. In this case, we used the alter system command to increase the amount of space allocated to the FRA.

SQL> select reason from dba_outstanding_alerts;
REASON
-------------------------------------------------------------
db_recovery_file_dest_size of 524288000 bytes is 100. 00% used
and has 0 remaining bytes available.

SQL> alter system set db_recovery_file_dest_size=800m;

The V$RECOVERY_FILE_DEST View The V$RECOVERY_FILE_DEST view provides an overview of the FRA that is defined in your database. It provides the size that the FRA is configured for, the amount of space used, how much space can be reclaimed, and the number of files in the FRA. In the following example, we can see that the increase in space to the FRA to 800MB has been recorded (SPACE_LIMIT). However, we still have used too much space (SPACE_
USED), and the FRA is still full.

SQL> select * from v$recovery_file_dest;
NAME
-----------------------------------------------------------------------  
SPACE_LIMIT             SPACE_USED  SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------- ---------------------- ------------------ --------------
c: \oracle\product\10. 2.0\flash_recovery_area
   838, 860, 800          1, 057, 116, 672        338, 081, 280              11
One nice thing about Oracle is that it manages the FRA space for us as much as it can, and if there is reclaimable space available, it will free it as required. Note that in the previous query, Oracle indicated we were out of FRA space. Did you notice the SPACE_RECLAIMABLE column, though? This column indicates that there is reclaimable space available. This is space that is taken up by archived redo logs or backup set pieces that are no longer needed by virtue of whatever
retention criteria we have selected (we will discuss retention criteria and setting those criteria later in this chapter). When Oracle needs space in the FRA (say, for example, we force a log switch), it will remove any files that are reclaimable and free up space. In the next query, we can see that this has occurred. After we ran the previous query that indicated we were out of FRA space, we forced a log switch. This caused Oracle to reclaim space from the FRA for reuse, and
it then was able to write out the archived redo log. We can query the V$RECOVERY_FILE_DEST view and see that this has indeed occurred:
SQL> alter system switch logfile;
System altered.
SQL> select * from v$recovery_file_dest;
NAME
-----------------------------------------------------------------------  
SPACE_LIMIT             SPACE_USED  SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------- ---------------------- ------------------ --------------
c: \oracle\product\10. 2.0\flash_recovery_area
   838, 860, 800            719, 412, 7 36             64, 000        

The V$FLASH_RECOVERY_AREA_USAGE View The V$FLASH_RECOVERY_AREA_USAGE view provides more detailed information on which types of files are occupying space in the FRA. This view groups the file types and then provides the percentage of space that is used by each file type, the percentage of the total FRA reclaimable space that comes from that group, and the number of files in the FRA that come from that group. Here is a query of the V$FLASH_RECOVERY_AREA_USAGE view:

SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- --------------CONTROLFILE                   0                         0               0
ONLINELOG                     0                         0               0
ARCHIVELOG                17. 14                     17 . 09               7
BACKUPPIECE              108. 88                     23. 22               4
IMAGECOPY                     0                         0               0
FLASHBACKLOG                  0                         0               0
In this example, we notice a few things:We are over our defined space allocation (the PERCENT_SPACE_USED of all the rows exceeds 1 00 percent). This is probably because the size of the FRA was recently changed and Oracle has not yet reclaimed enough space to bring the total used below 1 00 percent.The backup set pieces are consuming most of that space, and 23 .22 percent of that space is reclaimable.The archived redo logs consume only 1 7 percent of the space allocated to the FRA, and even if we were to remove all of the archived redo logs, we would  not free up enough space to bring the FRA under the amount of space allocated to it.Other Views with FRA Columns The column IS_RECOVERY_DEST_FILE can be found in a number of Oracle Database V$ views such as V$CONTROLFILE, V$LOGFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY, V$DATAFILE, and V$BACKU P_PIECE. This column is a Boolean that
indicates whether the file is in the FRA.Another column, BYTES, can be found in the V$BACKU P_PIECE and RC_BACKUP_PIECE (an RMAN recovery catalog view) views.

Comments