Chapter 24 *

Oracle8: Using Recovery Manager *

Introducing Recovery Manager *

Identifying Recovery Manager Architecture and Benefits *

Exercises *

Defining the Recovery Catalog *

Exercises *

Identifying Backup Types and Commands *

Backup Sets, Image Copies, and Tags *

Backup and Recovery Options with RMAN *

Preventing Problems *

New Control File Features *

Exercises *

Listing Recovery Manager Dictionary Views *

Exercises *

Using Catalog Commands and Reports *

Starting Recovery Manager *

Exercises *

Maintaining the Recovery Catalog *

Exercises *

Generating Reports and Lists from the Recovery Catalog *

Exercises *

Using RUN Commands and Scripts *

Channels, Scripts, and Attributes for RUN Commands *

Exercises *

Using the BACKUP Command *

Exercises *

Using the COPY Command *

Exercises *

Using the SWITCH and RESTORE Commands *

Exercises *

Using the RECOVER Command *

Exercises *

Chapter Summary *

Two-Minute Drill *

Chapter 24

Oracle8: Using Recovery Manager

In this chapter, you will understand and demonstrate knowledge in the following areas:

Until Oracle8, the DBA required skills for database backup and recovery that blended knowledge of the underlying operating system and available Oracle tools. With the release of Oracle8 comes the introduction of a new tool to assist the DBA with executing the backup and recovery strategy for the Oracle database. This new tool is called Recovery Manager, or RMAN. The purpose of this chapter is to cover the use and features of this new tool, the language constructs it possesses, and the advantages it offers over Oracle7 backup and recovery strategy.

Introducing Recovery Manager

In this section, you will cover the following topics related to introducing Recovery Manager:

RMAN possesses many features to ease the job of backup and recovery. This section will introduce you to the architecture and benefits of RMAN, along with the types of backups that are possible with the tool. The use of the RMAN catalog will also be presented in this section. Finally, the new data dictionary views provided to support RMAN are explained and presented.

Identifying Recovery Manager Architecture and Benefits

Recovery Manager, or RMAN, is used to manage the creation of database backups for the purpose of recovery. RMAN can be run as its own utility, or the functionality of RMAN can be used as a set of library functions that are embedded into another program or script. RMAN interfaces directly with Oracle8 to handle backup and recovery operations with the use of PL/SQL. The actual work of producing the backup or applying the recovery is done within Oracle8. RMAN also maintains a recovery catalog, or collection of backups taken to improve the DBA’s ability to provide fast and effective recovery. RMAN works in conjunction with other products designed to support the mechanics of backup and recovery, such as offline storage media.

RMAN’s approach to backup is as follows. The entire database can be backed up using RMAN, or it can be used for individual tablespaces and datafiles. This functionality is the same as that provided in Oracle8’s predecessor. In addition, RMAN supports backup to the granularity of changed data blocks, a function not provided in Oracle7. This new feature can correlate backup time directly to the amount of change made to a database rather than to the size of the database. Consider the impact of this change—instead of backups on infrequently changed large databases for DSS or data warehouses taking hours because the database stores 20G or more of data, RMAN can complete the backup task in only a short while by targeting only the changed blocks for backup.

RMAN also eases the task of automating overall database backup and recovery. If there is a backup operation executed repeatedly, the DBA can create a backup script in an Oracle-supported utility. This utility also lets the DBA generate logs of backup and recovery activity. RMAN is well integrated with the Oracle8 database architecture, and the backup and recovery operations take advantage of several of the database’s new features. These features include parallel backup and recovery, definition of conditions for backing up datafiles and targeting locations rather than simply listing the datafiles to back up and their correlated storage devices, and even compression of unused blocks.

RMAN can be run in two ways: either from the operating system command line as a batch interface or in an interactive mode, or with the graphical user interface provided by Oracle Enterprise Manager. There is even an application programming interface (API) available to allow other programming languages to use RMAN to manage Oracle backup and recovery.

Exercises

1. What is RMAN? How can DBAs interface with RMAN?
2. What new category of backup does RMAN provide?
3. Identify some benefits for using RMAN in backup and recovery.

Defining the Recovery Catalog

RMAN works in conjunction with another new feature: the recovery catalog. The recovery catalog is a collection of information about the backup and recovery operations, along with the actual backups taken with RMAN. Ideally, it is stored in a separate database from the production system whose backup and recovery processing is being handled by RMAN. The recovery catalog is not created automatically when Oracle8 is installed. The DBA must create it separately with the catrman.sql script provided with the Oracle database distribution software; the script is found in the rdbms/admin subdirectory of the Oracle software home directory. It is also recommended that a schema owner be created for RMAN to run under on the recovery catalog in order to manage the scripts and other information generated by RMAN effectively. After creating the recovery catalog in a separate database, the DBA makes that other database available to RMAN via remote links. Once created, the recovery catalog is its own database, and must be backed up as such. Thus, a symbiotic relationship is formed between the production or "target" database and the recovery catalog "backup" database; as the backup supports recovery for the production database, the production database can act as the backup for the recovery catalog database.

The contents of the recovery catalog include the following components. The physical structure of the production database is stored on the recovery catalog. Also stored in the recovery catalog are the datafiles of the database and the archived redo logs. Further, a set of copies for datafiles and archived redo logs are stored in the database. This recovery catalog is a repository of information useful to and maintained by RMAN, and is never directly accessed by the production database itself. Any structural changes to the production database should be maintained in the recovery catalog by RMAN. Instructions on how to perform this task will be covered shortly. Since a great deal of information about the structure of the database is taken from control files and rollback segments, the production database must be open in order to use RMAN to execute its processing. If for some reason RMAN attempts to execute something improperly, or attempts to use a corrupt file, there are integrity checks built into the Oracle database to prevent RMAN from causing inadvertent damage.

Oracle can also operate RMAN in the absence of the recovery catalog under certain conditions. These conditions include the maintenance of small databases where the use of an additional database to store the recovery catalog would be more trouble than it is worth. Since much of the structural information about the Oracle database maintained in the recovery catalog is taken from the control file anyway, RMAN in this case can go directly to the source for structural information about the database it maintains. There are, however, some limitations for using RMAN without the recovery catalog. For one thing, the use of automated scripts for executing routine backup operations is not supported without the recovery catalog. The operations involving a tablespace point-in-time recovery are also not supported without the use of the recovery catalog. Finally, recovery when the control file doesn’t reflect the current structure of the Oracle database cannot be accomplished using RMAN without the recovery catalog. These limits can be mild or severe, depending on the level of failure encountered on the production database.

Exercises

1. What is the recovery catalog? How does the DBA create it?
2. What are the components of the recovery catalog?
3. Under what situations might the DBA not want to use the recovery catalog? What are the limitations for doing so?

Identifying Backup Types and Commands

There are many features to RMAN. These features include enhanced backup and recovery operations, full-featured command syntax, changes to the control file to support RMAN, and other items covered in this discussion. The first item up for discussion is how RMAN interfaces with the database. As mentioned, RMAN uses several PL/SQL packages to interface with the different components of backup and recovery—Oracle8, the operating system, and third party backup products and/or offline storage media. With the use of these packages, Oracle can interface directly with the operating system to define the disks that need backing up and the disks that contain restore or recovery information. In this way, the DBA needn’t interface with the operating system as part of backup and recovery, as was required in prior versions of Oracle. In addition, scripts can be defined to handle routine backup and recovery operations using Oracle-supported products. This increases the level of service the DBA can expect from the Oracle database. And, with the use of the RMAN API, Oracle can communicate directly with backup and recovery products offered by other vendors, making the overall backup and recovery process available with the Oracle database much improved.

There are a host of maintenance commands the DBA should understand in order to use RMAN. These commands register the production database with the recovery catalog to store all information about the production database. There are commands used for resetting the recovery catalog after performing incomplete recovery as well. Recall from the discussion of incomplete recovery in Chapter 13 that the archived redo logs from after the point-in-time recovery should be discarded, or else data corruption issues will ensue. The recovery catalog can be used to reflect changes to the structure of the production database, and to reflect the status of the backup control files.

RMAN also supports a set of commands that perform the core functionality of the tool—backup, restore, and recover operations. The backup, restore, and recover operations can be used whenever the production database needs any of these operations performed, either with the use of the run command whereby they are executed immediately, or through the creation of a script. The script is then kept in the recovery catalog for reuse. The script is then executed with the use of the run command as well, and should be backed up into a flat file that can be stored externally from the Oracle recovery catalog in the event the recovery catalog is not available and the scripted operation needs to be run.

RMAN supports the logging of backup, restore, and recover operations as well. There are two categories of logging supported by RMAN: reports and lists. A report gives information on several areas, including datafile components that require incremental backup or redundant copies, datafile components that haven’t been backed up for a certain time period, unrecoverable datafile components, and unneeded backups. Reports are produced with the report command. A list gives information about several areas of the database backup and recovery plan, including backups and backup copies containing a given list of datafile components or datafile components belonging to a specified tablespace.

Backup Sets, Image Copies, and Tags

Backups for datafile or archived redo log components can be placed into collections called backup sets. There are two types of backup sets: archivelog backup sets and datafile backup sets. As the names imply, each type of backup set consists either of datafiles for database recovery or archived redo logs for recovery, but not both. Usually backup sets can written to offline storage such as tape or online storage such as a backup disk. One suggestion is for DBAs to develop a system whereby backup sets are placed on disk and copied to tape periodically. After a specified period, the backup set on disk is eliminated to make room for more recent backup sets. In this fashion, the DBA may improve recovery time in certain situations by eliminating the often time-consuming step of retrieving backup sets from tape where the appropriate backup was on disk. RMAN also manages an important process—the segmented movement of backup sets from disk to tape and vice versa during backup and recovery. This process is called staging.

Datafile backup sets have several features. The first is a user-specified parameter that limits the number of datafiles backed up at the same time to the same backup set. Moderating this activity allows the DBA to strike a good balance between backing up datafile information to tape efficiently without causing undue burden on a particular datafile, thereby limiting online performance. The datafile backup set can be created from a production datafile or from a backup datafile. Full and incremental backups of datafiles are also supported with RMAN, combining incremental and full database backup and recovery features of EXPORT/IMPORT with the ability to make backups of physical database components like datafiles with redo log archives to allow complete recovery to the point of failure. More information about incremental and full backups using RMAN will be covered shortly.

Backup sets can also be multiplexed. Multiplexed backup sets contain data from many datafiles stored together. Recall that the server process reads data from datafiles into the buffer cache for use in user SQL statements. The server process also retrieves data blocks for RMAN to create backup sets. Since multiple datafiles and tablespaces can be accessed at the same time by one server process, the server process can retrieve blocks from one datafile when the datafile is less active from online processing, then switch off to another datafile when activity on the first one picks up. The data will then be ported into the backup set in a nonsequential manner, as illustrated in Figure 24-1, which can keep the stream of data flowing smoothly from the production database onto offline storage. The only impediment to smooth backup in this scenario is the need to change the tape, which is still the responsibility of the DBA or systems administrator. Control files can be included in a datafile backup set; however, the control file information will not be multiplexed with datafile information.

Figure 1: Multiplexing datafile backup set information

Once the backup set is completed, each component file of a backup set is called a piece. When RMAN creates the backup set out of datafiles or archived redo logs, it produces a single file of sequentially stored blocks from all datafiles or archive logs stored in the backup set for each tape volume used in the backup. If multiplexing is used, the piece will contain blocks from multiple datafiles, each file stored in nonsequential order. In order to recover a database, the necessary datafiles must first be restored from pieces of the backup set. Datafile information can be distributed to different pieces on different tapes explicitly by the DBA or automatically by RMAN.

RMAN also supports the backup of individual datafiles in the database by creating image copies of these files. An image copy cannot be placed on offline storage, but can be made to disk. Unlike datafiles in backup sets, image copy datafiles needn’t be restored before they are used in database recovery. RMAN allows the DBA to define a special name used in conjunction with an image copy or a backup set. This name is called a tag. The tag may be up to 30 characters in length, like a database object such as a table, and has similar naming restrictions. The tag can then be used in conjunction with restoring the backup set or image copy. Multiple backup objects can have the same tag. If a tag is specified for use in recovery, and more than one object corresponds to that tag, then the most recent object that is fit to use for the recovery will be the one RMAN uses.

Backup and Recovery Options with RMAN

Datafile backup sets can consist of either full or incremental backups. A full backup of a datafile consists of all blocks in a datafile, while an incremental backup of a datafile consists only of the datafile’s blocks that changed since the last backup was taken. Thus, the DBA can reduce both the time it takes to obtain a backup of the database and the amount of storage that the backup will take. The DBA also has the option to take cumulative backups, which will consolidate the information stored in several incremental backups into one cumulative incremental backup of all changes made since the last full backup.

Multiple-level incremental backup strategies are also supported. Each level of incremental backup will capture data changes made according to specified time intervals. There are eight levels used in RMAN for multiple-level incremental backup strategy, numbered 0 through 7. Level 0 is a full backup of the datafile, level 1 is a monthly incremental, level 2 is a weekly incremental, level 3 is a daily incremental, and so on. The subsequent incremental backup strategy a DBA may choose to implement can take into account these different levels. Consider the following backup strategy. The baseline level 0 backup is made, followed by level 1 backups once a month, level 2 backups once a week, and level 3 backups once a day. Recovery of a datafile then consists of applying the most recent level 0 backup, then any level 1 backups occurring since then. The next step is to apply all level 2 backups made since the most recent level 1, followed by all level 3 backups made since the most recent level 2. This process continues until the supply of backups made is exhausted, at which point archived redo information taken after the most recent backup can be applied for full recovery to point of failure. RMAN also can interact with image copies of datafiles made without its assistance, such as in the case of mirrored datafiles on multiple disks used to provide highly fault-tolerant databases. However, these copies must be catalogued.

Database backup and recovery operation may also run in parallel. RMAN handles making backup and recovery operations run in parallel internally by running multiple sessions that have the ability to communicate with one another. Parallelism is used for the execution of only one command at a time. In other words, two commands (i.e., a backup on one part of the database while another is being recovered) cannot be run in parallel, but a backup operation can run in parallel, followed by a recover operation running in parallel.

A final change made to backup and recovery strategy in Oracle8 is the ability to handle point-in-time recovery of individual tablespaces. Recall from Chapter 13 that point-in-time recovery of an individual tablespace leads to read inconsistency of data in the Oracle7 database. To enact point-in-time recovery on the individual tablespace, the DBA must first create a clone of the database. It is highly recommended that this option be pursued only with the assistance of Oracle Worldwide Support, and point-in-time tablespace recovery can only be performed on non-SYSTEM tablespaces with the use of the EXPORT utility.

Preventing Problems

In order to execute a backup with RMAN, the recovery catalog database must be mounted and open, and the production database can be mounted or open. Thus, RMAN supports online backup of the Oracle database. As mentioned, to recover a damaged database, the necessary datafile and archive redo components must first be restored from backup sets. The restore operation may be performed with the instance open but the database not running, in the event that the control file is lost and must be re-created. As with Oracle7’s use of checksums and DBVERIFY, Oracle8 has similar mechanisms that prevent the creation of corrupted backup datafiles, or the application of corrupt datafile information to the database. The occurrence of corrupt data in either place causes Oracle to write information to the control file and the alert log.

New Control File Features

There are several new features that are present in the Oracle8 control file, making it significantly changed from and larger than the Oracle7 control file. The Oracle8 control file stores information that is of use to RMAN. Some of this information is recycled, while other information is permanent. A new parameter called CONTROL_FILE_RECORD_KEEP_TIME allows the DBA to specify the period of time after which data in recyclable portions of the control file expire and the space in the control file that data occupies is reused. If more of this RMAN information needs to be stored, and the old information has not expired, then the control file will expand to accommodate the new data as well as the old. The value for CONTROL_FILE_RECORD_KEEP_TIME is specified as an integer, representing the number of days recyclable data will be stored before it expires. When this parameter is set to 0, the control file will not expand, allowing Oracle to expire the recyclable data as needed to make room for new data.

Exercises

1. Identify several different types of commands available in RMAN. What is a script? What is the run command? What is a report? What is a list?
2. What are the two types of backup sets? What is a multiplexed backup set? What is a piece? If a control file is stored in a backup set, will it be multiplexed? What is an image copy? What is a tag?
3. What is the difference between a full and incremental backup in this context? What is a multiple-level backup? Does Oracle8 support point-in-time tablespace recovery? Explain.
4. What new features and new parameter are used in conjunction with RMAN and the control file?

Listing Recovery Manager Dictionary Views

Several dynamic performance views exist in the data dictionary to support RMAN, some of which are new. Both the old and new dictionary views available are listed below:

Exercises

1. Which of the V$ performance views are used to store information about backup sets?
2. Which of the V$ performance views are used to store information about datafiles?
3. Which of the V$ performance views are used to store information about redo logs?

Using Catalog Commands and Reports

In this section, you will cover the following topics related to using catalog commands and reports:

In this section, an in-depth discussion of several topics already presented in the overview section will be covered. Starting RMAN and the commands for operating RMAN will be presented in greater detail, along with the details of recovery catalog maintenance. Generating reports and lists will also be covered. This section can be read as the technical specification to the topics presented in the previous section.

Starting Recovery Manager

There are four types of commands available in RMAN: recovery catalog maintenance, script maintenance and execution, report/list generation, and run commands. To start the RMAN utility, type rman at the operating system command line followed by the target keyword, followed by the connect string for the production database on which RMAN will operate in single- or double-quotes and press enter. Optionally, at the command line, four other things can be specified: the connect string location of the recovery catalog preceded by the rcvcat keyword, the pathname and location of a script containing commands that RMAN will process, and the keyword cmdfile. If a command file is used, RMAN runs in batch; otherwise, RMAN runs interactively. A name and path for a message log for the execution of RMAN can be specified at the operating system command line as well, preceded with the msglog keyword. RMAN can maintain an ongoing message log with the specification of the append keyword. An example for running RMAN in batch mode in UNIX with these specifications is shown below:

An example of running RMAN in interactive mode is listed below:

RMAN terminates if it encounters an error at any point. Upon exit, RMAN will provide a return code according to its execution. If the entire operation was successful, RMAN returns ex_succ. If some commands succeeded, but the lost recent one did not, then ex_warn will result. If no command processed was successful, ex_fail will be returned. The results of each command processed will be stored in the message file if one is defined; otherwise, the return codes will be displayed on the screen if RMAN is running interactively.

Exercises

1. What is the difference between running RMAN in batch mode and in interactive mode? What five command-line options can be specified for RMAN? Which one must always be specified?
2. What conditions cause RMAN to exit? What are the three return statuses given by RMAN, and what do they mean?

Maintaining the Recovery Catalog

There are several commands for maintaining the recovery catalog with RMAN. These commands allow the DBA to do many things, such as registering the target database with the recovery catalog, resetting information in the recovery catalog, and synchronizing information in the recovery catalog with the status of the target database. Other commands allow the DBA to change availability on a backup set or image copy, access the operating system for a backup or recovery operation to send signals through a channel, and to catalog image copies of datafiles made outside of RMAN.

REGISTER DATABASE

This process must be executed the first time RMAN is run. When executed, RMAN obtains data from the production database targeted and places necessary information into the recovery catalog. The production instance must be started and the database mounted for this operation. There are no parameters or additional clauses for this operation. The following code block shows the execution of this procedure:

RESET DATABASE

If the database has been opened with the resetlogs option to reset the sequence number of the online redo logs, a new incarnation, or version, of the target database information in the recovery catalog must be created with the reset database command in RMAN. This step must be accomplished or else RMAN will not allow further access to the recovery catalog. Occasionally, such as in the situation of point-in-time recovery, the DBA may want to reinstate a prior incarnation of the database. This is done by adding the to incarnation num clause to the reset database command. To obtain the value to substitute for num, use the list incarnation of database command and take the value from the column with the "Inc Key" header in the resultant output. Examples of both situations appear in the following code listings:

and using the list incarnation of database command,

RESYNC CATALOG

The recovery catalog is not updated when a log switch occurs, when a log file is archived, or when datafiles or redo logs are added. Thus, the resync catalog command must periodically be executed to keep the recovery catalog in line with the production database. This command is executed automatically when a database is registered, and after a backup, recovery, or restoration. The default is for the recovery catalog to resync against the current control file. Alternately, a backup control file may be named for the process. The following code block illustrates use of this command:

ALLOCATE CHANNEL and RELEASE CHANNEL

These commands are used in conjunction with all major backup, restore, and recovery operations to allow communication between RMAN and the operating system for the purpose of manipulating files. The allocate channel channel_name command opens the line of communication, while the release channel channel_name command closes it. A channel can be named by adding a name in place of channel_name. The channel can be allocated with specific purposes in mind, such as with the for delete clause to delete files. Channels with specific resources in the filesystem can also be opened, both by name with the name "resource_name" clause or simply by type with the type disk clause. Parameters for allocating the channel and connect string for doing so can also be identified as part of the allocate channel command. Only one option is allowed for the release channel command, the name of the channel. Some examples for usage of these commands are listed in the following code block:

and for use of the release channel command,

CHANGE

The change command alters the availability status of a specified backup item. For backups, the backuppiece keyword is used. For archived redo logs, the archivelog keyword is used. For image copy, the datafilecopy keyword is used. For a control file backup, the backup controlfile keywords are used. The availability statuses that can be specified are delete, unavailable, available, and uncatalog. To delete a backup object, the DBA must first issue the allocate channel command, because the change command will issue a signal to the operating system to tell it to delete the backup file. Marking a backup object unavailable is used to identify the backups that are missing or offsite, and therefore allowed for use in a recovery or restoration operation. Marking the object available means it has been found or is onsite and available again. The uncatalog option removes the backup permanently from the control file if it has been deleted. Both the target and the recovery catalog must be defined for this operation to work. The following code block demonstrates its use:

CATALOG

A datafile image copy, backup control file, or archived redo log taken using methods other than RMAN can be used by RMAN so long as they are identified to the recovery catalog. The method used for identifying these files to the recovery catalog is with the catalog command. Only files that are part of the database can be part of the recovery catalog for that database. Only Oracle8 files can be cataloged. Both the target database and the recovery catalog must be defined for this operation to work. For backups, the backuppiece keyword is used. For archived redo logs, the archivelog keyword is used. For image copy, the datafilecopy keyword is used. For a control file backup, the backup controlfile keywords are used. The following code block contains an example for use of catalog:

Exercises

1. Identify the commands used for the maintenance of the recovery catalog.
2. Which command must be issued in conjunction with the change…delete command?

Generating Reports and Lists from the Recovery Catalog

Another series of commands available in RMAN include the commands used to define reports. Reports identify the database files that require backup. In addition, reports may help to identify which components of the database have not been backed up recently, and also to identify the backups that are no longer necessary for database recovery. Reports are generated with the report command. There are several common areas for report generation, listed here:

The following code block illustrates use of the report command:

Lists provide a complementary function of showing which backups are available for specified datafiles, what copies exist for certain datafiles, and backup sets or image copies for datafiles belonging to a specified list of tablespaces. Lists also provide information about backup sets of archived redo logs and incarnations of the database. Lists are created with the list command. The clauses available are copy of name, backupset of name, and incarnation of database dbname, where name is the name of a datafile or tablespace, and dbname is the name of the database. Some example uses of the list command appear in the following code block:

Exercises

1. What is the report command and what are its uses? What are its options?
2. What is the list command and what are its uses? What are its options?

Using RUN Commands and Scripts

In this section, you will cover the following topics related to using run commands and scripts:

The last two sets of commands are those used to operate backup, restoration, and recovery of the Oracle database, and the commands used to define scripts to execute the same. Collectively, the commands for backup and recovery are known as the run commands because this keyword precedes each of them when issued in RMAN. These operations map directly to API calls. A more complete explanation of the uses for each of the run commands appears as part of this section. The DBA can execute any of these operations with the run command, following the general syntax run {command}. There are four categories of run commands: backup, copy, restore, and recover. There are usually some associated allocate channel and release channel commands used for these to handle manipulation of files at the operating system level. In addition, the DBA can execute SQL DCL statements. DCL stands for data control language, the statements like alter database enable restricted session that set up the availability and runtime status of the database. These commands can be executed interactively within RMAN or, alternately, they can be put into a script and run with RMAN in batch. This section will cover each of these areas.

Channels, Scripts, and Attributes for RUN Commands

To execute most run commands, the DBA must first allocate a channel. This step establishes connection between RMAN and the operating system so that RMAN may create operating system files for backups and copies, or retrieve files for restores and recoveries. Channels can be allocated by type or by name. The syntax is allocate channel channel_name, where channel_name is a name the DBA assigns to the channel as a handle to refer to it later. If a channel is allocated by type such as with the type disk clause, then a specific device shouldn’t be named by the DBA. Alternately, if the DBA allocates a channel with a specific device by name, such as with the name ‘device_name’ clause, then the type clause shouldn’t be used. When name ‘device_name’ is used, an additional option called parms can be specified to allow the definition of port-specific parameters to be defined to allocate the channel. To operate a run command in parallel, the DBA must allocate a channel for each process working on the run command. An example for allocate channel is shown below:

Two related commands for channel allocation are release channel and setlimit channel. A channel can be released after the backup, copy, restore, or recover operation is complete. Syntax is straightforward, with only the specification of a channel_name. The second command is setlimit channel channel_name. It allows the DBA to set certain options on the activity of the channel. The parameters include the size of each backup piece with kbytes num, the number of blocks read per second by backup or copy commands with readrate num, and the number of files that can be open at one time by the channel with maxopenfiles num. Some examples of both statements appear in the following code block:

The run commands must be run in a script as well as interactively. When placed into a script, RMAN can execute the run command in batch. Scripts are created in RMAN using the create script command. Once created, the script is an object stored in the recovery catalog. It can be executed with the run command using the execute script command. To alter the commands in the script, the replace script command can be used. Deleting and printing scripts is possible as well with the delete script and print script commands, respectively. Examples of these statements appear in the following code block:

Attributes for the entirety of a run command can also be set using the set command. The attributes that can be defined include three clauses. The maxcorrupt num option defines a maximum number of corrupted blocks allowed in a datafile or list of datafiles extracted in a backup or copy command before RMAN terminates the run command. The newname name option can be used to change the name of the datafile being restored or switched. The archivelog destination path option changes the location where RMAN will look for restored redo log archives from the location specified in LOG_ARCHIVE_DEST to the location specified for path. The following code block illustrates its use:

Exercises

1. What statement is used to set up lines of communication between RMAN and the operating system? What statement is used to close that line of communication? What statement defines certain features of that line of communication?
2. What statement defines an object that can be executed to process backup and recovery operations? How is the object modified and eliminated? Where is that object stored?
3. What statement defines options used throughout the run command?

Using the BACKUP Command

Backups for the database are created with the backup command. This command produces one or more backup sets into which backup copies of datafiles, archived redo logs, or control files may be placed. Password files and init.ora files are backed up separately. The number of backup sets created depends on the number of files backed up, the number of tapes required for the backup, the parallelism of the backup, and other factors. The parallelism of a backup depends on the number of channels allocated to the backup, and several backup sets will be the result of multiple channeled backups. The general syntax of the backup command consists of two parts, options and scope, and looks like backup options (scope). The backup options that may be specified include several things, such as full, incremental level num, tag, cumulative, skip, parms, filesperset, and maxcorrupt. The backup scope can be database, tablespace, datafile, archivelog, backup controlfile, and current controlfile.

The following code block illustrates an example backup. In this example, the DBA wants to create a full backup of the database. Remember that "full" in this context means that the "full" datafile, not just the changed blocks, will be backed up. The fact that the "full" database is backed up is specified with the database clause. The DBA explicitly defines the number of datafiles to multiplex into each backup set with the filesperset parameter, and defines a naming convention for the backup pieces in the backup command with the format option. Offline datafiles for the database will be skipped in the backup. These and other parameters will be explained shortly. The example is listed here:

The clauses that can be specified as options for the backup statement include those options in the following list:

The clauses available for defining the scope of the backup are listed and defined in the following set of items:

Exercises

1. What command is used to perform backups?
2. What are two categories of options or clauses that can be specified with this command? What are the categories based on? What are some of the clauses in each?
3. What does the full clause mean? What does the incremental level clause mean?

Using the COPY Command

RMAN allows the DBA to create backup copies of the datafiles on the database. These copies are called image copies, and they are created with the copy command. The image copy can be put onto a disk only. Image copies can be made of current datafiles, datafiles copies made using any method, archived redo logs, and the current or backup control file. Once created, the image copy is immediately usable for a recovery without executing a restore command. General syntax for the copy command is copy file to location. The allocate channel command must precede the copy command, and the level of parallelism that can be used with the copy command relates directly to the number of channels allocated to the copy. Only full copies of datafiles are permitted with the copy command. An example of the copy command appears in the following code block. In this example, one copy of a single datafile is made.

TIP: The copy command only allows channels to be allocated that specify type disk. All other allocate channel commands will be ignored for the copy command.

Several clauses are available for use in place of file. These clauses are listed in the following set of items:

The filename and path to which the image copy will be placed is usually specified by location. Alternately, a few clauses are available for use as part of location. These clauses are listed in the following set of items:

Exercises

1. What command is used to create duplicates of database files?
2. What is the only option allowed in the channel allocation statement when this command is issued?

Using the SWITCH and RESTORE Commands

The switch command can be used to turn a datafile copy into the current datafile. This is done by switching the datafile name in the control file. This command creates the need for media recovery. It produces the same effect as the alter database rename datafile statement. General syntax for this command is switch datafile name to datafilecopy new_name. Optionally, the to datafilecopy portion can be dropped in favor of all, and all datafiles for which a new name is defined in the run command with the set newname clause will be switched. An example appears in the following code block:

Unlike image copies of datafiles, which are usable for recovery operations immediately, files in backup sets must be retrieved from tape and extracted from the backup set before they are available for recovery. The process to retrieve the backup is done when the DBA issues the restore command. When this command is issued, RMAN will either overwrite the current versions of datafiles, control files, and archived redo logs with the files from backup sets or place those files elsewhere according to the set newname clause. When this clause is used, RMAN recognizes the restored files as copies and marks them as such in the recovery catalog. This process can be useful if the DBA is trying to create a clone database. The restore command is usually not necessary for moving backup sets containing archived redo logs off tape and onto disk, but recovery performance is improved if the archives are restored. The names and locations used for archived redo logs when they are restored to disk is constructed by RMAN from the LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters set for the instance. The set archivelog destination clause in the run command overrides the location where LOG_ARCHIVE_DEST says to put the restored archives. If the entire set of files comprising the database is to be restored, then the database must be closed. General syntax for this statement is restore from_clause until_clause file_clause.

The following example shows the use of the restore command. In this example, the datafiles of a tablespace named are restored from the recovery catalog. No specific backup set is given, and no time range for which the backup should conform is given, so RMAN restores the most backup that will give the DBA a complete recovery automatically.

The options specified for a from_clause, needn’t be specified always, and are specified in different combinations. The following list of options are used in conjunction with the restore command as the from_clause:

The restore command also supports point-in-time recovery. As such, the until keyword can be used. RMAN will retrieve backup copies of datafiles from the recovery catalog based on the point in time specified with until. This clause has three options, time, scn, or log_sequence.

Files for the entire database can be restored, or individual datafiles can be named singly or in combination with their tablespaces. The restore command supports these options with the file_clause, which has the following keywords:

Exercises

1. What purpose does the restore command fulfill?
2. What items must be specified if the DBA wants to perform complete recovery on a datafile? A tablespace? The database?
3. What clauses are specified for restoring files to support incomplete recovery?

Using the RECOVER Command

Media or disk recovery is handled in RMAN with the recover command. RMAN applies incremental backups to the database in order to recover it. Only current datafiles will be recovered, and RMAN will restore archived redo logs from backup sets as needed to support the recovery operation. The recovery catalog should be available to support the recover command, and it must be available if the control file must be recovered. Since recovering data from incremental backup takes less time than the same recovery performed from archived redo logs, RMAN will always prefer an incremental backup over a set of archived redo logs if both are available for the recovery. If there are several levels of incremental backup available, RMAN will use the lowest level available (i.e., as close to level 0 as possible). The types of recovery available in RMAN are database, tablespace, and datafile. The same constraints covered in Unit III for each level of recovery apply, namely that the target instance must be started and mounted but not open for database recovery, and open for tablespace and datafile recovery with the damaged files offline. Both complete and incomplete recovery can be performed with the recover command. The general syntax is recover recover_clause. The following example shows the use of the recover command to handle incomplete database recovery to a specific system change number, skipping the temporary tablespace:

The parameters used in this option include those in the following list:

Exercises

1. What is the recover command? How does RMAN support complete database recovery? How can named tablespaces be skipped in a database recovery?
2. What is incomplete recovery? What clause is used to support it?

Chapter Summary

This chapter discusses the features of Oracle8’s new architecture for backup and recovery. This new feature supports several different backup and recovery strategies, combining interfaces with the operating system and third-party backup and recovery products, enhanced tracking of backup and archived redo information, scripting for automated backup and recovery operation, all with an Oracle-supported product. This important feature will be covered heavily on OCP Exam 5.

The new backup and recovery architecture has two components: the Recovery Manager, or RMAN, and the use of a new backup feature called the recovery catalog. RMAN is a utility executed either interactively or in batch from the operating system interface. This utility has its own syntax in which backup and recovery operations are defined and run. The second part of this new feature is the recovery catalog. It is a separate database in which information about the backups taken for the production or "target" database is stored. The actual backup and archived redo is stored in the recovery catalog, along with information about the structure of the database and backup and archived redo logs. Also kept in the recovery catalog are script objects that the DBA defines to handle routine backup and recovery operations. RMAN is created with the execution of the catrman.sql script found in rdbms/admin under the Oracle software home directory.

RMAN is executed from the operating system command line with the rman command. There are several options that can be specified at run time for RMAN, including the username and connection string for the production or target database, the connection string and username for the recovery catalog database, a file containing RMAN commands, and a log file. Each option is specified with a keyword, target rcvcat cmdfile and msglog, respectively. To reuse the log file specified, the append keyword can be named after the filename specified for msglog.

There are four categories for the commands available in RMAN. These categories are recovery catalog maintenance commands, report/list commands, script commands, and run commands. The recovery catalog is maintained with several commands. The production target database is registered with the register database command. When redo log sequence numbers are reset at the time the target database is opened, the reset database command must be issued in RMAN to the recovery catalog as well, since there is no direct interface between the target database and the recovery catalog other than through RMAN. With the introduction of RMAN and the recovery catalog comes an accurate and easy way to identify the version of the data in the database with the list incarnation of database statement. After log switches on the target, the recovery catalog must be updated with the resync catalog command. The information in the recovery catalog can be maintained with the change command, used for removing or altering availability of backups or copies of files or redo logs. To remove or create files using RMAN, the DBA must use the allocate channel command. This command opens a line of communication between Oracle and the operating system to handle file creation, movement, and deletion. Finally, database backup files created outside of RMAN can be registered with the recovery catalog using the catalog command.

The next commands are report and list. These complementary reporting commands are used to provide the DBA with an accurate picture of recoverability on the database with minimal research. The report command tells the DBA the backup status of file components in the database. It identifies when the last backup was performed, how many incremental backups would be required to provide complete recovery, and other information. The list command provides a report on the names of the backups that are available that would be required to provide recovery to a specified datafile, tablespace, or database. The DBA will use these reporting functions together to determine the backup needs for the database at any point in time, or the availability of backup data for recovery purposes.

The next commands are the scripting commands. Anything that can be executed in RMAN interactively can also be executed in batch. This feature is especially important for organizations that rely on Oracle for delivery of their most important data, data that most needs to be backed up and recovered efficiently, effectively, or frequently. Scripting allows the DBA to define the most routine aspects of backup and recovery once as a script and reuse that script (or even schedule it automatically) as often as the scripted operation needs to be performed. The commands for creating, replacing, printing, or deleting a script include create script, replace script, print script, and delete script, respectively.

Once created, a script is executed using the fourth set of commands, the run commands. Several other items are executed with the run commands, including the operation of backups, copies, restores, switches, and recoveries. The allocate channel command must be executed before other commands in the run command. Backups for the database are created with the backup command. Several different types of backups can be run database-wide, tablespace-wide, or on particular datafiles, including full backups and incremental backups. A full backup is one that makes a complete backup copy of all blocks in a datafile. An incremental backup is one that makes a copy of only the blocks in a datafile that have changed since the last full backup. There are eight levels of incremental backups available in RMAN, corresponding to different time ranges and to a level 0 backup, which is a full backup. Backups of datafiles, control files, and archived redo logs are placed into objects called backup sets. Datafiles and control files can be stored in the same backup set, while archived redo logs are stored in their own backup set. Multiple datafiles in a backup set can be multiplexed, or stored on sequential access media such as tape such that the blocks of each datafile are not stored contiguously. However, blocks for control files and archived redo logs may not be multiplexed. Finally, if a backup is created that the DBA subsequently needs to use as part of a database recovery, the DBA must first restore the file from the backup set and then run recovery. The restore command is used for this task.

Another run command covered was the copy command, used to create immediately usable copies of files. This copy is also called an image copy. Copies of files are made to disk, unlike backups, which can be made directly to tape. A current database file can be switched for a backup copy using the switch command, also covered in this chapter. To recover a database from backup, the DBA must first restore the necessary files using the restore command. Finally, to recover a database with appropriate backups in place, the recover command is used. RMAN handles the movement of needed archived redo logs onto disk from tape automatically, but the DBA can speed recovery by restoring needed archived redo logs to disk before running recover. The recovery catalog usually needs to be available to execute recovery properly, in order for the RMAN to select the needed backups and archives. The recovery catalog must be available if the DBA needs to recover from a backup control file. All types of database recovery supported in Oracle7 are available with RMAN in Oracle8, including complete and incomplete recovery, tablespace recovery, and datafile recovery. There are several new features to the control file that support RMAN, and new dictionary views as well, information about which is provided in the two-minute drill following.

Two-Minute Drill