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…
