ORA-19809: limit exceeded for recovery files db_recovery_file_dest...

https://jhdba.wordpress.com/2008/07/16/25/

ORA-19809: limit exceeded for recovery files

db_recovery_file_dest_size and archiver error
Posted by John Hallas on July 16, 2008
I have long been plagued by the parameter db_recovery_le_dest_size causing a problem when
the size limit is exceeded.
As I have been working on development systems my normal work around was to free up some
space in the db_recovery_le_dest and hope that
that the database would continue after the archiver logger error.
Invariably I needed to restart the database and hope that the problem resolves itself.
Today I decided to take some action and work out how to x the problem.
I logged onto the ASM disk using asmcmd -p (the -p shows the current working directory) and
moved to the archive log directory
ASCMD > cd FRA/SID/ARCHIVELOG/2008-07-16
ASCMD > rm thr* (I did not need to keep the archive logs as we had no need to backup/restore the
database as it could be rebuilt if necessary)
ASCMD > YES (to conrm the prompt)
I then waited for the database to continue from the archiver error but this did not happen
The alert log typically shows an entry as follows :ORA-19815: WARNING: db_recovery_le_dest_size of 42949672960 bytes is 100.00% used, and has
0 remaining bytes available.
************************************************************************
You have following choices to free up space from ash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up les to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_le_dest_size parameter to
reect the new space.
4. Delete unnecessary les using RMAN DELETE command. If an operating
system command was used to delete les, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Errors in le /u00/app/oracle/diag/rdbms/sid/SID/trace/SID_ora_20214.trc:
ORA-19809: limit exceeded for recovery les
ORA-19804: cannot reclaim 1063256064 bytes disk space from 42949672960 limit
ARCH: Error 19809 Creating archive log le to +FRA
I am sure that this message is either new in 11g or has been improved because I have never noticed
the 4th option before.
I had previously congured RMAN on the database and I realised that I needed to ensure that the
RMAN catalog was aware that the les had been removed manually and space was now available.
RMAN > CHANGE ARCHIVELOG ALL VALIDATE;
1 de 5 RMAN > DELETE EXPIRED ARCHIVELOG ALL;

29/08/2015 12:10

ORA-19809: limit exceeded for recovery files db_recovery_file_dest...

2 de 5

https://jhdba.wordpress.com/2008/07/16/25/

RMAN > CHANGE ARCHIVELOG ALL VALIDATE;

RMAN > DELETE EXPIRED ARCHIVELOG ALL;
Metalink Document h ps://metalink.oracle.com/metalink/plsql
/f?p=200:27:9917209390401703684::::p27_id,p27_show_header,p27_show_help:621248.995,1,1 has an
unpublished note on the subject
Cause
~~~~~~~
We register all the information about what we place in the ash recovery area in
the rman repository/controlle. If we determine that there is not sucient space
in the recovery le destination, as set by dest_size then we will fail.
Just deleting the old backups/archive logs from disk is not sucient as its the rman
repository/controlle
that holds the space used information.
Fix
~~~~
There are a couple of possible options.
1) Increase the parameter db_recovery_le_dest_size
2) Stop using the db_recovery_le_dest by unse ing the parameter.
( This assumes you never really wanted to use this option )
3) Remove the Entries from the rman repository/Controlle
The removal is desribed in the RMAN documentation but this is a quick and
dirty way if you dont have an rman repository but could endanger your ability
to recover so be careful.
a) delete unwanted archive log les from disk ( rm /del )
b) connect to rman
c) rman crosscheck archivelog all marks the controlle that the archives have been deleted
d) rman delete expired archivelog all deletes the log entries identied above.

This entry was posted on July 16, 2008 at 1:30 pm and is led under Oracle. Tagged: archiver,
db_recovery_le_dest_size, ORa-19804, ORA-19809, ORA-19815. You can follow any responses to
this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

29/08/2015 12:10

ORA-19809: limit exceeded for recovery files db_recovery_file_dest...

3 de 5

https://jhdba.wordpress.com/2008/07/16/25/

8 Responses to ORA-19809: limit exceeded for recovery files

db_recovery_file_dest_size and archiver error

1. phimic

said

January 29, 2009 at 4:22 pm

Thank you for this nice post. Increasing the parameter db_recovery_le_dest_size solves my
problem :)
Reply

2. John

Hallas said

January 29, 2009 at 8:36 pm

Thank you very much for taking the time to comment. It makes the eort worthwhile
John
Reply

3. Scott

Danforth said

June 25, 2009 at 10:55 pm

I used DB_RECOVERY_FILE_DEST in the init le for a production db and manage the archive
logs that are wri en there myself. I dont use RMAN or Flash Recovery, but used this se ing
because I thought it would give me the option of enabling Flash Recovery in the future. Now,
however, when restoring backups on a separate system, I ran into these
db_recovery_le_dest_size warnings. V$ash_recovery_area_usage indicates Im 44% full after
having wri en 594 archive log les, and Im quite worried about what would happen on my
production system if I allowed the limit to be reached. I experimented on my backup system by
running rman (%rman target /) and doing RMAN>CHANGE ARCHIVELOG ALL VALIDATE;
and RMAN > DELETE EXPIRED ARCHIVELOG ALL; and this xed my
V$ash_recovery_area_usage. Thanks so much for your note explaining this!!!
But, is this how I should proceed on my production system by periodically running RMAN
to x things? This just doesnt feel right. What is a non-RMAN archivelog database supposed to
do???
Reply

John Hallas said

29/08/2015 12:10

ORA-19809: limit exceeded for recovery files db_recovery_file_dest...

4 de 5

https://jhdba.wordpress.com/2008/07/16/25/

John Hallas said

June 26, 2009 at 2:08 pm
Sco , thanks for the comment and I am glad my note was useful.
Firstly the se ing of db_recovery_le_dest_size is not dependant upon space available. If
you have 5Gb in your backup lesystem then you can happily set the size to be 10gb as
Oracle does not check. What the parameter is used for is when you have several databases
all sharing the same db_recover_area then the se ing is used to stop one database taking all
the space from the others (which is what your error message was caused by)
I assume that you normally manually delete the archivelogs via a script. When you ran the
RMAN delete expired command it will have used the default retention period which I think
is 7 days (need to check that) and tided up based on that.
bear in mind that if you do a recovery then RMAN expects to backup the les again before
deleting them even though they are already on tape.
Cannot see why you do not use RMAN though
John
Reply

4. Bob

Siegel said

August 17, 2009 at 5:44 pm

John,
Excellent!!! I was having the same problem on a development Windows box after have the C:
drive AND ash recovery area was lled. After I cleaned up old archive log les I could not get
the DB to properly report the % free in the Flash Recovery Area.
I wasnt aware of the RMAN Change command. I always used the Crosscheck but that did not
always give me the results I desired and properly clean things up if someone deleted backups
or archivelogs at the OS level. RMAN always seems to be a bit twitchy to me. If you dont so it
exactly the way it expects it gets confused.
Thanks,
Bob
Reply

5. 2010

in review Oracle DBA A lifelong learning experience

said
January 4, 2011 at 8:03 am
[] Posts ORA-19809: limit exceeded for recovery les db_recovery_le_dest_size and
archiver errorRMAN backup script example logging outputWhere has consistent=y gone
when using Datapump []
Reply

29/08/2015 12:10

ORA-19809: limit exceeded for recovery files db_recovery_file_dest...

5 de 5

https://jhdba.wordpress.com/2008/07/16/25/

when using Datapump []

Reply

6. Pierre

said

May 8, 2012 at 1:13 pm

Almost four years that you have posted this information and it is still useful. Thanks
Reply

7. Ahmed

said

September 17, 2013 at 6:51 pm

Almost 5 years now? and still information was helpful.
Reply

29/08/2015 12:10