闪回恢复区（Fast Recovery Area，FRA）是一块可选的磁盘位置，可以用来存储与恢复相关的文件，例如控制文件和联机重做日志副本、归档重做日志文件、闪回日志和RMAN备份。Oracle数据库和RMAN自动管理快速恢复区域中的文件。可以指定磁盘配额（由参数DB_RECOVERY_FILE_DEST_SIZE决定），这是FRA区域的最大大小。Fast Recovery Area之前称为Flash Recovery Area，也可称为快速恢复区。
（一）创建快速恢复区
使用快速恢复区需要设置两个初始化参数，DB_RECOVERY_FILE_DEST和DB_RECOVERY_FILE_DEST_SIZE。DB_RECOVERY_FILE_DEST指定了快速恢复区的位置，这个位置可以指向磁盘，也可以指向ASM磁盘组；DB_RECOVERY_FILE_DEST_SIZE参数定义了快速恢复区的大小。在RAC环境下配置快速恢复区时，要保证每个节点的配置值都相同。这两个参数可以在数据库运行过程中在线修改，修改后立即就能生效，比如以下例子：
SQL> alter system set db_recovery_file_dest_size='2G' scope=both sid='*';
System altered.
SQL> alter system set db_recovery_file_dest='+fra' scope=both sid='*';
System altered.
注意1：如果使用ASM作为Fast Recovery Area时，只能指定到Diskgroup级别，而不能成某个目录。比如下面这个例子演示了这个错误：
SQL> alter system set db_recovery_file_dest='+fra/test' scope=both sid='*';
alter system set db_recovery_file_dest='+fra/test' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: 无法修改参数, 因为指定的值无效
ORA-01261: 无法转换参数 db_recovery_file_dest 的目标字符串
注意2：在配置Fast Recovery Area时，需要先设置参数DB_RECOVERY_FILE_DEST_SIZE，然后再设置参数DB_RECOVERY_FILE_DEST，否则会报错，如下：
SQL> alter system set db_recovery_file_dest='+fra' scope=both sid='*';
alter system set db_recovery_file_dest='+fra' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: 无法修改参数, 因为指定的值无效
ORA-19802: 无法使用 DB_RECOVERY_FILE_DEST, 由于缺少 DB_RECOVERY_FILE_DEST_SIZE
（二）快速恢复区的监控
配置快速恢复区时，需要定义区域空间大小，也就是必须配置参数DB_RECOVERY_FILE_DEST_SIZE。这个参数值确定了快速恢复区能使用的存储空间上限。
如果定义了备份保留策略，Oracle会根据策略判断哪些文件过期（obsolete）进而删除，但只有在定义了备份保留策略时，Oracle才会自动判断和删除。当快速恢复区空间使用率达到90%时，会触发自动删除。删除过程会在alert文件中记录日志，但是如果没有空间可以释放，并且使用空间超过85%，就会记录一个warning日志；如果超过了97%，会记录一条critical warning日志，这些日志内容可以从dba_outstanding_alerts视图中看到。如果FRA满了，那么会导致所有需要FRA空间的会话hang住，例如切换归档的会话。
因此日常工作中需要监控快速恢复区的使用情况，在需要时及时进行调整。可以通过视图V$RECOVERY_FILE_DEST和V$RECOVERY_AREA_USAGE来监控快速恢复区的使用情况。
通过视图V$RECOVERY_FILE_DEST可以查询闪回空间的使用情况，其SQL如下所示：
SELECT NAME,
TRUNC(SPACE_LIMIT/1024/1024/1024, 3) LIMIT_GB,
TRUNC(SPACE_USED/1024/1024/1024, 3) USED_GB,
TRUNC(SPACE_USED / SPACE_LIMIT, 3) "USED%",
TRUNC(SPACE_RECLAIMABLE, 3) RECLAIM,
NUMBER_OF_FILES
FROM V$RECOVERY_FILE_DEST V
WHERE V.SPACE_LIMIT <> 0;
以上SQL语句可能的查询结果如下所示：
若想查询详细使用情况，可以执行如下的SQL语句：
SELECT NVL(FRAU.FILE_TYPE, 'Total:') FILE_TYPE,
SUM(ROUND(FRAU.PERCENT_SPACE_USED / 100 * RFD.SPACE_LIMIT / 1024 / 1024 / 1024,3)) USED_GB,
SUM(FRAU.PERCENT_SPACE_USED) PERCENT_SPACE_USED,
SUM(FRAU.PERCENT_SPACE_RECLAIMABLE) PERCENT_SPACE_RECLAIMABLE,
SUM(ROUND(FRAU.PERCENT_SPACE_RECLAIMABLE / 100 * RFD.SPACE_LIMIT / 1024 / 1024 / 1024,3)) RECLAIM_GB,
SUM(FRAU.NUMBER_OF_FILES) NUMBER_OF_FILES
FROM V$FLASH_RECOVERY_AREA_USAGE FRAU, V$RECOVERY_FILE_DEST RFD
GROUP BY ROLLUP(FILE_TYPE);
以上SQL语句可能的查询结果如下所示：
fast recovery area
An optional disk location that you can use to store recovery-related files such as control file and online redo log copies, archived redo log files, flashback logs, and RMAN backups. Oracle Database and RMAN manage the files in the fast recovery area automatically. You can specify the disk quota, which is the maximum size of the fast recovery area. Formerly referred to as flash recovery area.
闪回恢复区（Fast Recovery Area，FRA）是一块可选的磁盘位置，可以用来存储与恢复相关的文件，例如控制文件和联机重做日志副本、归档重做日志文件、闪回日志和RMAN备份。Oracle数据库和RMAN自动管理快速恢复区域中的文件。可以指定磁盘配额（由参数DB_RECOVERY_FILE_DEST_SIZE决定），这是FRA区域的最大大小。Fast Recovery Area之前称为Flash Recovery Area，也可称为快速恢复区。
The components that create different backup and recovery-related files have no knowledge of each other or of the size of the file systems where they store their data. With automatic disk-based backup and recovery, you can create a fast recovery area (also called the recovery area), which automates management of backup-related files.
A fast recovery area minimizes the need to manually manage disk space for backup-related files and balance the use of space among the different types of files. In this way, a fast recovery area simplifies the ongoing administration of your database. Oracle recommends that you enable a recovery area to simplify backup management.
When you create a recovery area, you choose a location on disk and set an upper bound for storage space. You also set a backup retention policy that governs how long backup files are needed for recovery. The database manages the storage used for backups, archived redo logs, and other recovery-related files for the database within this space. Files no longer needed are eligible for deletion when RMAN must reclaim space for new files.
Configuring the Fast Recovery Area
As explained in "Fast Recovery Area", the fast recovery area feature enables you to set up a disk area where the database can create and manage a variety of files related to backup and recovery. Use of the fast recovery area is strongly recommended. Consider configuring a fast recovery area as a first step in implementing a backup strategy.
This section outlines the functions of the fast recovery area, identifies the files stored there, explains the rules for file management, and introduces the most important configuration options. This section contains the following topics:
-
Overview of the Fast Recovery Area
-
Enabling the Fast Recovery Area
-
Disabling the Fast Recovery Area
-
Configuring Locations for Control Files and Redo Logs
-
Configuring RMAN File Creation in the Fast Recovery Area
See Also:
"Maintaining the Fast Recovery Area"
Overview of the Fast Recovery Area
The fast recovery area can contain control files, online redo logs, archived redo logs, flashback logs, and RMAN backups. Files in the recovery area are permanent or transient. Permanent files are active files used by the database instance. All files that are not permanent are transient. In general, Oracle Database eventually deletes transient files after they become obsolete under the backup retention policy or have been backed up to tape.
The fast recovery area is an Oracle Database managed space that can be used to hold RMAN disk backups, control file autobackups and archived redo log files. The files placed in this location are maintained by Oracle Database and the generated file names are maintained in Oracle Managed Files (OMF) format.
Table 5-2 describes the files in the recovery area, the classification of each file as permanent or temporary, and how database availability is affected.
Table 5-2 Files in the Fast Recovery Area
| Files | Type | Database Behavior When Fast Recovery Area Is Inaccessible |
|---|---|---|
|
Multiplexed copies of the current control file |
Permanent |
The instance fails if the database cannot write to a multiplexed copy of the control file stored in the fast recovery area. Failure occurs even if accessible multiplexed copies are located outside the recovery area. See Also: "Configuring Control File Locations" to learn how to configure control files in the recovery area |
|
Online redo log files |
Permanent |
Instance availability is not affected if a mirrored copy of the online redo log exists in an accessible location outside the fast recovery area. Otherwise, the instance fails. See Also: "Configuring Online Redo Log Locations" to learn how to configure online redo logs in the recovery area |
|
Archived redo log files |
Transient |
Instance availability is not affected if the log is archived to an accessible location outside the fast recovery area. Otherwise, the database eventually halts because it cannot archive the online redo logs. See Also: "Configuring Archived Redo Log Locations" to learn how to configure archived redo logs in the recovery area |
|
Foreign archived redo log files |
Transient |
Instance availability is not affected. Note: 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. |
|
Image copies of data files and control files |
Transient |
Instance availability is not affected. |
|
Backup pieces |
Transient |
Instance availability is not affected. |
|
Flashback logs |
Transient |
Instance availability is not affected if guaranteed restore points are not defined. In this case, 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. The Oracle Flashback Database feature, which provides a convenient alternative to database point-in-time recovery (DBPITR), generates flashback logs. These logs are transient files and must be stored in the fast recovery area. Unlike other transient files, flashback logs cannot be backed up to other media. 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. See Also: "Enabling Flashback Database" to learn how to enable flashback logging |
If you are on a Windows platform, then you can use the Volume Shadow Copy Service (VSS) with the Oracle VSS writer. In this case, the fast recovery area automates management of files that are backed up in a VSS snapshot and deletes them as needed.
See Also:
-
Chapter 18, "Performing Flashback and Database Point-in-Time Recovery"
-
Oracle Database Platform Guide for Microsoft Windows to learn about making backups in a VSS environment
Oracle Managed Files and Automatic Storage Management
The fast recovery area can be used with Oracle Managed Files (OMF) and Automatic Storage Management (ASM). Because the fast recovery area is built on top of OMF, so it can be stored anywhere that Oracle Managed Files can. You can also use the recovery area with ASM.
Even if you choose not to set up the fast recovery area in ASM storage, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. However, you lose a major benefit of the fast recovery area: the automatic deletion of files no longer needed to meet your recoverability goals as space is needed for more recent backups. Nevertheless, the other automatic features of OMF still function.
When your store backups, using OMF on top of ASM without using a fast recovery area is supported but discouraged. It is awkward to directly manipulate files under ASM.
How Oracle Manages Disk Space in the Fast Recovery Area
Space in the fast recovery area is balanced among backups and archived logs that must be kept according to the retention policy, and other files that may be subject to deletion. Oracle Database does not delete eligible files from the fast recovery area until the space must be reclaimed for some other purpose. Files recently moved to tape are often still available on disk for use in recovery. The recovery area can thus serve as a cache for tape. When the fast recovery area is full, Oracle Database automatically deletes eligible files to reclaim space in the recovery area as needed.
See Also:
"Deletion Rules for the Fast Recovery Area" and "Responding to a Full Fast Recovery Area"
Enabling the Fast Recovery Area
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.
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.
Table 5-3 discusses both the mandatory and optional parameters for enabling the fast recovery area.
In an Oracle Real Application Clusters (Oracle RAC) database, all instances must have the same values for these initialization parameters. The location must be on a cluster file system, ASM, or a shared directory.
Table 5-3 Initialization Parameters for the Fast Recovery Area
| Initialization Parameter | Required | Description |
|---|---|---|
|
DB_RECOVERY_FILE_DEST_SIZE |
Yes |
Specifies the disk quota, which is maximum storage in bytes of data to be used by the recovery area for this database. You must set this parameter before DB_RECOVERY_FILE_DEST. The DB_RECOVERY_FILE_DEST_SIZE setting does not include the following kinds of disk overhead:
|
|
DB_RECOVERY_FILE_DEST |
Yes |
Specifies the recovery area location, which can be a file system directory or ASM disk group, but not a raw disk. The location must be large enough for the disk quota. |
|
DB_FLASHBACK_RETENTION_TARGET |
No |
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. This parameter indirectly determines how much flashback log data is kept in the recovery area. The size of flashback logs generated by the database can vary considerably depending on the database workload. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval. |
See Also:
Oracle Database SQL Language Reference for ALTER SYSTEM syntax, and Oracle Database Administrator's Guide for details on setting and changing database initialization parameters
Considerations When Setting the Size of the Fast Recovery Area
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 data files 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)
Considerations When Setting the Location of the Fast Recovery Area
Place the fast recovery area on a separate disk from the database area, where the database maintains active database files such as data files, control files, and online redo logs. Keeping the fast recovery area on the same disk as the database area exposes you to loss of both your live database files and backups if a media failure occurs.
Oracle recommends that DB_RECOVERY_FILE_DEST be set to a different value from DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n initialization parameters. The database writes a warning to the alert log if DB_RECOVERY_FILE_DEST equals these parameters.
Multiple databases can have the same value for DB_RECOVERY_FILE_DEST, but one of the following must be true:
-
No two databases for which the DB_UNIQUE_NAME initialization parameters are specified have the same value for DB_UNIQUE_NAME.
-
For those databases where no DB_UNIQUE_NAME is provided, no two databases have the same value for DB_NAME.
When databases share a single recovery area in this way, the location should be large enough to hold the files for all databases. Add the values for DB_RECOVERY_FILE_DEST_SIZE for the databases, then allow for overhead such as mirroring or compression.
Setting the Fast Recovery Area Location and Initial Size
Table 5-3 lists the initialization parameters that you must set to enable the fast recovery area. This section explains how to specify a location for the recovery area and set its initial size.
To determine the optimum size for the fast recovery area:
-
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.
-
Set the recovery area size.
If you plan to use flashback logging or guaranteed restore points, then ensure that the size value obtained from Step 1 is incorporated into the setting. Set the DB_RECOVERY_FILE_DEST_SIZE initialization parameter by any of the following means:
-
Shut down the database and set the DB_RECOVERY_FILE_DEST_SIZE parameter in the initialization parameter file of the database, as shown in the following example:
DB_RECOVERY_FILE_DEST_SIZE = 10G
-
Specify the parameter with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following examples:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*';
-
Use the Database Configuration Assistant to set the size.
Set the recovery area location.
Set the initialization parameters by any of the following means:
If you do not plan to use flashback logging, then open the database (if it is closed) and do not complete the rest of the steps in this procedure.
-
Set DB_RECOVERY_FILE_DEST in the initialization parameter file of the database, as shown in the following example:
DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'
-
Specify DB_RECOVERY_FILE_DEST with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following example:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
-
Use the Database Configuration Assistant to set the location.
If flashback logging is enabled, then run the database under a normal workload for the time period specified by DB_FLASHBACK_RETENTION_TARGET.
In this way, the database can generate a representative sample of flashback logs.
Query the V$FLASHBACK_DATABASE_LOG view as follows:
SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;
The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled.
If necessary, adjust the flashback log space requirement based on the actual size of flashback logs generated during the time period specified by DB_FLASHBACK_RETENTION_TARGET.
See Also:
"Managing Space for Flashback Logs in the Fast Recovery Area"
Disabling the Fast Recovery Area
If you have enabled Flashback Database or use the fast recovery area for archive logs, then take the appropriate steps from those that follow below. Otherwise, skip to Step 3:
-
If Flashback Database is enabled, then disable it before you disable the fast recovery area.
ALTER DATABASE FLASHBACK OFF;
-
If you are using the fast recovery area for archive logs, then set the initialization parameter LOG_ARCHIVE_DEST_n to use a non-fast recovery area location.
For example, to change the fast recovery area for LOG_ARCHIVE_DEST_1 to a non-fast recovery area location, use the command ALTER SYSTEM SET:
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/ORACLE/DBS/';
-
Disable the fast recovery area initialization parameter.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='';
Configuring Locations for Control Files and Redo Logs
As explained in "Overview of the Fast Recovery Area", the only permanent files are multiplexed copies of the current control file and online redo logs. This section explains how to set locations for these files and the archived logs.
Configuring Online Redo Log Locations
The initialization parameters that determine where online redo log files are created are DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST. Details of the effect of combinations of these parameters on online redo log creation can be found in Oracle Database SQL Language Reference in the description of the LOGFILE clause of the CREATE DATABASE statement.
The following SQL statements can create online redo logs in the fast recovery area:
-
CREATE DATABASE
-
ALTER DATABASE ADD LOGFILE
-
ALTER DATABASE ADD STANDBY LOGFILE
-
ALTER DATABASE OPEN RESETLOGS
The default size of an online log created in the fast recovery area is 100 megabytes. The log member file names are automatically generated by the database.
Configuring Control File Locations
The initialization parameters CONTROL_FILES, DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST all interact to determine the location where the database control files are created. For a full description of how these parameters interact, see the "Semantics" section of the description of CREATE CONTROLFILE in Oracle Database SQL Language Reference.
If the database creates an Oracle managed control file, and if the database uses a server parameter file, then the database sets the CONTROL_FILES initialization parameter in the server parameter file. If the database uses a client-side initialization parameter file, then you must set the CONTROL_FILES initialization parameter manually in the initialization parameter file.
Configuring Archived Redo Log Locations
Oracle recommends that you the use fast recovery area as an archiving location because the archived logs are automatically managed by the database. The generated file names for the archived logs in the fast recovery area are for Oracle Managed files and are not determined by the parameter LOG_ARCHIVE_FORMAT. Whatever archiving scheme you choose, it is always advisable to create multiple copies of archived redo logs.
You have the following basic options for archiving redo logs, listed from most to least recommended:
-
Enable archiving to the fast recovery area only and use disk mirroring to create the redundancy needed to protect the archived redo logs.
If DB_RECOVERY_FILE_DEST is specified and no LOG_ARCHIVE_DEST_n is specified, then LOG_ARCHIVE_DEST_10 is implicitly set to the recovery area. You can override this behavior by setting LOG_ARCHIVE_DEST_10 to an empty string.
-
Enable archiving to the fast recovery area and set other LOG_ARCHIVE_DEST_n initialization parameter to locations outside the fast recovery area.
If a fast recovery area is configured, then you can add the fast recovery area as an archiving destination by setting any LOG_ARCHIVE_DEST_n parameter to LOCATION=USE_DB_RECOVERY_FILE_DEST.
-
Set LOG_ARCHIVE_DEST_n initialization parameters to archive only to non-fast recovery area locations.
If you use the fast recovery area, then you cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters. Using either of these parameters prevents you from starting the instance. Instead, set the LOG_ARCHIVE_DEST_n parameters. After your database is using LOG_ARCHIVE_DEST_n, you can configure a recovery area.
Note also that if you enable archiving but do not set any value for LOG_ARCHIVE_DEST, LOG_ARCHIVE_DEST_n, or DB_RECOVERY_FILE_DEST, then the redo logs are archived to a default location that is platform-specific. For example, on Solaris the default is ?/dbs.
See Also:
Oracle Database Reference for details on the semantics of the LOG_ARCHIVE_DEST_ n parameters
Configuring RMAN File Creation in the Fast Recovery Area
This section describes RMAN commands or implicit actions (such as control file autobackups) that can create files in the fast recovery area, and explains how to control whether a command creates files there or in another destination. The commands are:
-
BACKUP
If you do not specify the FORMAT clause for disk backups, then RMAN creates backup pieces and image copies in the fast recovery area, with names in Oracle Managed Files name format. If a fast recovery area is enabled, and if you do specify FORMAT on BACKUP or a channel, then RMAN creates the backup in a platform-specific location rather than in the recovery area.
-
Control File Autobackup
RMAN can create control file autobackups in the fast recovery area. Use the RMAN command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR to clear any configured format option for the control file autobackup location on disk. RMAN creates control file autobackups in the fast recovery area when no other destination is configured.
-
RESTORE ARCHIVELOG
Explicitly or implicitly set a LOG_ARCHIVE_DEST_n parameter to LOCATION=USE_DB_RECOVERY_FILE_DEST. If you do not specify SET ARCHIVELOG DESTINATION to override this behavior, then RMAN restores archived redo log files to the fast recovery area.
-
RECOVER DATABASE or RECOVER TABLESPACE, RECOVER ... BLOCK, and FLASHBACK DATABASE
These commands restore archived redo log files from backup for use during media recovery, as required by the command. RMAN restores any redo log files needed during these operations to the fast recovery area and deletes them after they are applied during media recovery.
To direct the restored archived logs to the fast recovery area, set a LOG_ARCHIVE_DEST_n parameter to LOCATION = USE_DB_RECOVERY_FILE_DEST. Verify that you are not using SET ARCHIVELOG DESTINATION to direct restored logs to some other destination.
何为闪回恢复区
Oracle 10g 有一项新功能称为：自动的基于磁盘的备份与恢复( Automatic Disk-Based Backup and Recovery )。实现该功能的基础为本文要讲述的闪回恢复区( Flash Recovery Area )。闪回恢复区是 Oracle 10g 中的新事物。简单的说，闪回恢复区是一块用以存储恢复相关的文件的存储空间。允许用户集中存储所有恢复相关的文件。
闪回恢复区可以放在如下几种存储形式上：
- 目录
- 一个文件系统
- 自动存储管理(ASM)磁盘组
在 RAC 环境中,这个该位置必须为 集群文件系统 (cluster file system) 或是 ASM 磁盘组亦或是通过 NFS 控制的文件共享目录，还要注意的是，所有实例的位置和操作系统的磁盘限额 (disk quota) 必须一致。
如下几种文件可以放到闪回恢复区中：
- 控制文件
- 归档的日志文件(注：Oracle 手册上所说的在设定flash recovery area之后，LOG_ARCHIVE_DEST_10的值将自动设定为flash recovery area的位置，这个变化在笔者测试过程中观察不到)
- 闪回日志
- 控制文件和 SPFILE 自动备份
- RMAN 备份集
- 数据文件拷贝
为何要用闪回恢复区?
如前所述，闪回恢复区提供了一个集中化的存储区域，很大程度上减小了管理开销。这是其最主要的优点。与 RMAN 结合使用可以进行快速恢复。
近年来随着存储技术的发展，单个磁盘的存储能力已经加强。这使自动的基于磁盘的备份与恢复的技术实现成为可能。而闪回恢复区恰是基于磁盘的备份与恢复的基础。把闪回恢复区和OMF 与 ASM 结合运用看起来是比较完美的方案。当然，不可否认的是，自动备份恢复技术还远远不够成熟。
设定闪回恢复区
如果您使用DBCA创建的数据库，在安装时可以设定闪回恢复区的位置以及大小(点击这里查看安装截图)——这也是 Oracle 10g OUI 的新功能之一。如果在开始的时候没有启用闪回恢复区，可以通过如下方式设定。
调整如下两个动态初始化参数(无需重新启动实例)：
SQL> ALTER SYSTEM SET db_recovery_file_dest_size=2g SCOPE=BOTH; System altered. SQL> SQL> ALTER SYSTEM SET db_recovery_file_dest= '/u01/app/oracle/flash_recovery_area' 2 SCOPE=BOTH; System altered. SQL> |
之后查看所作的修改是否生效：
SQL> SHOW parameter db_recovery_file_dest NAME TYPE VALUE ----------------------- --------- --------------------------------- db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 2G SQL> |
如上所示，我们设定了闪回恢复区，位置在 /u01/app/oracle/flash_recovery_area，上限为2G。如果要撤销闪回恢复区，把初始化参数 DB_RECOVERY_FILE_DEST 的值清空即可。
注意: DB_RECOVERY_FILE_DEST_SIZE 只有在 DB_RECOVERY_FILE_DEST 清空之后才可以清空。
初始化参数 db_recovery_file_dest_size 的设定有一点点需要注意的地方：
- 文件的第0块和操作系统数据块头的空间大小不包含在内
- 该参数并不代表实际占用的空间大小。如果空间被压缩、镜像、RAID 的话，该参数的值意义是不一样的
管理并监控闪回恢复区
我们先看看闪回恢复区内的文架结构层次
SQL> host tree /u01/app/oracle/flash_recovery_area /u01/app/oracle/flash_recovery_area |-- DEMO | |-- archivelog | | |-- 2004_12_07 | | | |-- o1_mf_1_10_0vbwz2fm_.arc | | | |-- o1_mf_1_11_0vc1yj14_.arc | | | |-- o1_mf_1_12_0vc6vvws_.arc | | | |-- o1_mf_1_13_0vcbv6cg_.arc | | | |-- o1_mf_1_14_0vchlxb3_.arc | | | |-- o1_mf_1_15_0vcnBbz_.arc | | | |-- o1_mf_1_5_0vbk8goo_.arc | | | |-- o1_mf_1_6_0vbkq6dk_.arc | | | |-- o1_mf_1_7_0vbktl5f_.arc | | | |-- o1_mf_1_8_0vbo97xp_.arc | | | `-- o1_mf_1_9_0vbrrlo6_.arc | | `-- 2004_12_08 | | |-- o1_mf_1_16_0vcnyqvf_.arc | | |-- o1_mf_1_17_0vcp58bj_.arc | | |-- o1_mf_1_18_0vcv4qxb_.arc | | |-- o1_mf_1_19_0vczcsl0_.arc | | |-- o1_mf_1_20_0vd34svw_.arc | | |-- o1_mf_1_21_0vd7tg4h_.arc | | |-- o1_mf_1_22_0vddq7lc_.arc | | |-- o1_mf_1_23_0vdk0nbh_.arc | | |-- o1_mf_1_24_0vdojjky_.arc | | |-- o1_mf_1_25_0vdtg1rq_.arc | | |-- o1_mf_1_26_0vdz23B_.arc | | |-- o1_mf_1_27_0vf3nlnw_.arc | | |-- o1_mf_1_28_0vf6hon5_.arc | | |-- o1_mf_1_29_0vf867lt_.arc | | |-- o1_mf_1_30_0vf86pkg_.arc | | `-- o1_mf_1_31_0vfjphqm_.arc | `-- backupset | |-- 2004_12_07 | | |-- o1_mf_ncsn1_TAG20041207T150715_0vboq7kv_.bkp | | `-- o1_mf_nnnd1_TAG20041207T150715_0vboo3t2_.bkp | `-- 2004_12_08 | |-- o1_mf_ncsnf_TAG20041208T161219_0vffxv2n_.bkp | |-- o1_mf_ncsnf_TAG20041208T165456_0vfjcvgl_.bkp | `-- o1_mf_nnndf_TAG20041208T161219_0vffv40q_.bkp `-- tracking.dbf 7 directories, 33 files |
闪回恢复区中添加或删除文件等变化都将记录在数据库的 alert 日志中，Oracle 10g 也针对该新特性提供了一个新的视图， DBA_OUTSTANDING_ALERTS，通过该视图可以得到相关的信息。
DBA_OUTSTANDING_ALERTS 视图的存在体现了 Oracle 愈加人性化的一面。我们先来看一下该视图的基本结构，后面会用到。
SQL> DESC dba_outstanding_alerts Name Null? Type ------------------------------- ---------------------------- SEQUENCE_ID NUMBER REASON_ID NOT NULL NUMBER OWNER VARCHAR2(30) OBJECT_NAME VARCHAR2(513) SUBOBJECT_NAME VARCHAR2(30) OBJECT_TYPE VARCHAR2(64) REASON VARCHAR2(4000) TIME_SUGGESTED TIMESTAMP(6) WITH TIME ZONE CREATION_TIME TIMESTAMP(6) WITH TIME ZONE SUGGESTED_ACTION VARCHAR2(4000) ADVISOR_NAME VARCHAR2(30) METRIC_VALUE NUMBER MESSAGE_TYPE VARCHAR2(12) MESSAGE_GROUP VARCHAR2(64) MESSAGE_LEVEL NUMBER HOSTING_CLIENT_ID VARCHAR2(64) MODULE_ID VARCHAR2(64) PROCESS_ID VARCHAR2(128) HOST_ID VARCHAR2(256) HOST_NW_ADDR VARCHAR2(256) INSTANCE_NAME VARCHAR2(16) INSTANCE_NUMBER NUMBER USER_ID VARCHAR2(30) EXECUTION_CONTEXT_ID VARCHAR2(60) ERROR_INSTANCE_ID VARCHAR2(142) SQL> |
10g 的新视图 V$RECOVERY_FILE_DEST 包含闪回恢复区的相关信息：
SQL> desc V$RECOVERY_FILE_DEST Name Null? Type ------------------------------- ---------------------------- NAME VARCHAR2(513) SPACE_LIMIT NUMBER SPACE_USED NUMBER SPACE_RECLAIMABLE NUMBER NUMBER_OF_FILES NUMBER SQL> SELECT NAME, space_limit, space_used, space_reclaimable space_rec, 2 number_of_files file_num 3 FROM v$recovery_file_dest; NAME SPACE_LIMIT SPACE_USED SPACE_REC FILE_NUM --------------------------- ----------- ---------- ---------- ---------- /u01/app/oracle/flash_recovery_area 2147483648 1106849280 602410496 30 SQL> |
在一些 10g 的动态视图里( V$CONTROLFILE, V$LOGFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY 等 )的新的列 IS_RECOVERY_DEST_FILE ,指明相关的文件是否在恢复区内。
SQL> SELECT recid, blocks, is_recovery_dest_file 2 FROM v$archived_log 3 WHERE recid < 5; RECID BLOCKS IS_RECOVERY_DEST_FILE ---------- ---------- ----------------------------- 1 20072 YES 2 19566 YES 3 19566 YES 4 19566 YES SQL> |
闪回恢复区中文件的保持策略
- 持久文件从不会被删除。
- 通过RMAN 配置策略过期的文件会被删除。
- 已经拷贝到磁带上的临时性文件会被删除。
- 在 Data Guard 环境中，当已归档的重作日志文件可以从闪回恢复区中删除的时候，可以应用归档的重作日志删除策略进行自动删除(在恢复管理器中CONFIGURE ARCHIVELOG DELETION POLICY TO ......)
在闪回恢复区中的空间使用超过 85% 的时候，数据库将会向 alert 文件中写入告警信息。而当超过 97% 的时候将会写入严重告警信息。当闪回恢复区空间不够的时候，Oracle将报告如下类似的错误：
ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 52428800 bytes disk space from 1258291200 limit |
这个时候查询 dba_outstanding_alerts：
SQL> select reason,object_type, suggested_action from dba_outstanding_alerts; REASON OBJECT_TYPE SUGGESTED_ACTION ------------------------------ --------------- ------------------------------------- db_recovery_file_dest_size of RECOVERY AREA Add disk space and increase db_recovery_ 1258291200 bytes is 88.20% use file_dest_size, backup files to tertiary d and has 148509184 remaining device, delete files from recovery area bytes available. using RMAN, consider changing RMAN rete ntion policy or consider changing RMAN a rchivelog deletion policy. 1 rows selected. SQL> |
会给出相关的原因和建议的操作。
注意事项
自动化的东西总是给人不确定性。如果您在测试环境中启用了闪回恢复区，那么一定要注意监控空间的使用。在生产数据库上使用(如果有这样的人的话)，必须要把闪回恢复区放到单独的磁盘上。
