Database Reference
In-Depth Information
Managing the FRA
Management of the FRA is done principally by Oracle based on backup retention settings for
RMAN (see the section “Retention Policies” later in this chapter). Thus, as backups become
obsolete and as FRA space is exhausted by an instance, Oracle will remove those obsolete
backups automatically. As a result, over time FRA space tends to reach equilibrium, assuming
that the database data files do not grow at a great rate.
Really Using the FRA
In the real world, it's hard to get things right the first time. Using the FRA is no exception.
One of us had a client that had a few problems when they first switched to using the FRA.
The databases were not set up correctly, so the FRA would fill up.
Over time, the FRA became more stable as we understood the load profile and its relation-
ship to the creation of archived redo logs and backups. We eventually found the sweet spot
with respect to how much disk space we needed to allocate to the FRA. This is actually a
good thing because it forced the client to realize that understanding the disk-usage profile
of their databases was important.
Monitoring of the FRA is another real-world issue to be aware of. Many companies that
are using the FRA are investing some time in scripts to monitor FRA disk-space usage.
OEM can be used for this too.
The FRA does require some care and feeding by the DBA, however, particularly at first.
Sometimes it's hard to properly estimate the correct setting for the DB_RECOVERY_FILE_
DEST_SIZE and you will find the FRA filling up. Archived redo logs are stored in the FRA,
so if the FRA fills up, archived redo logs can no longer be written.
If this occurs, Oracle will first try to free space in the FRA by removing obsolete backups.
If Oracle cannot free up enough space, then eventually the inability to archive will cause the
database to freeze until the out-of-space condition can be rectified. In this case, you can free
up space by changing DB_RECOVERY_FILE_DEST_SIZE to a higher value. This parameter is
dynamic, so the change can be made immediately.
You can use the V$DB_RECOVERY_FILE_DEST view to determine the state of the FRA. In
the following example, we find that the FRA is sized to 2GB and that we have used 251MB
in total. We also see that 41MB of that space is reclaimable. In short, this FRA looks pretty
good at this point.
SQL> select name, space_limit, space_used, space_reclaimable
2 from v$recovery_file_dest;
Search WWH ::




Custom Search