In this section we will look at the architecture associated with RMAN. First we will look at the two different methods RMAN uses to store database backups, RMAN backup sets and image copies. Next, we will look at other features of RMAN including block checking, channels and the backup catalog.
When you use RMAN to back up a database, one method you can use to store the backed up database data is by using backup sets. Backup sets contain one or more datafiles or archive logs, but cannot contain both. Control file backups can also be contained in datafile backup sets. A backup set constitutes a complete full or incremental backup. Backup sets typically can go to disk or to tape, and there may be one or more sets for any given backup command, depending on how many backup devices you have available. As a result, you can parallelize writing to the backup sets and hopefully speed up the operation.
There are two kinds of backup sets, datafile backup sets and archivelog backup sets. Datafile backup sets contain backups of datafiles and/or control files. Archivelog backup sets contain archived redo logs. A backup set can contain one or more backup pieces, each piece being a single output file. You can restrict the size of the backup pieces so that it does not exceed a particular operating system or file system maximum file size. During the creation of the datafile backup set, Oracle provides block compression and block verification. When doing block compression Oracle will skip data blocks that have never been used, reducing the size and run time of the backup being executed.
Datafile backups can be multiplexed. This means that a single datafile can be stored noncontiguously in different backup pieces. Multiplexing also allows Oracle to selectively determine which tablespace or datafile is backed up. One benefit of multiplexing is that during the backup process RMAN may switch between backing up data in various tablespaces and datafiles, depending on the activity of the datafiles or tablespaces. If activity increases in one datafile, or within the tablespace, RMAN may choose to work on another tablespace or datafile of the backup, returning to the remaining tablespace or datafile when its activity has decreased or it is the only remaining piece of the backup.
RMAN allows you to create two different types of datafile backup sets. These two different types of datafile backups sets are:
An example of a multi-level, incremental backup would be a case where you would implement a three-level backup strategy. To begin using a multi-level backup strategy, you would take a level 0 backup of the database, which would be a full backup, once a month as the base backup. Following that, you would take daily level 2 backups providing backups of daily changes. Once a week, throughout the month, you would perform a level 1 backup, which would have the effect of being a cumulative backup of all the daily backups you did previously during the week. Once you have performed this backup, the daily backups that were taken during the previous week are no longer needed for recovery. Finally, when a new month rolls around, you will again take a level 0 backup of the entire database. Once you have taken this backup, the previous months weekly (level 1) backups will no longer need to be retained.
An example of this backup strategy is diagrammed below.
Legend: L0 = Level One Backup, L1 = Level Two Backup, L2 = Level Three Backup
In addition to backup sets, RMAN allows you to do image copies of datafiles. These are exact copies of datafiles that you can use as-is to perform recovery; no compression is performed. An image copy is not unlike an operating system copy of the file, except that it has these benefits:
Image copies can be made only to disk and can be restored to another disk, if need be, to prevent overwriting the original datafile with the same name. You can also use operating system-created image copies and record them in the recovery catalog.
One central benefit of RMAN is that control and checksum information is contained in the backup pieces, providing a way to validate the data and protecting from a possible corrupted backup set. During the backup process, if RMAN detects corruption, it logs the corruption to the V$BACKUP_COR-RUPTION and V$COPY_CORRUPTION views for later reporting. The corrupted block is also reported to the control file and the alert log of the database being backed up.
You can limit the number of bad blocks that RMAN backs up without failing the backup job by using the SET MAX CORRUPT clause in RMAN, as shown here:
set maxcorrupt for datafile 1 to 0;
This causes the backup to fail if any corrupt blocks are found. You can disable block corruption by using the NOCHECKSUM option. Note: by default, any error will cause RMAN to exit with an error code.
Before you can execute a backup or recovery using RMAN, you must allocate a channel between the backup processes and the operating system. The following operations in RMAN must have at least one channel allocated to operate correctly:
To allocate a channel, you use the RMAN command ALLOCATE CHANNEL. When you allocate the channel, you also specify the type of device that will be used for the operation that will occur through that channel. Multiple channels can be allocated, allowing for multiple backup sets or file copies to run in parallel by the execution of just a single RMAN command. Each time you issue an ALLOCATE CHANNEL command, a separate connection between the backup processes and the operating system is created.
The RMAN architecture revolves primarily around the recovery catalog. The recovery catalog is an Oracle database and associated objects in a schema that are created to manage RMAN backups. Although the recovery catalog is not required to use RMAN, some of the backup/recovery functions are not available without it being set up correctly. Generally, to set up a catalog, you identify the database in which the catalog will exist. This database should be separate from other Oracle databases. Once you have identified or created the database that will contain the recovery catalog, you create a user in that database and grant that user the RECOVERY_CATALOG_OWNER role. Then you will create the recovery catalog, create any backup scripts and begin to use the recovery catalog.
So, what are the benefits of using the recovery catalog? RMAN does not require the recovery catalog in most cases. Without the recovery catalog in place however, these RMAN features are not available:
The bottom line is that Oracle strongly recommends that you use the recovery catalog.
Once you have set up the recovery catalog, you use the RMAN executable in concert with RMAN manual commands or stored scripts to back up, recover, and report on backups. The next few sections of this topic look in more detail at the setup, backup, recovery, and reporting functions of RMAN. Finally, the topic returns (in much more detail) to the recovery catalog and addresses maintenance issues and reporting from the views Oracle supplies for the DBAs. First, let's look at how to set up the catalog and use it to register, back up, and recover databases.