What is a Flash Recovery Area and how to configure it ?

Subject:	What is a Flash Recovery Area and how to configure it ?
	Doc ID:	Note:305648.1	Type:	BULLETIN
	Last Revision Date:	06-OCT-2005	Status:	PUBLISHED

PURPOSE

-------

This document explains the basic design and configuration of a Flash Recovery Area.

SCOPE & APPLICATION

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

DBA, Support.

What is a Flash Recovery Area and how to configure it ?

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

The Flash Recovery Area is an unified storage location for all recovery-related 

files and activities in an Oracle database. All the files you need to completely

recover a database from a media failure are part of the Flash Recovery Area. 

Flash recovery extends the functionality of Oracle Managed Files to all recovery

related files (backup sets, image copies, and archived logs).  It also provides 

automated space management, by deleting older files (based on a user specified 

retention policy) to make room for newer ones. The user specifies only the 

location of a Flash Recovery Area, and the amount of disk space that Oracle is 

allowed to use for recovery related files. This feature is integrated with the 

10G MMON feature, so that out of space conditions can be handled through the 

standard Oracle monitoring framework.

Question : Why should we use a Flash Recovery Area?

As disk storage media is now competitive to tape with respect to purchase costs,

disk-based backup is an optimal and preferable storage mechanism. By using disks

for storage purposes, you gain significant benefits in terms of mass storage,and

you can randomly access your data in milliseconds rather than hours.  The 

previously expensive downtime in traditional recovery is exchanged for rapid 

data access and recovery times using cheap disk space.

The advantage that we have over tape is that tape is a sequential access device and disk is a random access

device. Hence the amount of time needed for restoring from the tape is eliminated

or reduced.

ASM (Automatic Storage Management) SUPPORT:

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

- RMAN can back up and restore files that are stored in ASM disk groups.In fact,

  RMAN is the only way to back up and restore ASM files.

- The Flash Recovery Area can be an ASM disk group.

- Backup sets and image copies can be created in ASM, either by automatically 

  creating them in the Flash Recovery Area, or by explicitly specifying an ASM 

  disk group for their location.

OMF (Oracle Managed Files) SUPPORT:

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

- Backup/Restore of OMF files is easier with RMAN as RMAN does not use 

  the long OMF file names in any commands.

- Backup sets and image copies can be created as OMF files by creating them in 

  the Flash Recovery Area. 

- RMAN can be used to migrate existing files to OMF.

Files are stored in the Flash Recovery Area:

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

The files in Flash Recovery Area are classified as permanent or transient.

-- Permanent Files

   The permanent files (assuming these are configured to be stored in the 

   recovery area) are multiplexed copies of the current control file and online 

   redo logs. These cannot be deleted without causing the instance to fail. 

-- Transient Files

   Transient files include archived redo logs, datafile copies, control file 

   copies, control file autobackups, backup pieces and flashback logs. Oracle 

   manages these files automatically for deletion whenever space is required 

   in the Flash Recovery Area. They are deleted once they become obsolete under 

   the retention policy or have been backed up to tape. Any transient file in

   the flash recovery area once backed up to tape even if not deleted are

   internally placed on a file can be deleted list. Until there is a backup

   of the file on disk made to a teriary storage device it cannot be obsolete.

Initialization Parameters for Flash Recovery Area:

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

To enable the Flash Recovery Area, you must set the two initialization parameters:

-- DB_RECOVERY_FILE_DEST_SIZE : 

   It is the disk limit, which is the amount of space the flash recovery area is

   permitted to use. The minimum size of the Flash Recovery Area should be at 

   least large enough to contain archive logs that have not been copied to tape. 

   Note: This value does not include certain kinds of disk overhead:

   -Block 0 or the OS block header of each Oracle file is not included in this 

    size, so make sure to allow an extra 10% for this data when computing the 

    actual disk usage required for the Flash Recovery Area.

   -DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk 

    when the underlying filesystem is mirrored, compressed, or in some other way

    affected by overhead not known to Oracle. 

-- DB_RECOVERY_FILE_DEST: 

   This initialization parameter is a valid destination to create the 

   Flash Recovery Area. The destination can be defined as a directory, 

   file system, or ASM disk group. 

   Note: The Flash Recovery Area cannot be stored on a raw file system.

   DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST. The two

   parameters must be set together to enable the FRA. In a RAC database, all

   instances must have the same values for these parameters. Even though there

   are multiple nodes they all share the same controlfiles.

Restrictions on Initialization Parameters:

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

- You cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters to 

  specify redo log archive destinations. You must always use the 

  LOG_ARCHIVE_DEST_n parameters in case you have configured flash recovery area.

- LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST if you 

  create a recovery area and do not set any other local archiving destinations.

- Multiple database can have the same DB_RECOVERY_FILE_DEST only if the DB_NAME 

  are different or if the DB_NAME is same (example the primary and standby 

  database) then the DB_UNIQUE_NAME parameter must be different for the

  databases.(3)

- For RAC the location of Flash Recovery Area must be on a cluster file system, 

  ASM or a shared directory configured through NFS. The location and disk quota 

  must be the same on all instances.

Example :

  Note 275083.1 Flash Recovery Area in 10G

References

----------

Note 293418.1 ORA-19815 WARNING DB_RECOVERY_FILE_DEST_SIZE 100.00% USED

Note 268197.1 New Background Processes In 10g

Note 273015.1 HowTo: 10G Migrating to RAC using Data Guard

Note 305817.1 FAQ - Flash Recovery Area feature of 10G

Unable to Archive Due to flash_recovery_area full

Subject:	Unable to Archive Due to flash_recovery_area full
	Doc ID:	Note:249452.1	Type:	PROBLEM
	Last Revision Date:	25-OCT-2005	Status:	REVIEWED

The information in this article applies to:

Use of the Oracle 10G database and flash recovery (recovery destination)  areas only.

This article is to help Support analysts workaround a specific problem.

This workaround should only be used following due consideration to how 

it may effect the ability to recover and as such should not be made public

even after 10G goes production.

Symptom(s)

~~~~~~~~~~

Archiving fails due to the flash_recovery_area being full.

The alert log will show something like :-

Fri Sep 26 12:05:27 2003

ARC0: Evaluating archive   log 2 thread 1 sequence 240

ARC0: Archiving not possible: No primary destinations

ARC0: Failed to archive log 2 thread 1 sequence 240

Fri Sep 26 12:05:27 2003

Errors in file /u02/primary/admin/DB1/bdump/beta_arc0_24471.trc:

ORA-16014: log 2 sequence# 240 not archived, no available destinations

ORA-00312: online log 2 thread 1: '/u02/primary/oradata/DB1/redo02.log

The archive trace file will show something like :-

*** SESSION ID:(11.1) 2003-09-26 11:47:00.270

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 9261056 bytes disk space from 2147483648 limit

*** 2003-09-26 11:47:00.272 49832 kcrr.c

ARC0: Error 19809 Creating archive log file to '/u02/primary/flash_recovery_area/BETA/archivelog/2003_09_26/o1_mf_1_241_%u_.arc'

*** 2003-09-26 11:47:00.273 48728 kcrr.c

kcrrfail: dest:10 err:19809 force:0 blast:1

Change(s)

~~~~~~~~~~

You will only see this if you are using a flash_recovery_area as set by the

initialisation parameter

db_recovery_file_dest    = /u02/primary/flash_recovery_area

And you use the allowed spce in that area as specified by ..

db_recovery_file_dest_size= 2147483648

Cause

~~~~~~~

We register all the information about what we place in the flash recovery area in 

the rman repository/controlfile.  If we determine that there is not sufficient space 

in the recovery file destination, as set by dest_size then we will fail.

Just deleting the old backups/archive logs from disk is not sufficient as it's the rman repository/controlfile

that holds the space used information.

Fix

~~~~

There are a couple of possible options.

1) Increase the parameter db_recovery_file_dest_size, which is dynamic.

SQL> alter system set db_recovery_file_dest_size=XG; (larger amount)

2) Stop using the db_recovery_file_dest by unsetting the parameter.

   ( This assumes you never really wanted to use this option )

3) Remove the Entries from the rman repository/Controlfile

   The removal is desribed in the RMAN documentation but this is a quick and

   dirty way if you don't have an rman repository - but could endanger your ability 

   to recover - so be careful.

   a) delete unwanted archive log files from disk ( rm /del )

   b) connect to rman 

   c) rman crosscheck archivelog all - marks the controlfile that the archives have been deleted

   d) rman delete expired archivelog all - deletes the log entries identified above.

You should then find archiving resumes OK.

Important Note

~~~~~~~~~~~~~~

When using ASM for your flash recovery area (with normal or high redundancy), 

make sure to take into account the miirrored space when setting the 

db_recovery_file_dest_size.  For example, if the ASM disk group space is 160GB,

then available space is only 80GB when using normal redundancy.  In this case,

it is recommended that the db_recovery_file_dest_size be set to 10% less than

80GB.  The 10% gives cushion for orphan files and OSD block headers.

References

~~~~~~~~~~~

Oracle10i Backup and Recovery Basics Release 1 (10.1)

RMAN and Flash Recovery Area

Subject:	RMAN and Flash Recovery Area
	Doc ID:	Note:305796.1	Type:	BULLETIN
	Last Revision Date:	06-OCT-2005	Status:	PUBLISHED

***

This article is being delivered in Draft form and may contain

errors.  Please use the MetaLink "Feedback" button to advise

Oracle of any issues related to this article.

***

PURPOSE

-------

  This article is about how RMAN uses the Flash Recovery Area incase 

  of a backup and restore.

SCOPE & APPLICATION

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

  New Feature in oracle 10G and for DBAs, support 

OVERVIEW

--------

Once a Flash Recovery Area is configured, RMAN will than use the Flash Recovery Area 

to store backups; thus, RMAN backups are stored initialy on disk and not on tape. 

Space management of the Flash Recovery Area is descibed in :

  Note 315098.1 How is the space pressure managed in the Flash Recovery Area

The Flash Recovery Area can be a filesystem or a directory, however alternatively, 

it can be an Automatic Storage Management (ASM) diskgroup. 

In that case, the Flash Recovery Area is specified by: 

SQL> alter system set db_recovery_file_dest = '+dskgrp1';

Consequently, using ASM and RMAN in combination, you can build a 

highly scaleable, fault-tolerant storage system using cheap disks 

such as Serial ATA or SCSI drives, with no additional software required 

This approach not only makes the backup process much faster but also cheap 

enough to compete with the tape-based approach. An additional benefit is 

protection against user errors. Because ASM files are not true filesystems, 

they are less likely to be corrupted accidentally by DBAs and sysadmins.

Files Created by RMAN Commands in the Flash Recovery Area

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

RMAN commands or implicit actions (such as controlfile autobackup) 

can create files in the Flash Recovery Area.

Other files which are stored in the Flash Recovery Area, but out of the

control of RMAN, are :

   - Flashback logs

   - Archived redologs

   - Data-, redolog- and controlfiles 

The related RMAN commands are:

- BACKUP

  Per default a backuppiece is created in the Flash Recovery Area unless

  it is overruled by using the FORMAT-clause.

  The FORMAT-clause can be specified in the BACKUP command or configured

  in the persistent configuration, by using CONFIGURE command.

  The default name of a backuppiece will be in Oracle Managed Files name format.

- Controlfile Autobackup

  RMAN can enable controlfile autobackups.

  RMAN> configure controlfile autobackup on;

  Like with normal backup, the Controlfile autobackup will be stored in the 

  Flash Recovery Area unless the location is overruled by the FORMAT for

  the autobackup.

  RMAN> configure controlfile autobackup format for device type disk to <....>;

- RESTORE ARCHIVELOG

  Per default RMAN restores the archived redologs in the LOG_ARCHIVE_DEST_n

  location.  If one of the LOG_ARCHIVE_DEST_n parameters is set to 

  "LOCATION=USE_DB_RECOVERY_FILE_DEST" then restored archived 

  redo log files will be stored in the Flash Recovery Area.

  This can be overrulled by using the RMAN command : 

  RMAN> SET ARCHIVELOG DESTINATION <....>;

- RECOVER DATABASE or TABLESPACE, BLOCKRECOVER & FLASHBACK DATABASE

  These commands restore archived redologs from the backup to be used for 

  the media recovery, as required by the command. RMAN restores the needed 

  archived redologs and deletes them once they are applied during media recovery.

  The location of the restored archived redolog is handle as if it is

  a explicit RESTORE ARCHIVELOG as described above.

REFERENCE

----------

Note 305817.1 FAQ - Flash Recovery Area feature of 10G

ORA-19815: WARNING: DB_RECOVERY_FILE_DEST_SIZE 100.00% USED

Subject:	ORA-19815: WARNING: DB_RECOVERY_FILE_DEST_SIZE 100.00% USED
	Doc ID:	Note:293418.1	Type:	PROBLEM
	Last Revision Date:	10-OCT-2005	Status:	PUBLISHED

The information in this document applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.0 to 10.2.0.0
This problem can occur on any platform.
This affects RMAN backups to the 10g Flash Recovery Area

Errors

ORA-19815 WARNING: %s of %s bytes is %s used, and has %s remaining bytes

Symptoms

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

Cause

You are making backups to the flash recovery area. You may be using the Oracle disk strategy or just backing up the database to the FRA. All objects written to the FRA will consume space there and to reclaim this space you must backup the FRA files. Once you backup the recovery files they are placed on an internal "file can be deleted" list. Once this is done the reclaimable space increases and Oracle will manage the FRA automatically.
You can monitor the space in the flash_recovery_area using the provided query. The main column is the reclaimable column. If it is 0 then Oralce will not cleanup any files in the db_recovery_file_dest. Where if you backup the recovery area to tape as shown above the reclaimable space is > 0 and the files that were backed up are placed on a file can be deleted list because there is a tape backup of the files. If Oracle needs space after that it will remove the oldest can be delete file available in the FRA. It will remove old archivelogs that have been backed up then backupsets.
The only way to increase the reclaimable column is to have RMAN backup the flash recovery area. Once backed up the files in the recovery area are placed on a files that can be deleted list and Oracle will manage the flash recovery area space.

Fix

SELECT substr(name, 1, 30) name, space_limit AS quota,
       space_used        AS used,
        space_reclaimable AS reclaimable,
        number_of_files   AS files
  FROM  v$recovery_file_dest ;
NAME                                QUOTA       USED RECLAIMABLE      FILES
------------------------------ ---------- ---------- ----------- ----------
/n01/10G/FRAB                  4294967296 2647365120           0        105

# backup the flash recovery area to tape
RMAN> backup recovery area;

SELECT substr(name, 1, 30) name, space_limit AS quota,
       space_used        AS used,
        space_reclaimable AS reclaimable,
        number_of_files   AS files
  FROM  v$recovery_file_dest ;
NAME                                QUOTA       USED RECLAIMABLE      FILES
------------------------------ ---------- ---------- ----------- ----------
/n01/10G/FRAB                  4294967296 2647365120  2254337536        105

References

Note 20978.1 OERR: ORA-9815 File name buffer overflow

How to change Flash Recovery Area to a new location ?

Subject:	How to change Flash Recovery Area to a new location ?
	Doc ID:	Note:305651.1	Type:	HOWTO
	Last Revision Date:	25-NOV-2005	Status:	PUBLISHED

PURPOSE

-------

This document shows how to change the Flash Recovery Area destination and

how to move the files from old area to new area.

SCOPE & APPLICATION

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

DBA Support

How to change Flash Recovery Area to a new location ?

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

If you need to move the Flash Recovery Area of your database to a new location, 

invoke SQL*Plus to change the DB_RECOVERY_FILE_DEST initialization parameter. 

For example:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';

After you change this parameter, all new Flash Recovery Area files will be 

created in the new location.

The permanent files (control files and online redolog 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.

For the FLASHBACK logfiles to be able to to pick up the new 'db_recovery_file_dest' location, 

the flashback option needs to be toggled off and on.

This can be done like this:

- Shutdown the Database

- Startup mount the Database:

  SQL> startup mount;

- Toggle the Flashback off:

  SQL> alter database flashback off;

- Toggle the Flashback on:

  SQL> alter database flashback on;

- Open the Database:

  SQL> alter database open;

If you need to actually move your current permanent files, transient files, to the new Flash Recovery Area, then follow the following steps:

1) To move the existing backupsets and archived redo log files,use the following 

   command:

   RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;

   RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;

2) To move the datafile copies. Run the below command for each datafile copy:

   RMAN> BACKUP AS COPY DATAFILECOPY  DELETE INPUT;

   where the  is the datafilecopy name in the old recovery area.

3) To move the controlfile from the old Flash Recovery Area to new one. Run the 

   following command with database in NOMOUNT state.

   RMAN> RESTORE CONTROLFILE FROM 'filename_of_old_control_file';

4) To move the online redo logs. Use the commands to add a a log file stored in 

   the new Flash Recovery Area and drop the logfile in the old Flash Recovery Area 

   for each redo log group.

   SQL> alter database add logfile size 100M;

   SQL> alter database drop logfile 'name of the old redo log';

Oracle will clean up transient files remaining in the old Flash Recovery Area 

location as they become eligible for deletion.

REFERENCE

----------

Note 305817.1 FAQ - Flash Recovery Area feature of 10G

How is the space pressure managed in the Flash Recovery Area - An Example

Subject:	How is the space pressure managed in the Flash Recovery Area - An Example.
	Doc ID:	Note:315098.1	Type:	BULLETIN
	Last Revision Date:	06-OCT-2005	Status:	REVIEWED

PURPOSE

-------

This article explains the handling of space pressure in Flash Recovery Area 

by way of an example.

SCOPE & APPLICATION

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

DBA, Support

How is the space pressure managed in the Flash Recovery Area - Example.

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

This testcase has been done with the following configuration:

RMAN> show all;

using target database controlfile instead of recovery catalog

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/tmp/)';

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/oracle/product/1010/dbs/snapcf_db10g.f'; # default

When the space used in the Flash Recovery Area goes above 85% the we will get 

the following warning in the alert log:

  Wed Jun 15 21:51:19 2005

  Errors in file /opt/oracle/product/1010/admin/db10g/udump/db10g_ora_13900.trc:

  ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 86.07% used, 

  and has 149591552 remaining bytes available.

  ************************************************************************

  You have following choices to free up space from flash recovery area:

  1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,

     then consider changing RMAN ARCHIVELOG DELETION POLICY.

  2. Back up files to tertiary device such as tape using RMAN

     BACKUP RECOVERY AREA command.

  3. Add disk space and increase db_recovery_file_dest_size parameter to

     reflect the new space.

  4. Delete unnecessary files using RMAN DELETE command. If an operating

     system command was used to delete files, then use RMAN CROSSCHECK and

     DELETE EXPIRED commands.

  ************************************************************************

When the Flash Recovery Area is completely full then we get a error message as follow:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 06/15/2005 22:39:22

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 52428800 bytes disk space from 1073741824 limit

To make space reclaimable we have the following options:

1)  The space occupied by archivelogs created in the Flash Recovery Area 

    would become reclaimable in 2 circumstances:

A) If the free space becomes less then 15% in the Flash Recovery Area then all 

   the archivelogs in the Flash Recovery Area which are not needed for recovery 

   by the current backups in the FRA will become obsolete and the space occupied 

   will be shown in the SPACE RECLAIMABLE column of V$RECOVERY_FILE_DEST.

Output BEFORE free space less than 15%:

  SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  913181184                 0              11

Output AFTER free space less then 15%:(SPACE_RECLAIMABLE column it is now not zero)

   SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  913181184           2124288              11

RMAN> report obsolete;

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 3

Report of obsolete backups and copies

Type                 Key    Completion Time    Filename/Handle

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

Archive Log          51     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_110_1c0mj1b2_.arc

Archive Log          52     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_111_1c0mj8co_.arc

Archive Log          53     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_112_1c0mj9tp_.arc

Archive Log          54     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_113_1c0mjh6j_.arc

Archive Log          55     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_114_1c0mjn90_.arc

B) If the archivelogs have been backed up (either to the Flash Recovery Area itself 

   or to another destination) and the archivelog not deleted. Then the space occupied 

   by that archivelog will be marked as reclaimable.

   RMAN> backup archivelog all;

Starting backup at 15-JUN-05

current log archived

using channel ORA_DISK_1

channel ORA_DISK_1: starting archive log backupset

channel ORA_DISK_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=110 recid=51 stamp=561071961

input archive log thread=1 sequence=111 recid=52 stamp=561071968

input archive log thread=1 sequence=112 recid=53 stamp=561071969

input archive log thread=1 sequence=113 recid=54 stamp=561071975

input archive log thread=1 sequence=114 recid=55 stamp=561071980

input archive log thread=1 sequence=115 recid=56 stamp=561074872

channel ORA_DISK_1: starting piece 1 at 15-JUN-05

channel ORA_DISK_1: finished piece 1 at 15-JUN-05

piece handle=/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/backupset/2005_06

_15/o1_mf_annnn_TAG20050615T220755_1c0pc73n_.bkp comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09

Finished backup at 15-JUN-05

RMAN> report obsolete;

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 3

Report of obsolete backups and copies

Type                 Key    Completion Time    Filename/Handle

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

Archive Log          51     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_110_1c0mj1b2_.arc

Archive Log          52     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_111_1c0mj8co_.arc

Archive Log          53     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_112_1c0mj9tp_.arc

Archive Log          54     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_113_1c0mjh6j_.arc

Archive Log          55     15-JUN-05          /opt/oracle/product/1010/dbs/ora_

flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_114_1c0mjn90_.arc

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  934593024          11767296              13

Here we see that 6 archivelogs have been backed up. Out of the 6 archivelogs 

5 are not needed for recovery and are hence obsolete. But 1 of the archivelogs

is needed for recovery and hence is not shown in the report obsolete. But still 

the space occupied by that archivelog will be added to the reclaimable space.

2) When the Flash Recovery Area is full and there is no space available to 

   create archivelogs in the Flash Recovery Area. We will get the following error

   in the alert log:

Wed Jun 15 23:01:09 2005

Errors in file /opt/oracle/product/1010/admin/db10g/udump/db10g_ora_13754.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 1032704 bytes disk space from 1073741824 limit

ARCH: Error 19809 Creating archive log file to '/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/archivelog/2005_06_15/o1_mf_1_116_0_.arc'

ARCH: All standby destinations failed; successful archival assumed

ARCH: Failed to archive thread 1 sequence 116 (19809)

Wed Jun 15 23:01:27 2005

ARC1: Evaluating archive thread 1 sequence 116

ARC1: Archiving not possible: No primary destinations

ARC1: Failed to archive thread 1 sequence 116 (4)

ARCH: Archival stopped, error occurred. Will continue retrying

Wed Jun 15 23:01:27 2005

ORACLE Instance db10g - Archival Error

ARCH: Connecting to console port...

Wed Jun 15 23:01:27 2005

ORA-16014: log 2 sequence# 116 not archived, no available destinations

ORA-00312: online log 2 thread 1: '/opt/oracle/product/1010/oradata/db10g/redo02.log'

ARCH: Connecting to console port...

ARCH:

Wed Jun 15 23:01:27 2005

ORA-16014: log 2 sequence# 116 not archived, no available destinations

ORA-00312: online log 2 thread 1: '/opt/oracle/product/1010/oradata/db10g/redo02.log'

3) To free space in the FRA we could do take a backup of the Flash Recovery Area 

   using the command BACKUP RECOVERY AREA.

   This command will take the backup of al the files in the FRA to tape only. 

   After this the space occupied by the files in the FRA will be marked as reclaimable.

   Make sure that you have configured channels for backups to tape for this command to succeed.

    RMAN> backup recovery area;

Starting backup at 15-JUN-05

released channel: ORA_DISK_1

using channel ORA_SBT_TAPE_1

specification does not match any datafilecopy in the repository

channel ORA_SBT_TAPE_1: starting archive log backupset

channel ORA_SBT_TAPE_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=116 recid=57 stamp=561079349

channel ORA_SBT_TAPE_1: starting piece 1 at 15-JUN-05

channel ORA_SBT_TAPE_1: finished piece 1 at 15-JUN-05

piece handle=28gn2p4a_1_1 comment=API Version 2.0,MMS Version 8.1.3.0

channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:02

input backupset count=58 stamp=561073729 creation_time=15-JUN-05

channel ORA_SBT_TAPE_1: starting piece 1 at 15-JUN-05

piece handle=1qgn2ji1_1_2 comment=API Version 2.0,MMS Version 8.1.3.0

channel ORA_SBT_TAPE_1: finished piece 1 at 15-JUN-05

channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:25

input backupset count=60 stamp=561073791 creation_time=15-JUN-05

channel ORA_SBT_TAPE_1: starting piece 1 at 15-JUN-05

piece handle=1sgn2jjv_1_2 comment=API Version 2.0,MMS Version 8.1.3.0

....

input backupset count=66 stamp=561076762 creation_time=15-JUN-05

channel ORA_SBT_TAPE_1: starting piece 1 at 15-JUN-05

piece handle=22gn2mgq_1_2 comment=API Version 2.0,MMS Version 8.1.3.0

channel ORA_SBT_TAPE_1: finished piece 1 at 15-JUN-05

channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01

Finished backup at 15-JUN-05

RMAN>

Now the output of the query would look like this:

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  623138304         623138304               7

Note that this command will not delete the files from the FRA. The files would be 

deleted whenever any space is required for any new operation.

4) If suppose the FRA is full and the reclaimable space is 0 or insufficient 

   and we cannot backup the Flash Recovery Area to tape. Then to free 

   space we may delete unwanted files which are not yet obsolete by the following method:

A) Use the RMAN DELETE command to delete some files from the FRA:

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  633155072         0               8

RMAN> delete backupset 45;

using channel ORA_DISK_1

using channel ORA_SBT_TAPE_1

List of Backup Pieces

BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name

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

52      45      1   1   AVAILABLE   DISK        opt/oracle/product/1010/dbs/ora

_flash_area/DB10G/backupset/2005_06_15/o1_mf_ncsnf_TAG20050615T215053_1c0odcbg_.bkp

Do you really want to delete the above objects (enter YES or NO)? yes

deleted backup piece

backup piece handle=/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/backupset/

2005_06_15/o1_mf_ncsnf_TAG20050615T215053_1c0odcbg_.bkp recid=52 stamp=561073891

Deleted 1 objects

SQL>SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  630189568         0               7

B) You can delete the files from the OS using the OS command and then run 

   the RMAN CROSSCHECK command and DELETE EXPIRED command to free the space.

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  630189568         0               7

[oracle@incq073ac 2005_06_15]$ ls -l

total 1016

-rw-r-----  1 oracle dba 1033216 Jun 15 23:22 o1_mf_1_116_1c0tpxb6_.arc

[oracle@incq073ac 2005_06_15]$ rm *

[oracle@incq073ac 2005_06_15]$

RMAN> crosscheck archivelog all;

released channel: ORA_DISK_1

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=142 devtype=DISK

validation failed for archived log

archive log filename=/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/archivelo

g/2005_06_15/o1_mf_1_116_1c0tpxb6_.arc recid=57 stamp=561079349

validation succeeded for archived log

archive log filename=/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/archivelo

g/2005_06_16/o1_mf_1_117_1c1ds0cf_.arc recid=58 stamp=561097849

Crosschecked 2 objects

RMAN> delete expired archivelog all;

released channel: ORA_DISK_1

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=142 devtype=DISK

List of Archived Log Copies

Key     Thrd Seq     S Low Time  Name

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

57      1    116     X 15-JUN-05 /opt/oracle/product/1010/dbs/ora_flash_area/DB1

0G/archivelog/2005_06_15/o1_mf_1_116_1c0tpxb6_.arc

Do you really want to delete the above objects (enter YES or NO)? yes

deleted archive log

archive log filename=/opt/oracle/product/1010/dbs/ora_flash_area/DB10G/archivelo

g/2005_06_15/o1_mf_1_116_1c0tpxb6_.arc recid=57 stamp=561079349

Deleted 1 EXPIRED objects

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/opt/oracle/product/1010/dbs/ora_flash_area

 1073741824  629156864         0               6

REFERENCE

----------

Note 305817.1 FAQ - Flash Recovery Area feature of 10G