While the flash recovery area is largely self-managing, there are some situations in which DBA intervention may be required.
You have a number of choices on how to resolve a full flash recovery area when there are no files eligible for deletion:
Make more disk space available, and increase DB_RECOVERY_FILE_DEST_SIZE
to reflect the new space.
Move backups from the flash recovery area to a tertiary device such as tape. One convenient way to back up all of your flash recovery area files to tape at once is the BACKUP
RECOVERY
AREA
command.
After you transfer backups from the flash recovery area to tape, you can resolve the full recovery area condition by deleting files from the flash recovery area, using forms of the RMAN DELETE
command.
Note:
Flashback logs, by design, cannot be backed up outside the flash recovery area. Therefore, in aBACKUP
RECOVERY
AREA
operation the flashback logs are not backed up to tape.
Flashback logs are deleted automatically to satisfy the need for space for other files in the flash recovery area. However, a guaranteed restore point can force the retention of flashback logs required to perform Flashback Database to the restore point SCN. See
Delete unnecessary files from the flash recovery area using the RMAN DELETE
command. (Note that if you use host operating system commands to delete files, then the database will not be aware of the resulting free space. You can run the RMAN CROSSCHECK
command to have RMAN re-check the contents of the flash recovery area and identify expired files, and then use the DELETE EXPIRED
command to remove missing files from the RMAN repository.)
You may also need to consider changing your backup retention policy and, if using Data Guard, consider changing your archivelog deletion policy.
See Also:
Chapter 4, "Backing Up Databases Using RMAN" for more on how to decide on a retention policy, and Oracle Data Guard Concepts and Administration for more on archivelog deletion policy with Data GuardIf you need to move the flash recovery area of your database to a new location, you can follow this procedure:
Invoke SQL*Plus to change the DB_RECOVERY_FILE_DEST
initialization parameter. For example:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
After you change this parameter, all new flash recovery area files will be created in the new location.
The permanent files (control files and online redo log files), flashback logs and transient files can be left in the old flash recovery area location. The database will delete the transient files from the old flash recovery area location as they become eligible for deletion.
If you need to actually move your current permanent files, transient files, or flashback logs to the new flash recovery area, see Oracle Database Backup and Recovery Advanced User's Guide . The process outlined there for moving database files into and out of an ASM disk group with RMAN will also work when moving files into and out of a flash recovery area location.
Oracle will clean up transient files remaining in the old flash recovery area location as they become eligible for deletion.
As a rule, the flash recovery area is self-maintaing, but when an instance crashes during the creation of a file in the flash recovery area, Oracle may leave the file in the flash recovery area. When this occurs, you will see the following error in the alert log:
ORA-19816: WARNING: Files may exist in location that are not known to database.
where location
is the location of the flash recovery area.
In such a situation, you should use the RMAN command CATALOG RECOVERY AREA
to re-catalog any such files so that they appear in the RMAN repository. If the file header of the file in question is corrupted, then you will have to delete the file manually using an operating system-level utility.