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. 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. 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. 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. 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. In this case, the fast recovery area automates management of files that are backed up in a VSS snapshot and deletes them as needed. You can also use the recovery area with ASM. 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. It is awkward to directly manipulate files under ASM. 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. 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. Table discusses both the mandatory and optional parameters for enabling the fast recovery area. The location must be on a cluster file system, ASM, or a shared directory.
Specifies the disk quota , which is maximum storage in bytes of data to be used by the recovery area for this database. For example, if the recovery area is on a two-way mirrored ASM disk group, each file of x bytes occupies 2 x bytes on the ASM disk group. 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. 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.
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. Oracle technology is changing and we strive to update our BC Oracle support information.
If you find an error or have a suggestion for improving our content, we would appreciate your feedback. Just e-mail: and include the URL for the page. All rights reserved by Burleson. RMAN reads each line sequentially and executes it, only exiting when it reaches the last line of the script.
Instead, RMAN writes to standard output. The single-quotes around the stored script name are required when the script name either begins with a number or is an RMAN reserved word. You should avoid creating script names that begin with a number or that match RMAN reserved words. Connecting Without a Recovery Catalog: Example This example connects to the target database prod1 without a recovery catalog:.
Connecting to an Auxiliary Instance: Example This example connects to target database prod1 , recovery catalog database rcat , and auxiliary instance aux1 :.
Syntax Check in an Interactive Session: Example This example starts an interactive session to perform syntax checking:. The target and remote instances must use the same SYSDBA password, which means that both instances must already have password files.
You can create the password file with a single password so you can start all the database instances with that password file. Connect RMAN to the standby database where backups are performed as target, and to the recovery catalog. Skip backing up datafiles for which there already exists a valid backup with the same checkpoint:. The following RMAN configurations are recommended at a standby database where backups are not done:.
The following topics are covered:. The standby database allows you to offload all backup operations to one specific standby database, except the backups of SPFILE. The fast recovery area on the standby database can serve as a disk cache for tape backup. Disk is used as the primary storage for backups, with tape providing long term, archival storage. Incremental tape backups are taken daily and full tape backups are taken weekly.
The commands used to perform these backups are described in the following sections. When deciding on your backup strategy, Oracle recommends that you take advantage of daily incremental backups.
Datafile image copies can be rolled forward with the latest incremental backups, thereby providing up-to-date datafile image copies at all times. RMAN uses the resulting image copy for media recovery just as it would use a full image copy taken at that system change number SCN , without the overhead of performing a full image copy of the database every day. An additional advantage is that the time-to-recover is reduced because the image copy is updated with the latest block changes and fewer redo logs are required to bring the database back to the current state.
To implement daily incremental backups, a full database backup is taken on the first day, followed by an incremental backup on day two.
Archived redo logs can be used to recover the database to any point in either day. For day three and onward, the previous day's incremental backup is merged with the datafile copy and a current incremental backup is taken, allowing fast recovery to any point within the last day. Redo logs can be used to recover the database to any point during the current day.
The standby control file will be automatically backed up at the conclusion of the backup operation because the control file auto backup is enabled. Resynchronizes the information from all other database sites primary and other standby databases in the Data Guard setup that are known to recovery catalog.
Rolls forward level 0 copy of the database by applying the level 1 incremental backup taken the day before. In the example script just shown, the previous day's incremental level 1 was tagged OSS. On the first day this command is run there will be no roll forward because there is no incremental level 1 yet. Again on the second day there is no roll forward because there is only a level 0 incremental.
On the third and following days, the roll forward will be performed using the level 1 incremental tagged OSS created on the previous day. Create a new level 1 incremental backup. On the first day this command is run, this will be a level 0 incremental. On the second and following days, this will be a level 1 incremental. If the archived logs are in a fast recovery area, then they are automatically deleted when more open disk space is required. Therefore, you only need to use this command if you explicitly want to delete logs each day.
This ensures that all current incremental, image copy, and archived log backups on disk are backed up to tape. A media manager handles loading, unloading, and labeling of sequential media such as tapes. In this scenario, full backups are taken weekly, with incremental backups taken daily on the standby database. These commands resynchronize the information from all other databases in the Data Guard environment. They also create a level 1 incremental backup of the database, including all archived logs.
On the first day this script is run, if no level 0 backups are found, then a level 0 backup is created. These commands resynchronize the information from all other databases in the Data Guard environment, and create a level 0 database backup that includes all archived logs.
When a standby database is completely removed from a Data Guard environment, the database information in the recovery catalog can also be removed after you connect to another database in the same Data Guard environment.
The backups that were associated with the database that was unregistered are still usable by other databases. For example, after connecting to the recovery catalog, you could use the following commands to display information for a database with a DBID of and to list the databases in the Data Guard environment. This information, along with file-sharing attributes, is used to determine which files can be accessed during various RMAN operations.
0コメント