Thursday, December 17, 2009

Unable to Archive Due to flash_recovery_area full


Subject:
Unable to Archive Due to flash_recovery_area full

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)

No comments:

Post a Comment