Best practice: managing FRA

Question

I was not sure this was the most appropriate forum for this question; if not, please feel free to make an alternative suggestion.
For those of us who run multiple databases on a box with shared disk for FRA, I am finding the extra layer of ASM and db_recovery_file_dest_size to be a minor inconvenience. The Best Practice white papers I have found so far say that you should use db_recovery_file_dest_size, but they do not specify how you should set it. Currently, we have been setting db_recovery_file_dest_size rather small, as the databases so far are small and even at 3x the database size, the parameter is still significantly smaller than the total disk available in that diskgroup.
So, my question; is there any downside to setting db_recovery_file_dest_size equal to the total size of the FRA diskgroup for all databases? Obviously, this means that the amount of free space in the diskgroup may be consumed even if db_recovery_file_dest_size is not yet full (as reflected in the instance V$RECOVERY_FILE_DEST). But is that really a big deal at all? Can we not simply monitor the FRA diskgroup, which we have to do anyway? This eliminates the need to worry about an additional level of disk management. I like to keep things simple.
The question is relevant to folks using other forms of volume management (yes, I know, ASM is "not a volume manager"), but seems germane to the ASM forum because most articles and DBAs that I have talked to are using ASM for FRA.
Most importantly, what ramifications does "over-sizing" db_recovery_file_dest_size have? Aside from the scenario above.
TIA

Answer 1

As a general rule, the larger the flash recovery area(db_recovery_file_dest_size ), the more useful it becomes. Ideally, the flash recovery area should be large enough to hold a copy of all of your datafiles and control files, the online redo logs, and the archived redo log files needed to recover your database using the datafile backups kept under your retention policy.
Setting the size of DB_FILE_RECOVERY_DEST_SIZE must be based on following factors.
1) your falshback retention target,
2) what all files you are storing in flashback and
3) if that inclueds backup then the retention policy for them or how often you move them to tape
The bigger the flash recovery area, the more useful it becomes. Setting it much larger or equal to you FRA disk group does not cause any [b]overhead that is not known to Oracle.
But there are reasons why Oracle lets you define a disk limit, which is the amount of space that Oracle can use in the flash recovery area out of your FRA disk group.
1) A disk limit lets you use the remaining disk space for other purposes and not to dedicate a complete disk for the flash recovery area.
2)Oracle does not delete eligible files from the Flash Recovery Area until the
space must be reclaimed for some other purpose. So even though your database size is 5GB your restention target is very small but if your recovery_dest_size is much larger it will just keep filling.
3)Say in my case I have one FRA disk group of 150GB shared by 3 different databases. Based on the nature and criticaly of the database I have different size requirement of flashback recovery area for these databases. So I use varrying db_file_recovery dest_size (30GB, 50GB,70GB) respectively for meeting my retention target or the kind of files and backup I want to store them in FRA for these databases.
Oracle Internal Space management mehcanism for Falshback recovery area itself is designed in such way that if you define your db_recovery_file_dest_size and DB_FLASHBACK_RETENTION_TARGET at a optimal value, you wont need any further administration or management. If a Flash Recovery Area is configured, then the database uses an internal algorithm to delete files from the Flash Recovery Area that are no longer needed because they are redundant, orphaned, and so forth. The backups with status OBSOLETE form a subset of the files deemed eligible for deletion by the disk quota rules. When space is required in the Flash Recovery Area, then the following files are deleted:
a) Any backups which have become obsolete as per the retention policy.
b) Any files in the Flash Recovery Area which has been already backed up
to a tertiary device such as tape.
c) Flashback logs may be deleted from the Flash Recovery Area to make space available for other required files.
NOTE: If your FRA is 100GB and 3 databases have thier DB_RECOVERY_FILE_DEST set FRA then logically the total of db_recovery_file_dest_size for these 3 databases should not exceed 100GB. Even though practically it allows you to cross this limit.
Hope this helps.