CONFIGURE CONTROFILE&FAST RECOVERY AREA

（一）Maintaining the Control File Repository

控制文件记录包括两类：可覆盖以及不可覆盖记录

The control file contains two types of records:

1. Circular reuse records contain noncritical information that is eligible to be overwritten if needed. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.

这部分使用顺序是当控制文件没空间时，优先覆盖超过CONTROL_FILE_RECORD_KEEP_TIME设置记录，仍无空间则扩展控制文件大小，如果无法扩展文件则覆盖最旧的Circular records，上面所有过程均会记录在alert log中

When the database must add new RMAN repository records to the control file, but no record is older than the threshold, the database attempts to expand the size of the control file. If the underlying operating system prevents the expansion of the control file (due to a disk full condition, for instance), then the database overwrites the oldest record in the control file.

1. Noncircular reuse records contain critical information that does not change often and cannot be overwritten. Some examples of information in noncircular reuse records include data files, online redo log files, and redo threads.

The best way to prevent the loss of RMAN metadata：

1. If you cannot use a recovery catalog, then you can take the following measures:

1. Set the CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file that you must keep. For example, if you back up the whole database once a week, then you must keep every backup for at least 7 days. Set CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14. The default value of CONTROL_FILE_RECORD_KEEP_TIME is 7 days.
2. Store the control file in a file system rather than on a raw device so that it can expand
3. Monitor the alert log to ensure that Oracle Database is not overwriting control file records. The alert log is located in the Automatic Diagnostic Repository (ADR).

1. If you use a fast recovery area, then follow these guidelines to avoid a situation in which the control file cannot hold a record of all fast recovery area files needed to satisfy the backup retention policy:

1. If the block size of the control file is not at its maximum, then use a larger block size, preferably 32 kilobytes. To achieve this aim, you must set the SYSTEM tablespace block size to be greater than or equal to the control file block size, and re-create the control file after changing DB_BLOCK_SIZE. The files in the fast recovery area are recataloged, but the records for files on tape are lost.
2. Make the files in the fast recovery area eligible for deletion by backing them up to tertiary storage such as tape.

For example, you can use BACKUP RECOVERY AREA to specifically back up files in the fast recovery area to a media manager.

1. If the backup retention policy is keeping backups and archived logs longer than your business requirements, then you can make more files in the fast recovery area eligible for deletion by changing the retention policy to a shorter recovery window or lower degree of redundancy.

（二）Maintaining the Fast Recovery Area

Fast Recovery Area可包含以下文件：(可通过参数设置指定，详见OMF文档说明)

1. Multiplexed copies of the current control file：Permanent
2. Online redo log files：Permanent
3. Archived redo log files：Transient
4. Foreign archived redo log files：Transient

Foreign archived redo logs are received by a logical standby database for a LogMiner session. Unlike a normal archived log, a foreign archived redo log is associated with a different DBID. For this reason, it cannot be backed up or restored on a logical standby database.

1. Image copies of data files and control files：Transient
2. Backup pieces：Transient
3. Flashback logs：Transient

1. Deletion Rules for the Fast Recovery Area

Fast Recovery Area内文件分为永久Permanent/临时Transient

临时文件只在空间不够时会由Oracle自动删除

RMAN uses certain rules to determine when files can be deleted from the fast recovery area.

The following rules govern when files become eligible for deletion from the recovery area:

1. Permanent files are never eligible for deletion.
2. Files that are obsolete under the retention policy are eligible for deletion.
3. Transient files that have been copied to tape are eligible for deletion.
4. Archived redo logs are not eligible for deletion until all the consumers of the logs have satisfied their requirements.

Consumers of logs can include RMAN, standby databases, Oracle Streams databases, and the Flashback Database feature.

1. Foreign archived logs that have been mined by a LogMiner session on a logical standby database are eligible for deletion. Because it is generated from a different database than the current database, a foreign archived redo log has a different DBID than the current archived redo logs.

在闪回区空间不够时将优先删除超RMAN retention的备份，再删除flashback logs。如果使用了保证还原点则不会删除对应SCN之后所有flashback logs

If the fast recovery area has insufficient space to store flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs.

if guaranteed restore points are not defined, the database automatically disables Flashback Database, writes a message to the alert log, and continues with database processing.

If guaranteed restore points are configured, the instance fails because of interdependencies on the flashback logs.

If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only.

2. PARAMETERS OF Fast Recovery Area

1) DB_RECOVERY_FILE_DEST_SIZE

要先于DB_RECOVERY_FILE_DEST设置，它的大小不包含各种磁盘消耗，所以设置时应将大小多设置需要数据量的10%

The DB_RECOVERY_FILE_DEST_SIZE setting does not include the following kinds of disk overhead:

1. Block 0 or the operating system block header of each Oracle Database file is not included.
2. Allow an extra 10% for this data when computing the actual disk usage required for the fast recovery area.

2) DB_RECOVERY_FILE_DEST

3) DB_FLASHBACK_RETENTION_TARGET

Specifies the upper limit (in minutes) on how far back in time the database may be flashed back.

This parameter is required only for Flashback Database.

If you plan to use flashback logging or guaranteed restore points, then query V$ARCHIVED_LOG to determine how much redo the database generates in the time to which you intend to set DB_FLASHBACK_RETENTION_TARGET.

1. Estimated Space

flashback log的大小可近似等于相同量产生redo log大小，如DB_FLASHBACK_RETENTION_TARGET设置为24H，数据库1天产生redo logs为20G

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.

下面假设备份冗余为1，使用增量备份，则通过以下公式计算：

n为增量备份的间隔时间，y为应用foreign archive redo logs的延时

n is the interval in days between incremental updates

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)

1. Monitoring Fast Recovery Area Space Usage

SELECT * FROM V$RECOVERY_FILE_DEST;

SELECT * FROM V$RECOVERY_AREA_USAGE;

SELECT * FROM V$RESTORE_POINT;

1. Responding to a Full Fast Recovery Area

闪回空间在还剩余15%及3%时会在alert log告警

The database issues a warning alert when reclaimable space is less than 15% and a critical alert when reclaimable space is less than 3%. To warn the DBA of this condition, an entry is added to the alert log and to the DBA_OUTSTANDING_ALERTS table (used by Enterprise Manager). Nevertheless, the database continues to consume space in the fast recovery area until there is no reclaimable space left.

You have several choices for how to resolve a full fast recovery area when no files are eligible for deletion:

1. Make more disk space available and increase DB_RECOVERY_FILE_DEST_SIZE to reflect the additional space.
2. Move backups from the fast recovery area to tertiary storage such as tape. 

One convenient way to back up all of your recovery area files to tape together is the BACKUP RECOVERY AREA command. After you transfer backups from the recovery area to tape, you can delete files from the fast recovery area. Flashback logs cannot be backed up outside the recovery area and are not backed up by BACKUP RECOVERY AREA.

1. Run DELETE for any files that have been removed with an operating system utility.
2. Ensure that your guaranteed restore points are necessary. If not, delete them.
3. Review your backup retention policy and, if using Data Guard, your archived redo log deletion policy.

1. Changing the Fast Recovery Area to a New Location

直接在OPEN状态更改DB_RECOVERY_FILE_DEST即可

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';

After you change this parameter, all new fast recovery area files are created in the new location.

Either leave or move the permanent files, flashback logs, and transient files in the old flash recovery location.

1. Disabling the Fast Recovery Area

Before disabling the fast recovery area, you must first drop all guaranteed restore points and then turn off Flashback Database.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';

The database no longer provides the space management features of the fast recovery area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files are still known to the RMAN repository, however, and available for backup and restore activities.