一：在制定rman備份策略前，需對redo日誌進行評估。本文按照官方文檔的建議進行設置：
文檔建議：
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.
oracle建議使用多個redolog（如圖中redo01a.log），保證redo的冗餘！，並將冗餘的redolog放在不同的磁盤上（圖中redo01a.log放在diakA中），以減少I/O開銷！
二：歸檔日誌的配置本文參考的是：
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.
oracle還是建議使用log_archive_dest_n來配置archivelog的放置路徑！而且還是遵循上的冗餘策略！
注意：
If you configure a Fast Recovery Area (by setting the DB_RECOVERY_FILE_DEST andDB_RECOVERY_FILE_DEST_SIZE parameters) 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.
要確保指定的歸檔路徑有足夠的空間來存放歸檔日誌。如果oracle在歸檔時發現空間不足的話，就會停止響應（掛起），在alter文件中會有提示磁盤不足的消息！
三：所以快速恢復區的大小需要dba進行估算後設置!
Use of the fast recovery area is strongly recommended. Consider configuring a fast recovery area as a first step in implementing a backup strategy
oracle強烈推薦使用快速恢復區。制定備份策略的第一步就是配置快速恢復區！
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 parameter
DB_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_TARGET to 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 to
REDUNDANCY 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; 查看有那些文件
在根據備份策略來合理的進行設置大小！
如：我現在的備份策略是 基於時間窗口30天的備份策略。週末0級增備，1,2,3差異增備，4累計增備，5，6差異增備！
沒開閃回數據庫，歸檔日誌在其他目錄下，redo也沒在快速恢復區中。
每天數據量改變不到5%。剛纔我做了個全備，佔用了1.5G快速恢復區大小。根據rman策略，設置大小爲：10G大小。