5 Configuring the RMAN Environment
This chapter explains the most basic tasks involved in configuring RMAN. This chapter contains the following topics:
See Also:
-
Configuring the RMAN Environment: Advanced Topics to learn about configuration options not covered in this chapter, including backup compression and encryption
-
Appendix C in the Oracle Database Backup and Recovery Reference for information about configuring RMAN for the Oracle Secure Backup (OSB) Cloud Module.
5.1 About Configuring the Environment for RMAN Backups
RMAN provides sensible defaults for most parameters required to perform basic backup and recovery. You can modify the value of default parameters or override these values for a particular session.
When implementing an RMAN-based backup strategy, you can use RMAN more effectively if you understand the most common configurations.
To simplify ongoing use of RMAN, you can set several persistent configuration settings for each target database. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups, default backup device type, and so on. You can use the SHOW
and CONFIGURE
commands to view and change RMAN configurations.
This section explains what an RMAN configuration is and how you can use the CONFIGURE
command to change RMAN default behavior for your backup and recovery environment. This section also introduces the major settings available to you and their more common values.
Note:
If you plan to back up to tape, refer to Configuring RMAN to Make Backups to a Media Manager.
See Also:
Oracle Database Backup and Recovery Reference for CONFIGURE
syntax
5.1.1 Showing and Clearing Persistent RMAN Configurations
You can use the SHOW
command to display the current value of RMAN configured settings for the target database. You can also view whether these commands are currently set to their default values.
To view or change your CONFIGURE command settings:
See Also:
Oracle Database Backup and Recovery Reference for SHOW
syntax
5.1.2 Configuring the Default Device for Backups: Disk or SBT
Backups for which no destination device type is specified are directed to the configured default device. RMAN is preconfigured to use disk as the default device type. No additional configuration is necessary.
You may need to change the default device type from disk to tape, or change it back from tape to disk. Table 5-1 shows the commands that configure the default device.
Table 5-1 Commands to Configure the Default Device Type
Command | Explanation |
---|---|
|
Specifies that backups go to disk by default. If a recovery area is enabled, then the backup location defaults to the fast recovery area. Otherwise, the backup location defaults to an operating system-specific directory on disk. When backing up to disk, the logical block size of the database file must be an even multiple of the physical block size of the destination device. For example, a device of type DISK with a block size of 2 kilobytes can only be used as a destination for backups of database files with logical block sizes of 2 KB, 4 KB, 6 KB, and so on. Most disk drives have physical block sizes of 512 bytes, so this limitation rarely affects backup to disk drives. Nevertheless, you can encounter this limitation when backing up to a writable DVD or a device that has a larger physical block size. |
|
Specifies that backups go to tape by default. "Configuring RMAN to Make Backups to a Media Manager" explains how to set up RMAN for use with a media manager. When RMAN can communicate with the media manager, you can configure RMAN to make backups to tape and specify SBT as the default device type. |
You can always override the default device by using the DEVICE
TYPE
clause of the BACKUP
command, as shown in the following examples:
BACKUP DEVICE TYPE sbt DATABASE;
BACKUP DEVICE TYPE DISK DATABASE;
To change the configured default device type:
-
Start RMAN and connect to a target database and a recovery catalog (if used).
-
Run the
SHOW ALL
command to show the currently configured default device. -
Run the
CONFIGURE DEFAULT DEVICE TYPE
command, specifying eitherTO DISK
orTO sbt
.
See Also:
Oracle Database Backup and Recovery Reference for more details on using the BACKUP
command with the DEVICE
TYPE
clause
5.1.3 Configuring the Default Type for Backups: Backup Sets or Copies
The BACKUP
command can create either backup sets or image copies. For disk, you can configure RMAN to create either backup sets or image copies as its default backup type with the CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO
command.
Note:
Because RMAN can write an image copy only to disk, the backup type for tape can only be a backup set.
The default backup type for disk is an uncompressed backup set.
RMAN can create backup sets using binary compression. You can configure RMAN to use compressed backup sets by default on a device type by specifying the COMPRESSED
option in the BACKUP TYPE TO ... BACKUPSET
clause. To disable compression, use the CONFIGURE DEVICE TYPE
command with arguments specifying your other desired settings, but omit the COMPRESSED
keyword.
To configure the default type of backup:
5.1.4 Configuring Channels
An RMAN channel is a connection to a database server session. RMAN uses channels to perform most tasks.
This section contains the following topics:
5.1.4.1 About Channel Configuration
Use the CONFIGURE
CHANNEL
command to configure options for disk or SBT channels. You can configure generic channel settings for a device type, that is, a template that is used for any channels created based on configured settings for that device.
Note:
This section explains configuration of disk channels. To learn how to configure channels for tape, see Configuring SBT Channels for Use with a Media Manager.
CONFIGURE
CHANNEL
takes the same options used to specify one-time options with the ALLOCATE CHANNEL
command.
If you use CONFIGURE
CHANNEL
to specify generic channel settings for a device, any previous settings are discarded, even if the settings are not in conflict. For example, after the second CONFIGURE
CHANNEL
command, which specifies only the FORMAT
for configured disk channels, the MAXPIECESIZE
for the disk channel is returned to its default value:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;
5.1.4.2 Configuring Channels for Disk
By default, RMAN allocates one disk channel for all operations. You can specify different options for this channel, for example, a new default location for backups.
Example 5-1 Configuring a Nondefault Backup Location
This example configures RMAN to write disk backups to the /disk1
directory and specifies a nondefault format for the relative file name.
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p';
RMAN automatically replaces the format specifier %t
with a four byte time stamp, %s
with the backup set number, and %p
with the backup piece number.
Note:
When you configure an explicit format for disk channels, RMAN does not create backups by default in the fast recovery area. In this case, you lose the disk space management capabilities of the fast recovery area.
Example 5-2 Configuring an ASM Disk Location
This example demonstrates how to configure an ASM disk location.
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';
See Also:
Backing Up Database Files with RMAN to learn how to make backups
5.1.4.3 Configuring Parallel Channels for Disk and SBT Devices
The number of channels available for a device type when you run a command determines whether RMAN reads or writes in parallel. As a rule, the number of channels used in executing a command should match the number of devices accessed.
For tape backups, allocate one channel for each tape drive. For disk backups, allocate one channel for each physical disk, unless you can optimize the backup for your disk subsystem architecture with multiple channels. Failing to allocate the right number of channels adversely affects RMAN performance during I/O operations.
You can configure channel parallelism settings, binary compression for backup sets, and other options for an SBT device with CONFIGURE
DEVICE
TYPE
sbt
. You set the configuration for the device type independently of the channel configuration.
Example 5-3 Configuring Parallelism for an SBT Device
This example changes the SBT device (sample output included) so that RMAN can back up to a media manager using two tape drives in parallel. Each configured SBT channel backs up approximately half the total data.
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored
Example 5-4 Configuring the Backup Type for an SBT Device
This example changes the default backup type for the SBT device to an uncompressed backup set (sample output included).
The CONFIGURE DEVICE TYPE
commands used in this example only affect parallelism and backup type and do not affect the values of settings not specified. In Example 5-3, the default backup type of compressed backup set was not changed by changing the parallelism setting. In this example, the ability to use multiple tape drives in parallel is not affected by changing the default backup type.
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2;
new RMAN configuration parameters are successfully stored
See Also:
-
Specifying Multiple Formats for Disk Backups to learn how to make disk backups in parallel
-
Oracle Database Backup and Recovery Reference for reference material on the
CHANNEL
parameter of theBACKUP
command -
Oracle Real Application Clusters Administration and Deployment Guide for information about taking advantage of parallel operations in an Oracle Real Application Clusters (Oracle RAC) configuration
5.1.4.4 Manually Overriding Configured Channels
If you manually allocate a channel during a job, then RMAN disregards any configured channel settings.
To manually override configured channels:
-
Assume that the default device type is SBT. Run the following command to override the default configuration.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK; BACKUP TABLESPACE users; }
In this case, RMAN uses only the disk channel that you manually allocated within the
RUN
command, overriding any defaults set by usingCONFIGURE
DEVICE
TYPE
,CONFIGURE
DEFAULT
DEVICE
, orCONFIGURE
CHANNEL
settings.
See Also:
-
About RMAN Channels to learn about configured and allocated channels
-
Oracle Database Backup and Recovery Reference for
ALLOCATE CHANNEL
syntax -
Oracle Database Backup and Recovery Reference for
CONFIGURE
syntax
5.1.5 Configuring Control File and Server Parameter File Autobackups
You can configure RMAN to automatically back up the control file and server parameter file. The autobackup occurs whenever a backup record is added.
If the database runs in ARCHIVELOG
mode, then an autobackup is also taken whenever the database structure metadata in the control file changes. A control file autobackup enables RMAN to recover the database even if the current control file, recovery catalog, and server parameter file are lost.
Because the file name for the autobackup follows a well-known format, RMAN can search for it without access to a repository and then restore the server parameter file. After you have started the instance with the restored server parameter file, RMAN can restore the control file from an autobackup. After you mount the control file, the RMAN repository is available, and RMAN can restore the data files and find the archived redo logs.
To enable the autobackup feature:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
To disable the autobackup feature:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
By default, control file autobackups are turned on for CDBs and standalone databases that have the COMPATIBLE
initialization parameter set to 12.2 or higher.
See Also:
5.1.5.1 Configuring the Control File Autobackup Format
By default, the format of the autobackup file for all configured devices is the substitution variable %F
in the FORMAT clause.
The %F
variable format translates into c-IIIIIIIIII-YYYYMMDD-QQ
, with the placeholders defined as follows:
-
IIIIIIIIII
stands for the DBID. -
YYYYMMDD
is a time stamp of the day the backup is generated. -
QQ
is the hexadecimal sequence that starts with00
and has a maximum ofFF
.
To change the default format for the autobackup file:
-
Use the following command, where
deviceSpecifier
is any valid device type, and 'string
' must contain the substitution variable%F
(and no other substitution variables) and is a valid handle for the specified device:CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE deviceSpecifier TO 'string';
For example, you can run the following command to specify a nondefault file name for the control file autobackup. In the file name,
?
stands forORACLE_HOME
.CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/cf_%F';
The following example configures the autobackup to write to an Automatic Storage Management disk group:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '+dgroup1/%F';
Note:
The valid formats for control file autobackups are: %D
, %I
, %M
, %Y
, %F
, %T
, %d
, and %n
. If you use formats other than these, you may not be able to restore the control file autobackup.
To clear control file autobackup formats for a device:
-
, Use the following commands:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR;
If you have set up a fast recovery area for the database, then you can direct control file autobackups to the fast recovery area by clearing the control file autobackup format for disk.
Note:
All files in the fast recovery area are maintained by Oracle Database and associated file names are maintained in the Oracle Managed Files (OMF) format.
5.1.5.2 Overriding the Configured Control File Autobackup Format
The SET CONTROLFILE AUTOBACKUP FORMAT
command, which you can specify either within a RUN
command or at the RMAN prompt, overrides the configured autobackup format in the current session only.
The order of precedence is:
SET CONTROLFILE AUTOBACKUP FORMAT
(within aRUN
block)
SET CONTROLFILE AUTOBACKUP FORMAT
(atRMAN
prompt)CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
The following example shows how the two forms of SET
CONTROLFILE
AUTOBACKUP
FORMAT
interact:
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F'; BACKUP AS COPY DATABASE; RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; }
The first SET CONTROLFILE AUTOBACKUP FORMAT
controls the name of the control file autobackup until the RMAN client exits, overriding any configured control file autobackup format. The SET CONTROFILE AUTOBACKUP FORMAT
in the RUN
block overrides the SET CONTROLFILE AUTOBACKUP FORMAT
outside the RUN
block for the duration of the RUN
block.
5.2 Configuring RMAN to Make Backups to a Media Manager
On most platforms, to back up to and restore from sequential media such as tape you must integrate a media management software with your Oracle database. You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager.
Note:
You can also use a third-party media manager. This section describes the generic steps for configuring RMAN for use with a third-party media manager. The actual steps depend on the media management product that you install and the platform on which you run the database. If you opt to use RMAN with a media manager other than Oracle Secure Backup, then you must obtain all product-specific information from the vendor.
To configure RMAN for use with a media manager:
5.2.1 Prerequisites for Using a Media Manager with RMAN
Before you can begin using RMAN with a third-party media manager, you must install the media manager and ensure that RMAN can communicate with it. Refer to the media management vendor's software documentation for instructions.
In general, you begin by installing and configuring the media management software on the target host or production network. Ensure that you can make non-RMAN backups of operating system files on the target database host. This step makes later troubleshooting much easier by confirming that the basic integration of the media manager with the target host has been successful. Refer to your media management documentation to learn how to back up files to the media manager without using RMAN.
Then, obtain and install the third-party media management module for integration with the database server. This module contains the media management library that the Oracle database loads and uses when accessing the media manager. It is generally a third-party product that must be purchased separately. Contact your media management vendor for details.
5.2.2 Determining the Location of the Media Management Library
Before attempting to use RMAN with a media manager, determine the location of the media management library.
When allocating or configuring a channel for RMAN to use to communicate with a media manager, you must specify the SBT_LIBRARY
parameter in an ALLOCATE CHANNEL
or CONFIGURE CHANNEL
command. The SBT_LIBRARY
parameter specifies the path to the library.
When RMAN allocates channels to communicate with a media manager, it attempts to load the library indicated by the SBT_LIBRARY
parameter. If you do not provide a value for the SBT_LIBRARY
parameter in an allocated or preconfigured channel, then RMAN looks in a platform-specific and secured default location.
On Linux and UNIX, the SBT library is loaded from:
/opt/oracle/extapi/[32,64]/{SBT}/{VENDOR}/{VERSION}/libobk.so
The SBT library file name extension name varies according to platform:
-
.so
,.sl
on HP-UX, -
.a
on AIX,
On Windows, the SBT library is loaded from:
%SYSTEM_DRIVE%\oracle\extapi\[32,64]\{SBT}\{VENDOR}\{VERSION}\orasbt.dll
If RMAN cannot use the secured default location or if you are using Oracle Database 11g or earlier, then RMAN loads the SBT library from the location designated by the environment variables PATH
or LIBPATH
.
In some cases, your organization may have security or regulatory compliance requirements that prohibit the use of environment variables PATH
or LIBPATH
to designate a library directory. To disable this behavior, set the PARMS
string to SBT_SECURE=1
.
Note:
The default media management library file is not part of the standard database installation. It is present only if you install third-party media management software.
See Also:
Your operating system-specific database documentation and the documentation supplied by your media vendor for instructions on how to achieve media manager integration on your platform
Example: Configuring the Media Management Library Location
The following example shows the channel syntax, where pathname is the absolute file name of the library:
CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=pathname';
5.2.3 Configuring Media Management Software for RMAN Backups
After installing the media management software, perform the configuration required by your vendor so that the software can accept RMAN backups.
Depending on the type of media management software that you installed, you may have to define media pools, configure users and classes, and so on. Consult your media management vendor documentation for the appropriate RMAN settings. The PARMS
parameter sends instructions to the media manager. If PARMS
values are needed for the ALLOCATE CHANNEL
or the CONFIGURE CHANNEL
command, or if a FORMAT
string is recommended for the BACKUP
or CONFIGURE
command, then refer to the vendor documentation for this information.
Example 5-5 PARMS Setting for Oracle Secure Backup
This example shows a PARMS
setting for Oracle Secure Backup. This PARMS
settings instructs the media manager to back up to a family of tapes called datafile_mf
. The PARMS
settings are always vendor-specific.
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';
See Also:
-
Oracle Database Backup and Recovery Reference for
ALLOCATE
CHANNEL
syntax -
Oracle Database Backup and Recovery Reference for channel control options
-
Oracle Secure Backup Reference for RMAN-specific parameter settings for Oracle Secure Backup
5.2.4 Testing Whether the Media Manager Library Is Integrated Correctly
After you have confirmed that the database server can load the media management library, test to ensure that RMAN can back up to the media manager.
You can perform the following tasks:
5.2.4.1 Testing ALLOCATE CHANNEL on the Media Manager
The ALLOCATE CHANNEL
command is used to perform a basic test of RMAN communication with the media manager.
To test channel allocation on the media manager:
Whenever channel allocation fails, the database writes a trace file to the trace
subdirectory in the Automatic Diagnostic Repository (ADR) home directory. The following shows sample output:
SKGFQ OSD: Error in function sbtinit on line 2278 SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log SBT Initialize failed for /oracle/lib/libobk.so
See Also:
Oracle Database Administrator’s Guide to learn how to use the Automatic Diagnostic Repository to monitor database operations
5.2.4.2 Testing Backup and Restore Operations on the Media Manager
After testing a channel allocation on the media manager, create and restore a test backup.
Use the BACKUP
and RESTORE
commands to perform backup and recovery operations on the media manager. If the backup and restore operations succeed, then you are ready to use the media manager with RMAN.
Possible reasons for failures include the following cases:
-
The backup hangs.
A hanging backup usually indicates that the media manager is waiting to mount a tape. Check if there are any media manager jobs in tape mount request mode and fix the problem. Ensure that the steps in Configuring RMAN to Make Backups to a Media Manager are correctly done.
-
The backup fails with
ORA-27211: Failed to load Media Management Library
.This error indicates that the media management software is not correctly configured. Ensure that the steps in Configuring RMAN to Make Backups to a Media Manager are correctly done. Also, ensure that you have the
PARMS
andFORMAT
strings required by your media management software.
Example 5-6 Backing Up the Server Parameter File to Tape
You can use the command in this example (substituting the channel settings required by your media management vendor) to test whether a backup can be created on the media manager. If your database does not use a server parameter file, then back up the current control file instead.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
BACKUP SPFILE;
# If your database does not use a server parameter file, use:
# BACKUP CURRENT CONTROLFILE;
}
Example 5-7 Restoring the Server Parameter File from Tape
This example restores the backup created in Example 5-6 to a temporary directory. If the backup to the media manager succeeds, then attempt to restore the server parameter file as an initialization parameter file.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
RESTORE SPFILE TO PFILE '/tmp/test_restore.f';
# If your database does not use a server parameter file, use:
# RESTORE CURRENT CONTROLFILE TO '/tmp/test_restore.f';
}
5.2.5 Configuring SBT Channels for Use with a Media Manager
Configuring SBT channels creates a persistent setting that is the default used for backup and recovery operations with a media manager.
5.2.5.1 About Media Manager Backup Piece Names
A backup piece name is determined by the FORMAT
string
specified in the BACKUP
command, CONFIGURE CHANNEL
command, or ALLOCATE CHANNEL
command.
The media manager considers the backup piece name as the name of the backup file, so
every backup piece must have a unique name in the media management catalog. You can use
the substitution variables in a FORMAT
parameter to generate unique
backup piece names. For example, %d
specifies the name of the database,
whereas %t
specifies the backup time stamp. For most purposes, you can
use %U
, in which case RMAN automatically generates a unique file name.
The backup piece name 12i1nk47_1_1
is an example. If you do not specify
the FORMAT
parameter, then RMAN automatically generates a unique file
name with the %U
substitution variable.
Your media manager may impose restrictions on file names and sizes. In this case, you may need more control over the naming of backup pieces so that they obey media manager restrictions. For example, some media managers only support a 14-character backup piece name, and some require special FORMAT
strings. The unique names generated by the %U
substitution variable do not exceed 14 characters.
Some media managers may have limits on the maximum size of files that they can back up or restore. You must ensure that RMAN does not produce backup sets larger than those limits. To limit backup piece sizes, use the parameter MAXPIECESIZE
, which you can set in the CONFIGURE CHANNEL
andALLOCATE CHANNEL
commands.
See Also:
-
About Number and Size of RMAN Backup Pieces to learn how to set
MAXPIECESIZE
-
Oracle Database Backup and Recovery Reference for the complete list of variables allowable in format strings with the
BACKUP
command -
Your media management documentation to determine the string character limit for the media manager
5.2.5.2 Configuring Automatic SBT Channels
The easiest technique for backing up to a media manager is to configure automatic SBT channels
As explained in "Configuring the Default Device for Backups: Disk or SBT", you can use a tape device as your default backup destination.
To configure channels for use with a media manager:
5.3 Configuring RMAN to Make Backups to Recovery Appliance
RMAN commands can be used to back up target databases to Zero Data Loss Recovery Appliance (Recovery Appliance). Certain configuration steps are required to use the Recovery Appliance as a centralized repository for the target database backups.
To configure RMAN to create backups to Recovery Appliance:
-
Ensure that the prerequisites described in "Prerequisites for Using Recovery Appliance" are met.
-
Complete the steps listed in "Steps to Configure RMAN for Backups to Recovery Appliance".
5.3.1 Prerequisites for Using Recovery Appliance
Before you can use RMAN to back up a target database to Zero Data Loss Recovery Appliance (Recovery Appliance), you must install the Recovery Appliance backup module in the Oracle home of the target database.
The backup module can be installed in the default location or a user-specified location. Installing the Recovery Appliance backup module creates the shared library used to transfer backups to the Recovery Appliance and the Oracle wallet containing credentials used to authenticate the target database with Recovery Appliance.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration Guide for information about installing the Recovery Appliance backup module
5.3.2 Steps to Configure RMAN for Backups to Recovery Appliance
RMAN configuration is required before you can back up Oracle databases to Zero Data Loss Recovery Appliance (Recovery Appliance).
5.3.3 Determining the Location of the Recovery Appliance Backup Module
Before using RMAN to back up target databases to Zero Data Loss Recovery Appliance (Recovery Appliance), you need to determine the location of the Recovery Appliance backup module on the target database host. This location is used while configuring or allocating RMAN channels for Recovery Appliance.
The SBT_LIBRARY
parameter in the CONFIGURE
or ALLOCATE
command specifies the location of the Recovery Appliance backup module. When RMAN attempts to back up to Recovery Appliance, it loads the shared library indicated by the SBT_LIBRARY
parameter.
You can specify an absolute path name or a file name for the SBT_LIBRARY
parameter. If you specify a file name, then RMAN searches for the file in an operating system-specific location. By default, the Recovery Appliance backup module is located in $ORACLE_HOME/lib/libra.so
on UNIX/Linux and in %ORACLE_HOME\database\lib\libra.sso
on Windows.
Example 5-8 Specifying the Recovery Appliance Backup Module Location During Channel Configuration
The following command configures an RMAN SBT channel by specifying the absolute path name of the Recovery Appliance backup module on Linux:
CONFIGURE CHANNEL DEVICE TYPE sbt PARAMS 'SBT_LIBRARY=/u01/oracle/lib/libra.so';
5.3.4 Specifying Recovery Appliance Configuration Settings for RMAN Backups
The client configuration file, stored on the protected database, contains the configuration settings that are used by the Zero Data Loss Recovery Appliance (Recovery Appliance) backup module to communicate with the Recovery Appliance. This file is created automatically when the Recovery Appliance backup module is installed.
The client configuration file must contain the location of the Oracle wallet that stores credentials required to authenticate the target database with Recovery Appliance. Other optional settings may be included.
When using Recovery Appliance, you can include the client configuration settings in an RMAN command. Use the ENV
parameter of the RMAN CONFIGURE CHANNEL
or ALLOCATE CHANNEL
command to directly specify client configuration parameters for Recovery Appliance.
Example 5-9 Specifying Recovery Appliance Client Configuration Settings
The following command specifies the Recovery Appliance client configuration settings directly as part of the CONFIGURE CHANNEL
command:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= libra.so,
ENV=(BA_WALLET=location=file:/home/oracle/product/12.1.0/dbhome_1/wallet credential_alias=ra-scan:1521/zdlra5:dedicated)';
In this example, ra-scan
is the SCAN of the Recovery Appliance and zdlra5
is the service name of the Recovery Appliance metadata database.
5.4 Configuring the 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:
See Also:
5.4.1 Overview of Files in 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:
-
Oracle Database Administrator’s Reference for Microsoft Windows to learn about making backups in a VSS environment
5.4.1.1 Fast Recovery Area with 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, 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.
5.4.1.2 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.
5.4.2 Enabling the Fast Recovery Area
You enable the fast recovery area by setting two initialization parameters. These parameters enable the fast recovery area with or 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 |
---|---|---|
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 The
|
|
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. |
|
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 -
Oracle Database Administrator’s Guide for details on setting and changing database initialization parameters
5.4.2.1 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 is large enough to contain the control files, online redo logs, archived redo logs, and flashback logs. It 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 incremental forever. 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)
5.4.2.2 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 forDB_UNIQUE_NAME
. -
For those databases where no
DB_UNIQUE_NAME
is provided, no two databases have the same value forDB_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.
5.4.2.3 Setting the Fast Recovery Area Location and Initial Size
Use database initialization parameters to set the location and size of the fast recovery area.
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 and set the recovery area location:
5.4.3 Disabling the Fast Recovery Area
You can use the ALTER SYSTEM
command to disable 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:
5.4.4 Configuring Locations for Control Files and Redo Logs
Use initialization parameters to configure the default locations for control files and redo logs.
5.4.4.1 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
.
The following SQL statements can create online redo logs in the fast recovery area:
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.
See Also:
Description of the LOGFILE
clause of the CREATE
DATABASE
statement in Oracle Database SQL Language Reference for details of the effect of combinations of the initialization parameters on online redo log creation
5.4.4.2 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.
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.
See Also:
The "Semantics" section of the description of CREATE CONTROLFILE
in Oracle Database SQL Language Reference for a full description of how these parameters interact
5.4.4.3 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:
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
5.4.5 Configuring RMAN File Creation in the Fast Recovery Area
Certain RMAN commands or implicit actions (such as control file autobackups) can create files in the fast recovery area.
This section explains how to control whether a command creates files in the fast recovery area or in another destination. The commands are:
-
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 (OMF) format. If a fast recovery area is enabled, and if you do specifyFORMAT
onBACKUP
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 toLOCATION=USE_DB_RECOVERY_FILE_DEST
. If you do not specifySET
ARCHIVELOG DESTINATION
to override this behavior, then RMAN restores archived redo log files to the fast recovery area. -
RECOVER
DATABASE
orRECOVER TABLESPACE
,RECOVER ... BLOCK
, andFLASHBACK 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 toLOCATION = USE_DB_RECOVERY_FILE_DEST
. Verify that you are not usingSET ARCHIVELOG DESTINATION
to direct restored logs to some other destination.
5.5 Configuring the Backup Retention Policy
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. Use the CONFIGURE RETENTION POLICY
command to specify the retention policy.
This section contains the following topics:
See Also:
-
Oracle Database Backup and Recovery Reference for
CONFIGURE
syntax
5.5.1 Configuring a Redundancy-Based Retention Policy
The REDUNDANCY
parameter of the CONFIGURE
RETENTION
POLICY
command specifies how many full or level 0 backups of each data file and control file that RMAN keeps. The default retention policy is REDUNDANCY 1
.
If the number of full or level 0 backups for a specific data file or control file exceeds the REDUNDANCY
setting, then RMAN considers the extra backups as obsolete. 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 REDUNDANCY
is 2
, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup of data file 7 becomes obsolete.
Assume a different case in which REDUNDANCY
is 1
. 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. Immediately after each daily backup you run the command DELETE OBSOLETE
. 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. However, the DELETE
command on Thursday removes the previous level 0 and level 1 backups.
Run the CONFIGURE
RETENTION
POLICY
command at the RMAN prompt, as in the following example:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
5.5.2 Configuring a Recovery Window-Based Retention Policy
The RECOVERY
WINDOW
parameter of the CONFIGURE
command specifies the number of days between the current time and the earliest point of recoverability.
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. Use the CONFIGURE
RETENTION
POLICY
command at the RMAN prompt to configure a recovery window-based retention policy.
The following example ensures that you can recover the database to any point within the last week:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN does not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE
in the REPORT
OBSOLETE
output and in the OBSOLETE
column of V$BACKUP_FILES
. RMAN deletes obsolete files if you run the DELETE
OBSOLETE
command.
5.5.3 Disabling the Retention Policy
When you disable the retention policy, RMAN does not consider any backup as obsolete.
To disable the retention policy, run this command:
CONFIGURE RETENTION POLICY TO NONE;
Configuring the retention policy to NONE
is different from clearing it. Clearing returns the default setting of REDUNDANCY 1
, whereas NONE
disables it.
If you disable the retention policy and run REPORT OBSOLETE
or DELETE OBSOLETE
commands without passing a retention policy option to the command, then RMAN issues an error because no retention policy exists to determine which backups are obsolete.
Caution:
If you are using a fast recovery area, then do not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the fast recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. This action is likely to use all of the space in your recovery area, which interferes with the normal operation of your database. See "How Oracle Manages Disk Space in the Fast Recovery Area"
5.6 Backup Optimization and the CONFIGURE command
Run the RMAN CONFIGURE
command to enable and disable backup optimization. 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.
This section contains the following topics:
5.6.1 Overview of Backup Optimization
When you enable backup optimization, the BACKUP
command skips backing up files when the identical file has been backed up to the specified device type.
Table 5-4 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.
Table 5-4 Criteria to Determine an Identical File
Type of File | Criteria to Determine an Identical File |
---|---|
Data file |
The data file must have the same DBID, checkpoint SCN, creation SCN, and |
Archived log |
Same DBID, thread, sequence number, and |
Backup set |
Same DBID, backup set record ID, and stamp |
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:
-
The
CONFIGURE
BACKUP
OPTIMIZATION
ON
command has been run to enable backup optimization. -
You run
BACKUP
DATABASE
,BACKUP
ARCHIVELOG
withALL
orLIKE
options, orBACKUP
BACKUPSET
ALL
,BACKUP RECOVERY AREA
,BACKUP RECOVERY FILES
, orBACKUP DATAFILECOPY
.Note:
When
TO DESTINATION
is used withBACKUP RECOVERY AREA
orBACKUP RECOVERY FILES
, RMAN only skips backups of files that have identical backups in theTO DESTINATION
location that you provide. -
Only one type of channel is allocated, do not mix disk and SBT channels in the same backup command.
Note:
In backup undo optimization, RMAN excludes undo changes (that are not needed for recovery of a backup) for transactions that have been committed. You can enable and disable backup optimization, but backup undo optimization is built-in behavior.
For example, assume that you have configured backup optimization. These commands back up to tape the database, all archived logs, and all backup sets:
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL;
If no backed-up file 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.
You can override optimization at any time by specifying the FORCE
option on the BACKUP
command. For example, you can run:
BACKUP DATABASE FORCE; BACKUP ARCHIVELOG ALL FORCE;
See Also:
The CONFIGURE
entry in Oracle Database Backup and Recovery Reference for a complete description of the backup optimization rules
5.6.2 Effect of Retention Policies on Backup Optimization for SBT Backups
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.
-
About Backup Optimization for SBT Backups with Recovery Window Retention Policy
-
About Backup Optimization for SBT Backups With Redundancy Retention Policy
Note:
Use caution when enabling backup optimization if you use a media manager with its own internal expiration policy. Run the CROSSCHECK
command periodically to synchronize the RMAN repository with the media manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups stored on tape.
5.6.2.1 About Backup Optimization for SBT Backups with Recovery Window Retention Policy
Suppose that backup optimization is enabled, and a recovery window backup retention policy is in effect. In this case, when performing SBT backups RMAN always backs up data files whose most recent backup is older than the recovery window.
For example, assume the following scenario:
-
Today is February 21.
-
The recovery window is 7 days.
-
The most recent backup of tablespace
tools
to tape is January 3. -
Tablespace
tools
is read-only.
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 is 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.
5.6.2.2 About Backup Optimization for SBT Backups With Redundancy Retention Policy
Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only data files to SBT when there are r
+ 1 backups of the files, where r
is set in CONFIGURE
RETENTION
POLICY
TO
REDUNDANCY
r
.
For example, assume that you enable backup optimization and set the following retention policy:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
With these settings, RMAN only skips backups when three identical files are backed up. Also assume that you have never backed up the users
tablespace, which is read/write, and that you perform the actions described in Table 5-5 over the course of the week.
Table 5-5 Effect of Redundancy Setting on Backup Optimization
Day | Action | Result | Redundant Backup |
---|---|---|---|
Monday |
Take |
||
Tuesday |
|
The |
|
Wednesday |
|
The |
|
Thursday |
|
The |
Tuesday backup |
Friday |
|
The |
Tuesday backup |
Saturday |
|
The |
Tuesday backup |
Sunday |
|
The Tuesday backup is deleted. |
|
Monday |
|
The |
Wednesday backup |
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.
See Also:
5.6.3 Configuring Backup Optimization
By default, backup optimization is configured to OFF
. You can use the SHOW BACKUP OPTIMIZATION
command to view the current settings of backup optimization.
To configure backup optimization:
See Also:
"Using Backup Optimization to Skip Files" for examples of how to optimize RMAN backups
5.7 Configuring an Archived Redo Log Deletion Policy
You can use RMAN to create a persistent configuration that governs when archived redo logs are eligible for deletion from disk.
This section contains the following topics:
5.7.1 About Archived Redo Log Deletion Policies
You can use the CONFIGURE ARCHIVELOG DELETION POLICY
command to specify when archived redo logs are eligible for deletion.
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
... DELETE INPUT
or DELETE ARCHIVELOG
commands.
5.7.1.1 When the Archived Redo Log Deletion Policy Is Disabled
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. Archived redo logs are needed by Flashback Database if the logs were created later than SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'
.
See Also:
-
The
CONFIGURE ARCHIVELOG DELETION POLICY
entry in Oracle Database Backup and Recovery Reference for detailed information about policy options -
Oracle Data Guard Concepts and Administration to learn how to configure an archived log deletion policy in a Data Guard environment
5.7.1.2 When the Archived Redo Log Deletion Policy Is Enabled
You can use the CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP
integer
TIMES TO DEVICE TYPE
command to enable an archived log deletion policy. 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.
If the deletion policy is configured with the BACKED UP
integer
TIMES
clause, then a BACKUP ARCHIVELOG
command copies the logs unless integer
backups exist on the specified device type. If integer
backups of the logs exist, then the BACKUP ARCHIVELOG
command skips the logs. In this way, the archived log deletion policy functions as a default NOT BACKED UP
integer
TIMES
clause on the BACKUP ARCHIVELOG
command. You can override the deletion policy by specifying the FORCE
option on the BACKUP
command.
The archived log deletion policy also has options specific to a Data Guard environment. For example, if you specify the APPLIED ON STANDBY
clause, then RMAN can delete logs after they have been applied at all mandatory remote destinations. If you specify SHIPPED TO STANDBY
, then RMAN can delete logs when they have been transferred to all mandatory standby destinations.
See Also:
-
The
CONFIGURE ARCHIVELOG DELETION POLICY
entry in Oracle Database Backup and Recovery Reference for detailed information about policy options -
Oracle Data Guard Concepts and Administration to learn how to configure an archived log deletion policy in a Data Guard environment
5.7.2 Enabling an Archived Redo Log Deletion Policy
By default the archived redo log deletion policy is set to NONE
.
To enable an archived redo log deletion policy:
See Also:
-
Oracle Data Guard Concepts and Administration to learn how to manage archived redo logs in a Data Guard environment
-
Oracle Database Backup and Recovery Reference for a complete explanation of the
CONFIGURE ARCHIVELOG DELETION POLICY
command and the conditions under which archived logs are eligible for deletion
5.8 Configuring RMAN in a Data Guard Environment
If you use RMAN in a Data Guard environment, then you can use the CONFIGURE
command to register and configure settings for the physical databases in this environment.
RMAN uses the DB_UNIQUE_NAME
initialization parameter to distinguish one database from another. Thus, it is critical that you maintain the uniqueness of the DB_UNIQUE_NAME
in the Data Guard environment.
RMAN must be connected to a recovery catalog when you create or alter a configuration for a database in the Data Guard environment. If you use the SET DBID
command to set the DBID in the RMAN session, then you can configure a standby database even when RMAN is not connected as TARGET
to a database in the Data Guard environment. You can even create a configuration for a standby database that has not yet been created.
You can use the following forms of the CONFIGURE
command:
-
CONFIGURE DB_UNIQUE_NAME
defines a connection to a physical standby database and implicitly registers the new database.New standby databases are also automatically registered when RMAN connects as
TARGET
to a standby database for the first time. -
CONFIGURE FOR DB_UNIQUE_NAME
configures settings for a database in the Data Guard environment.For example, you can configure channels, default devices, and so on for a specified database or for all databases in the environment. You can use
SHOW ALL FOR DB_UNIQUE_NAME
to show the configuration for a specific standby database orSHOW ALL FOR DB_UNIQUE_NAME ALL
to show configurations for all known databases.
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.
See Also:
-
Oracle Data Guard Concepts and Administration to learn how to configure the RMAN environment for use with a standby database
-
Oracle Database Backup and Recovery Reference for a complete explanation of the
CONFIGURE ARCHIVELOG DELETION POLICY
command and the conditions under which archived logs are eligible for deletion