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. 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 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.
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.
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. 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:.
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. When databases share a single recovery area in this way, the location should be large enough to hold the files for all databases.
Table 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. 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.
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. 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 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 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. The default size of an online log created in the fast recovery area is megabytes.
The log member file names are automatically generated by the database. Oracle recommends that you the use fast recovery area as an archiving location because the archived logs are automatically managed by the database. 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. Using either of these parameters prevents you from starting the instance. For example, on Solaris the default is? 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:.
RMAN can create control file autobackups in the fast recovery area. RMAN creates control file autobackups in the fast recovery area when no other destination is configured. 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. As explained in "Backup Retention Policies" , the backup retention policy specifies which backups must be retained to meet your data recovery requirements.
This policy can be based on a recovery window or redundancy. As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all archived logs and incremental backups that are needed to recover the nonobsolete backups. Assume that you make a full backup of data file 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four full backups of this data file. If you make another backup on Friday, then the Wednesday backup of data file 7 becomes obsolete.
You run a level 0 database backup at noon on Monday, a level 1 cumulative backup at noon on Tuesday and Wednesday, and a level 0 backup at noon on Thursday. The Wednesday DELETE command does not remove the Tuesday level 1 backup because this backup is not redundant: the Tuesday level 1 backup could be used to recover the Monday level 0 backup to a time between noon on Tuesday and noon on Wednesday.
RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window. This example ensures that you can recover the database to any point within the last week:.
RMAN does not automatically delete backups rendered obsolete by the recovery window. When you disable the retention policy, RMAN does not consider any backup as obsolete. To disable the retention policy, run this command:. Configuring the retention policy to NONE is different from clearing it. Backup optimization skips the backup of files in certain circumstances if the identical file or an identical version of the file has been backed up.
If you enable backup optimization , then the BACKUP command skips backing up files when the identical file has already been backed up to the specified device type. Table describes criteria that RMAN uses to determine whether a file is identical to a file that it backed up. Table Criteria to Determine an Identical File. The data file must be offline-normal, read-only, or closed normally. If RMAN determines that a file is identical and it has been backed up, then it is a candidate to be skipped.
RMAN must do further checking to determine whether to skip the file, however, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.
RMAN uses backup optimization when the following conditions are true:. Only one type of channel is allocated, do not mix disk and SBT channels in the same backup command.
For example, assume that you have configured backup optimization. These commands back up to tape the database, all archived logs, and all backup sets:. If none of the backed-up files has changed since the last backup, then RMAN does not back up the files again.
RMAN also does not signal an error if it skips all files specified in the command because the files have already been backed up. For example, you can run:. Backup optimization is not always applied when backing up to SBT devices. The exceptions to normal backup optimization behavior for recovery window-based and redundancy-based retention policies are described in the following sections. Suppose that backup optimization is enabled, and a recovery window backup retention policy is in effect.
For example, assume the following scenario:. On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it did not change after the January 3 backup because it is read-only. RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window. This behavior enables the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely.
By making a more recent backup of tablespace tools on February 21, RMAN enables the media manager to expire the tape containing the January 3 backup. Assume that you configure a retention policy for redundancy. With these settings, RMAN only skips backups when three identical files are already backed up. The backups on Tuesday, Wednesday, and Thursday back up the offline users tablespace to satisfy the condition that three backups must exist one more than redundancy setting.
The Friday and Saturday backups do not back up the users tablespace because of backup optimization. The Tuesday backup of users is obsolete beginning on Thursday. On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users. The Tuesday backup is obsolete because of the retention policy setting.
The whole database backup on Monday then backs up the users tablespace to satisfy the condition that three backups must exist one more than redundancy setting. In this way, you can recycle your tapes over time.
By default, backup optimization is configured to OFF. You can use RMAN to create a persistent configuration that governs when archived redo logs are eligible for deletion from disk. This deletion policy applies to all archiving destinations, including the fast recovery area. Archived redo logs can be deleted automatically by the database or by user-initiated RMAN commands. Only logs in the fast recovery area can be deleted automatically by the database.
For archived redo log files in the fast recovery area, the database retains them as long as possible and automatically deletes eligible logs when additional disk space is required. You can manually delete eligible logs from any location, whether inside or outside the fast recovery area, when you issue BACKUP By default, there is no archived redo log deletion policy and this is why the archive redo log policy is set to the NONE clause.
In this particular case, the fast recovery area considers archived redo log files in the recovery area as eligible for deletion if they have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy. The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by Oracle Flashback Database. Oracle Data Guard Concepts and Administration to learn how to configure an archived log deletion policy in a Data Guard environment.
This configuration specifies that archived logs are eligible for deletion only when the specified number of archived log backups exist on the specified device type. The archived log deletion policy also has options specific to a Data Guard environment.
This section explains how to configure an archived redo log deletion policy. By default the policy is set to NONE. The following example specifies that archived redo logs are eligible to be deleted from the fast recovery area and all local archiving destinations when logs have been backed up at least twice to tape:. RMAN must be connected to a recovery catalog when you create or alter a configuration for a database in the Data Guard environment.
You can even create a configuration for a standby database that has not yet been created. For example, you can configure channels, default devices, and so on for a specified database or for all databases in the environment.
A Data Guard environment involves many considerations that are only relevant for Data Guard. For example, you can configure an archived redo log deletion policy based on whether archived logs are transferred to or applied on a standby database. Oracle Training from Don Burleson The best on site " Oracle training classes " are just a phone call away!
You can get personalized Oracle training by Donald Burleson, right at your shop! Burleson is the American Team Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.
Feel free to ask questions on our Oracle forum. Verify experience! Some frequently used configuration settings are described below. By default, RMAN allocates one disk channel for all operations automatically, and directs all backups to disk if no destination is specified. If your database uses a flash recovery area, then backups to disk are stored there if no other location is specified in the BACKUP command. Otherwise, disk backups are assumed to be stored in a platform-specific default location.
After configuring your media management software, you can make the media manager the default destination for RMAN backups:. Multiple channels can be configured to run backups in parallel. This command configures three sbt channels for use in RMAN jobs:.
0コメント