Technology RMAN
Ready to Recover
By Joe Johnson
Oracle Recovery Manager is ready, reliable, and easy to implement.
Having effective and reliable disaster recovery plans for critical systems is a key responsibility
of every database administrator (DBA). Historically, these recovery plans have included hot or cold physical backups of the database using a combination of operating system commands and SQL scripts. Most DBAs continue to use these backup techniques because they are time-tested, reliable, and easy to implement.
Oracle introduced the Recovery Manager (RMAN) utility in Oracle8, and
while RMAN offered a lot
of promise for improved
database disaster recovery planning, many DBAs have resisted implementing RMAN. In working with my own clients, the reasons for forgoing the use of RMAN usually fall into one of the following three categories:
- "The backup solution I have now works fine, and I'm not going to mess with a good thing."
- "I tried setting up RMAN, but I could not get it to work so I gave up on it."
- "I set up RMAN once, but the RMAN syntax was so cryptic I gave up on it."
With the release of Oracle9i Database, however, RMAN made each of these reasons irrelevant. The purpose of this article is to show you why Oracle9i RMAN is worth another look as a potential disaster recovery solution.
The Backup Solution I Have Works Fine
Although a DBA may feel that his or her current backup solution works fine, does the DBA know that some RMAN features might make the current backup solution even better than fine? RMAN offers many features that are not available using traditional physical backup techniques. These features include: trial recovery, skipping unused blocks, performing true incremental backups, recovering data at the block level, using multiple I/O channels to access backup devices, and writing directly to enterprise backup systems.
RMAN allows trial recovery. If a recovery fails using a traditional hot or cold backup, the entire recovery may have
to be restarted, resulting in additional downtime. RMAN allows you to perform a trial recovery prior to the actual recovery to be sure all the files needed for recovery are available and usable.
RMAN skips unused blocks. When taking
a complete RMAN backup of a database, RMAN will not back up those database blocks that have never contained data. This can save a substantial amount of space on your backup media and help
to minimize the backup window.
RMAN offers true incremental backups. During an RMAN backup, every block in every data file is read into memory and examined to determine whether its contents have changed since the last backup, but only those blocks that have changed since the last backup will actually be written to the backup device.
RMAN offers block-level recovery. The RMAN utility can identify corrupt database blocks during an RMAN backup. During a recovery, RMAN allows you to recover just the affected blocks within the damaged data file, leaving the rest of the data file online and available to application users.
RMAN allows multiple I/O channels to access backup devices. When writing the database backups to a disk or tape device, RMAN has the ability to use several concurrent processes to perform the write activity. This can greatly speed up the backup process, particularly in situations where the backups are being written directly to tape.
RMAN can interact directly with enterprise backup systems. The complexity of most business computing environments has increased dramatically in recent years. Therefore, it's generally not feasible to perform backups to a dedicated tape drive at each server anymore. Instead, corporate computing environments are making increased use of enterprisewide backup solutions such as Tivoli and Veritas. These systems utilize agent software installed on each server to write that server's backup information to a central backup repository.
I Couldn't Get It to Work
Setting up an RMAN environment is not difficult, but it does require some up-front planning and an understanding of the RMAN infrastructure. The most common RMAN configuration consists of four components:
1. The RMAN repository database (optional)
2. The RMAN utility or Oracle Enterprise Manager (OEM) Console (required)
3. The target database (required)
4. The enterprise tape backup client software for RMAN (optional)
Each of these components is described briefly in the following sections. The examples in this article use an Oracle9i Release 2 target database called PROD located on a Windows 2000 server, and an Oracle9i Release 2 RMAN repository database called RMAN on a Red Hat Linux 7.2 server.
The RMAN repository database. The RMAN repository database contains the schema that owns the tables, indexes, and PL/SQL packages that comprise the RMAN repository, or catalog. While it
is possible to perform basic RMAN backups without the use of a repository, a repository is recommended in order to utilize RMAN to its full potential. The RMAN catalog should be stored in a separate, standalone database that is dedicated to this purpose. Listings 1 and 2 show the init.ora and database-creation script for the RMAN repository database used for the examples in this article.
The script in Listing 2 also creates a user account, RMAN, to hold the catalog objects that store the details of each RMAN backup. The RMAN user account does not contain the actual data from the backup of the target database; this data is written to disk or tape. Instead, the RMAN user account contains metadata about the backups that have been performed by RMAN.
The RMAN utility. The RMAN utility is the executable program that connects the RMAN repository database to the target database via Oracle Net. Start the RMAN utility by typing rman and the appropriate connect information at the operating system prompt as shown:
C:\>rman rcvcat=rman/manager@rman
target=sys/manager@prod
...
connected to target database: PROD ƒ
connected to recovery catalog database
RMAN>
Specify the connect information for both the RMAN repository database (RMAN) and the target database (PROD) when you invoke the RMAN utility in command-line mode.
Alternatively, you can start the RMAN utility in command-line mode from the server hosting the RMAN repository
database, or from a workstation where OEM is installed. Once the RMAN utility starts, you can issue the CREATE CATALOG command at the RMAN> prompt to create the RMAN repository schema objects.
In addition to command-line operation, the OEM console offers a GUI interface for the RMAN utility. This utility is available on the console's main menu under Tools->Database Tools->Backup Management.
The target database. The RMAN target database is the database that is being backed up.
Enterprise backup client software for RMAN. The enterprise backup client software component of the RMAN infrastructure is optional. It is only required if you want to use RMAN to write backups to an enterprise tape backup system (ETBS). If this is the case, you must first install the RMAN client software for the ETBS on the server that will be running the RMAN utility. This client software provides the media management layer that allows RMAN to write directly to the ETBS when the database backups are performed.
That's all you need to get started with RMAN: The Oracle9i RMAN utility; a small Oracle9i repository database that contains the RMAN catalog; a target database; and optionally, the RMAN client software for your ETBS.
The RMAN Syntax Was Too Cryptic
This is the most common complaint I hear when working with clients who are considering RMAN as a backup solution. However, enhancements in Oracle9i have made the syntax to perform standard RMAN backups much easier. Performing an RMAN backup consists of three steps: Registering the target database with the RMAN repository, determining whether to perform an open or closed database backup, and then issuing the RMAN backup commands that perform the backup via either command-line commands or the OEM RMAN interface.
Registering the target database with RMAN repository. Once you have used the RMAN utility to connect to the RMAN repository and target databases, and created the RMAN catalog, you need to register the target database in the catalog before you can create an RMAN backup. The registration process allows the repository database to collect information about the names and locations of the target database's control files, redo logs, and data files. To register the target database, issue register database; at the RMAN> prompt.
Determining whether to use open or closed backup. RMAN can be used to back up a database when it is open or when it is closed. Just as with traditional backup methods, open database backups require that the target database operates in archive log mode. However, unlike traditional backup methods, RMAN hot backups do not require the issuance of ALTER TABLESPACE BEGIN/END BACKUP commands before each tablespace's datafiles are backed up.
Closed RMAN backups also differ slightly from traditional cold backups because the target database must be mounted, not actually shut down, when performing a "closed" RMAN backup. This is required because RMAN needs to access the target database's control files during the backup.
Issuing the RMAN backup commands. Regardless of whether the backup being created is open or closed, the RMAN backup command is the same: at the RMAN> prompt, type backup database;. RMAN will create the RMAN backup files in the default location: $ORACLE_ HOME/database on UNIX systems and %ORACLE_HOME%/database on Windows 2000 systems.
Writing Backups to an
Enterprise Tape Backup System
If you want to write your RMAN backups to an ETBS instead of the default $ORACLE_HOME/database location, then you must perform some additional preconfiguration of RMAN. This configuration essentially changes the default backup device (disk) and location ($ORACLE_HOME/database) to one of your choosing. In the case of an ETBS, the device will be your enterprise tape device.
To have RMAN access your ETBS tape drives requires client software provided by the ETBS vendor and designed specifically for use with Oracle9i RMAN. The RMAN API that interfaces with the ETBS vendor's media management software generically refers to the tape devices using the name sbt. All references to tape devices—no matter what the vendor or type—are made using this sbt keyword within the RMAN syntax.
Once the ETBS client software is installed and tested, you can configure RMAN to use this software to back up to the ETBS whenever you issue the RMAN backup command. Setting up the ETBS default configuration requires two additional steps: Defining an RMAN device to access the ETBS tape drives via the vendor's media management software, and then specifying this device as the default device for all RMAN backups. Listing 3 shows the syntax for the first of these steps, configuring RMAN to use the ETBS device.
Notice the inclusion of the PARMS option in the RMAN syntax in Listing 3. This option allows you to specify additional parameters that the media management software needs when performing the backup. For example, in Listing 3, an environment variable called TDPO_OPTFILE, which is needed by the Tivoli media management software, is defined within the PARMS parameter.
Once the ETBS tape device is configured within RMAN, you can then make it the default device for all RMAN backups. You can use the commands shown in Listing 4 to make the tape device the default RMAN device, and then confirm its configuration.
Once the sbt device is set up as your default RMAN backup device, you can perform hot or cold RMAN backups to your ETBS simply by using the backup database; command.
Using OEM and RMAN Wizards for Backups
In addition to the command-line interface, OEM incorporates an easy-to-use graphical RMAN interface and RMAN Backup and Recovery wizards. Use the RMAN Backup wizard to configure and schedule regular backups. The first screen of the RMAN Backup wizard, Strategy Choice, allows you to either create a customized backup strategy or utilize RMAN's predefined backup strategy.
After you select a backup strategy, establish the backup frequency. The RMAN Backup wizard proposes three backup frequencies, each based on the frequency with which application users modify the database's contents. In this manner, decision support system (DSS) databases are backed
up with less frequency than online transaction processing (OLTP) systems. Figure 1 shows the Backup Frequency
screen and a compromise between these two approaches: a full
backup weekly with daily incremental backups.
|
| Figure 1: RMAN Backup wizard's Backup Frequency screen |
Once you have established the backup frequency, set the time for each backup in the Backup Time screen.
The RMAN Configuration screen displays a summary
of the configuration
for the RMAN backup. Click on the Edit Backup Configuration button to modify the default settings for the backup. The Edit Backup Configuration dialog box appears.
The default configuration that the RMAN Backup wizard has created will store the RMAN repository information in the target database's control file. Because there are several advantages to using a repository database instead of the target database's control file to hold backup metadata, Figure 2 shows how the RMAN session can be configured to use the same RMAN repository database shown in the previous command-line examples.
|
| Figure 2: RMAN Edit Backup Configuration dialog box |
Once you establish the backup configuration, use the Multiple Targets screen of the RMAN Backup wizard to determine the databases to which the backup configuration is to be applied.
Finally, click Finish to submit the RMAN backup to the OEM job subsystem. The backup now appears as a scheduled task under the Jobs node in the OEM console. The OEM job scheduler will execute the RMAN backup at the specified time each day, writing the RMAN backup files to disk or ETBS, just as with command-line backups.
Restoring from an RMAN Backup
You can perform RMAN database recovery using either the command-line or GUI interface. Like the backup command, the RMAN command-line recovery commands in Oracle9i are greatly simplified. In fact, in most cases, the database recovery process consists of connecting to the target and RMAN repository databases and then issuing the RESTORE DATABASE and RECOVER DATABASE commands, as shown in Listings 5 and 6.
If you use OEM RMAN tools to perform the recovery, the process is even easier because these tools perform the restore and recovery operations automatically. Figure 3 shows the first screen, Operation Selection, of the RMAN Recovery wizard that I will use to restore a damaged TOOLS tablespace in the PROD database. Note that there are several restore and recovery options available.
|
| Figure 3: Operation Selection screen of the RMAN Recovery wizard |
The next screen, Object Selection, allows you to specify the recovery at the data file or tablespace level. In this example, I select the Tablespace option to recover the TOOLS tablespace. After I select the Tablespace option, a list of the tablespaces in the target database displays in the Tablespaces screen. I select the TOOLS tablespace as the tablespace for recovery. If the device where the data file associated with the TOOLS tablespace was located is damaged, I can restore the data file to an alternative location using the Rename screen. If the data file can be restored to its original location, I can skip this screen.
The Recovery Wizard Configuration screen allows me to check the configuration details of the backup. After I click Finish in the Configuration screen, the Summary screen displays all the recovery options I selected. Clicking the OK button on the Summary screen submits the recovery job to the OEM job scheduler for execution.
Once the job is scheduled, the OEM console will execute the job and perform the recovery on the TOOLS tablespace. Once completed, I can view the results of the job's execution on the History tab of the Jobs section of the OEM Console.
Notice that I did not need to specify the names and locations of the files to be restored; RMAN automatically did that work for me.
Obviously there are many more recovery scenarios possible with RMAN. An RMAN backup can also be used, for example, to recover databases with missing control files or redo logs, to perform point-in-time recovery, and to clone databases.
Summary
Even if you are satisfied with your tried-and-true backup methods, the improvements made to RMAN in Oracle9i Release 2 render it worth another look. The latest release of RMAN offers an easy-to-configure infrastructure and removes all the formerly cryptic and confusing command-line syntax related to performing a backup or a recovery. This ease of use—coupled with unique RMAN-only backup functionality such as trial recovery, incremental backups, block-level recovery, and the ability to interact directly with enterprise tape backup systems—makes RMAN worthy of serious DBA consideration.
Joe Johnson (josephcjohnson@yahoo.com) is an Oracle Certified Professional in database administration with years of experience managing Oracle databases. He is the author of OCP: Oracle9i Performance Tuning Study Guide (Sybex Publishing).
Bookmark
