Oracle RMAN Pocket Reference

BUY THIS BOOK

Print Book $9.95

PDF $7.99

Safari Books Online

What is this?

Print Book £6.95

What is this?

Looking to Reprint or License this content?

Tell a friend

Oracle RMAN Pocket Reference

By Darl Kuhn, Scott Schulze
Book Price: $9.95 USD
£6.95 GBP
PDF Price: $7.99

Cover | Table of Contents

Chapter 1: Oracle RMANPocket Reference

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is a quick-reference guide for Recovery Manager (RMAN), Oracle's utility to manage all of your Oracle database backup and recovery activities. This book is not a comprehensive backup and recovery book. It contains an overview of RMAN architecture, shows briefly how to backup and restore databases using RMAN, describes catalog setup issues, and provides quick-reference syntax diagrams of RMAN commands.

The purpose of this book is to help you quickly find the syntax for, and use, RMAN commands to back up, restore, and recover a database. We assume that you, the reader, have basic Oracle database administrator (DBA) skills, and that you are familiar with backup and recovery concepts. We also point out that the batch mode examples in this book are scripted with Unix shell scripts. Many of these examples contain Unix paths that are appropriate for our environment. If you are developing your own set of scripts, you will want to change the examples to reflect your own environment.

Many thanks to "our man," editor Jonathan Gennick. His feedback and suggestions have added significant improvements and clarity to this book. Thanks also to the technical reviewers Jeff Cox, Tim Gorman, Dick Goulet, Mark Hampton, Steve Orr, Walt Weaver, and Jeremiah Wilton.

We have taken the Pareto's Law approach in writing this book, in that we have tried to cover topics that you are most likely to encounter while using RMAN. This material does not cover every type of environment, nor does it cover all of the backup and recovery scenarios that you will encounter as an Oracle DBA.

While some of the more common backup and recovery scenarios are covered in this book, it is still critical that you are comfortable with your RMAN implementation and can recover your database no matter what type of failure occurs. We can't stress enough the importance of regular testing in preparation for recovering from unplanned disasters.

A sound implementation and regular testing will give you the confidence to handle the impending 2 A.M. call: "Hey, I'm getting this strange ORA-01116 error, unable to open file, what do I do?"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A sound implementation and regular testing will give you the confidence to handle the impending 2 A.M. call: "Hey, I'm getting this strange ORA-01116 error, unable to open file, what do I do?"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

RMAN Architecture

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Recovery Manager (RMAN) is a utility that can manage all of your Oracle backup and recovery activities. DBAs are often wary of using RMAN because of its perceived complexity and its control over performing critical tasks. The traditional backup and recovery methods are tried-and-true. Thus, when your livelihood depends on your ability to back up and recover the database, why implement a technology like RMAN? The reason is that RMAN comes with several benefits:

Incremental backups that only copy data blocks that have changed since the last backup.
Tablespaces are not put in backup mode, thus there is no extra redo log generation during online backups.
Detection of corrupt blocks during backups.
Parallelization of I/O operations.
Automatic logging of all backup and recovery operations.
Built-in reporting and listing commands.

RMAN's architecture is a combination of an executable program (the rman utility) and background processes that interact with one or more databases and with I/O devices. There are several key architectural components to be aware of:

RMAN executable
Server processes
Channels
Target database
Recovery catalog database (optional)
Media management layer (optional)
Backups, backup sets, and backup pieces

The following sections describe each of these components.

The RMAN executable, usually named rman, is the program that manages all backup and recovery operations. You interact with the RMAN executable to specify backup and recovery operations you want to perform.

You don't need an extra license for RMAN; it comes as a standard utility included with an Oracle 8.0.x, Oracle8i, or Oracle9i installation.

The executable then interacts with the target database, starts the necessary server processes, and performs the operations that you requested. Finally, the RMAN executable records those operations in the target database's control file and the recovery catalog database, if you have one.

RMAN server processes are background processes, started on the server, used to communicate between RMAN and the databases. They can also communicate between RMAN and any disk, tape, or other I/O devices. RMAN server processes do all the real work for a backup or restore operation, and a typical backup or restore operation results in several server processes being started.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting RMAN

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section explains some of the prerequisites that must be in place before you can use RMAN. It then shows you how to invoke RMAN and finally, how to connect to a target database both with and without using a recovery catalog.

If you already have your target database environment set up, you can skip this section. If not, there are a few things you need to have in place before instructing RMAN to connect to the target:

Appropriate target environment variables must be established.
You must have access to an O/S account or a schema that has SYSDBA privileges.

Before you connect to your target database, you must ensure that the standard Unix environment variables are established. These variables include: ORACLE_SID, ORACLE_HOME, PATH, NLS_LANG, and NLS_DATE_FORMAT. They govern the name of the instance, the path to the RMAN executable; and the behavior of backup, restore, and reporting commands.

When using RMAN, NLS_LANG should be set to the character set that your database was created with. If you do not set NLS_LANG, you may encounter problems when issuing BACKUP, RESTORE, and RECOVER commands.

Once you have the appropriate environment variables set, you then need access to an O/S account or a database schema that has SYSDBA privileges. You must have access to the SYSDBA privilege before you can connect to the target database using RMAN. There are two methods of administering the SYSDBA privilege:

Locally via O/S authentication
Remotely via password file

O/S authentication is established when you install the Oracle binaries. At that time, you set up a Unix group, often named dba, and specify this as the O/S group with SYSDBA privileges. Often the Unix account used to install the Oracle binaries is named oracle. This account is usually set up to belong to the dba group, and consequently, it lets you start RMAN and connect to the target database.

O/S authentication is what permits you to connect locally without having to specify the AS SYSDBA option. For local connections, RMAN automatically connects you to the target database with SYSDBA privileges.

Setting up a password file is the other method by which you can administer the SYSDBA privilege. There are two good reasons to use RMAN with a password file:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Executing Commands

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In order to perform any type of function from within RMAN, you must use the RMAN command syntax. An extensive array of commands is available, and you will often execute a series of commands to perform a task. You can issue commands either by typing them in at the RMAN prompt or by executing them from within O/S scripts or RMAN scripts.

The most basic way of executing RMAN commands is to type them in manually from the RMAN command-line prompt. In fact, we recommend that you become familiar with this method. There are two good reasons for learning how to type in commands manually:

Concepts are reenforced.
It may be the only option available during a backup and recovery scenario.

In other words, don't rely on a tool for backup and recovery if you don't understand the underlying command syntax. You don't want to be caught in a situation in which you're responsible for a recovery but do not know how to compose ad hoc RMAN commands. Here's a simple example of how to do a full disk-based backup of datafiles by typing in the commands manually:

$ rman nocatalog

Recovery Manager: Release 9.0.1.0.0 - Production

RMAN> connect target /

connected to target database: BRDSTN (DBID=3662736385)
using target database controlfile instead of recovery catalog

RMAN> run {allocate channel d1 type disk;
2> backup full format '/ora01/backup/rman_%d_%U.bus'
3> database;}

This performs a full database backup of datafiles to a local disk in the /ora01/backup directory.

The target must be in archivelog mode before running an on-line backup. Here's an example of how to alter a database into archivelog mode:

SQL> connect sys/heeraa as sysdba;
SQL> alter database archivelog;

Even when simple tasks complete successfully, RMAN presents you with a voluminous information stack. When typing in commands manually, you have probably noticed that RMAN parses each line as you type it in. Therefore, if you type in something that is not syntactically correct, you are immediately presented with an error stack and must start over. The following example has a syntactical error on the second line. As soon as you type it and hit Return, RMAN displays an error stack:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Implementing a Catalog

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One important decision when using RMAN is deciding whether to use a recovery catalog. This section covers the pros and cons of a catalog and then details catalog implementation issues.

In many respects, RMAN can be thought of as an Oracle database file backup and restoration utility. RMAN must keep track of many things. When was the last backup taken? Which files were backed up? Which backup sets contain which database files? The answers to these questions can be found in the target control files. Optionally, RMAN can be configured to store this information in a separate database known as the catalog.

The catalog consists collectively of a database and a database schema. The schema objects hold the RMAN-specific information for each of your target databases.

Section 1.5.1.1: Catalog advantages

When you use a catalog repository, you get more flexibility and access to all the features of RMAN. The advantages of using a catalog accrue in the following areas:

If you are using Oracle8i, it can be difficult to recover control files if you don't have a catalog.
You can retain backup and recovery metadata for long periods of time.
You can centralize operations.
RMAN becomes more flexible in certain backup and recovery scenarios.

A catalog enables you to recover your control files in the event that they are all corrupted or lost. If you are not using a catalog, and you haven't backed up your control files via an ALTER DATABASE BACKUP CONTROLFILEcommand, you could find yourself in the unenviable position of not being able to recover your target.

Another good reason to use a catalog is that information pertaining to your RMAN backup and recovery activities can be stored for very long periods of time. If for any reason you had to use a backup set that was several months old, a catalog provides more flexibility to go back further in time than with the NOCATALOG option.

With a catalog, you can manage all of your backup and recovery activities from one repository. The advantage of this is that if you have multiple databases to maintain, you're storing all of your backup and recovery metadata in one place.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Stored Catalog Scripts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Storing scripts in the catalog is another common technique saves RMAN commands for reuse. To use this method you must have a catalog database.

To store a script you need to connect to both the catalog and the target. You need to connect to the catalog so that RMAN knows where to store the scripts, and you need to connect to the target so that RMAN knows which target database the stored script is associated with.

Once a connection to the target and catalog is established, you can store a script using either the create script or replace script commands. The replace script command creates a new script or replaces a previously stored script by the name under which you store the script. The following example creates a script to do a full backup of a database:

$ rman target / catalog rman_901/rman_901_pwd@rman_catalog

Recovery Manager: Release 9.0.1.0.0 - Production

connected to target database: BRDSTN (DBID=664610428)
connected to recovery catalog database
RMAN> replace script full_back{
2> allocate channel d1 type disk;
3> backup full format
4> '/d0102/backup/rman_%d_%U.bus' database;
5> }

replaced script full_back

This stores the script, which is named full_back, in the catalog. This does not execute the script. To run the commands that you've just stored, you need to execute the script.

After you've stored your scripts, you will want to run them. Once connections have been established to both the catalog and target database, you can call the stored script via the execute script command:

$ rman target / catalog rman_901/rman_901_pwd@rman_catalog

Recovery Manager: Release 9.0.1.0.0 - Production

connected to target database: BRDSTN (DBID=664610428)
connected to recovery catalog database

RMAN> run {execute script full_back;}

executing script: full_back

You can also call stored scripts from other stored scripts. This allows you to modularize your RMAN commands. For example, you may want one script to allocate a channel, another to release a channel, and a third to run a backup command. For example, create a file called stsc.sto and place within it the following commands:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Backups

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section provides a series of RMAN and korn shell scripts that illustrate backing up a database and its separate components. RMAN can back up datafiles, control files, archived redo files, and backup pieces. RMAN does not back up the online redo logs.

RMAN, as part of its default backup behavior, touches each datafile block, performs verification checks, and then logs any detected corruption. You can monitor potential corruption by querying the V$BACKUP_CORRUPTION and V$COPY_CORRUPTION views.

For a database to be backed up it must be in mount mode or open. The database needs to at least be in mount mode, because RMAN needs to access the target database control file before performing a backup.

For offline backups, the database needs to be shut down and restarted in mount mode. The database does not have to be in archivelog mode.

Here's a shell script for an Oracle9i database that shuts down the database, mounts it, backs it up, and opens it:

#!/bin/ksh

rman target / <<EOF
shutdown immediate;
startup mount;
backup database format 
  '/d99/rmanback/brdstn/rman_%d_%t_%U.bus';
alter database open;
EOF
exit

The following shell script takes a full backup of an Oracle8i database. Notice that the command syntax is a little more verbose than that needed for Oracle9i. For Oracle8i, the syntax requires you to place the allocate and backup commands within the run{} command.

#!/bin/ksh

rman target / nocatalog <<EOF
shutdown immediate;
startup mount;
run {
allocate channel d1 type disk;
backup database format 
  '/d99/rmanback/brdstn/rman_%d_%t_%U.bus';
}
alter database open;
EOF
Exit

We've used the format parameter in both examples to provide a specific location and unique name for the backup pieces. If the format parameter is not used, the backup pieces will be directed to $ORACLE_HOME/dbs. Please refer to Table 1-1 in the Section 1.9 section.

For online backups, the database is open for use and must be in archivelog mode. If you're using Oracle9i, the syntax can be fairly simple:

RMAN> backup database format 
2> '/d99/rmanback/brdstn/rman_%d_%t_%U.bus';

Unlike traditional online (hot) backups, RMAN does not put tablespaces in backup mode. No extra redo is generated. For high-transaction databases, this can lead to significant resource savings.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Restoring Files

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In general there are three steps involved in restoring files:

Ensure that the target database is started in the appropriate mode for the restoration operation. For lost control files, this will be nomount mode. If the entire database needs to be restored, this will be mount mode. If datafiles that don't belong to the SYSTEM tablespace are damaged, you have the option of keeping the database open and taking only the tablespace(s)/datafile(s) that needs to be restored offline.
Start RMAN and connect to the target and recovery catalog if one is being used.
Run the appropriate RMAN RESTORE command to bring back required files. The requested files and the appropriate archived redo log files will be restored.

Once the necessary files are restored, you need to recover your database and open it for use. You can recover the database from either RMAN, SQL*Plus, or Server Manager (Oracle8i only).

In this scenario, it is assumed that your control files are still accessible. Your first step is to make sure that the target database is shut down:

SQL> connect sys/harakhat as SYSDBA;
SQL> shutdown abort;
ORACLE instance shut down.

Next, you need to start up your target database in mount mode. RMAN cannot restore datafiles unless the database is at least in mount mode, because RMAN needs to be able to access the control file to determine which backup sets are necessary to recover the database. If the control file isn't available, you have to recover it first. Issue the STARTUP MOUNT command shown in the following example to mount the database:

SQL> startup mount;
Oracle instance started.

Total System Global Area		  309809312 bytes
Fixed Size 			              7388 bytes
Variable Size			             145715200 bytes
Redo Buffers			              180224 bytes
Database mounted.

Since backup set files are created in an RMAN-specific format, you must use RMAN to restore the datafiles. To use RMAN, connect to the target database:

$ rman target / catalog rman_901/rman_901_pwd@rman_catalog
Recovery Manager Release 9.0.1.0.0 - Production
connected to target database: BRDSTN (DBID=664610428)
connected to recovery catalog

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

RMAN Command Reference

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It is beyond the scope of this book to detail the ins and outs of every RMAN command. There's simply not enough room. We do provide the syntax for every command. We have also provided the syntax for Oracle8i and Oracle9i. And we provide examples for the most frequently used commands.

Many keywords are used in many different commands throughout this syntax section. To save space, we list these common keywords first.

allocOperand: See allocOperand later in Section 1.9.3.
DBID: A unique number that identifies a database.
BACKUPSET: Specifies the backup set to be used for an operation.
CHANNEL channel_id: Specifies a communication channel that RMAN uses to communicate with an I/O device.
CHECK LOGICAL: Tests blocks for logical corruption, which is then logged in the alert log and trace files. Additionally, the ranges of corrupt blocks can be queried in V$BACKUP_CORRUPTION. Ranges of corrupt blocks can be recovered with the Oracle9i BLOCK RECOVER command.
DATAFILE: Specifies a datafile by name or by number.
DATAFILECOPY: Indicates that image copies of datafiles should be used.
DEVICE TYPE deviceSpecifier: Indicates the type of device that should be used for an operation.
FORMAT 'format_string': Specifies the name and location for backup pieces. Various masks, described in Table 1-1, can be used as part of the format string.
LEVEL integer: Indicates the backup level to perform.
TABLESPACE tablespace_name: Specifies a tablespace name.
TAG tag_name: Specifies an arbitrary tag name for backups, file copies, archived logs, and control file copies.
UNTIL untilClause: Used by various RMAN commands to specify an upper limit for time, System Change Number (SCN), or log sequence numbers.

Table 1-1: Format string masks
Mask	Description
%c	Copy number of the backup piece
%d	Database name
%D	Day of the month (DD)
%M	Month of the year (MM)
%F	A unique name based on the DBID (a unique number that identifies a database), day of month, month, year, and a sequence number
%n	The database name, right-padded to a maximum length of eight characters
%u	An eight-character name representing the backup set and the time it was created

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Return to Oracle RMAN Pocket Reference