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)