What is a Flash / Fast Recovery Area and how to configure it
The flash recovery area
is an Oracle-managed directory, file system, or Automatic Storage Management
disk group that provides a centralized disk location for backup and recovery
files. All the files which is needed for complete recovery of the database from
a media failure are part of the Flash Recovery Area. Oracle creates archived
logs and flashback logs in the flash recovery area. RMAN can store
its backup sets and image copies in the flash recovery area, and
it uses it when restoring files during media recovery. The flash recovery area
also acts as a disk cache for tape.
Flash recovery extends
the functionality of Oracle Managed Files to all recovery related files (backup
sets, image copies, and archived logs). Oracle Database automatically manages
this storage, deleting files that are no longer needed. The user specifies only
the location of a Flash Recovery Area, and the amount of disk space that Oracle
is allowed to use for recovery related files. This feature is integrated with
the 10G MMON feature, so that out of space conditions can be handled through
the standard Oracle monitoring framework.
Periodically copying
backups to tape frees space in the flash recovery area for other files. Oracle
recommends that enable a recovery area to simplify backup management.
The following
recovery-related files are stored in the flash recovery area:
v Current control file
v Online redo logs
v Archived redo logs
v Flashback logs
v Control file autobackups
v Datafile and control
file copies
v Backup pieces
v Foreign archived redo
log ( An archived redo log received by a logical standby database for a
LogMiner session.)
2. Why
should we use a Flash Recovery Area?
As disk storage media is
now competitive to tape with respect to purchase costs, disk-based backup is an
optimal and preferable storage mechanism. By using disks for storage purposes, we
gain significant benefits in terms of mass storage, and we can randomly access our
data in milliseconds rather than hours. The previously expensive downtime in
traditional recovery is exchanged for rapid data access and recovery times
using cheap disk space.
The advantage that we have over tape is that tape is a sequential access device and disk is a random access device. Hence the amount of time needed for restoring from the tape is eliminated or reduced.
The advantage that we have over tape is that tape is a sequential access device and disk is a random access device. Hence the amount of time needed for restoring from the tape is eliminated or reduced.
The flash recovery area
should place on a separate disk from the working set of database files.
Otherwise, the disk becomes a single point of failure for our database.
The larger the flash
recovery area is, the more useful it becomes. Ideally, the flash recovery area
should be large enough to contain the required files. The recovery area should
be able to contain a copy of all datafiles in the database and the incremental
backups used by our 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 flash 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 flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs to make room.
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 flash 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 flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs to make room.
Formulas for estimating
a useful flash recovery area size depend on whether:
v Database has a small or
large number of data blocks that change frequently.
v Store backups only on
disk, or on disk and tape.
v Use a redundancy-based
backup retention policy, or a recovery window-based retention policy.
v Plan to use Flashback
Database or a guaranteed restore point as alternatives to point-in-time
recovery.
If we plan to enable
flashback logging, then note that the volume of flashback log generation is
approximately the same order of magnitude as redo log generation. For example,
if we intend to set DB_FLASHBACK_RETENTION_TARGET to 24 hours, and if the
database generates 20 GB of redo in a day, then a rule of thumb is to allow 20
GB to 30 GB 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 redo every day, and if the guaranteed restore
point will be kept for a day, then plan to allocate 20 to 30 GB.
For an example suppose
that we want to determine the size of a flash recovery when the backup
retention policy is set to REDUNDANCY 1 and we intend to follow the
Oracle Suggested Strategy of using an incrementally updated backup. We
use the following formula to estimate the disk quota
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)
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:
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)
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:
5. Can I
have same Flashback Recovery Area for multiple databases?
Multiple databases can
have the same value for DB_RECOVERY_FILE_DEST, but one of the following must be
true:
v No two databases for
which the DB_UNIQUE_NAME initialization parameters are specified have the same
value for DB_UNIQUE_NAME.
v 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.
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.
The Flash Recovery Area
can be an ASM disk group. RMAN can back up and restore files that are stored in
ASM disk groups. In fact, RMAN is the only way to back up and restore ASM
files. Backup sets and image copies can be created in ASM, either by
automatically creating them in the Flash Recovery Area, or by explicitly
specifying an ASM disk group for their location.
Backup/Restore of OMF
files is easier with RMAN as RMAN does not use the long OMF file names in any
commands.
Backup sets and image copies can be created as OMF files by creating them in the Flash Recovery Area.
RMAN can be used to migrate existing files to OMF.
Backup sets and image copies can be created as OMF files by creating them in the Flash Recovery Area.
RMAN can be used to migrate existing files to OMF.
For RAC database the
location and disk quota must be the same on all instances. To accomplish this,
Oracle recommends that we place the flash recovery area on the shared ASM
disks. In addition, we must set the DB_RECOVERY_FILE_DEST and
DB_RECOVERY_FILE_DEST_SIZE parameters to the same values on all instances.
To use the Flash Recovery feature, we must first configure the flash recovery area for each instance in our Oracle RAC cluster.
To use the Flash Recovery feature, we must first configure the flash recovery area for each instance in our Oracle RAC cluster.
The files in Flash
Recovery Area are classified as permanent or transient.
v Permanent Files
The permanent files
(assuming these are configured to be stored in the recovery area) are
multiplexed copies of the current control file and online redo logs. These
cannot be deleted without causing the instance to fail.
v Transient Files
Transient files include
archived redo logs, datafile copies, control file copies, control file
autobackups, backup pieces and flashback logs. Oracle manages these files
automatically for deletion whenever space is required in the Flash Recovery
Area. They are deleted once they become obsolete under the retention policy or
have been backed up to tape. Any transient file in the flash recovery area once
backed up to tape even if not deleted are internally placed on a file can be
deleted list. Until there is a backup of the file on disk made to a tertiary
storage device it cannot be obsolete.
To enable the Flash
Recovery Area, we must set the two initialization parameters:
--DB_RECOVERY_FILE_DEST_SIZE:
It is the disk limit,
which is the amount of space the flash recovery area is permitted to use. The
minimum size of the Flash Recovery Area should be at least large enough to
contain archive logs that have not been copied to tape.
Note: This value does not include certain kinds of disk overhead:
-Block 0 or the OS block header of each Oracle file is not included in this size, so make sure to allow an extra 10% for this data when computing the actual disk usage required for the Flash Recovery Area.
-DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying filesystem is mirrored, compressed, or in some other way affected by overhead not known to Oracle.
--DB_RECOVERY_FILE_DEST:
This initialization parameter is a valid destination to create the Flash Recovery Area. The destination can be defined as a directory, file system, or ASM disk group.
Note: This value does not include certain kinds of disk overhead:
-Block 0 or the OS block header of each Oracle file is not included in this size, so make sure to allow an extra 10% for this data when computing the actual disk usage required for the Flash Recovery Area.
-DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying filesystem is mirrored, compressed, or in some other way affected by overhead not known to Oracle.
--DB_RECOVERY_FILE_DEST:
This initialization parameter is a valid destination to create the Flash Recovery Area. The destination can be defined as a directory, file system, or ASM disk group.
Note1: The Flash
Recovery Area cannot be stored on a raw file system.
Note2 : DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST.
Note2 : DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST.
- We cannot use the
LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters to specify redo log
archive destinations. We must always use the LOG_ARCHIVE_DEST_n parameters in
case we have configured flash recovery area.
- LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST if we create a recovery area and do not set any other local archiving destinations.
- Multiple database can have the same DB_RECOVERY_FILE_DEST only if the DB_NAME are different or if the DB_NAME is same (example the primary and standby database) then the DB_UNIQUE_NAME parameter must be different for the databases.
- For RAC the location of Flash Recovery Area must be on a cluster file system, ASM or a shared directory configured through NFS. The location and disk quota must be the same on all instances.
- LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST if we create a recovery area and do not set any other local archiving destinations.
- Multiple database can have the same DB_RECOVERY_FILE_DEST only if the DB_NAME are different or if the DB_NAME is same (example the primary and standby database) then the DB_UNIQUE_NAME parameter must be different for the databases.
- For RAC the location of Flash Recovery Area must be on a cluster file system, ASM or a shared directory configured through NFS. The location and disk quota must be the same on all instances.
0 Comments:
Post a Comment