How To Maintain The Fast Recovery Area

You understand what the Fast Recovery Area aka FRA is, what files are stored there and how to enable it. If you need a refresher, check out last week’s post here: 3 Questions Answered About FRA – What, Who, How?.

I’d like to take this a step further, and show you a few more things about the FRA.

Today’s post will show you how the FRA is cleaned up, what to do when the FRA is full, and I have a special BONUS for you.

One of my readers was kind to share the setup that he is using with his clients, when it comes to FRA!

I won’t keep you waiting any longer! Keep on reading!

1. Who Is Cleaning Up The FRA?
2. The FRA Is Full, What Do I Do?
3. FRA Setup From Real Life

1. Who is cleaning up the FRA?

Have you ever asked yourself that question? How is the space managed within the Fast Recovery Area?

Do you think that Oracle is deleting the files automatically in the FRA?

Think again!

Before going any further, lets clarify some things.

The transient files in the FRA should stay there for a specific time called a retention period.
This retention period is set in RMAN for the database backups, archived logs and controlfile backup by configuring the backup retention policy.

The retention period for the flashback logs is set with the parameter db_flashback_retention_target.

Based on the set retention, the transient files become eligible or available for deletion.

But, just because a file is eligible to be deleted, doesn’t mean it will be deleted. Oracle will only start deleting the eligible files from the FRA, when space must be reclaimed.

What does this mean to you, how is this affecting your work?

• DBA must not wait for the FRA to get full, meaning, DBA must have a process in place to cleanup the FRA.
• DBA must set a backup retention policy in RMAN and flashback retention if applicable, in order to age out files in the FRA.
• DBA must create a script or job that will delete the eligible files from the FRA.

2. The FRA Is Full, What Do I Do?

What happens when the FRA gets full?

The answer to that question is, it depends on what you are storing in the FRA.

a) If you are storing archived logs in the FRA, and if the FRA is full, then the answer is obvious.
The database cannot write out changes to the archived logs, meaning the database will not accept new connections, meaning the users will be experiencing an outage.

In this case, the users will get the following error message:

ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.

In order to quickly fix this problem, you can increase the quota in the FRA (free space permitting), and/or delete obsolete archived logs or backup, through RMAN.
Do not remove files manually with the rm command, as this may not free up “logically” the space in the FRA.

$df -k             -- > check for free space on disk

SQL>alter system set db_recovery_file_dest_size=300G scope=both;     --> increase the FRA quota to quickly return the db to users

RMAN>delete archivelog until time 'sysdate-1' backed up 1 times to sbt;  --> come up with the criteria that fits your needs for deleting files

b)If no archived logs are stored in the FRA, and the FRA gets full, then your database is not affected. Your backups will be affected, as those will fail.
In this case you will have to increase the FRA and/or delete obsole backups.

c)If you have flashback logs writing to the FRA, and the database has a Guaranteed Restore Point created, and the FRA is full, then the database will crash, in order to maintain the restore point. This means an outage for users.
In this case as well you will need to add space to FRA and/or delete obsolete backups.

3. FRA Setup From Real Life

Wouldn’t it be cool to see FRA in action, in real life?
Well, look no further!

Wayne, one of my dear readers, was very kind to share with me the setup he is using for FRA, and he gave me permission to share with all of you.

Wayne is implementing the FRA on an external NAS device.

All the databases are configured to be backed up to the FRA on the NAS, under a central location, lets call this /oradata/backups.
Each database has a subdirectory within the central location: /oradata/backups/DB1, /oradata/backups/DB2, and so on.

Each database has a parameter setup for the FRA, similar to this:

db_recovery_file_dest=/oradata/backups/DB1
db_recovery_file_dest_size=200G

The key thing here is what files are stored in the FRA! Wayne only stores database backups, archived logs backups, and control file backups.

The following files are created locally and are not stored in the NAS: redo logs, archived logs, control files.

Why is this setup great?

If the NAS is unavailable (due to multiple causes, not only disk full), the database keeps on going, the availability of the database is not affected.
Only backups are affected. And backups you can always re-run.

As a quick glance, here is the setup:

Thank you Wayne for sharing your wisdom and knowledge with us!

If you enjoyed this article, and would like to learn more about databases, please sign up below, and you will receive
The Ultimate 3 Step Guide To Find The Root Cause Of The Slow Running SQL!

–Diana