You can display the current snapshot control file details using the SHOW command: RMAN> show snapshot controlfile name;
Here’s some sample output:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/oracle/app/oracle/product/11.2.0/db_1/dbs/snapcf_O11R2.f'; # default For most situations, the default location and format of the snapshot control file are sufficient. This file doesn’t use much space or have any intensive I/O requirements. I recommend that you use the default setting.
If you have a good reason to configure the snapshot control file to a nondefault location, you can configure it as follows:
RMAN> configure snapshot controlfile name to '/oradump/O11R2/snapcf.ctl'; 469
7
CHAPTER 17 ■ CONFIGURING RMAN
You can set the snapshot control file back to the default like this:
RMAN> configure snapshot controlfile name clear;
10. Using a Recovery Catalog
RMAN always stores its latest backup operations in the target database control file. You can set up an optional recovery catalog to store metadata regarding RMAN backups. The recovery catalog is a separate schema (usually in a different database than the target database) that contains database objects (tables, indexes, and so on) that store the RMAN backup information. The recovery catalog doesn’t store RMAN
backup pieces—only backup metadata.
The main advantages of using a recovery catalog are as follows:
• Provides a secondary repository for RMAN metadata. If you lose all your control files and backups of your control files, you can still retrieve RMAN metadata from the recovery catalog.
• Stores RMAN metadata for a much longer period than is possible when you just use a control file for the repository.
• Provides access to all RMAN features. Some restore and recovery features are simpler when using a recovery catalog.
The disadvantages of using a recovery catalog are that this is another database you have to set up, maintain, and back up. When you start a backup and attempt to connect to the recovery catalog, if the recovery catalog isn’t available for any reason (server down, network issues, and so on), you must decide whether you want to continue with the backup without a recovery catalog.
You must also be aware of versioning aspects when using a recovery catalog. You need to make sure the version of the database you use to store the recovery catalog is compatible with the version of the target database. When you upgrade a target database, be sure the recovery catalog is upgraded (if necessary).
■
Note
See the last section in this chapter for details on how to implement a recovery catalog.
RMAN works fine with or without a recovery catalog. For most of the databases I maintain, I don’t use a recovery catalog; this eliminates having to set it up and maintain it. For me, simplicity takes precedence over the features available with the recovery catalog.
However, if you have good business reasons to use a recovery catalog, then implement and use one.
The recovery catalog isn’t that difficult to set up and maintain, and Oracle recommends that you use it.
11. Using a Media Manager
A media manager is required for RMAN to back up directly to tape. Several vendors provide this feature (for a cost). Media managers are used in large database environments like data warehouses where you may not have enough room to back up a database to disk. You may also have a disaster-recovery requirement to back up directly to tape.
470
CHAPTER 17 ■ CONFIGURING RMAN
If you have such requirements, then you should purchase a media-management package and implement it. If you don’t need to back up directly to tape, there’s no need to implement a media manager. RMAN works fine backing up directly to disk.
Keep in mind that many shops use RMAN to back up directly to disk and then have the system administrator back up the RMAN backups to tape after the RMAN backups to disk have finished. If you do this, you have to be sure your RMAN backups aren’t running the same time the tape backups are running (because you may get partial files backed up to tape).
12. Setting the CONTROL_FILE_RECORD_KEEP_TIME
Initialization Parameter
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum number of days a reusable record in the control file is retained before the record can be overwritten. The RMAN metadata is stored in the reusable section of the control file and therefore is eventually overwritten.
If you’re using a recovery catalog, then you don’t need to worry about this parameter because RMAN metadata is stored in the recovery catalog indefinitely. Therefore, when you use a recovery catalog, you can access any historical RMAN metadata.
If you’re only using the control file as the RMAN metadata repository, then the information stored there will eventually be overwritten. The default value for CONTROL_FILE_RECORD_KEEP_TIME is seven days: SQL> show parameter control_file_record_keep_time
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
You can set the value to anything from 0 to 365 days. Setting the value to 0 means the RMAN
metadata information can be overwritten at any time.
The CONTROL_FILE_RECORD_KEEP_TIME parameter was more critical in older versions of Oracle where it wasn’t easy to repopulate the control file with RMAN information in the event that metadata was overwritten. Starting with Oracle Database 10
g
, you can use the CATALOG command to quickly make the control file aware of RMAN backup files.
I recommend that you leave this parameter at seven days. If for some reason you have a retention policy greater than seven days, and you’re not using a recovery catalog, then you may want to consider increasing the value. The downside to increasing this parameter is that if you have a significant amount of RMAN backup activity, this can increase the size of your control file.
13. Configuring RMAN’s Backup-Retention Policy
RMAN retention policies allow you to specify how long you want to retain backups. RMAN has two mutually exclusive methods of specifying a retention policy:
• Recovery window
• Number of backups (redundancy)
With a recovery window, you specify a number of days in the past for which you want to be able recover to any point in that window. For example, if you specify a retention policy window of five days, then RMAN doesn’t mark as obsolete backups of datafiles and archive-redo logs that are required to be able to restore to any point in that five-day window:
RMAN> configure retention policy to recovery window of 5 days;
471
CHAPTER 17 ■ CONFIGURING RMAN
For the specified recovery, RMAN may need backups older than the five-day window because it may need an older backup to start with to be able to recover to the recovery point specified. For example, suppose your last good backup was made six days ago, and now you want to recover to four days in the past. For this recovery window, RMAN needs the backup from six days ago to restore and recover to the point specified.
You can also specify that RMAN keep a minimum number of backups. For example, if redundancy is set to 2, then RMAN doesn’t mark as obsolete the latest two backups of datafiles and archive-redo log files:
RMAN> configure retention policy to redundancy 2;
I find that a retention policy based on redundancy is easier to work with and more predictable with regard to how long backups are retained. If I set redundancy to 2, I know RMAN won’t mark as obsolete the latest two backups. The recovery-window retention policy depends on the frequency of the backups and the window length to determine whether a backup is obsolete.
You can report on backups that RMAN has determined to be obsolete per the retention policy as follows:
RMAN> report obsolete;
To delete obsolete backups, run the DELETE OBSOLETE command:
RMAN> delete obsolete;
You’re prompted with:
Do you really want to delete the above objects (enter YES or NO)?
If you’re scripting this, you can specify the delete not to prompt for input: RMAN> delete noprompt obsolete;
I usually have the DELETE NOPROMPT OBSOLETE command coded into the same shell script that backs up the database. This instructs RMAN to delete any obsolete backups and any obsolete archive-redo logs as specified by the retention policy. See the shell script later in this chapter for an example of how to automate the deleting of obsolete backups.
The default retention policy is redundancy of 1. You can completely disable the RMAN retention policy via the TO NONE command:
RMAN> configure retention policy to none;
To set the retention policy back to the default, use the CLEAR command: RMAN> configure retention policy clear;
14. Configuring the Archive-Redo Logs’ Deletion Policy
In most scenarios, I have RMAN delete the archive-redo logs based on the retention policy of the database backups. This is the default behavior. You can view the database retention policy using the SHOW command:
RMAN> show retention policy;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
To remove archive-redo logs (and backup pieces) based on the database retention policy, run the following:
RMAN> delete obsolete;
472
CHAPTER 17 ■ CONFIGURING RMAN
As of Oracle Database 11
g
, you can specify an archive-redo log deletion policy that is separate from the database backups. This deletion policy applies to both archive-redo logs outside of the FRA and in the FRA.
■
Note
Prior to Oracle Database 11g, the archive-deletion policy only applied to archive-redo logs associated with a standby database.
To configure an archive-redo log deletion policy, use the CONFIGURE ARCHIVELOG DELETION
command. The following command configures the archive-redo deletion policy so that archive-redo logs aren’t deleted until they have been backed up twice to disk:
RMAN> configure archivelog deletion policy to backed up 2 times to device type disk; To have RMAN delete obsolete archive-redo logs as defined by the archivelog-deletion policy, issue the following:
RMAN> delete archivelog all;
To see whether a retention policy has been set specifically for the archive-redo log files, use this command:
RMAN> show archivelog deletion policy;
To clear the archive deletion policy, do this:
RMAN> configure archivelog deletion policy clear;
■
Tip
Run the CROSSCHECK command before running the DELETE command. Doing so ensures that RMAN is aware of whether a file is on disk.
15. Setting the Degree of Parallelism
You can significantly increase the performance of RMAN backup and restore operations if your database server is equipped with the hardware to support multiple channels. If your server has multiple CPUs and multiple storage devices (disks or tape devices), then you can improve performance by enabling multiple backup channels.
If you require better performance from backup and restore operations and have hardware that facilitates parallel operations, you should enable parallelism and perform tests to determine the optimal degree. If you have hardware that can take advantage of parallel RMAN channels, there is little downside to enabling parallelism.
If you have multiple CPUs but just one storage-device location, you can enable multiple channels to write to and read from one location. For example, if you’re backing up to an FRA, you can still take advantage of multiple channels by enabling parallelism. Suppose you have four CPUs on a server and want to enable a corresponding degree of parallelism:
RMAN> configure device type disk parallelism 4;
473
CHAPTER 17 ■ CONFIGURING RMAN
You can also write to separate locations in parallel by configuring multiple channels associated with different mount points. For example:
RMAN> configure device type disk parallelism 4;
RMAN> configure channel 1 device type disk format '/ora01/O11R2/rman/rman1_%U.bk'; RMAN> configure channel 2 device type disk format '/ora02/O11R2/rman/rman2_%U.bk'; RMAN> configure channel 3 device type disk format '/ora03/O11R2/rman/rman3_%U.bk'; RMAN> configure channel 3 device type disk format '/ora04/O11R2/rman/rman4_%U.bk'; This code configures four channels that write to separate locations on disk. When you configure separate channels for different locations, make sure you enable the degree of parallelism to match the number of configured device channels. If you allocate more channels than the specified degree of parallelism, RMAN only writes to the number of channels specified by the degree of parallelism and ignores the other channels.
If you need to clear the degree of parallelism, you can do so as follows: RMAN> configure device type disk clear;
Similarly, to clear the channel device types, use the CLEAR command. This example clears channel 3: RMAN> configure channel 3 device type disk clear;
16. Using Backup Sets or Image Copies
When you issue an RMAN BACKUP command, you can specify the backup to be one of the following:
• Backup set
• Image copy
A backup set is the default type of backup that RMAN creates. A backup set contains backup pieces, which are binary files that only RMAN can write to or read from. Backup sets are desirable because they’re usually smaller than the datafiles being backed up. If you’re using Oracle Database 10
g
release 2
or higher, RMAN automatically attempts to create backup pieces with
unused block compression
. In this mode, RMAN reads a bitmap to determine which blocks are allocated and only reads from those blocks in the datafiles. This feature is supported only for disk-based backup sets and Oracle Secure Backup tape backups.
If you’re using a database version prior to Oracle Database 10
g
release 2, by default backup sets are created using
null block compression
(sometimes referred to more aptly as
block skipping
). In this mode, RMAN checks blocks in the datafile; if the blocks haven’t been used, they aren’t backed up.