Oracle recommends that you multiplex the online redo log. The loss of log files can be catastrophic if recovery is required. When you multiplex the online redo log, the database must increase the amount of I/O it performs. Depending on your system, this additional I/O may impact overall database performance.
To archive to multiple destinations, you can choose to archive to two or more locations using theLOG_ARCHIVE_DEST_n initialization parameters, or to archive only to a primary and secondary destination using theLOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters.
If you configure a Fast Recovery Area (by setting the DB_RECOVERY_FILE_DEST andDB_RECOVERY_FILE_DEST_SIZEparameters) and do not specify any local archive destinations, the database automatically selects the Fast Recovery Area as a local archive destination and setsLOG_ARCHIVE_DEST_1 to USE_DB_RECOVERY_FILE_DEST.
如果指定了 快速恢复区（Fast Recovery Area），并且没有指定任何本地归档路径时。oracle将默认快速恢复区作为归档路径。
You must ensure that there is sufficient disk space at all times for archive log destinations. If the database encounters a disk full error as it attempts to archive a log file, a fatal error occurs and the database stops responding. You can check the alert log for a disk full message.
Use of the fast recovery area is strongly recommended. Consider configuring a fast recovery area as a first step in implementing a backup strategy
You enable the fast recovery area by setting two initialization parameters.
These parameters enable the fast recovery area without having to shut down and restart the database instance.
启用fast recovery area只需启用以下2个参数就OK了！不用重启instance
You set the size of the fast recovery area with the parameter DB_RECOVERY_FILE_DEST_SIZE first,
and then you set the physical location of the flash recovery files with the parameterDB_RECOVERY_FILE_DEST.
The larger the fast recovery area is, the more useful it becomes. Ideally, the fast recovery area should be large enough to contain the files listed in Table 5-2. The recovery area should be able to contain a copy of all datafiles in the database and the incremental backups used by your chosen backup strategy.
If providing this much space is impractical, then it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet on tape. At an absolute minimum, the fast recovery area must be large enough to contain the archived redo logs not yet on tape. If the recovery area has insufficient space to store new flashback logs and meet other backup retention requirements, then to make room, the recovery area may delete older flashback logs.
Formulas for estimating a useful fast recovery area size depend on whether:
Your database has a small or large number of data blocks that change frequently
You store backups only on disk, or on disk and tape
You use a redundancy-based backup retention policy, or a recovery window-based retention policy
You plan to use Flashback Database or a guaranteed restore point as alternatives to point-in-time recovery in response to logical errors
If you plan to enable flashback logging, then the volume of flashback log generation is approximately the same order of magnitude as redo log generation. For example, if you intend to set DB_FLASHBACK_RETENTION_TARGETto 24 hours, and if the database generates 20 gigabytes of redo in a day, then a general rule of thumb is to allow 20 GB to 30 GB of disk space for the flashback logs. The same rule applies to guaranteed restore points when flashback logging is enabled. For example, if the database generates 20 GB of redo every day, and if the guaranteed restore point is kept for a day, then plan to allocate 20 to 30 GB.
Suppose that you want to determine the size of a fast recovery area when the backup retention policy is set toREDUNDANCY 1 and you intend to follow Oracle's suggested strategy of using an incrementally updated backup. In this example, you use the following formula to estimate the disk quota, where n is the interval in days between incremental updates and y is the delay in applying the foreign archived redo logs on a logical standby database:
Disk Quota =
Size of a copy of database +
Size of an incremental backup +
Size of (n+1) days of archived redo logs +
Size of (y+1) days of foreign archived redo logs (for logical standby) +
Size of control file +
Size of an online redo log member * number of log groups +
Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)
看起太复杂了 。我采用的方法是 先大楷估计oracle的数据量，合理分配一个大小。以后每天检查一次快速恢复区的大小；
SELECT * FROM V$RECOVERY_FILE_DEST; 查看快速恢复区大小
SELECT * FROM V$RECOVERY_AREA_USAGE; 查看有那些文件