Using the FRA for ArchiveLogs ?
26741Jun 2 2009 — edited Jun 15 2009With 10g you can setup a Flash Recovery Area, defined by "db_recovery_file_dest".
If you do not specify a log_archive_dest, then Oracle default to "USE_DB_RECOVERY_FILE_DEST" for the ArchiveLogs.
Reading some posts here, it seems that many sites / DBAs use this default.
I would ask you to consider :
a. Is your FRA created on storage / LUNs with the same "quality" as the database ? The Database may be on RAID 1+0 (or RAID 5, baarf). BUT your Data Centre / Storage might have created the FRA on RAID 0 or on a "Tier-2" Storage (aka "cheaper disks"). Do you want your ArchiveLogs to go to such storage ?
Some sites may use the logic "the database is protected by the best storage parameters, the backups created on FRA don't necessarily need the same level of storage support, so we can put the backups on cheaper storage". Think particularly about FRAs that are larger than the Database itself and the storage cost involved.
Pre-10g, we used to put ArchiveLogs on "good" storage, on seperate mount points (ie, LUNs) from the Database and from the Online Redo Logs. If we lost the database or had corruption in the database and needed to restore we would restore the database from the last backup (whether the backup was on disk or on tape) and "replay" the archivelogs available on disk {which hadn't been backed up last night}. If we lost the Disk Backup Area, we wouldn't lose our ArchiveLogs.
If you now put your ArchiveLogs in the Disk Backup Area -- call it "db_recovery_file_dest" OR Flash Recovery Area -- confirm with your Storage admin the level of "support" (ie protection against disk failure) it has.
You wouldn't want to lose ArchiveLogs and/or the ability to write to your ArchiveLog Destination in the scenario that the Disk Backup Area was lost but the Database and the Online Redo Logs were still working !
b. With USE_DB_RECOVERY_FILE_DEST alone, you lose the ability to Archive to a secondary archivelog destination. If you used log_archive_dest_N , you could write your ArchiveLogs to multiple destinations. There are sound reasons (other than Standby Database implementations) for having multiple log archive destinations.
Note : MetaLink Note#297397.1 would be useful.
c. If the FRA is "100% full" and RMAN doesn't auto-delete files because all files are still required, as defined by the Retention policy (unless you've also configured an archive log deletion policy), your database comes to a halt. Such a situation would also occur with a "normal" log_archive_dest. But it is easier to use "OS" methods to cleanup a "normal" log_archive_dest. I see from forums postings that some DBAs are unable to cleanup the FRA. (they don't know that they also have to use CROSSCHECK and DELETE EXPIRED for the archivelogs manually deleted using "OS" commands and lose time trying to figure this out).
Request for Comments, please.
Hemant K Chitale
http://hemantoracledba.blogspot.com
Edited by: Hemant K Chitale on Jun 3, 2009 11:58 AM
Added reference to ML Note#297397.1 for scenario b so that we don't use "USE_DB_RECOVERY_FILE_DEST" alone.