Configuring RMAN

Go back to OCM 12c Preparation Project 

Hands On Lab – Index

[1] Configuring the Default Device for Backups: Disk or SBT
[2] Configuring the Default Type for Backups: Backup Sets or Copies
[3] Configuring Channels
[4] Configuring Parallel Channels for Disk and SBT Devices
[5] Configuring Control File and Server Parameter File Autobackups
[6] Configuring the Fast Recovery Area
[7] Configuring the Backup Retention Policy
[8] Backup Optimization and the CONFIGURE command
[9] Configuring an Archived Redo Log Deletion Policy
[10] Configuring RMAN in a Data Guard Environment
[11] Configuring Advanced Channel Options
[12] Configuring Advanced Backup Options
12.1 Configuring the Maximum Size of Backup Sets.
12.2 Configuring the Maximum Size of Backup Pieces.
12.3 Configuring Backup Duplexing.
12.4 Configuring Tablespaces for Exclusion from Whole Database Backups.
12.5 Configuring Compression Options.
[13] Configuring Backup Encryption.
13.1 About Backup Encryption
13.2 Configuring RMAN Backup Encryption Modes
13.3 Configuring the Backup Encryption Algorithm
[14] Configuring Auxiliary Instance Data File Names
[15] Configuring the Snapshot Control File Location
[16] Configuring RMAN for Use with a Shared Server
[17] Enabling Lost Write Detection

Showing and Clearing Persistent RMAN Configurations

To view or change your CONFIGURE command settings:

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default

Note:
You can save the output in a text file and use this command file to re-create 
the configuration on the same or a different database.

#You can also use the SHOW command with the name of a particular configuration.
SHOW RETENTION POLICY;
SHOW DEFAULT DEVICE TYPE;

#use the CONFIGURE ... CLEAR command to return any configuration to its default value

CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

[1] 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.

CONFIGURE DEFAULT DEVICE TYPE TO DISK
CONFIGURE DEFAULT DEVICE TYPE TO sbt

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 DISK DATABASE;

[2] 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.
The default backup type for disk is an uncompressed backup set.

Note:
Because RMAN can write an image copy only to disk, the backup type for 
tape can only be a backup set.

To configure the default type of backup:

Configure backup sets or image copies as the default backup type.
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed

The following examples configure compression for backup sets:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;

[3] Configuring Channels
An RMAN channel is a connection to a database server session. 
RMAN uses channels to perform most tasks.

Note: Only one type of channel is allocated, do not mix disk and SBT channels 
in the same backup 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;

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.

This example demonstrates how to configure an ASM disk location.

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

[4] 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

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;

Manually Overriding Configured Channels
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 using 
CONFIGURE DEVICE TYPE, CONFIGURE DEFAULT DEVICE, or CONFIGURE CHANNEL settings.

[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.

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP OFF;

By default, control file autobackups are turned on for CDBs and 
turned off for non-CDBs.

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. This 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 with 00 and has a maximum of FF.

For example, you can run the following command to specify a nondefault 
file name for the control file autobackup. In the file name, ? stands 
for ORACLE_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.

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:

1. SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block)
2. SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt)
3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

[6] 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.

->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.

Note:
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.

Note:
When your store backups, using OMF on top of ASM without using a 
fast recovery area is supported but discouraged.
It is awkward to directly manipulate files under ASM.

How Oracle Manages Disk Space in the Fast Recovery Area
Space in the fast recovery area is balanced among backups and archived logs 
that must be kept according to the retention policy, and other files that 
may be subject to deletion. Oracle Database does not delete eligible files 
from the fast recovery area until the space must be reclaimed for some other 
purpose. Files recently moved to tape are often still available on disk 
for use in recovery. The recovery area can thus serve as a cache for tape. 
When the fast recovery area is full, Oracle Database automatically deletes
eligible files to reclaim space in the recovery area as needed.

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.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*';

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
OR
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/disk1/fast_recovery_area' SCOPE = BOTH SID = '*';

Considerations When Setting the Size of the Fast Recovery Area

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)

Considerations When Setting the Location of the Fast Recovery Area
-> Multiple databases can have the same value for DB_RECOVERY_FILE_DEST, 
but one of the following must be true:

No two databases for which the DB_UNIQUE_NAME initialization parameters 
are specified have the same value for DB_UNIQUE_NAME.

For those databases where no DB_UNIQUE_NAME is provided, no two databases 
have the same value for DB_NAME.

When databases share a single recovery area in this way, the location should 
be large enough to hold the files for all databases.

Add the values for DB_RECOVERY_FILE_DEST_SIZE for the databases, then allow 
for overhead such as mirroring or compression.

To determine the optimum size for the fast recovery area:->

1. If you plan to use flashback logging or guaranteed restore points, 
then query V$ARCHIVED_LOG to determine how much redo the database generates 
in the time to which you intend to set DB_FLASHBACK_RETENTION_TARGET.

2. Set the recovery area size.
If you plan to use flashback logging or guaranteed restore points, then 
ensure that the size value obtained from Step 1 is incorporated into the 
setting. Set the DB_RECOVERY_FILE_DEST_SIZE initialization parameter by 
any of the following means:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*';

3. Set the recovery area location.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
OR
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/disk1/fast_recovery_area' SCOPE = BOTH SID = '*';

4. If flashback logging is enabled, then run the database under a normal 
workload for the time period specified by DB_FLASHBACK_RETENTION_TARGET. 
In this way, the database can generate a representative sample of flashback logs.

5. Query the V$FLASHBACK_DATABASE_LOG view as follows:

SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;

The result is an estimate of the disk space needed to meet the current 
flashback retention target,based on the database workload since 
Flashback Database was enabled.

6. If necessary, adjust the flashback log space requirement based on the 
actual size of flashback logs generated during the time period specified 
by DB_FLASHBACK_RETENTION_TARGET.

Disabling the Fast Recovery Area

1. If Flashback Database is enabled, then disable it before you disable 
the fast recovery area.
ALTER DATABASE FLASHBACK OFF;
2. If you are using the fast recovery area for archive logs, then set the 
initialization parameter LOG_ARCHIVE_DEST_n to use a non-fast recovery area location.
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/ORACLE/DBS/';

3. Disable the fast recovery area initialization parameter.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='';

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.

BACKUP
-> If you do not specify the FORMAT clause for disk backups, then RMAN 
creates backup pieces and image copies in the fast recovery area, with 
names in Oracle Managed Files (OMF) format.
-> If a fast recovery area is enabled, and if you do specify FORMAT on 
BACKUP or a channel, then RMAN creates the backup
in a platform-specific location rather than in the recovery area.

Control File Autobackup
->RMAN can create control file autobackups in the fast recovery area.
->Use the RMAN command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE 
TYPE DISK CLEAR to clear any configured format option for the control file 
autobackup location on disk.

RESTORE ARCHIVELOG
-> Explicitly or implicitly set a LOG_ARCHIVE_DEST_n parameter to 
   LOCATION=USE_DB_RECOVERY_FILE_DEST.
-> If you do not specify SET ARCHIVELOG DESTINATION to override this behavior,
   then RMAN restores archived redo log files to the fast recovery area.

RECOVER DATABASE or RECOVER TABLESPACE, RECOVER ... BLOCK, and FLASHBACK DATABASE

-> These commands restore archived redo log files from backup for use 
   during media recovery, as required by the command. RMAN restores any 
   redo log files needed during these operations to the fast recovery area 
   and deletes them after they are applied during media recovery.

-> To direct the restored archived logs to the fast recovery area,
set a LOG_ARCHIVE_DEST_n parameter to LOCATION = USE_DB_RECOVERY_FILE_DEST.

-> Verify that you are not using SET ARCHIVELOG DESTINATION to direct 
   restored logs to some other destination.

Note:
If DB_RECOVERY_FILE_DEST is specified and no LOG_ARCHIVE_DEST_n is specified,
then LOG_ARCHIVE_DEST_10 is implicitly set to the recovery area.
You can override this behavior by setting LOG_ARCHIVE_DEST_10 to an empty string.

[7] 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.

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. 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. The default retention policy is REDUNDANCY 1.

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.

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

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.

Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. 
This 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.

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.

[8] Backup Optimization and the CONFIGURE command

Run the 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.

Note:
When TO DESTINATION is used with BACKUP RECOVERY AREA or BACKUP RECOVERY FILES,
RMAN only skips backups of files that have identical backups in the 
TO DESTINATION location that you provide.

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 disk the database, all archived logs, and all backup sets:

BACKUP DEVICE TYPE DISK DATABASE PLUS ARCHIVELOG;
BACKUP DEVICE TYPE DISK 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;

To configure backup optimization:

SHOW BACKUP OPTIMIZATION;
CONFIGURE BACKUP OPTIMIZATION ON;

[9] 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.

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.

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'.

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.

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

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.

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

[10] Configuring RMAN in a Data Guard Environment

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
or
SHOW ALL FOR DB_UNIQUE_NAME ALL to show configurations for all known databases.

[11] Configuring Advanced Channel Options

11.1 Configuring Specific Channels: 
Examples sends disk backups to two different disks. 
Configure disk channels as follows:

CONFIGURE DEFAULT DEVICE TYPE TO disk; # backup goes to disk
CONFIGURE DEVICE TYPE disk PARALLELISM 2; # two channels used in parallel
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U' # 1st channel to disk1
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U' # 2nd channel to disk2
BACKUP DATABASE; # backup - first channel goes to disk1 and second to disk2

11.2 Limit backup sets and pieces

=> Configure exact size for the backup sets.
CONFIGURE MAXSETSIZE TO 20M;

=> RMAN cretes 6 different backup piece 100MB each for a 600M backup file, 
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 100M;

11.3 Limit I/O bandwidth consumption using RATE parameter
ALLOCATE CHANNEL ch1 TYPE DISK RATE 40M;

11.4 Channel parallel backup and restore operations

#If you were asked to allocate 2 channels, split the process and  
create each part of the backup in the different folder by using 
CONFIGURE CHANNEL n DEVICE TYPE DISK FORMAT command.

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup1/file_%p_%d_%U.bkp';
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup2/file_%p_%d_%U.bkp';

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;

RMAN> BACKUP DATAFILE 2,3;

[12] Configuring Advanced Backup Options

12.1 Configuring the Maximum Size of Backup Sets.

-> The value set by the CONFIGURE MAXSETSIZE command is a default for the given channel.
You can override the configured MAXSETSIZE value by specifying a MAXSETSIZE 
option for an individual BACKUP command.

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
CONFIGURE MAXSETSIZE TO 7500K;
BACKUP TABLESPACE users;
BACKUP TABLESPACE tools MAXSETSIZE 5G;

> The backup of the users tablespace uses the configured SBT channel and 
the configured default MAXSETSIZE setting of 7500K.
> The backup of the tools tablespace uses the MAXSETSIZE setting of 5G 
specified in the BACKUP command.

12.2 Configuring the Maximum Size of Backup Pieces.

For example, to limit the backup piece size to 2 gigabytes or less,
you can configure the automatic DISK channel as follows and then run BACKUP DATABASE:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
BACKUP DATABASE;

12.3 Configuring Backup Duplexing.

Note: A control file autobackup is never duplexed.

The CONFIGURE settings for duplexing only affect backups of data files, 
control files, and archived logs into backup sets, and do not affect 
image copies.

RMAN can duplex backups to either disk or tape,but cannot duplex backups 
to tape and disk simultaneously. When backing up to tape, ensure that the 
number of copies does not exceed the number of available tape devices.

The following examples show possible duplexing configurations:

# Makes 2 disk copies of each data file and control file backup set
# (autobackups excluded)
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;

# Makes 3 copies of every archived redo log backup to tape
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 3;

12.4 Configuring Tablespaces for Exclusion from Whole Database Backups.

You can run CONFIGURE EXCLUDE FOR TABLESPACE to exclude the specified 
tablespace from the BACKUP DATABASE command.
The exclusion condition applies to any data files that you add to this 
tablespace in the future.

For example, you can exclude testing tablespaces cwmlite and example from
whole database backups as follows:
CONFIGURE EXCLUDE FOR TABLESPACE cwmlite;
CONFIGURE EXCLUDE FOR TABLESPACE example;

If you run the following command, then RMAN backs up all tablespaces in 
the database except cwmlite and example:
BACKUP DATABASE;

You can still back up the configured tablespaces by explicitly specifying 
them in a BACKUP command or by specifying the NOEXCLUDE option on a 
BACKUP DATABASE command. For example, you can enter one of the following commands:

BACKUP DATABASE NOEXCLUDE; #backs up database, including cwmlite and example
BACKUP TABLESPACE cwmlite, example; # backs up only cwmlite and example

You can disable the exclusion feature for cwmlite and example as follows:
CONFIGURE EXCLUDE FOR TABLESPACE cwmlite CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE example CLEAR;

RMAN includes these tablespaces in future whole database backups.

12.5 Configuring Compression Options.

RMAN supports precompression processing and binary compression of backup sets.
The CONFIGURE COMPRESSION ALGORITHM command enables you to configure compression options.

About RMAN Precompression Block Processing
-> Better backup compression ratios are achieved by consolidating the 
free space in each data block, and setting that free space to binary zeroes. 
This precompression processing stage has the most benefit for data blocks 
that have been the subject of many deletes and inserts operations.
Conversely, it has no effect on data blocks that are still in their initial 
loaded state.

-> The OPTIMIZE FOR LOAD option controls precompression processing. 
By specifying the default, OPTIMIZE FOR LOAD TRUE, you ensure that RMAN 
optimizes CPU usage and avoids precompression block processing. 
By specifying OPTIMIZE FOR LOAD FALSE, RMAN uses additional CPU resources to
perform precompression block processing.

About RMAN Supported Compression Levels
> Oracle Database provides two categories of compression algorithms: 
a default compression algorithm and a group of compression algorithms 
available with the Oracle Advanced Compression option.
The default algorithm is a standard feature of Oracle Database while the 
Oracle Advanced Compression option is a separately purchased option.

CONFIGURE COMPRESSION ALGORITHM 'BASIC';

> If you have enabled the Oracle Advanced Compression option, you can 
choose from the following compression levels:
HIGH -> Best suited for backups over slower networks where the limiting factor is network speed.
MEDIUM -> Recommended for most environments. Good combination of compression ratios and speed.
LOW -> Least effect on backup throughput.

[13] Configuring Backup Encryption.

13.1 About Backup Encryption

The V$RMAN_ENCRYPTION_ALGORITHMS view contains a list of encryption algorithms 
supported by RMAN. If no encryption algorithm is specified, then the default 
encryption algorithm is 128-bit Advanced Encryption Standard (AES).
RMAN encryption requires the COMPATIBLE initialization parameter at a 
target database to be at least 10.2.0.

RMAN offers the following encryption modes:

Transparent Encryption of Backups
-> This is the default mode and uses the Oracle software keystore.
A keystore is a password-protected container used to store a Transparent 
Data Encryption (TDE) key. In previous releases, this container was referred 
to as a wallet.

Password Encryption of Backups
-> This mode uses only password protection. You must provide a password 
when creating and restoring encrypted backups.

Dual Mode Encryption of Backups
-> This mode requires either the keystore or a password.

Note:
Keystore-based encryption is more secure than password-based encryption 
because no passwords are involved. Use password-based encryption only 
when it is absolutely necessary because your backups must be transportable.

Encrypted backups are decrypted automatically during restore and recovery,
if the required decryption keys are available. Each backup set gets a separate key.
The key is stored in encrypted form in the backup piece. The backup is decrypted with
keys obtained by a user-supplied password or the Oracle software keystore.

The Oracle Secure Backup media management software is the only supported 
interface for making encrypted RMAN backups directly to tape. 
RMAN issues an ORA-19919 error if you attempt to create encrypted RMAN 
backups using a media manager other than Oracle Secure Backup.

When you use the BACKUP BACKUPSET command with encrypted backup sets, 
the backup sets are backed up in encrypted form. Because BACKUP BACKUPSET 
copies an already-encrypted backup set to disk or tape, no decryption key 
is needed during BACKUP BACKUPSET. The data is never decrypted during any 
part of the operation. The BACKUP BACKUPSET command can neither encrypt 
nor decrypt backup sets.

Transparent encryption can create and restore encrypted backups with no 
DBA intervention,if the required Oracle key management infrastructure is
available. Transparent encryption is best suited for day-to-day backup 
operations, where backups are restored to the same database from which 
they were created. Transparent encryption is the default for RMAN encryption.

Transparent backup encryption supports both the auto-login software keystore 
and password-based software keystore. When you use the auto-login software 
keystore, encrypted backup operations can be performed at any time, because 
the auto-login keystore is always open. When you use the password-based 
software keystore, the keystore must be opened before you can perform 
backup encryption.

Caution:
If you use an auto-login keystore, do not back it up along with your 
encrypted backup data, because users can read the encrypted backups if 
they obtain both the backups and the autologin keystore. It is safe to 
back up the Oracle keystore because that form of the keystore cannot be
used without the keystore password.

Caution:
If you lose your Oracle keystore, then you are unable to restore any 
transparently encrypted backups.

To use password encryption, use the SET ENCRYPTION ON IDENTIFIED BY password 
ONLY command in your RMAN scripts.

Caution:
If you forget or lose the password that you used to encrypt a 
password-encrypted backup, then you are unable to restore the backup.

Dual Mode Encryption of Backups
-> When restoring a dual-mode encrypted backup, you can use either the 
Oracle keystore or a password for decryption.

Caution:
If you forget or lose the password that you used to encrypt a dual-mode 
encrypted backup and you also lose your Oracle keystore, then you are 
unable to restore the backup.

To create dual-mode encrypted backup sets, 
specify the SET ENCRYPTION ON IDENTIFIED BY password command in your RMAN scripts.

13.2 Configuring RMAN Backup Encryption Modes

You can use the CONFIGURE command to persistently configure transparent 
encryption of backups.

To configure the environment so that all RMAN backups are encrypted:
CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE ENCRYPTION FOR DATABASE OFF;

SET ENCRYPTION ON;
SET ENCRYPTION OFF;

13.3 Configuring the Backup Encryption Algorithm

You can use the CONFIGURE command to persistently configure the default 
algorithm to use for encryption when writing backup sets. 
Possible values are listed in V$RMAN_ENCRYPTION_ALGORITHMS. 
The default algorithm is AES 128-bit.

CONFIGURE ENCRYPTION ALGORITHM TO 'AES256';

[14] Configuring Auxiliary Instance Data File Names

Assume that you are performing data file tablespace point-in-time recovery (TSPITR) 
or performing data transfer with RMAN. In this case, you may want to set 
the names of data files in the auxiliary instance before starting the TSPITR or
database duplication.

For example, you might configure a new auxiliary name for data file 2 as follows:
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/newdisk/datafiles/df2.df';
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;

[15] Configuring the Snapshot Control File Location

When RMAN needs a read-consistent version of the control file, it creates 
a temporary snapshot control file. RMAN needs a snapshot control file 
when resynchronizing with the recovery catalog or when making a backup of
the current control file.

The default location for the snapshot control file is platform-specific 
and depends on the Oracle home of each target database.

For example, the default file name on some Linux platforms is 
$ORACLE_HOME/dbs/snapcf_@.f.

If a fast recovery area is configured for a target database, 
then the default location for the snapshot control file is not 
the fast recovery area.

Viewing the Configured Location of the Snapshot Control File
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;

Setting the Location of the Snapshot Control File
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';

Note:
In an Oracle Real Application Clusters (Oracle RAC) environment, 
the snapshot control file location must be on shared storage—that is, 
storage that is accessible to all Oracle RAC instances.

[16] Configuring RMAN for Use with a Shared Server

-> RMAN cannot connect to a target database through a shared server dispatcher.
RMAN requires a dedicated server process. If your target database is configured 
for a shared server, then you must modify your Oracle Net configuration to 
provide dedicated server processes for RMAN connections.

-> To ensure that RMAN does not connect to a dispatcher when a target database 
is configured for a shared server, the net service name used by RMAN must 
include (SERVER=DEDICATED) in the CONNECT_DATA attribute of the connect string.

To use RMAN with a shared server:

vi tnsnames.ora
inst1_ded =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
(CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated))
)

[17] Enabling Lost Write Detection

A data block lost write occurs when an I/O subsystem acknowledges the completion 
of the block write,but the write did not occur in the persistent storage. 
On a subsequent block read, the I/O subsystem returns the stale version 
of the data block, which might be used to update other blocks of the database,
thereby corrupting it...

You can set the DB_LOST_WRITE_PROTECT initialization parameter to TYPICAL 
or FULL so that a database records buffer cache block reads in the redo log. 
The default setting is NONE. When the parameter is set to TYPICAL,
the instance logs buffer cache reads for read/write tablespaces in the redo log, 
but not read-only tablespaces. When set to FULL, the instance also records reads 
for read-only tablespaces. The performance overhead for TYPICAL
mode is approximately 5 to 10% and potentially higher for FULL mode.

Lost write detection is most effective when used with Data Guard. 
In this case, you set DB_LOST_WRITE_PROTECT in both primary and standby databases.
When a standby database applies redo during managed recovery, it reads the
corresponding blocks and compares the SCNs with the SCNs in the redo log. 
If the block SCN on the primary database is lower than on the standby database, 
then it detects a lost write on the primary database and throws an 
external error (ORA-752). If the SCN is higher, it detects a lost write on 
the standby database and throws an internal error (ORA-600 [3020]). 
In either case, the standby database writes the reason for the failure
in the alert log and trace file.

To repair a lost write on a primary database, you must initiate failover 
to the standby database. To repair a lost write on a standby database, 
you must re-create the entire standby database or restore a backup of only 
the affected files.

Enabling lost write detection is also useful when you are not using Data Guard.
In this case, you can encounter a lost write in two ways: 
during normal database operation or during media recovery.

In the first case, there is no direct way to detect the error. 
Indirect symptoms such as inconsistent tables cannot be
unambiguously traced to the lost write. If you retained a backup made 
before the suspected lost write, however, then you can restore this backup 
to an alternative location and recover it. To diagnose the problem, recover 
the database or tablespace to the SCN of the stale block read, which then 
generates the lost write error (ORA-752).

If a lost write error is encountered during media recovery, the only response 
is to open the database with the RESETLOGS option. The database is in a 
consistent state, but all data after the RESETLOGS SCN is lost. If you 
recover a backup made after database creation, you have no guarantee that 
other stale blocks have not corrupted the database. This possibility exists 
because the restored backup may have been made after an earlier lost write.
To guarantee that no lost writes have corrupted the database, 
you must perform media recovery from database creation,
which is not a practical strategy for most database environments.

======================
Patch to Documentation
======================
Database Backup and Recovery User's Guide
-> 5 Configuring the RMAN Environment
-> 6 Configuring the RMAN Environment: Advanced Topics

Database Backup and Recovery Reference -> CONFIGURE

Thank you for visiting this blog…