Oracle9i Database - Advanced Backup and Recovery Using RMAN - Student Guide

Oracle9i Database: Advanced Backup
and Recovery Using RMAN

Student Guide
D16507GC10
Production 1.0
March 2003
D37796
Author
Copyright Oracle Corporation, 2003. All rights reserved.
Jim Womack
This documentation contains proprietary information of Oracle Corporation. It is

provided under a license agreement containing restrictions on use and disclosure and
is also protected by copyright law. Reverse engineering of the software is prohibited.
If this documentation is delivered to a U.S. Government Agency of the Department of
Defense, then it is delivered with Restricted Rights and the following legend is
applicable:
Technical Contributors
and Reviewers
Matthew Arrocha
Tammy Bednar
Dairy Chen
Phillip Garm
Joel Goodman
Lex De Haan
Matthew Hart
Magnus Isaksson
Donna Keesling
Petter Stene
Sabine Teuber
Publisher
Michael Sebastian
Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for
commercial computer software and shall be deemed to be Restricted Rights software
under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Rights in Technical Data and Computer Software (October 1988).
This material or any portion of it may not be copied in any form or by any means
without the express prior written permission of Oracle Corporation. Any other copying
is a violation of copyright law and may result in civil and/or criminal penalties.
If this documentation is delivered to a U.S. Government Agency not within the
Department of Defense, then it is delivered with Restricted Rights, as defined in
FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
The information in this document is subject to change without notice. If you find any
problems in the documentation, please report them in writing to Education Products,
Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065.
Oracle Corporation does not warrant that this document is error-free.
All references to Oracle and Oracle products are trademarks or registered trademarks
of Oracle Corporation.
All other products or company names are used for identification purposes only, and
may be trademarks of their respective owners.
Contents
1 Overview of Recovery Manager (RMAN)

Objectives 1-2
RMAN 1-3
RMAN Features 1-4
RMAN Architecture 1-6
The RMAN Environment 1-7
RMAN and Enterprise Manager 1-8
RMAN Version Compatibility 1-9
RMAN Components 1-10
RMAN Utility Executable 1-12
RMAN Executable: The recover.bsq File 1-13
Recovery Catalog 1-14
Target Database: Control File Tables and Views 1-15
Target Database: DBMS_BACKUP_RESTORE 1-16
Channels and Media Manager Server 1-18
Running RMAN Commands 1-19
RMAN Usage Considerations 1-20
Simple Backup and Recovery Concepts 1-22
Database Inconsistency 1-24
Comparing Redo and Undo 1-26
Redo and Undo Generation 1-27
Recovery Concepts 1-28
Differences Between Crash and Media Recovery 1-29
Stuck Recovery 1-31
NOLOGGING and Recovery 1-32
Summary 1-33
2 Configuring RMAN
Objectives 2-2
RMAN Configuration Decisions 2-3
Issues to Consider 2-4
Using RMAN Without a Recovery Catalog 2-5
Creating the Recovery Catalog 2-6
Creating a Recovery Catalog 2-7
Recovery Catalog Strategy 2-9
RMAN Backup Strategy Guidelines 2-10
Ways to Start RMAN 2-11
Oracle Real Application Clusters 2-12
Connecting to an Auxiliary Database 2-13
RMAN and Pipes 2-14
Registering a Database in a Recovery Catalog 2-15
iii
Catalog Maintenance Commands 2-16

RESYNC CATALOG Command 2-17
Control File Record Types 2-18
Recovery Catalog Resync Types 2-19
When to Run a RESYNC CATALOG 2-20
Resync and Snapshot Control Files 2-21
Persistent RMAN Configuration Parameters 2-23
Retention Policies 2-24
The CONFIGURE RETENTION POLICY Command 2-25
The CONFIGURE CHANNEL Command 2-26
Automatic Channel Allocation 2-27
Channel Allocation By Using Enterprise Manager 2-28
CONFIGURE CONTROLFILE AUTOBACKUP 2-29
CONFIGURE SNAPSHOT CONTROLFILE and CONFIGURE AUXNAME 2-30
Other Configuration Commands 2-31
Calling Configuration Sets 2-32
The CATALOG Command 2-33
Catalog of Consistent and Inconsistent Copies 2-34
Recovery Catalog Compatibility 2-35
Determine the Schema Version of the Recovery Catalog 2-36
Upgrading Recovery Catalog 2-37
Dropping the Recovery Catalog 2-38
Summary 2-39
Practice Overview: Configuring RMAN 2-40
3 Backups with RMAN
Objectives 3-2
RMAN Backups 3-3
Running the BACKUP Command 3-4
Backup Tags 3-6
RMAN-Managed Backups 3-7
Parallelization of File Copies 3-8
Backup Sets 3-9
Backup Set: Example 3-10
Archivelog Backup Sets 3-11
Multiplexed Backup Sets 3-12
Parallelization of Backup Sets 3-13
Creating a Backup Set with Enterprise Manager 3-15
Backup Pieces 3-16
Backup Piece Contents 3-17
Incremental Data File Backup 3-18
Cumulative Incremental Backups 3-19
SCN and Incremental Backups 3-20
Basic Backup Algorithm 3-21
Algorithm Rules 3-22
Advanced Algorithm 3-24
Algorithm Behavior for Standard Backup Sets 3-25
iv
Algorithm Behavior for Archivelog Backup Sets 3-27

Algorithm Behavior for File Copies 3-28
Backup Optimization 3-29
Backup Optimization Algorithm 3-30
Duplexed Backups 3-32
Mirrored Backups 3-35
Proxy Copy 3-36
Backup Set Backup 3-37
Archived Log Backups 3-38
Archived Log Backup Methods 3-39
Long-Term Backups 3-40
Performing Test Backups by Using RMAN 3-41
Restarting a Backup 3-43
Default Autolocation for RAC Clusters 3-44
Summary 3-45
Practice Overview: Backups with RMAN 3-46
4 Restore and Recovery with RMAN
Objectives 4-2
The RESTORE Command 4-3
Steps in the RESTORE Process 4-4
File Selection When Restoring 4-5
Restore Optimization 4-6
Restoring Data Files and Tablespaces 4-7
Restoring to a New Location 4-8
Restoring Archived Logs 4-9
Restoring the Server Parameter File 4-10
Restoring the Database to a New Host 4-12
Create Standby Database with DUPLICATE 4-14
Validating Restore of Backups and Copies 4-15
Restore Autolocation 4-17
Restore When All Is Lost 4-18
RMAN Media Recovery Steps 4-20
RMAN Recovery Phases 4-21
Recover Database with Recovery Wizard 4-23
Tablespace Recovery with Recovery Wizard 4-24
RMAN Incomplete Database Recovery 4-25
DBPITR with Enterprise Manager 4-26
Specifying the Sequence 4-27
Block Media Recovery (BMR) 4-28
The BLOCKRECOVER Command 4-29
RMAN BMR Interface 4-31

Trial Recovery 4-32
Tablespace Recovery: Example 4-33
Recover Database: Example 4-34
Performing Incomplete Recovery by Using UNTIL TIME: Example 4-36
Performing Incomplete Recovery by Using UNTIL SEQUENCE: Example 4-38
Recovering a NOARCHIVELOG Database: Example 4-39
Examples of BLOCKRECOVER 4-40
Summary 4-42
Practice Overview: Restore and Recovery with RMAN 4-43
5 RMAN Maintenance
Objectives 5-2
RMAN Catalog Maintenance 5-3
The CROSSCHECK Command 5-4
The LIST Command 5-5
LIST Command Output 5-7
The REPORT Command 5-8
Report Objects Needing Backup 5-9
Report Unrecoverable Backups and Copies 5-11
Report Obsolete Backups and Copies 5-12
Report Database Schema 5-14
Show RMAN Configuration Settings 5-15
The CHANGEUNAVAILABLE and CHANGEAVAILABLE Commands 5-16
The CHANGEUNCATALOG Command 5-17
Deleting Specified Backups and Copies 5-18
Delete Expired or Obsolete Backups 5-20
Stored Script Information 5-21
Maintenance Required When Not Using a Recovery Catalog 5-22
Summary 5-23
Practice Overview: RMAN Maintenance 5-24
6 Using RMAN with a Media Manager
Objectives 6-2
Backups to Tape 6-3
Media Manager 6-4
Media Manager Prerequisites 6-5
Linking a Media Manager on UNIX 6-6
Linking a Media Manager on NT 6-8
Testing the Media Manager Installation 6-9
Performing a Test Backup to Tape 6-10
Testing Automatic Channels and MML 6-11
Default SBT Interface 6-13
Events in a Media Manager Backup 6-14
Events in a Media Manager Restore 6-16
Media Manager Diagnostics 6-18
vi
Troubleshooting: Media Manager or RMAN 6-19

Troubleshooting Media Manager 6-26
SBTINIT and SBTINIT2 Function Errors 6-28
SBTOPEN or SBTBACKUP Failures 6-30
SBTOPEN or SBTRESTORE Failures 6-31
SBTWRITE or SBTREAD Failures 6-32
SBT API Return Codes 6-33
Vendor Differences 6-34
Summary 6-35
Practice Overview: Using RMAN with a Media Manager 6-36
7 Debugging RMAN
Objectives 7-2
RMAN Message Output 7-3
The DEBUG Option 7-4
RMAN Code Layer Error Numbers 7-5
Media Manager Error Numbers 7-6
Interpreting RMAN Error Stacks 7-7
Interpreting RMAN Errors 7-8
Interpreting Server Errors 7-9
The sbttest Utility 7-10
Checking Backup and Restore Progress 7-11
Monitoring the Media Manager 7-13
Monitoring RMAN Sessions 7-14
Determining Which Data Files Require Recovery 7-16
Insufficient Privileges 7-17
UNIX Tape Backup Failure 7-19
NT Tape Backup Failure 7-21
RMAN Session Is Hung in the Media Manager 7-22
RPC Call Fails 7-24
Failure of Snapshot Control File Creation 7-25
RMAN Cannot Locate an Archived Log 7-27
Missing Log Causes Duplication Failure 7-29
Summary 7-30
Practice Overview: Debugging RMAN 7-31
8 RMAN Performance Tuning
Objectives 8-2
Tuning RMAN 8-3
Allocating RMAN Disk Buffer 8-4
Allocating Disk Buffer: Example 8-5
Allocating Tape Buffer 8-6
Synchronous Versus Asynchronous I/O 8-7
Setting LARGE_POOL_SIZE 8-9
Performance Monitoring 8-10
vii
Asynchronous I/O Bottlenecks 8-11

Synchronous I/O Bottlenecks 8-12
Tape Backup Speed 8-13
Tape Subsystem Performance Rules 8-14
Empty Files and Incremental Backups 8-15
Control Tape Buffer Size with BLKSIZE 8-17
Channel Tuning 8-18
Tuning the BACKUP Command 8-19
Summary 8-20
Appendix A
Appendix B - Practices
Appendix C - Solutions
viii
Overview of Recovery Manager (RMAN)
Copyright 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do
the following:
Explain the fundamentals of the RMAN
architecture and its components
Identify the features, components, and tasks of
RMAN
Describe the basic concepts of block consistency
1-2
Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-2
RMAN
1-3
It is an Oracle utility that can back up, restore, and

recover database files.
It is a PRO*C application that translates command
syntax into a series of PL/SQL calls.
It has a command line interface.
It has a graphical interface that is provided by the
Enterprise Manager.
It provides a powerful scripting language that can
be used in an interactive or a batch mode.
It is independent of the operating system.
RMAN
RMAN is a tool that manages the process of creating backups and the process of restoring and
recovering data from these backups. The product is a feature of the Oracle database server and
does not require separate installation. RMAN is a client-server application that uses database
server sessions to perform backup and recovery. It stores metadata about its operations in the
control file of the target database and, optionally, in a recovery catalog schema in an Oracle
database.
You can invoke RMAN as a command line executable from the operating system prompt or use
some RMAN features through the Enterprise Manager GUI.
RMAN Features
The features of RMAN include:
Automation of backup, restore, and recovery
Easy backup of archived redo logs
Automatic detection and inclusion of new data
files
Support of incremental backups
Reduction of recovery errors
No generation of extra redo during open database
backups
1-4
RMAN Features
RMAN automates backup and recovery, whereas the user-managed method requires you to keep
track of all database files and backups. For example, instead of requiring you to locate backups
for each data file, then copy them to the correct place by using operating system commands, and
choose which logs to apply, RMAN manages these tasks automatically.
RMAN simplifies the backup and restore process when using Oracle Managed Files. When you
use Oracle Managed Files, the Oracle server names and manages your data files, control files,
and online redo logs. This simplifies your management of these files. However, it may be harder
for you to keep track of the filenames of the various database files because you have not named
them yourself. RMAN handles all record keeping. For example, the addition of a data file will
automatically be detected, and included within the next backup.
RMAN can perform incremental backups, which back up only those data blocks that changed
after a previous backup. However, you can only take incremental backups of a NOARCHIVELOG
database after a consistent shutdown. You can restore the database by using incremental
backups, which means that you can restore a NOARCHIVELOG database.
RMAN Features
1-5
Corrupt block detection

Fractured block handling
Automatic parallelization of backup, restore, and
recovery
Restrict backups to limit reads per file or per
second
Online tablespaces need not be placed in backup
mode for backups
RMAN Features (continued)

RMAN computes checksums for each block during a backup and checks for corrupt blocks when
backing up or restoring. Many of the integrity checks that are normally performed when
executing SQL are also performed when backing up or restoring. RMAN also omits blocks that
have never been used from data file backups so that only data blocks that have been written to
are included in a backup. This is also known as null compression.
When backing up online files, RMAN rereads the fractured data blocks to get a consistent read.
You do not need to place online tablespaces in backup mode when performing backups. In
addition, RMAN can limit the number of open files to overcome OS limits on concurrent files
that are opened and limit the size of a backup piece. Users can limit RMAN operations per file,
or reads per second so that the effect of backups on online transaction processing (OLTP) work
can be minimized. The configuration of automatic parallelization of backup, restore, and
recovery functions greatly improves performance and ease of use. This is important because the
size of a backup piece can easily be more than the maximum file size allowed by the operating
system or media management software.
RMAN Architecture
Target instance
Server
session
(default)
Enterprise
Manager
DBMS_RCVMAN
RMAN
Server
session
(Catalog)
DBMS_RCVCAT
DBMS_RCVMAN
1-6
Fixed
tables and
views
DBMS_BACKUP_RESTORE
Server
session
(polling)
MML
Disk
Media Manager
Catalog tables
and views
Recovery
catalog
Target
control file
Server
session
(channel)
Server
session
(channel)
Target
database
files
Tertiary storage
RMAN Architecture
The RMAN executable can run on any machine, with Oracle9i Net Services connections being
made to the databases. The Recovery Catalog is a simple database schema residing in a database
that is separate from the target database. Relevant information is obtained from the control file if
a catalog is not used. Using the Recovery Catalog is optional.
The target database is the database from which backup, restoration, or recovery is taking place.
The RMAN connection to it is always of the SYSDBA type. In the target instance and database,
the following is used:
Two sessions for administrative purposes. These will make use of several packages in the
database that are installed when catproc.sql runs.
One session for every allocated channel. Channels transfer the actual database data.
The control file stores schema, backup, and recovery information. The control file and the
recovery catalog information are synchronized with RMAN.
The Media Management Library (MML) is a software that connects to a particular
vendors tape backup system. This is linked to the Oracle executable at installation.
Backup disks must reside on the same machine as the target database. If you are working with a
tape system, then it can reside anywhere. The MML software component ensures connectivity
between RMAN and the tape subsystem. Using Enterprise Manager to control RMAN is
optional.
The RMAN Environment

A typical RMAN environment uses the following items:
RMAN executable
Target database
Recovery catalog database
Media management software
1-7
The RMAN Environment

The RMAN environment consists of the utilities and the databases that play a role in a backup
and recovery strategy. Of the components listed above in the slide, only the RMAN executable
and target database are required.
RMAN automatically stores its metadata in the target database control file, so the recovery
catalog database is optional. Nevertheless, maintaining a recovery catalog is strongly
encouraged. If you create a catalog on a separate machine, and if the production machine fails
completely, then you have all the restore and recovery information that you need, present in the
catalog.
RMAN and Enterprise Manager
1-8
Using Enterprise Manager

RMAN backup, recover, and restore functionalities are implemented in Enterprise Manager
through the Backup Management wizards. You can access the Backup Management wizards and
property sheets by using one of the following methods:
From the Console Navigator tree, select the database that you want to administer; then,
choose the tool from the context-sensitive Backup Management menu.
From the Storage Management container of the Console Navigator tree, select the
tablespace or datafile that you want to administer; then, choose the tool from the contextsensitive Backup Management menu.
From the Object menu, select the Backup Management menu.
From the Tools menu, expand the Database Tools menu and select the Backup
Management menu.
RMAN Version Compatibility

The following four separate items must be compatible
with one another:
The RMAN executable
The target database
The recovery catalog
The database containing the recovery catalog
1-9
RMAN Version Compatibility

The four components listed above in the slide above must be compatible with one another.
Please note that not all combinations are supported. The RMAN executable of a later Oracle
database version may expect to use some feature in the target database that is not present in an
earlier version of the database. There are three general rules:
The RMAN catalog schema version (meaning, the version of RMAN that created or
updated the schema) should be equal or later than the catalog database version.
The version RMAN catalog schema should be equal or later than the version of RMAN,
that is, the RMAN catalog is backward compatible to back up target databases.
Use the same version of the RMAN executable as the target database.
You can use RMAN to create multiple catalog schemas in a single recovery catalog to store all
metadata of different releases.
RMAN Components
The RMAN tool consists of the following components:
RMAN executable
RMAN library file: recover.bsq
Recovery catalog
Tables
Views
RMAN packages
DBMS_RCVMAN
DBMS_RCVCAT
DBMS_BACKUP_RESTORE
1-10
RMAN Components
RMAN executable: The executable translates RMAN commands into a sequence of steps that
operate on the database physical files. It sends the backup, restore, and recovery steps to the
target database for execution, and coordinates and monitors the execution of these steps.
Recovery catalog: The recovery catalog is a repository that stores information relating to the
target database obtained from the target database control file. It contains information about the
physical schema of the target database, data files, archivelog backup sets and pieces, data file
copies, archived redo logs, and stored scripts. If the recovery catalog is not used, then RMAN
queries the target databases control file to decide what actions to perform.
RMAN packages: RMAN uses the DBMS_RCVMAN and DBMS_RCVCAT packages to query,
and update the recovery catalog, respectively. DBMS_BACKUP_RESTORE is the RPC interface
to the code that physically performs the backup, restore, and recovery actions. Note that these
packages are used by RMAN and it is extremely rare that a DBA would need to access them
directly.
The recover.bsq file: The recover.bsq file is also called the RMAN library file.
RMAN Components
1-11
Target database
Control file fixed tables and views
Channel (Server Sessions)
Media management interface module
Media Manager Server
RMAN Components (continued)

Target database: The database on which the specified backup, restore, and recover actions are
executed.
Control file fixed tables and views: The control file contains data that is used by RMAN to
populate the recovery catalog.
Channel (server sessions): For each channel, RMAN creates an Oracle Server process on the
target database to perform the backup, restore, or recovery.
Media manager interface: The media manager interface is an optional third-party media
management interface module that is linked to the Oracle Server.
Media manager server: A non-Oracle product that communicates with the interface module to
manage tertiary storage.
RMAN Utility Executable

The RMAN executable is responsible for:
Parsing RMAN command syntax
Performing name translations relative to any time
specifications such as point-in-time recovery or
user-specified tags
Generating PL/SQL programs that make remote
procedure code (RPC) calls to the RMAN packages
Coordinating execution of PL/SQL calls on
channels that are allocated
Updating the recovery catalog
1-12
RMAN Utility Executable

RMAN takes RMAN command syntax, parses it for correctness, and then translates these
commands into one or more PL/SQL programs. Each PL/SQL program is a step, with each step
having a status. A backup command is broken down into steps, one per backup set. For example,
if there are five sets to create, and there are five channels allocated, then each channel allocated
will create a set.
The RMAN executable is automatically included with the Oracle software installation. Its
location is platform-specific and is typically located in the same place as the other Oracle
executables. On UNIX systems, for example, the RMAN executable is located in
$ORACLE_HOME/bin.
To start the executable, enter the filename on the command line. For example, on a UNIX
system, enter:
$ rman
RMAN Executable:
The recover.bsq File
RMAN does not work without recover.bsq.

The recover.bsq file contains a version number
that must match that of the RMAN executable,
otherwise the following error will result:
OERR:RMAN 6035 wrong version of recover.bsq
expecting %s, found %s
The recover.bsq file location is port-specific.

UNIX: $ORACLE_HOME/rdbms/admin/recover.bsq
NT: %ORACLE_HOME%\rdbms\admin\recover.bsq
1-13
recover.bsq is also called the RMAN library file

and its contents are called library members.
The recover.bsq File

The recover.bsq file must exist in order for the RMAN executable to function correctly.
This file contains the following information:
PL/SQL code fragments
SQL statements
PL/SQL package specifications and bodies used for CREATE CATALOG
RMAN code fragments that are used for recursive RMAN invocation during commands
such as DUPLICATE DATABASE and tablespace point-in-time recovery
External commands such as the export/import used by TSPITR
Many library members contain substitution variables (&args&) that are replaced with real
values during compilation. See the example below:
define 'kbytes'
<<<
sys.dbms_backup_restore.setLimit(
sys.dbms_backup_restore.kbytes,&args&);
>>>
Recovery Catalog
The recovery catalog consists of the following

components:
1-14
Base tables and indexes

RC_* views
DBMS_RCVMAN package
DBMS_RCVCAT package
All information in the recovery catalog originates

from the target database control file.
Recovery Catalog
The recovery catalog is a set of tables, views, indexes, and PL/SQL packages, which are created
in a schema known as the recovery catalog owner. The recovery catalog consists of several
components, which include:
Base tables and indexes: These tables and indexes need not be queried.
RC_* views: RC_* views can be queried. These views will be covered in more detail in
lesson 5.
DBMS_RCVMAN package: RMAN queries the recovery catalog tables via the procedures in
this package. RMAN never selects data directly from the recovery catalog tables; it uses
views.
DBMS_RCVCAT package: RMAN updates the recovery catalog tables via the procedures in
this package. RMAN never updates the recovery catalog tables directly.
Target Database:
Control File Tables and Views
1-15
Both the V$ views and X$ tables can be queried

when the database is mounted, but not open.
All the V$ control file fixed views are based on
underlying X$ fixed tables.
Use the V$FIXED_VIEW_DEFINITION to see the
underlying X$ tables that are used by the views.
Control File Table and Views

The control file data can be viewed from a collection of views. This data is the source of
information that is used by RMAN to populate the recovery catalog. The following is a partial
list of the tables and views that are available:
V$BACKUP_ASYNC_IO
V$BACKUP_CORRUPTION
V$BACKUP_DATAFILE
V$BACKUP_DEVICE
V$BACKUP_PIECE
V$BACKUP_REDOLOG
V$BACKUP_SET
V$CONTROLFILE_RECORD_SECTION
V$COPY_CORRUPTION
V$DATABASE
V$DATAFILE
Target Database:
DBMS_BACKUP_RESTORE
It is a fixed package that is linked to the kernel so

that it can be called when the database is not
open.
It updates the target databases control file to
show what actions have been completed.
The package specification is in dbmsbkrs.sql.
1-16
DBMS_BACKUP_RESTORE
DBMS_BACKUP_RESTORE is the RPC interface to the code that physically performs the
backup, restore, and recovery actions that are requested by RMAN.
Because it is linked to the Oracle executable, DBMS_BACKUP_RESTORE can be called
whenever an instance is started; the database does not need to be mounted or open.
Target Database:
DBMS_BACKUP_RESTORE
Each DBMS_BACKUP_RESTORE call is:

Executed as an asynchronous RPC call to the target
database
Polled by RMAN, to identify the status of the call
During job execution for each channel, RMAN

initiates an RPC call, then polls to see if it has
started.
This information may be viewed by performing the
following SELECT operation:
SQL> select module, action from v$session;
1-17
Channels and Media Manager Server
A channel is a stream of data to a device type.

A channel connects RMAN to a database instance
by starting a server session on the instance.
The Media Manager Server communicates with the
interface module to manage tertiary storage.
Disk
Target
database
1-18
Server
session
Channel (disk)
Server
session
Channel (sbt)
RMAN
Channels and Media Manager Server

An RMAN channel represents one stream of data to a device type and corresponds to one server
session. Allocation of one or more RMAN channels is necessary to execute most backup and
recovery commands. Each channel establishes a connection from the RMAN executable to a
target or auxiliary database instance by starting a server session on the instance. The server
session performs the backup, restore, and recovery operations. Only one RMAN session
communicates with the allocated server sessions. Automatic channel allocation relieves the user
from performing the step of explicitly allocating a channel in a backup/restore or maintenance
session.
Oracle Corporation has integrated proxy copy functionality into its media management API.
Vendors can use this API to develop media management software that takes control of backup
and restore operations. RMAN provides a list of files requiring backup or restore to the media
manager, which in turn makes all decisions regarding how and when to move the data.
Running RMAN Commands
Individually:
RMAN> backup database;
In a RUN block:
RMAN>
2>
3>
4>
run {
copy datafile 10 to
'/oracle/prod/backup/prod_10.dbf';
}
Invoking an RMAN command file:

RMAN> @copy_10.rcv
1-19
Running RMAN Commands

RMAN commands can be run by several methods. The commands can be typed in manually
from an RMAN prompt as illustrated in the slide above. The commands can also be stored in an
OS text file and invoked from the RMAN prompt. In the example, the file copy_10.rcv
stores the RMAN commands.
The commands can also be stored in the recovery catalog as a stored script. A stored script is
associated with only one target database. Use the EXECUTE SCRIPT command to run an
RMAN script that you have stored in the recovery catalog. After connecting to the recovery
catalog and target database, issue a RUN command to execute the desired script. For example:
RMAN> RUN { EXECUTE SCRIPT backup_full; }
Note that you do not need to run ALLOCATE CHANNEL if you already did so within the script
or if you have automatic channels configured.
The CREATE SCRIPT command is used to create a stored script and is covered in detail in a
later lesson.
RMAN Usage Considerations
Resources: Shared memory, more processes

Privileges given to users
Database: SYSDBA
Operating System: Access to devices
Remote operations
Set up the password file
Ensure that the password file is backed up
Globalization environment variables

Format used for the time parameters in RMAN
commands
1-20
RMAN Usage Considerations

You must consider the following points before using RMAN:
Shared resources on the system: Most of the functions of RMAN are performed through
Oracle server processes. The operations can also be performed in parallel to increase
throughput. This implies that the PROCESSES parameter must be sufficiently high. From
the OS standpoint, this means that shared memory and semaphores are adequately set.
Set of users performing privileged operations: You must decide on the set of users who
perform privileged operations. Accordingly, you can set those users accounts with the
necessary privileges at the operating system and at the Oracle database.
To start up and shut down a database, the user must have the SYSDBA privilege.
RMAN Usage Considerations (continued)

Remote operations: You must use a password file to connect to the target database via
Oracle Net to perform privileged operations such as shutdown, startup, backup, and
recovery from a remote machine. You may have to set up a password file. You should
ensure that there is a strategy to backup the password file as well.
Globalization environment variables: Before invoking RMAN, set the
NLS_DATE_FORMAT and NLS_LANG environment variables. These variables
determine the format that is used for the time parameters in RMAN commands such as
RESTORE, RECOVER, and REPORT.
Use of the recovery catalog: When you use a recovery catalog, RMAN can perform a
wider variety of automated backup and recovery functions. Use of the recovery catalog
involves storage space and maintenance efforts.
You should also decide whether to have a database that is dedicated to maintaining the
recovery catalog of many target databases. Also, consider a strategy for backing up the
recovery catalog.
Simple Backup and Recovery Concepts
1-22
Crash recovery versus media recovery

Cold (offline) versus hot (online) backups
Restore and recovery
Read-only tablespaces
Offline tablespaces
Simple Backup and Recovery Concepts

A crashed database is a database that was not shut down in an orderly manner. Crash recovery
occurs automatically when the database is reopened after an abrupt termination such as a power
failure or SHUTDOWN ABORT. Only the online redo log files will be used. Deferred rollback of
any uncommitted transaction takes place after the database is open. Deferred rollback means that
the rollback that used to take place before the database was open now takes place after and may
even be done in parallel.
Media recovery occurs when the RECOVER command is used. It can use archive log files and the
online redo log files. The server will ask for media recovery if the data file header and control
file information do not match, or if the data file headers have indicators set that the file was not
closed normally. Deferred rollback of any uncommitted transaction occurs when the database is
opened.
A cold or offline backup is taken when the database is closed. With manual cold backups, the
instance can be shutdown; with RMAN offline backups, the instance must be in MOUNT mode.
Although you can use a backup that was taken of a crashed database in a recovery scenario, it is
not recommended.
Simple Backup and Recovery Concepts (continued)

A hot or online backup is taken when the database is open. ARCHIVELOG mode is a
prerequisite. For manual hot backups, the tablespaces involved must be placed in backup mode.
With RMAN online backups, the rereading of fractured blocks ensures block consistency. Thus,
you do not place tablespaces into any special mode for backup.
There are usually two steps to perform a media recovery: The first step (optional) is restore,
which is a simple copying of files from the backup system to the database locations. (RMAN
may need to assemble the file from several incremental RMAN backups.) The second step is the
recover step, when the server applies the archive and online redo logs. Normally, when people
refer to recovery, they are referring to the restore phase.
Read-Only Tablespaces
The intention of read-only tablespaces is to avoid performing repeated backups of data that does
not change, and to protect table row data against alteration. Even if you do not change any data,
the data files are written to during every database open, close, and checkpoint, if the database is
in normal mode. The data files of a tablespace set into read-only mode will not be written to, and
are allowed to be out of date compared with the other data files. You do not perform media
recovery on a read-only tablespaces data files, you only restore them. Read-only tablespaces
data files can be moved to a CD-ROM or WORM (Write Once, Read Many).
Note: Tables in a read-only tablespace can be dropped but keep in mind the table data is not
dropped, just the table definition.
Offline Tablespaces
There may be reasons for having only a partial set of the database available. Offlining a
tablespace causes the server to close the data files, thus freeing them for some operation (for
example, moving to shelf storage). Later, the data files are returned to their original location and
can be made online again. If the tablespace is offlined IMMEDIATE, which requires
ARCHIVELOG mode, then it will require media recovery because the related files were not
closed normally (the data in the buffer cache was not flushed). This occurs regardless of whether
data was in the cache or not. Note that if you take files offline, as opposed to offline tablespaces,
you do not get a choice. The process is immediate, thus requiring recovery when placing the
tablespace online again.
Database Inconsistency
Constraint inconsistency
Logical inconsistency
Structural inconsistency
Physical inconsistency
At the block level
At the inter-block level
1-24
When Is the Database Inconsistent?

The term inconsistent is often used, but can have several levels of meaning. If the data schema
presumes a constraint such as a foreign key constraint, any data in the database that violates that
would be a constraint inconsistency. This might happen when no constraints are used, but are
only implied. This is called a logical inconsistency. It might happen if an older version of a table
(that participates in a relation with other tables) is imported.
If the database does not contain the files that the dictionary says it should, then there is a gross
structural inconsistency. Normally, the database will not open until the fault is remedied.
Inside each block, there are many structures, apart from the row data of a table. There are
number of pointers between these structures. If these pointers are incorrect, then this can be
described as physical inconsistency. Some pointers refer to another block. If they point to the
wrong block, or if the other block does not have the content that it should have, then there is
physical inconsistency between blocks.
When Is the Database Inconsistent? (continued)

Many of the algorithms implemented for processing capabilities mean that at any stage during
normal database operation, different portions of the database (and the memory structures used to
access it) are inconsistent with regard to one another.
Consider that the database is the physical files in which you store data, and the instance is the
memory structures. You know that database blocks are read from the disk into memory buffers
and are then modified while they are resident in these buffers. Many changes can occur before
the blocks are written back into the data files by the LRU algorithm. These blocks are therefore
from a later state in time than the blocks on disk, and perhaps than other blocks in memory. The
database is therefore inconsistent, and anything other than a controlled shutdown will leave the
database inconsistent.
Another way of defining physical inconsistency is the following: if not all the blocks in a data
file or database are from the same point in time (that is, assuming all blocks have been flushed
from the cache), then the data file or database, respectively, is physically inconsistent.
Comparing Redo and Undo
1-26
The redo after image is used to repeat a data

modification, when the result has been lost.
The undo (or rollback) before image is used to get
the original data back after a change has
overwritten it.
Redo and undo are handled and stored separately
in the Oracle server architecture, but they are
created simultaneously by any data change.
Redo and Undo

To understand the recovery architecture, it is imperative to distinguish between undo and redo.
In the Oracle server, the primary use of undo is to ensure isolation, and the primary use of redo is
to ensure durability.
Undo is directly associated with a transaction, whereas redo is implicitly associated with a
transaction. Some redo is not part of the transaction with which it appears to be associated, for
example, delayed block cleanout changes. Undo can be discarded after the transaction commits;
redo can be discarded after the buffer cache is flushed or checkpointed.
Redo is stored in separate files in Oracle, the online redo log files, whereas undo is stored inside
normal data files in the special undo tablespace or the special (rollback) segments.
The words rollback and undo are synonyms.
Redo and Undo Generation
Redo is generated whenever any data file

changes:
Table data, LOBs, and associated indexes,
including the data dictionary
Undo data
Internal data block structures, pointers, or data file
headers
Control file changes
Redo can be partially suppressed (NOLOGGING)

Undo is generated whenever the user or the data
dictionary data changes:
Table data and associated indexes
1-27
Redo Generation
Redo is generated whenever any data block changes for whatever reason. Recall that the data file
header is a special data block, and that the control file, too, is read and written in blocks (but not
cached data blocks like the data files).
When a transaction generates redo, it also generates undo, which in turn generates more redo. In
practice, this is done backward: the server code first generates all the redo, then the undo, and
lastly the data change. The amount of redo generated can be controlled by the use of the
NOLOGGING clause. You can see the amount of redo generated in V$SYSSTAT in the row
redo size.
Undo Generation
Undo cannot be suppressed. It is the same mechanism regardless of whether you use automatic
undo management or manually-managed rollback segments.You can see the amount of undo
generated in V$ROLLSTAT under the column WRITES, and V$TRANSACTION under the
columns USED_UBLK and USED_UREC.
Recovery Concepts
Recovery for a thread starts at the last checkpoint.

Recovery progresses redo record by redo record,
until all available redo has been applied.
1-28
Find the block

Block time > Redo record time: Skip block
Block time = Redo record time: Apply changes
Block time < Redo record time: Stuck recovery
No generation of redo.
Recovery Concepts
For all redo vectors:
The data block address (DBA) specified in the vector is read into the cache.
If the block has the same time as the redo record, then the redo vector is applied.
The block is written out by a recovery checkpoint at a log switch or when aged out of
cache.
The method that determines whether or not a block needs recovery allows for the situation that
blocks inside the data file were written between the full checkpoints. The start of redo is
determined by the file header and is a safe starting point. The recovery decision process also
facilitates recovery being reapplied repeatedly, or restarted after a crash while applying redo.
The redo will be applied only if the redo and block match in time. Note that the word time
refers to the logical time line as given by the SCN and SEQ (sequence) and not to any
timestamp. This also makes the recovery process safe against changes of the clock such as
daylight savings time. There is no redo generated while performing recovery. The control file is
also modified, tracking the progress of the recovery.
Differences Between Crash and Media

Recovery
Crash recovery:
Two pass reading
Scan Block Written Records (BWRs) in redo stream
Reread redo stream and apply only required redo
Database consistent and complete

Media recovery:
Recovery checkpoints
Incomplete or complete, but consistent
1-29
Differences Between Crash and Media Recovery

Crash recovery is automatic and uses the online redo logs that are CURRENT or ACTIVE. Media
recovery is manual. Media recovery can be performed even without ARCHIVELOG mode,
provided there is enough information in the online redo logs. Crash recovery can only occur on
one thread. For media recovery, the redo records of all threads are taken in SCN/SEQ order as
the data files may have been modified by several instances.
Two Pass Recovery in Crash Recovery
The ordinary cache aging and the incremental checkpoint system have probably written a
number of blocks to disk, without the file headers being updated. When the database writer
(DBWn) completes a data block write operation, it also adds a redo record that states that the
block has been written. This is called a Block Written Record (BWR). During crash recovery,
the online redo log is read twice.
The first read of the redo builds a list of blocks that are mentioned in the redo. Some of the redo
records are the BWR entries which signify that the block mentioned is up to date until that point
in the redo. The block is removed from the list. The resultant list of this first pass is a list of
blocks, which have redo that were not written to disk.
Differences Between Crash and Media Recovery (continued)

Two Pass Recovery in Crash Recovery (continued)
The second read of the redo now only processes a block from this list, which should be much
smaller than all the blocks touched in the redo stream. Many fewer data blocks are read and
written, thus offsetting the cost of reading the online redo log files twice.
If the system is unable to perform two pass recovery, then it will fall back to the single pass. The
alert file states the result from two pass recovery.
Media Recovery
During media recovery, the blocks are in the buffer cache, waiting to be written out to the data
files. The blocks are recovery checkpointed at log switches. Recovery checkpoints are noted in
the control file, so that the server does not need to reprocess the same redo data in case the
recovery is restarted. The recovery checkpoints also update the data file headers.
Media recovery can be complete or incomplete. An incomplete recovery will require the use of
RESETLOGS. Before Oracle9i, if a media recovery got stuck or crashed, then the database was
possibly left in a physically inconsistent state. To open the database, data files had to be restored
and then an incomplete recovery done. Since Oracle9i, the data block writing during recovery is
modified, such that at an aborted recovery, the database is in a consistent state.
Stuck Recovery
A block is older than the redo that you are trying

to apply.
Recovery was not started early enough
in the redo stream.
Some redo is lost.
There is block corruption in data or redo.
Possible recovery from stuck recovery:

Retry recovery with older data and archive the log
files.
Corrupt the block.
1-31
Stuck Recovery
Stuck recovery should cause a trace or a dump, typically ORA-600[3020]. To progress past a
stuck recovery, the block must be marked corrupt because there is no consistent information
about what the block content should be.
In Oracle9i, this is performed with either ALLOW 1 CORRUPTIONS, or with TEST in the
recover command.
Test Recovery
Oracle9i introduced test or trial recovery. Test recovery is a dry run of a media recovery,
reading and modifying data blocks, but not writing the changes back to disk. During normal
recovery, if there is any serious error, then the recovery will stop. After correcting the error, the
recovery is attempted again, and possibly fails at the next error. Test recovery is used to see how
many such serious errors might occur. Depending on the answer, a different recovery scenario
might be attempted. Test recovery can also mark blocks as corrupt. Data cannot be retrieved
from such blocks, but can be skipped.
NOLOGGING and Recovery
1-32
Data manipulated in NOLOGGING mode cannot be

crash recovered or media recovered.
Blocks that do not have complete redo are marked
invalid on recovery.
Temporary tables and sort segments are always
NOLOGGING.
NOLOGGING and Recovery

The data that is manipulated in the NOLOGGING mode cannot be crash recovered or media
recovered. When a bulk data operation is performed on an object that is marked NOLOGGING,
the range of blocks that are affected will be noted as invalidated in the redo record. On recovery,
the data blocks will be marked as soft corrupt in the data file. This avoids issues with old blocks
in the data file being reused as segments are dropped and the space allocated to other objects
seeing old data.
When users attempt to retrieve data from such a table or index they receive:
ORA-26040: Data block was loaded using the NOLOGGING option
Versions before Oracle8i may report:
ORA-1578: ORACLE data block corrupted (file nn, block nn)
The blocks that belong to sort segments, temporary tables, and any block in a temporary
tablespace, will not generate any redo. As these blocks contain data that only has a lifetime of a
statement or session, then the data is not needed if there is a crash, which either aborts the
statement or the session.
Summary
In this lesson, you should have learned how to:
Explain the fundamentals of the RMAN
architecture and its components
Describe the basic backup structures
Identify the features, components, and tasks of
RMAN
1-33
Configuring RMAN
Objectives
the following:
Explain RMAN configuration decisions
Outline the steps that are involved in creating a
recovery catalog
Create and grant privileges to an RMAN user
Start RMAN and register a database in a recovery
catalog
Demonstrate the use of recovery catalog
maintenance commands such as RESYNC,
CONFIGURE, and CATALOG
2-2
Upgrade and drop a recovery catalog

RMAN Configuration Decisions

Before configuring RMAN, decide:
Whether to use a recovery catalog
Whether Oracle password files will be used
How and when to back up OS files
What name to be given to the snapshot control file
2-3
RMAN Configuration Decisions

Although RMAN can conduct all major backup and recovery operations by using just the control
file, note the following advantages of using the catalog:
Some RMAN commands and operations function only with a catalog.
The recovery catalog retains historical backup information that can get overwritten in the
control file.
The recovery catalog stores information about backups from different incarnations of the
database.
RMAN automatically propagates information about the database structure, archived redo logs,
backup sets, and data file copies into the recovery catalog from the target databases control file.
When you use a recovery catalog, RMAN requires that you maintain a recovery catalog schema.
The recovery catalog is stored in the default tablespace of the schema. Note that SYS cannot be
the owner of the recovery catalog.
Decide which database you will use to install the recovery catalog schema, and also how you
will back up this database. You must not install the catalog in the target database because this
tactic defeats the purpose of the catalog. Also, decide whether to operate the catalog database in
ARCHIVELOG mode, which is recommended.
Issues to Consider
The following are some issues to consider when
deciding whether to use a recovery catalog or not:
If the control file is lost and you need to restore
and recover the database (Oracle8i), then you
require the assistance of Oracle Customer
Support Services.
Point-in-time recovery (PITR) can be difficult or
impossible.
Overheads are incurred in the use of a recovery
catalog.
2-4
Issues to Consider
RMAN can be configured to use a recovery catalog in addition to the target databases control
file. Some complications that are related to not using a recovery catalog include:
Losing a control file with a need to restore and recover. If the database is pre-Oracle9i,
Oracle Customer Support Services can only help if the user maintains excellent records
(that is, RMAN message log files) of which files were backed up, the date on which the
backup occurred, and the names of the backup pieces.
Point-in-time recovery may be more difficult if the database schema has changed since the
point that you want to recover until, especially if there are data files that existed then but
do not exist now. Such a recovery cannot be automated with RMAN. You must first restore
a backup control file that knows about the physical schema that existed at the recovery
time.
If the database uses a large number of data files (more than 1000), then backup and restore
performance is better with a recovery catalog. If not using a recovery catalog, multiple backups
of the control file should be kept on different disks, tapes, and/or machines. These backups must
be restorable without RMAN.
Using RMAN Without a Recovery Catalog

If you choose to operate without a recovery catalog,
then the following commands will not be available:
{CREATE|UPGRADE|DROP} CATALOG
{CREATE|DELETE|REPLACE|PRINT} SCRIPT
LIST INCARNATION
REGISTER DATABASE
REPORT SCHEMA AT TIME
RESET DATABASE
RESYNC CATALOG
2-5
Using RMAN Without a Recovery Catalog

If you choose not to use a recovery catalog, then you can still use RMAN effectively.
Remember, RMAN obtains the information that it needs from the control file of the target
database. Nevertheless, some commands are not available when you use the control file as the
sole repository of RMAN metadata.
With the advent of Oracle9i, the importance of the recovery catalog is diminished. The needed
functionality is provided with the control file store, except when dealing with environments
containing many databases.
Note: LIST INCARNATION is supported in Oracle9i, release 2 databases running in
NOCATALOG mode.
Creating the Recovery Catalog

1.
2.
3.
4.
5.
6.
2-6
Decide in which database to create the catalog.

Decide the frequency of backup and resync.
Create an RMAN tablespace.
Create and grant privileges to a RMAN user.
Connect as the RMAN user.
Create the repository with the CREATE CATALOG
command.
Creating a Recovery Catalog
SQL>
2
3
4
create user RMAN identified by RMAN

temporary tablespace TEMP
default tablespace RCVCAT
quota unlimited on RCVCAT;
SQL> grant recovery_catalog_owner to RMAN;
2-7
Create the RMAN User and Schema

In this example, the user RMAN is created and the default tablespace that will store the users
schema is assigned. Next, grant the RECOVERY_CATALOG_OWNER role to the schema owner.
This role provides the user with the privileges to maintain and query the recovery catalog.
SQL> grant recovery_catalog_owner to rman;
Grant other desired privileges to the RMAN user as needed.

SQL> connect / as sysdba
SQL> grant dba, connect, resource, sysdba to rman;
Creating a Recovery Catalog

Connect as RMAN user and create the recovery
catalog repository by issuing the create catalog
command:
$ rman catalog RMAN/RMAN
Recovery Manager: Release 9.2.0.0.0
(c) Copyright 2003 Oracle Corporation.
connected to recovery catalog database
RMAN> create catalog
2-8
Creating the Repository

The recovery catalog is created by issuing the RMAN command and connecting to the RMAN
database (if you chose to create a separate database for the recovery catalog) as user RMAN and
issuing the CREATE CATALOG command.
Recovery Catalog Strategy

When using a recovery catalog, the following
decisions on backup and resyncs must be made:
How the recovery catalog will be backed up
How often the recovery catalog will be backed up
How often to resync the recovery catalog
How to automate catalog resynchronizations
2-9
Recovery Catalog Strategy

Include the recovery catalog in your backup and recovery strategy. If you do not back up the
recovery catalog and a disk failure occurs that destroys the recovery catalog database, then you
may lose the metadata in the catalog. Avoid this unpleasant scenario by deciding how to back up
and recover the recovery catalog.
Back up the recovery catalog with the same frequency that the target database is backed up. If
you make a weekly whole database backup of the target database, then back up the recovery
catalog immediately after all target database backups. The backed up catalog contains a record
of the target backup preceding it, so if you need to restore the catalog you can use it to restore a
target backup.
When the RMAN resync catalog command is issued, the tables in the catalog database will
be updated with any new information stored in the control file such as the new backup sets
created or new stored scripts.
RMAN Backup Strategy Guidelines
2-10
Run the recovery catalog database in ARCHIVELOG

mode.
Back up the database onto two separate media
such as disk and tape.
Back up the database and archived logs at regular
intervals.
Do not use another recovery catalog as the
repository for the backups.
Configure the backup so that the control file is
automatically backed up too.
RMAN Backup Strategies

When backing up the recovery catalog database, you can use RMAN to make the backups.
RMAN should be started in this circumstance with the NOCATALOG option so that the repository
for the recovery catalog is the control file in the catalog database. With this strategy, the control
file autobackup feature ensures that the recovery catalog database can always be recovered.
Ways to Start RMAN
No recovery catalog and no username/password

$ ORACLE_SID=U01;export ORACLE_SID
$ rman nocatalog
RMAN> connect target
No recovery catalog, HR has SYSDBA privileges

$ rman target hr/hr nocatalog
Using a recovery catalog

$ rman catalog rman/rman@rcat
RMAN> connect target
2-11
Starting RMAN
There are many ways that a user can start RMAN depending on how RMAN was configured and
of course the users current needs. In addition to the methods demonstrated in the slide above,
RMAN can also be started in the following ways:
By connecting to a target database (either locally or remotely) when using a password file
and specifying a net service name in the target connect string while not using a recovery
catalog:
$ rman target_db internal/secret@prod rcvcat rman/rman@rcat
By connecting to a target database (either locally or remotely) when using a password file
and specifying a net service name in the target connect string, no recovery catalog:
$ rman target scott/tiger@prod nocatalog
Oracle Real Application Clusters
RMAN can connect to only one RAC instance at a

time.
Net service names that distribute connections to
more than one database cannot be used with
RMAN.
Automatic channels can be configured for each
RAC instance.
By using this method, you can back up the entire
database with one command.
2-12
Connecting to Oracle Real Application Cluster Databases

RMAN can connect initially to only one instance at a time in an Oracle Real Application
Clusters configuration. Assume that RAC1, RAC2, and RAC3 are net service names for three
instances in an Oracle Real Application Clusters configuration. You can connect to the target
database by using only one of these net service names. For example, you can connect as follows:
$ rman TARGET SYS/oracle@RAC2 CATALOG rman/rman@catdb
Each net service name must specify one and only one instance. You cannot specify a net service
name that uses Oracle Net features to distribute connections to more than one instance.
Although RMAN connects to only one instance for its initial target connection, note that this
does not preclude running a backup against all three instances. For example, you can configure
automatic channels to connect to each instance, then make a whole database backup by running
the BACKUP DATABASE command.
Connecting to an Auxiliary Database
Connect to an auxiliary instance from the

operating system command line:
$ rman AUXILIARY SYS/aux_passwd@auxiliarydb
Connect to the target database, auxiliary

database, and recovery catalog database at the
same time:
$ rman TARGET SYS/oracle@trgt \

CATALOG rman/cat@catdb AUXILIARY SYS/aux@auxdb
2-13
Connecting to an Auxiliary Database

To use the DUPLICATE command or to perform tablespace point-in-time recovery with RMAN,
you must connect to an auxiliary instance. If the auxiliary database uses password files for
authentication, then you can connect by using a password for either local or remote access. If
you are connecting remotely through a net service name, then authentication through a password
file is mandatory.
The examples in the slide above demonstrate the command syntax that is necessary to connect to
an auxiliary database and simultaneously to target, catalog, and auxiliary database respectively.
Alternatively, you can start RMAN and connect to the databases individually from the RMAN
prompt:
$ rman
RMAN> CONNECT TARGET SYS/oracle@trgt
RMAN> CONNECT CATALOG rman/cat@catdb
RMAN> CONNECT AUXILIARY SYS/aux@auxdb
RMAN and Pipes
RMAN can use pipes to connect and execute

RMAN commands.
By interfacing with the DBMS_PIPE package,
RMAN can avoid using an operating system shell.
The use of public pipes with RMAN is not
permitted for security reasons.
To use RMAN in pipe mode, connect to the target
database and specify the PIPE option.
$ rman PIPE pipe_name TARGET SYS/oracle@trgt
2-14
Using Pipes with RMAN

The RMAN pipe interface is an alternative method for issuing commands to RMAN and
receiving the output. By using a pipe, RMAN can interface with the DBMS_PIPE PL/SQL
package and avoid using an operating system command shell altogether.
RMAN does not permit the pipe interface to be used with public pipes because they are a
potential security problem. With a public pipe, any user who knows the name of the pipe can
send commands to RMAN and intercept its output. If the pipes are not already initialized, then
RMAN creates them as private pipes. If you want to put commands on the input pipe before
starting RMAN, be careful to first create the pipe by calling DBMS_PIPE.CREATE_PIPE.
Whenever a pipe is not explicitly created as a private pipe, the first access to the pipe
automatically creates it as a public pipe, and RMAN returns an error if it is directed to use a
public pipe.
If multiple RMAN sessions can run against the target database, then use unique pipe names for
each session of RMAN. The DBMS_PIPE.UNIQUE_SESSION_NAME function is one method
that can be used to generate unique pipe names.
Registering a Database
in a Recovery Catalog
When using a recovery catalog, you must register

the database with the recovery catalog before
using RMAN to perform backups.
The target database that you connect to will be the
database that is registered in the catalog.
RMAN> register database;
2-15
The register command identifies the database to

the recovery catalog.
Information about the target databases structure
is propagated from the target databases control
file.
Registering a Database in a Recovery Catalog

The enrolling of a database in a recovery catalog is called registration. You can register more
than one target database in the same recovery catalog. You can register a database only once in a
given catalog schema. Because RMAN distinguishes databases by a unique database identifier
(DBID), each database registered in a given catalog must have a DBID. You cannot register two
databases with the same DBID in the same catalog.
However, each database does not need to have a unique database name. If you use operating
system commands to copy a database, then the copied database has the same DBID as the
original database. Thus, you cannot copy a database manually and then register it in the same
catalog with its parent unless you change the DBID of the copied database. For this reason, it is
easiest to use the DUPLICATE command to create a copied database because RMAN
automatically gives the copied database a different DBID. You can also use the DBNEWID utility
to change the DBID (or the database name) of any Oracle database. DBNEWID is useful when
you have already created multiple databases with the same DBID and you now want to register
them all in the same recovery catalog.
Catalog Maintenance Commands
2-16
The RESYNC CATALOG command synchronizes the

recovery catalog with the target databases control
file.
With the CONFIGURE command, the user can
adjust persistent configuration parameters in
Oracle9i.
The CATALOG command allows user-managed
backups to be managed by RMAN.
Catalog Maintenance Commands

There are a number of RMAN commands that the user can use to maintain information in the
recovery catalog. The RESYNC command compares the catalog and target control file and brings
them back to a state of agreement. By using the CONFIGURE command, the user can create
and manage a set of configuration parameters that greatly enhance the useability of RMAN. The
CATALOG command allows user-managed data file and archived log file backups to be
cataloged in the RMAN repository.
RESYNC CATALOG Command
RMAN> resync catalog;
Triggers RMAN to compare the recovery catalog to

the target databases control file
Causes RMAN to copy data from the V$ views in
the target database control file to the recovery
catalog
Initiates resyncs in two ways:
Manual: With the RESYNC CATALOG command
Automatic: When needed, at the start and/or end of
an RMAN command
2-17
RESYNC CATALOG Command

The RESYNC CATALOG command causes RMAN to compare the recovery catalog to either the
current control file of the target database, or a control file copy, if the keyword from control file
copy is specified. RMAN automatically detects what information has been updated in the control
file, and updates the recovery catalog with the information that is missing or changed. If the
target database is open, then it also registers information about which tablespaces contain undo
segments. This is used for tablespace point-in-time-recovery (TSPITR), to ensure that all
tablespaces with undo segments in them are restored for the TSPITR to be successful.
Because the control file employs a circular reuse system, backup and copy records eventually get
overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and
so are not lost.
Following is a list of records that are resynced:
Log history archivelog copy (archivelog copy, or archivelog backupset restore)
Backup history (backup or copy performed that is not already present in the catalog)
Physical schema (must have current control file mounted)
If syncing from control file copy, then resync does not validate that backup pieces, file copies,
and archive logs exist.
Control File Record Types

Two types of control file records exist:
Circular reuse
Resync is possible without a read-consistent image
of the control file.
Noncircular reuse
Resync requires a read-consistent image of the
control file, thus there is a need for snapshot.
2-18
Control File Record Types

Circular Reuse
This record type is suited for information that is continuously generated by the server and can be
overwritten if need be, because it is not critical for production operation. Records are arranged in
a logical ring. When all available slots are full, the control file is either expanded to make room
for the new record or the oldest record is overwritten. The parameter that determines which of
these two options will be used is CONTRO_LFILE_RECORD_KEEP_TIME. Examples include
log history, archived log, backup record, and offline ranges. The default value for this parameter
is seven days.
Noncircular Reuse
This record type is for information that is not changed often and cannot be overwritten, because
it is critical for production operation. Examples include data files, redo threads, and online redo
logs.
Recovery Catalog Resync Types

There are two types of recovery catalog resyncs:
Partial resync: Used when only circular reuse
records need to be resynced
Full resync:
Used when some noncircular reuse records need to
be resynced
Always performed by RESYNC CATALOG command
2-19
Recovery Catalog Resync Types

Partial Resync
Partial resyncs are used when only circular reuse records need to be resynced and as such does
not require a read-consistent image of the control file. Partial resyncs are only done during an
RMAN automatic resync, and when RMAN detects that a full resync is not needed.
Full Resync
Because full resyncs are used when some noncircular reuse records need to be resynced, a readconsistent image of the control file is needed. A full resync reads from the snapshot control file,
not from the current control file. Whenever the RESYNC CATALOG command is issued, a full
resync is always performed. An RMAN automatic resync will only be a full resync when a
noncircular reuse record has changed to avoid creating the snapshot control file if not necessary.
RMAN automatically detects when it needs to perform a full or partial resynchronization and
executes the operation as needed. You can also force a full resynchronization by issuing a
RESYNC CATALOG command.
When to Run a RESYNC CATALOG

The RESYNC CATALOG command should be run:
2-20
Each time the physical database structure

changes
When data files are added or resized
When a tablespace is dropped
When undo segments are created or dropped
At least once per each 10 archived logs
When to Run the RESYNC CATALOG Command

The recovery catalog should be resynced regularly, because it is not automatically updated when
a redo log is archived; instead this information is cached in the control file, and should be
periodically propagated to the recovery catalog. To ensure that the catalog stays current, run the
RESYNC CATALOG command periodically. It is a good practice to run it at least once per each
10 archived logs. The cost of this operation is related to the number of new or changed records in
the control file since the previous resync. So, the more often you resync, the quicker the
operation will complete.
Resync and Snapshot Control Files
2-21
When RMAN needs to resynchronize from a readconsistent version of the control file, it creates a
temporary snapshot control file.
RMAN needs a snapshot control file only when
resynchronizing with the recovery catalog or when
making a backup of the current control file.
The control file is created the same way as
if running the command:
ALTER DATABASE BACKUP CONTROLFILE
Resync and Snapshot Control Files

RMAN generates a snapshot control file, which is a temporary backup control file, each time it
performs a full resynchronization. This snapshot control file ensures that RMAN has a consistent
view of the control file. Because the snapshot control file is intended for short-term use by
RMAN, it is not registered in the recovery catalog. RMAN records the snapshot control file
checkpoint in the recovery catalog to indicate the currency of the recovery catalog.
The Oracle server ensures that only one RMAN session accesses a snapshot control file at any
point in time. This safeguard is necessary to ensure that two RMAN sessions do not interfere
with each others use of the snapshot control file.
The default value for the snapshot control file is platform specific. The default filename on some
UNIX platforms is $ORACLE_HOME/dbs/snapcf_@.f.
Use the CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'filename' command to
change the name or location of the snapshot control file to a nondefault value. Subsequent
snapshot control files that RMAN creates use the specified filename.
Resync and Snapshot Control Files (continued)

The snapshot control file can be written to a raw device. An Oracle Real Application Clusters
configuration does not require the snapshot control file to be shared across all instances, but the
snapshot control filename must be set to a location where any instance can create one. Each
instance is permitted to create the snapshot control file in its own file system as it needs one. The
following example sets the snapshot control file name to a raw device:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/dev/vgd_1_0/rlvt5';
Note that if one RMAN job is already backing up the control file while another needs to create a
new snapshot control file, you may see the following message:
waiting for snapshot controlfile enqueue
Under normal circumstances, a job that must wait for the control file enqueue waits for a brief
interval and then successfully retrieves the enqueue. RMAN makes up to five attempts to get the
enqueue and then fails the job. The conflict is usually caused when two jobs are both backing up
the control file, and the job that first starts backing up the control file waits for service from the
media manager.
Persistent RMAN
Configuration Parameters
2-23
The customizable configuration parameters

simplify formerly complicated RMAN operations.
The default settings are set once and reused for
subsequent jobs.
The default parameters can be overridden with the
CONFIGURE command.
The configuration values are stored in the control
file and written to the recovery catalog when
resynced.
Persistent RMAN Configuration Parameters

It is possible to create a persistent backup configuration. After these parameters are configured
RMAN will continue to reuse the configured options for subsequent backups unless you override
the option within your script or disable it. In RMAN you use the show command to see the
currently configured options.
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR TYPE DISK TO '%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/9.0.2/dbs/snapcf_U02.f';
Retention Policies
A retention policy describes which backups will be

kept and for how long.
There are two types of retention policies:
Recovery window: This policy establishes a period
of time within which point-in-time recovery must be
possible.
Redundancy: Establishes a fixed number of
backups that must be kept. Backups that are in
excess of this can be deleted.
2-24
These policies are mutually exclusive and can be

set with the CONFIGURE command.
Retention Policies
A retention policy describes which backups will be kept and for how long. The value of the
retention policy is set by the CONFIGURE command. The best practice is to establish a period of
time during which it will be possible to discover logical errors and fix the affected objects by
doing a point-in-time recovery to just before the error occurred. This period of time is called the
recovery window. This policy is specified in number of days. For each data file, there must
always exist one backup which satisfies the condition:
SYSDATE - CHECKPOINT_TIME <= recovery_window
For example, if the policy were to be set as follows:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Then for each file there must be a backup that satisfies:

SYSDATE - (SELECT CHECKPOINT_TIME FROM V$DATAFILE) >= 7
For DBAs who require the exact number of backups, they may set the retention policy based on
the redundancy option. This option requires a specified number of backups to be cataloged
before any backup is identified as obsolete. This policy is specified as number of backups.
The default retention policy is redundancy 1. A backup is deemed obsolete when a more recent
version of the same files has been backed up.
The CONFIGURE RETENTION POLICY

Command
Setting a recovery window policy

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY
2> WINDOW OF 5 DAYS;
Setting a redundancy policy

RMAN> CONFIGURE RETENTION POLICY TO
2> REDUNDANCY 5;
Setting no retention policy

RMAN> CONFIGURE RETENTION POLICY TO NONE;
2-25
The CONFIGURE RETENTION POLICY Command

The CONTROL_FILE_RECORD_KEEP_TIME parameter determines when the records or
entries in the control file will be reused with new information. When the data is replaced,
RMAN is no longer able to reconstruct a list of backup files that are required to do a valid
restore. If the value specified for the recovery window is greater than the
CONTROL_FILE_RECORD_KEEP_TIME parameter, then a recovery catalog is required.
The DELETE OBSOLETE command is used to delete obsolete backup sets, based on the
retention policy. Backup sets that are identified to never expire are not affected by the retention
policy or DELETE OBSOLETE command.
RMAN cannot implement an automatic retention policy if backups are deleted by using nonRMAN methods. One such method is the media managers tape retention policy. Ideally, the
media manager will never expire a tape until all RMAN backups residing on that tape have been
removed from the media managers repository.
There is a difference between CONFIGURE RETENTION POLICY TO NONE and
CONFIGURE RETENTION POLICY TO CLEAR. The former means that there is no retention
policy, backups will never expire and DELETE OBSOLETE will give an error. latter means that
the default retention policy (REDUNDANCY 1) will be in effect.
The CONFIGURE CHANNEL Command

The CONFIGURE CHANNEL command is used to
configure channel settings.
CONFIGURE CHANNEL [n] <channel_option_list>;
channel_option_list:= TYPE, NAME, PARMS,
CONNECT, DEBUG,
FORMAT, TRACE,
MAXPIECESIZE, RATE,
MAXOPENFILES, SEND
2-26
The CONFIGURE CHANNEL Command

The CONFIGURE CHANNEL command gives the DBA the capability to substitute parameter
option values automatically such as NAME, PARMS, CONNECT STRING, DEBUG, FORMAT,
MAXPIECESIZE, and SEND to be used when RMAN needs I/O.
When parallelizing channels, it may be necessary for each channel to be uniquely identified. An
example of this is in an Oracle Real Application Clusters architecture. In this environment,
online redo logs are archived to different nodes in a cluster. It is necessary for RMAN to connect
to each node to back up the archived logs.
If the channel number [n] is specified, the settings apply just to the channel. Otherwise, the
settings apply to all channels of the specified type.
Example of settings for all channels:
RMAN> CONFIGURE CHANNEL TYPE SBT;
Example of settings for a specific channel:

RMAN> CONFIGURE CHANNEL 1 TYPE SBT CONNECT 'node1';
In this example, the channel is set to make backups in a particular directory:

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK
2> FORMAT '/u01/backup/U01_%U';
Automatic Channel Allocation
2-27
Channels can now be allocated automatically for

BACKUP, COPY, RESTORE, and assorted
maintenance commands.
A channel is automatically allocated if not
explicitly specified in the RMAN command.
Default values are specified with the CONFIGURE
command.
Automatic Channel Allocation

When a channel is automatically allocated, the channel name is in the format
ORA_devicetype_n where devicetype refers to a disk or tape device and n refers to the
channel number. RMAN is aware of the command being run and allocates the proper channel
type. For example:
ORA_DISK_1
ORA_SBT_TAPE_2
Automatic channel allocation also applies to maintenance commands. If you manually allocate a
maintenance channel by using ALLOCATE CHANNEL FOR MAINTENANCE, then RMAN
uses the following convention for channel naming: ORA_MAINT_devicetype_n.
For example, RMAN uses these names for two manually allocated disk channels:
ORA_MAINT_DISK_1 and ORA_MAINT_DISK_2
RMAN knows the command that is being run. For backups, only a single type of channel is
allocated. For restores, RMAN knows which device types are required, and thus allocates all
necessary channels.
Channel Allocation By Using Enterprise

Manager
2-28
Channel Allocation By Using the Create Backup Configuration Wizard

You can use the Create Backup Configuration Wizard to define a configuration with a set of
defaults for backup and recovery. On the General page, you provide a name and description for a
set of defaults that are used for backup, recovery, and catalog maintenance operations. On the
Channels page, you specify whether the configuration will be used for backups that use an image
copy or for backups that use a backup set.
CONFIGURE CONTROLFILE AUTOBACKUP
CONFIGURE CONTROLFILE AUTOBACKUP backs up

the control file and the current server parameter
file automatically:
After every RMAN BACKUP or COPY command
Whenever a BACKUP or COPY command within a
RUN block is followed by a command that is neither
BACKUP nor COPY
After database structural changes such as adding a
new tablespace
To enable control file autobackups:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
2-29
CONFIGURE CONTROLFILE AUTOBACKUP

RMAN can automatically back up the control file and server parameter file whenever the
database structure metadata in the control file changes and whenever a backup or copy record is
added. The purpose of the control file autobackup is to provide a way to restore the backup
repository contained in the control file when the control file is lost and the recovery catalog is
either lost or was never used. You do not need a recovery catalog or target control file to restore
the control file autobackup. For example, you can issue:
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
If CONFIGURE CONTROLFILE AUTOBACKUP is ON then RMAN automatically backs up

the control file and the current server parameter file in the following circumstances:
After every BACKUP or COPY command issued at the RMAN prompt
Whenever a BACKUP or COPY command within a RUN block is followed by a command
that is neither BACKUP nor COPY
After database structural changes such as dropping a tablespace
Note: When autobackups are ON and the backup includes data file 1, then RMAN does not
automatically include the current control file in the data file backup set. Instead, RMAN writes
the control file and server parameter file to a separate autobackup piece.
CONFIGURE SNAPSHOT CONTROLFILE

and CONFIGURE AUXNAME
For consistency, two commands have been renamed
in Oracle9i:
SET SNAPSHOT CONTROLFILE has been renamed
as CONFIGURE SNAPSHOT CONTROLFILE
'$HOME/snapcf_c82.f';
SET AUXNAME has been renamed as CONFIGURE

AUXNAME
CONFIGURE AUXNAME FOR DATAFILE 2 TO
'$HOME/df2.dbf';
2-30
CONFIGURE SNAPSHOT CONTROLFILE and CONFIGURE AUXNAME

These command name changes are consistent with the rule that CONFIGURE sets persistent
options that last across RMAN sessions and SET controls options for a single RMAN session.
The old syntax is still supported for backward compatibility.
When RMAN needs to resynchronize from a read-consistent version of the control file, it creates
a temporary snapshot control file. RMAN needs a snapshot control file only when
resynchronizing with the recovery catalog or making a backup of the current control file.
The default value for the snapshot control file is platform specific and depends on the Oracle
home directory. For example, the default filename on some UNIX platforms is:
$ORACLE_HOME/dbs/snapcf_@.f.
If you are performing TSPITR or using the DUPLICATE command, then by setting AUXNAME
you can preconfigure the filenames for use on the auxiliary database without manually
specifying the auxiliary filenames during the procedure.
Other Configuration Commands

Some other persistent configuration parameters that
you can modify with the CONFIGURE command:
CONFIGURE <DATAFILE|ARCHIVELOG> BACKUP COPIES
FOR DEVICE TYPE <device_type_spec> TO <n>;
CONFIGURE EXCLUDE FOR TABLESPACE <tablespace>
[CLEAR];
CONFIGURE DEVICE TYPE <device type>
PARALLELISM <n>;
CONFIGURE DEFAULT DEVICE TYPE TO
<device_type_spec>|CLEAR;
2-31
Other Configuration Commands

The CONFIGURE BACKUP COPIES command provides additional database file protection by
allowing the user to specify how many identical copies of each backup are created. The number
of copies for data files, and archive logs can be set independently. For example:
RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT TO 3;
The CONFIGURE EXCLUDE command excludes tablespaces from whole database backups. This
is useful in preventing repeated backups of read-only or offline tablespaces. Note that the system
tablespace may not be excluded.
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE SAMPLE;
By using the CONFIGURE command, the user can adjust the level of parallelism for backup,
restore, and maintenance operations. For tape (SBT), the degree of parallelism should be set to
the number of physical tape drives. Otherwise, degradation will occur. For example:
RMAN> CONFIGURE DEVICE TYPE SBT PARALLELISM 2;
The CONFIGURE DEFAULT DEVICE command specifies which device type is used for
automated backups. Valid values for device_type_spec are DISK or SBT. The default
value is DISK.
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;
Many elements of RMAN scripts are repetitive and are usually identical in every script. It is
possible to enter and store a persistent configuration that describes such repetitive elements such
as the number and type of channels that will be used or the degree of parallelism.
Also, it is no longer necessary to use the RUN{} syntax for most scripts.
Calling Configuration Sets

Create specialized configuration sets by including
CONFIGURE commands in a run block:
run {
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE MAXSETSIZE TO UNLIMITED;
'$HOME/back/snapf_U01.f';
}
2-32
Calling Configuration Sets

Obviously, a fixed set of configuration parameters will not suffice for all backup operations. Use
the CONFIGURE command to make these changes.You can script the CONFIGURE commands
within a run block to change more then one parameter or just change a single parameter at a time
from the RMAN prompt if not using a run block. You can save the configuration to a script and
call it when performing a backup that requires the configuration changes.
The CATALOG Command
Allows user-managed backups to be registered

with RMAN
Works on archived redo logs data file copies,
control file copies, and so on
RMAN> catalog archivelog
2> '/U01/archlog/al_U01_1234.rdo';
2-33
The CATALOG Command

The control file keeps records of all archived logs generated by the target database. If you use a
recovery catalog, then RMAN propagates the archived log information from the control file to
the catalog. If you have to restore a control file backup, and if you change the archiving
destination or format during recovery, then the repository will not have information about
archived logs that are needed for recovery. Therefore, you must catalog these logs if you want to
use them for recovery.
When you make user-managed copies, the repository has no record of them. You must manually
notify RMAN when you make copies with an operating system utility such as the UNIX cp
command. Run the RMAN CATALOG command when:
Adding information about a user-managed data file copy, archived redo log copy, or
control file copy to the recovery catalog and control file
Cataloging a data file copy as a level 0 backup, thus enabling you to perform an
incremental backup later by using the data file copy as the base of an incremental backup
strategy
Recording the existence of user-managed copies of Oracle, release 8.0 and later databases
that were created before RMAN was used
Recording the existence of Oracle7 backups before migrating to Oracle 8.0 or later
Catalog of Consistent
and Inconsistent Copies
For a user-managed copy to be cataloged, it must be:
Accessible on disk
A complete image copy of a single file
Either a data file copy, control file copy, or an
archived redo log copy
2-34
Cataloging Consistent and Inconsistent Copies

Whenever you make a user-managed copy, make sure to catalog it. When making user-managed
copies, you can use the ALTER TABLESPACE ... BEGIN/END BACKUP statement in
conjunction with an OS copy command to make data file copies of an online tablespace.
Although RMAN does not create such data file copies, you can use the CATALOG command to
add them to the recovery catalog so that RMAN is aware of them.
For example, if you store data files on mirrored disk drives, then you can create a user-managed
copy by breaking the mirror. In this scenario, use the CATALOG command to notify RMAN of
the existence of the user-managed copy after breaking the mirror. Before reforming the mirror,
run a CHANGE...UNCATALOG command to notify RMAN that the file copy no longer exists.
Recovery Catalog Compatibility

The rules of RMAN compatibility are as follows:
The recovery catalog schema can be created with
any current Oracle release.
The recovery catalog schema version must be
greater than or equal to the RMAN executable
version.
The versions of the RMAN executable and the
target database should be the same.
2-35
Recovery Catalog Compatibility

The RMAN environment can contain the following components:
RMAN executable
Recovery catalog database
Recovery catalog schema in the recovery catalog database
Target database
Auxiliary database (that is, a duplicate or standby database)
Each component has a release number. For example, you can use a release 9.2.0 RMAN
executable with:
A release 9.2.0 target database
A release 9.2.0 duplicate database
A release 8.1.5 recovery catalog database whose catalog tables were created with RMAN
release 9.2.0
If you use a version of the recovery catalog that is older than that required by the RMAN
executable, then you must upgrade it. For example, you must upgrade the catalog if you use an
Oracle9i version of the RMAN executable with a Oracle8i version of the recovery catalog.
Determine the Schema Version

of the Recovery Catalog
1. Start SQL*Plus and connect to the recovery
catalog database as the catalog owner:
$ sqlplus rman/cat@catdb
2. Query the RCVER table to obtain the schema

version:
SQL> SELECT * FROM RCVER;
VERSION
-----------09.02.00
2-36
Determining the Schema Version of the Recovery Catalog

In the example shown in the slide above, the SELECT operation on the RCVER table retrieves a
single row. However, if the table displays multiple rows, then the highest version in the RCVER
table is the current catalog schema version. The table stores only the major version numbers and
not the patch numbers. For example, assume that the SELECT operation on the RCVER table
displays the following rows:
VERSION
-------08.01.07
09.00.01
09.02.00
These rows indicate that the catalog was created with a release 8.1.7 executable, then upgraded
to release 9.0.1, and finally upgraded to release 9.2.0. The current version of the catalog schema
is 9.2.0.
Upgrading Recovery Catalog

To upgrade the catalog, start RMAN.
An error occurs if the catalog needs to be
upgraded.
$ rman TARGET / CATALOG rman/cat@catdb
PL/SQL package rcat.DBMS_RCVCAT version
08.01.01 in RCVCAT database is too old
Use the UPGRADE CATALOG command to upgrade

the catalog to the required release.
RMAN> UPGRADE CATALOG;
recovery catalog owner is rman
enter UPGRADE CATALOG command again to
confirm catalog upgrade
2-37
Upgrading Recovery Catalog

An error is generated when issuing UPGRADE CATALOG if the recovery catalog is already of a
version greater than that required by the RMAN executable. However, RMAN permits the
UPGRADE CATALOG command to be run if the recovery catalog is current and does not require
upgrading, so that you can re-create packages at any time if necessary. Check the message log
for error messages that are generated during the upgrade. After issuing the UPGRADE CATALOG
command, the user will be prompted to run the UPGRADE CATALOG once again to confirm that
the upgrade was successful:
RMAN> UPGRADE CATALOG;
recovery catalog upgraded to version 09.02.00
DBMS_RCVMAN package upgraded to version 09.02.00
DBMS_RCVCAT package upgraded to version 09.02.00
Dropping the Recovery Catalog
Use RMAN to connect to the target and recovery

catalog databases.
$ rman TARGET / CATALOG rman/cat@catdb
Run DROP CATALOG command twice to confirm:

RMAN> DROP CATALOG;
recovery catalog owner is rman
enter DROP CATALOG command again to confirm
catalog removal
RMAN> DROP CATALOG;
2-38
Dropping the Recovery Catalog

The DROP CATALOG command must be entered twice to confirm that it is what you really want
to do. All backups for all target databases managed by this catalog will become unusable.
Dropping the catalog does not remove the copies from disk or backup sets from the media they
are stored on. Only the catalog tables are removed.
If you do not want to maintain a recovery catalog, then you can drop the recovery catalog
schema from the tablespace. The DROP CATALOG command deletes all information from the
recovery catalog. Therefore, if you have no backups of the recovery catalog schema, then all
backups of all target databases managed by this catalog become unusable.
The DROP CATALOG command is not appropriate for unregistering a single database from a
catalog that has multiple target databases registered. If you try to delete the metadata for one
target database by dropping the catalog, then you delete the metadata for all target databases.
Summary
Explain RMAN configuration decisions
Outline the steps that are involved in creating a
recovery catalog
Create and grant privileges to an RMAN user
Start RMAN and register a database in a recovery
catalog
Demonstrate the use of recovery catalog
maintenance commands such as RESYNC,
CONFIGURE, and CATALOG
2-39
Upgrade and drop a recovery catalog
Practice Overview:
Configuring RMAN
This practice covers the following topics:
Starting RMAN and connecting to a target
database
Creating a recovery catalog
Registering a database
Querying relevant views in the repository
2-40
Backups with RMAN
Objectives
the following:
Identify the types of backups that are supported
by RMAN
Define a file copy backup, and identify its contents
Define a backup set, its types, contents, and
purpose
Identify the difference between an incremental
backup and a cumulative incremental backup
Outline the RMAN backup algorithm
Demonstrate a working knowledge of the BACKUP
command functionality
3-2
RMAN Backups
RMAN allows a whole database backup, or any of

the following subsets, whether the database is
open or closed:
Database, tablespaces, data files and data file
copies, control file, archived logs
RMAN automatically updates changes in database

structure to the recovery catalog before executing
certain commands such as BACKUP
The information updated includes new data files,
resized data files, dropped tablespaces, new
archivelogs
3-3
RMAN Backups
Run backups of any of the following objects with the RMAN BACKUP command when the
database is either mounted or open:
Primary or standby database
Tablespace
Data file (current or image copy)
Archived redo log
Control file (current or image copy)
Server parameter file (currently in use)
Backup set
The BACKUP command backs up database files into one or more backup sets on disk or tape.
You can set parameters for the BACKUP command to specify the filenames for the backup
pieces, the number of files to go in each set, and which channel should operate on each input
file. You can make RMAN backups when the database is open or closed. Closed backups can be
consistent or inconsistent, depending on how the database was shut down. RMAN backups are
further divided into full and incremental backups. Full backups are nonincremental, that is, every
used block is backed up.
Running the BACKUP Command

The BACKUP command can be run:
Interactively:
From a stored script:

RMAN> RUN { EXECUTE SCRIPT backup_whole_db };
From an OS command file:

$ rman TARGET / @backup_db.rman
# From a command line
RMAN> @backup_db.rman # From RMAN prompt
RMAN> RUN { @backup_db.rman }
# From a RUN command
3-4
Running the BACKUP Command

Interactive mode
To run RMAN commands interactively, start RMAN and then enter commands into the
command-line interface.
$ rman TARGET SYS/oracle@prod1 CATALOG rman/cat@catdb
After the RMAN prompt is displayed, you can enter commands such as the following:
RMAN> BACKUP DATABASE;
RMAN> BACKUP SPFILE;
Stored scripts
A stored script is a block of RMAN job commands that is stored in the recovery catalog. To
create a stored script, enter the script interactively into the RMAN command-line interface. You
must be connected to a target database and recovery catalog. An example of stored script
creation and execution is as follows:
RMAN> CREATE SCRIPT backup_whole_db
{
# back up whole database and archived logs
BACKUP
TAG backup_whole
DATABASE PLUS ARCHIVELOG;
}
Running the BACKUP Command (continued)

Stored scripts (continued)
You can execute this stored script from the RMAN prompt as follows:
RMAN> RUN { EXECUTE SCRIPT b_whole_10 };
View your stored scripts by querying the recovery catalog view RC_STORED_SCRIPT:
SQL> SELECT * FROM RC_STORED_SCRIPT;
DB_KEY DB_NAME SCRIPT_NAME
------ ------- ----------------------------1
RMAN
full_backup
1
RMAN
incr_backup_0
1
RMAN
incr_backup_1
1
RMAN
incr_backup_2
1
RMAN
log_backup
Running a command file

You can run an operating system stored command file from a shell prompt, RMAN prompt, or a
RUN block by preceding the command file name by the @ character. If the command file is not
found in your current path, then you must provide the correct relative or absolute path as part of
the command file name. This example creates a command file and then runs it from the
operating system command line:
$ echo "BACKUP DATABASE;" > /u01/backups/cmd_files/backup_db.rman
$ rman TARGET / @/u01/backups/cmd_files/backup_db.rman
The following example runs a command file from the RMAN prompt:
RMAN> @/u01/backups/cmd_files/backup_db.rman
Backup Tags
A tag is a name or identifier given to a backup.

Tags can be up to 30 characters in length and do
not need to be unique.
RMAN> BACKUP DEVICE TYPE DISK DATAFILE 1 TAG
2> "wkly_bkup";
In Oracle9i, release 2, RMAN automatically

provides a name if one is not specified.
Control file autobackups are the exception.
3-6
A tag applies to each backup piece in a given copy

of a backup set.
Backup Tags
A character string called a tag may be assigned to backup sets and image copies. A tag is a caseinsensitive name for a backup set or file copy such as weekly_backup. You can specify the
tag rather than the filename when executing the RESTORE or CHANGE command. The maximum
length of a tag is 30 characters.
RMAN now creates a tag for backups and copies (if you do not specify a tag name) in the format
TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is
the hour (in 24-hour format), MM is the minutes, and SS is the seconds. The date and time refer
to when RMAN started the backup. For example, a backup of data file 1 may receive the tag
TAG20020208T133437. When applied to a backup set, a tag applies to a specific copy of the
backup set. If the backup set is not duplexed, then a one-to-one relationship exists between the
tag and the backup set.
Tags do not need to be unique, so multiple backup sets or image copies can have the same tag
name, for example, wkly_bkup. When a tag is not unique, then with respect to a given data
file, the tag refers to the most current suitable file. By default, RMAN selects the most recent
backups to restore unless qualified by a tag or a SET UNTIL command. The most current
suitable backup containing the specified file may not be the most recent backup, as can occur in
point-in-time recovery.
RMAN-Managed Backups
RMAN-managed backups:
File copy
A file copy is an exact image copy of the original file
that was created by the COPY command.
A file copy can only be written to a disk.
File copies contain only a single input file (data file,
archivelog, or control file).
Backup set
A backup set is a logical object containing backups
of one or more data files or archived logs.
A backup set is created by the BACKUP command.
3-7
RMAN-Managed Backups
File copies
File copies can be performed through RMAN or the host operating system. Operating system
backups on disk can be cataloged in the recovery catalog for immediate use. After the operating
system backups have been cataloged, they can then be backed up by RMAN to a disk or through
the Media Management Layer. The LEVEL 0 option to the CATALOG command allows
operating system backups to be used as a basis for incremental backups. RMAN-initiated file
copies are like OS copies in that all blocks of the file are copied whether they contain data or
not. Because of this, all copies are considered to be LEVEL 0.
run {
allocate channel d1 type disk;
copy level 0 datafile 1 to '/oracle/prod/backup/file1.dbf';
}
Backup sets
A backup set consists of one or more physical output files that are called backup pieces. Backup
sets usually contain multiple source files that are multiplexed in the output. It can be written to a
disk or tertiary storage, which requires media manager support. A restore operation is required to
extract files from a backup set.
Parallelization of File Copies

File copies are parallelized by allocating multiple
channels and copying multiple files in one command.
run {
copy
# first
datafile 1 to '$HOME/prd1.dbf',
datafile 2 to '$HOME/prd2.dbf';
copy
# second
datafile 3 to '$HOME/prd3.dbf';
sql 'alter system archive log current';
}
3-8
Parallelization of File Copies

RMAN executes commands serially. The previous command must finish before the next
command is started. In this example, the first copy command will perform in parallel. The
second copy command is not executed until the command before it is completed. Therefore, you
should always attempt to increase parallelism to speed backups. The example in the slide shows
manual channel allocation to achieve the desired level of parallelization. The channels can be
configured and stored in the persistent configuration along with the default level of
parallelization. These settings will be used whenever a backup is executed unless overridden
manually with a series of allocate channel commands
Note: The greater the degree of parallelism, the higher the machine resource but shorter the
duration.
Backup Sets
There are two types of backup sets:
Data file backup sets
Can include the control files
Can be Incremental or Full backups
Do not include empty blocks
Archivelog backup sets

Contain archived log files only
Datafile
1
Datafile
4
Datafile
1
Datafile
3
Datafile
2
Control
file
Datafile
2
Datafile
4
Backup
set 1
Backup
set 2
Datafile
3
3-9
Control
file
Backup
set 3
Backup Sets
You can back up data files, control files, archived redo logs, and the current server parameter
file. A backup set contains one or more physical files that are called backup pieces. Archived
logs can be backed up also, but they require a separate set. You can also back up another backup
set, as when you want to back up a disk backup to a tape, or an image copy. For example, you
can issue commands such as the following, each of which uses an automatic channel
configuration:
RMAN> BACKUP DATABASE;
RMAN> BACKUP TABLESPACE users, tools;
When backing up data files, the target database must be mounted or open. If the database is in
ARCHIVELOG mode, then the target can be open or closed: you do not need to close the
database cleanly. If the database is in NOARCHIVELOG mode, then you must close it cleanly
before making a backup.
Data file backup sets do not include empty blocks. An empty block is a block that has never
contained data. If a block has been used, but is no longer part of an allocated extent, then it is
still backed up because the backup process does not have access to space management
information. This is a source of some confusion because some users think that RMAN will omit
blocks that do not currently contain data. For example, if a table is dropped, then RMAN will
continue to back up the blocks even though the extents that are used by that table are now free.
Backup Set: Example

Full database backup, five backup sets, two files
per set.
run {
allocate channel t1 type 'SBT_TAPE';
backup
filesperset 2
format 'df_%t_%s_%p'
database;
}
3-10
Data File Backup Set: Example

The syntax in the example above illustrates a full database backup of a database with 10 files,
including the control file, to two tape drives. The number of files per backup set has been
restricted to two, which means that five sets will be created, each with two files multiplexed. If
two channels are allocated, then two sets can be created in parallel. RMAN will automatically
perform the partitioning of files to channels, multiplex the files, and skip any unused blocks. The
format string determines the output file name that is passed to sbtopen. Some common format
identifiers include:
%D specifies the current day of the month from the Gregorian calendar in format DD.
%F combines the database ID (DBID), day, month, year, and sequence into a unique and
repeatable generated name.
%p specifies the piece number within the backup set. This value starts at 1 for each backup
set and is incremented by 1 as each backup piece is created.
%t specifies the backup set time stamp, which is a 4-byte value derived as the number of
seconds that have elapsed since a fixed reference time.
This is a partial list of format identifiers. For more information about format identifiers, refer to
Oracle9i Recovery Manager Reference.
Archivelog Backup Sets
Archivelog backup sets only include archivelogs.

Archivelog backup sets are always full backups
unless backup optimization is enabled.
RMAN has access to control file information so it
knows what logs have been archived.
Archivelog backups are automatically distributed
across the allocated channels.
RMAN>
RMAN>
RMAN>
2>
3-11

backup format 'al_%t_%s' archivelog all
delete input;
Archivelog Backup Sets

Because RMAN has access to control file information, it knows what logs have been archived.
This prevents users from not knowing whether an archive log has been completely copied out to
the archive log destination before attempting to back it up. As with data file backup sets,
archivelog backups are automatically distributed across the channels that are specified before the
backup command.
Multiplexed Backup Sets

Multiplex two or more datafiles into a backup set for
tape streaming.
filesperset = 3
Backup set
Datafile
1
Datafile
2
Datafile
3
3-12
Server
process
(channel)
Datafile
1,2,3,1,2,3
MML
Tape
RMAN-Multiplexed Backup Sets

The technique of RMAN multiplexing is to simultaneously read files on disks and then write
them into the same backup piece. When more than one file is written to the same backup file or
piece, RMAN automatically performs the allocation of files to channels, multiplexes the files,
and skips any unused blocks. With a sufficient number of files to back up concurrently, highperformance sequential output devices (for example, fast tape drives) can be streamed. This is
important for backups that must compete with other online system resources. It is the
responsibility of the operator or storage subsystem to change the tape on the target database
where the tape drive is located. This process was designed for writing to a tape but it can also be
used to write to a disk.
Multiplexing is controlled by the following RMAN command modifiers:
The FILESPERSET parameter on the BACKUP command
The MAXOPENFILES parameter of the ALLOCATE CHANNEL and CONFIGURE
CHANNEL commands
Example
The database contains three datafiles that will be multiplexed together into one physical file (set)
and stored on tape. The datafiles are multiplexed by writing n number of blocks from datafile 1,
then datafile 2, then datafile 3, then datafile 1, and so on until all files are backed up.
Parallelization of Backup Sets

Backup sets are parallelized by allocating multiple
channels or by using the CONFIGURE command for
automatic channel allocation.
Backup Set 1
Datafile
1
Datafile
4
Datafile
5
Backup Set 2
Datafile
2
Datafile
3
Datafile
9
Backup Set 3
Datafile
6
3-13
Datafile
7
Datafile
8
Server
process
(channel)
MML
Set 1
Server
process
(channel)
MML
Set 2
Server
process
(channel)
MML
Set 3
Parallelization of Backup Sets

When you create multiple backup sets and allocate multiple channels, RMAN automatically
parallelizes its operation and writes multiple backup sets in parallel. The allocated server
sessions share the work of backing up the specified datafiles, control files, and archived redo
logs. Note that you cannot stripe a single backup set across multiple channels. Parallelization of
backup sets is achieved by:
Configuring PARALLELISM to greater than 1 or allocating multiple channels
Specifying many files to back up
Each channel gets enough data files to make each backup set roughly the same size.
Parallelization can be accomplished manually, or automatically by using the PARALLELISM
clause.
run {
allocate channel t1 type 'sbt_tape';
allocate channel t2 type 'sbt_tape';
backup
...}
The CONFIGURE DEVICE TYPE ... PARALLELISM command specifies the number of
channels that RMAN uses when allocating automatic channels for a specified device type.
Parallelization of Backup Sets (continued)

For example, if you configure parallelism to 3, then RMAN allocates three channels of the
default device type whenever it uses automatic channels.
When parallelizing backups, RMAN always allocates channels in numerical order beginning
with 1 and ending with the parallelism setting. For example, if the device type is sbt and
parallelization is set to 3, then RMAN allocates as follows:
ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3
You can change a parallelism setting by issuing another CONFIGURE DEVICE TYPE...
PARALLELISM command.
Creating a Backup Set with Enterprise

Manager
3-15
Creating a Backup Set by Using Enterprise Manager

You can use the Backup Wizard to create a backup set. By using the Create Backup
Configuration property sheets, you can edit an existing backup configuration or create other
backup configurations. A backup configuration is automatically created for each target database
by Enterprise Manager. In the backup configuration, you can specify the following options:
Create a configuration that backs up to a disk by using a backup set.
Create a configuration that backs up to a tape by using a backup set.
Create a configuration that uses an image copy.
Set the limits for any backup or copy operation.
Specify to have media management software take over the backup and recovery of your
files instead of using RMAN.
Set storage parameters for the current backup set, overriding the RMAN default settings
that the RMAN has calculated for datafiles or archivelogs.
Register the database with the recovery catalog. A recovery catalog is created if you
specify for the Enterprise Manager repository to be located in a local database.
Backup Pieces
A backup piece is a file in a backup set.

A backup piece can contain blocks from more
than one datafile.
A backup piece consists of one or more physical
output files that are contained within a backup set.
Backup set 1 (Logical)
Piece 1 (file) Piece 2 (file)
Datafile
1
Datafile
4
Datafile
5
Backup set 2 (Logical)

Piece 1 (file)
Datafile
2
3-16
Datafile
3
Datafile
9
Piece 1
Channel
MML
Piece 2
Set 1
Channel
MML
Set 2
Backup Pieces
Each backup set contains at least one backup piece. If you do not restrict the backup piece size,
then every backup set contains only one backup piece. To restrict the size of each backup piece,
specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL
commands. This option limits backup piece size to the specified number of bytes.
RMAN> ALLOCATE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G;
You can either let RMAN determine a unique name for backup pieces or use the FORMAT
parameter to specify a name. If you do not specify a filename, then RMAN uses the %U
substitution variable to generate a unique name.
RMAN automatically generates unique names for the backup pieces. The FORMAT parameter
provides substitution variables that you can use to generate unique filenames. For example, you
can run a command as follows:
RMAN> BACKUP TABLESPACE user FORMAT = '/tmp/user_%u%p%c';
Format can be specified in three places, and will be used in the following precedence:
1. BACKUP OBJECT
2. BACKUP COMMAND
3. ALLOCATE/CONFIGURE CHANNEL
Backup Piece Contents
Each piece in a set has a piece header that is

located in the first block.
The first block in the piece header includes:
3-17
Database ID
Piece number
Set stamp, set count
Type of backup
How many directory blocks follow the piece header
Backup Piece Contents

The directory contains metadata about each file in the backup set. A directory entry contains
different information, depending on whether it is a data file or archivelog backup set. All blocks
in the backup set, including the directory, have a logical block size equal to the block size of the
files that are being backed up. Data file directory entries include:
Absolute and relative file number for the file
Creation SCN
Resetlogs SCN
Checkpoint SCN
Incremental-start SCN
Archivelog directory entries include:
Thread
Sequence
Low SCN
Next SCN
Resetlogs SCN
Following the header and directory are the blocks for the files that are being backed up. For each
file, block 2 is the first block in the backup, and the header is the last block.
Incremental Data File Backup
Incremental data file backups are by default

noncumulative.
Incremental data file backups are available only
with Oracle9i Enterprise Edition.
An incremental backup at level N backs up all
blocks that have been modified since the previous
incremental at a level less than or equal to N.
Changed
blocks
All nonempty
blocks
Level 0
Day
Sun
3-18
2
Mon
2
Tue
1
Wed
2
Thu
2
Fri
2
Sat
0
Sun
Incremental Data File Backup

An incremental data file backup is a backup of a data file that only copies out data blocks that
have been modified since a previous incremental backup.
An incremental backup at level N, where N is greater than zero, backs up all blocks that have
been modified since the previous incremental backup at all levels that are less than or equal to N.
Incremental backups are initially based on a level 0 backup set, or a level 0 file copy.
Incremental backups write out fewer blocks than full (or level 0) backups, and therefore can be
faster.
Cumulative Incremental Backups
A cumulative incremental backup at level N backs

up all blocks that have been modified since the
previous incremental at a level less than N.
Cumulative incremental backups are provided for
recovery speed.
Changed
blocks
All nonempty
blocks
Level 0
Day
Sun
3-19
2
Mon
2C
Tue
1
Wed
2
Thu
2C
Fri
2C
Sat
0
Sun
Cumulative Incremental Backups

Cumulative incremental backups duplicate work performed by other incremental backups at the
same level. This means that the cumulative backup may take longer and will be larger than if it
were not cumulative. Because cumulative incrementals back up blocks previously backed up at
the same level, they may take longer and will write more blocks than noncumulative backups.
Fewer backups at each level must be applied when recovering. Basically, a cumulative
incremental backup supersedes incremental backups at the same level as itself. If you take a
level 2, then a cumulative level 2, the second level 2 backs up all the blocks modified, including
those backed up by the first level 2. This means that only one incremental backup of any level is
needed to completely recover.
SCN and Incremental Backups
There are two important SCNs:

CHECKPOINT_CHANGE#
INCREMENTAL_CHANGE#
Incremental level equal to 0

Backs up all blocks with data
Incremental level greater than 0

Backs up all blocks with SCNs greater than or
equal to the INCREMENTAL_CHANGE#
3-20
SCN and Incremental Backups

CHECKPOINT_CHANGE#
It is the data files checkpoint SCN at the time the backup began. This is the checkpoint that the
file will have after this incremental is applied.
INCREMENTAL_CHANGE#
The INCREMENTAL_CHANGE# is also known as the incremental-start SCN.
Incremental level greater than 0
All blocks with SCNs greater than or equal to the INCREMENTAL_CHANGE# are backed up
when the incremental level is greater than 0. That is, all blocks that were modified since the first
file was checkpointed and blocks that are at the same checkpoint as the file (because they may
have been modified more than once at the same SCN in between being written out).
It is better to do a level 0 if there are many updates to different blocks. It is better to do an
incremental greater than 0 if there are many updates to fewer blocks.
Basic Backup Algorithm

In determining the characteristics of the backup sets,
the basic algorithm is influenced by the following:
The number of backupSpec clauses that you
specify
The number of channels that you allocate
The FILESPERSET parameter that limits the
number of files for a backup set
The MAXSETSIZE parameter (specified on the
CONFIGURE and BACKUP commands) that specifies
a maximum backup set size
3-21
Basic Backup Algorithm

The total number and size of backup sets depends on which algorithm RMAN uses: the basic
algorithm or the advanced algorithm. Each backupSpec clause produces at least one backup
set.
RMAN uses the basic algorithm when any of the following conditions are true:
You are backing up files other than data files or control files.
The operating system does not provide data about which files are located on which disks,
or which nodes in a cluster have affinity with which disks.
You manually set the DISKRATIO parameter of the BACKUP command to 0.
If all of these conditions are false, then RMAN uses the advanced algorithm. You can always
force RMAN to use the basic algorithm by setting DISKRATIO=0.
Algorithm Rules
The most important rules in the algorithm for creating
a backup set are:
Each allocated channel that performs work in the
backup job generates at least one backup set
containing at least one piece.
RMAN will calculate FILESPERSET parameter of
the BACKUP command if it is not set.
3-22
RMAN detects the drives that a data file is located

on, and tries to make each backup set read from
the same number of disk drives.
Algorithm Rules
The basic backup algorithm follows several important tenets when creating backup sets. Each
allocated channel that performs work in the backup jobthat is, each channel that is not idle
generates at least one backup set. By default, this backup set contains one backup piece. RMAN
always tries to divide the backup load so that all allocated channels have roughly the same
amount of work to do.
The basic algorithm determines the number and size of the backup pieces by balancing the
FILESPERSET and MAXSETSIZE (if used) parameters of the BACKUP command. The
FILESPERSET parameter of the BACKUP command determines the maximum number of data
files in each backup set. If none is specified, RMAN will calculate this figure by comparing the
value 64 to the rounded-up ratio of number of files divided by the number of channels, and sets
FILESPERSET to the lower value. For example, if you are backing up 140 files and allocating
two channels, RMAN divides 140 by two, compares the resultant 70 to 64 and chooses 64 as the
value for FILESPERSET.
The maximum size of a backup set is determined by the MAXSETSIZE parameter of the
CONFIGURE or BACKUP command. When you set this, RMAN uses the algorithm to determine
the number of files to write to each set.
Algorithm Rules (continued)

When both parameters are being used, the number of backup sets is the greater of the following
ratios:
Total number of blocks divided by MAXSETSIZE
Total number of data files divided by FILESPERSET
RMAN will enforce both the FILESPERSET and MAXSETSIZE limits. If necessary, then
RMAN creates more backup sets than are calculated in the preceding comparison. RMAN uses
the algorithm of best fit so that the majority of backup sets have a size as close to the
MAXSETSIZE limit with the number of files as close to the FILESPERSET limit as possible.
Advanced Algorithm
3-24
The advanced algorithm considers DISKRATIO in

addition to FILESPERSET and MAXSETSIZE.
If DISKRATIO is not set, then it defaults to the
same value of FILESPERSET.
If DISKRATIO or FILESPERSET is not set, then the
value of DISKRATIO defaults to 4.
Advanced Algorithm
The advanced algorithm uses the same factors as the basic algorithm to determine the number
and size of backup sets. The difference is that the advanced algorithm is also influenced by the
DISKRATIO parameter. If DISKRATIO = n, then each backup set must read data from at
least n disk drives. RMAN uses file location information obtained from the database server to
determine which data files are present on which disk drives.
If you set FILESPERSET but not DISKRATIO, then DISKRATIO defaults to the same value
as FILESPERSET. If you specify neither parameter, then DISKRATIO defaults to 4. RMAN
compares DISKRATIO to the number of devices and uses the lowest value.
Assume that a database contains 50 data files spread across six disks, and the operating system is
able to deliver this disk contention information to the server. You configure a single sbt
channel and then run BACKUP DATABASE.
RMAN uses the advanced algorithm for the reason that the basic algorithm indicates that
because you did not specify FILESPERSET or MAXSETSIZE, RMAN should produce a single
backup set. The advanced algorithm also looks at DISKRATIO, which in this case defaults to 4.
Therefore, each backup set must contain data files from at least four disks. Because RMAN is
only producing one backup set containing all data files from all six disks, DISKRATIO makes
no difference.
Algorithm Behavior for Standard

Backup Sets
3-25
Allocates memory structures and I/O buffers for

each file in the set
Orders the files to be backed up in a channel in
the descending order of their sizes
Checkpoints files in the set at the same SCN
Reads, validates, and saves each files header
block
Multiplexes the files together
Algorithm Behavior for Standard Backup Sets

The algorithm allocates memory structures and I/O buffers for each file in the set. Input buffers
and output buffers do not necessarily need to be in sync. Many input buffers may be processed
before an output buffer is filled. This may be the case for incremental backups with a level
greater than 0. The files to be backed up are inspected and arranged in the channel based on their
sizes in the descending order.
At this time all the files in the backup set are checkpointed at the same SCN and the file header
blocks are validated.
Algorithm Behavior for Standard

Backup Sets
For each buffer, it is decided whether to include

blocks.
If incremental, then check SCN in the block to see if
it qualifies for inclusion
If full or level 0, then check to see whether the block
has ever contained data
3-26
Check for physical and logical corruption and

calculate checksum.
Replace the file number in RDBA with a backup
set relative file number.
Algorithm Behavior for Standard Backup Sets (continued)

While processing the buffer contents, decisions are made as to the inclusion of the blocks. If an
incremental backup is being performed, then the block SCN is queried. If a full backup is
performed, then the block is checked to see if it is empty. If a file contains many empty blocks,
for each total_number_of_input_blocks (four times the number of blocks per buffer) in the
buffer, then only one empty block is actually copied out. This specifically addresses the restore
performance.
During this process, the blocks are checked for physical and logical corruption. It is possible for
the user to allow a certain number of corrupt blocks per file.
The file number in the data block address (DBA) is replaced with a unique number, which is the
absolute file number within the set. This number is stored in the files directory entry. When
restoring files from backup sets, the file header is written last to ensure that the file has not been
truncated before the restore process is completed.
When the output buffer is filled, it is sent to the output device. When the input buffer is empty, a
read ahead operation is performed. Finally, the file header is written into the backup set and the
control file is updated.
Algorithm Behavior for Archivelog

Backup Sets
3-27
Archived logs are included in a backup set

ordered by descending size.
Process is similar to the data file backup
algorithm.
Sequence number is converted to a backup-set
relative file number.
No blocks are skipped.
Corruptions that are detected cause the backup to
be terminated.
When the backup is complete, the control file is
updated.
Algorithm Behavior for Archivelog Backup Sets

When RMAN is creating archivelog backup sets, all blocks are copied out. There is no provision
to skip empty blocks. All blocks are multiplexed, similar to data file backups. The input and
output buffers are in sync, because all blocks are included. Any corruptions that are encountered
during an archivelog backup will cause the backup to be terminated.
Algorithm Behavior for File Copies
3-28
A single server process operates on one file at a

time.
No blocks are skipped.
RMAN checks for physical and logical corruption
and calculates checksum.
The file header is written last.
The control file is updated when the copy is
complete.
Algorithm Behavior for File Copies

When RMAN performs a file copy, no data movement takes place; the buffers are shared. A
single server process works on one file at a time. As with the archivelog backup sets, no blocks
are skipped.
Backup Optimization
The BACKUP command will skip a file if an identical

copy already exists.
This process is enabled by running the
CONFIGURE BACKUP OPTIMIZATION ON
command.
CONFIGURE BACKUP OPTIMIZATION {ON|OFF|CLEAR}
The default behavior is OFF.
Only one channel type may be allocated in a

backup operation.
Channels of type DISK and SBT may not be mixed.
3-29
Backup Optimization
If you enable backup optimization, then the BACKUP command skips the backup of a file when
the identical file has already been backed up to the allocated device type. If RMAN determines
that a file is identical and it has already been backed up, then it is a candidate for skipping.
However, RMAN must do further checking to determine whether to skip the file, because both
the retention policy feature and the backup duplexing feature influence the algorithm that
determines whether RMAN has enough backups on the specified device type.
With backup optimization, the BACKUP command skips the backup of a file if the identical file
has already been backed up to the allocated device type. To override this behavior and back up
all files whether they have changed or not, specify the FORCE option of the BACKUP command.
To enable or disable backup optimization, specify ON or OFF with the CONFIGURE BACKUP
OPTIMIZATION command.
Backup Optimization Algorithm

Algorithm criteria that is used to determine identical
files:
Data file
Same DBID, checkpoint SCN, RESETLOGS SCN and
time
Data file must be offline-normal, read-only, or
closed normally
Archived redo log

Same thread, sequence number, and RESETLOGS
SCN and time
Backup set
Same backup set record ID and stamp
3-30
Backup Optimization Algorithm

Data file backups
If you have a retention policy, then RMAN skips a data file backup only if the latest backup of a
file is earlier than the earliest point in the recovery window. If you did not configure a recovery
window, then RMAN sets n = 1 and searches for values of n in this order of precedence:
1. If CONFIGURE RETENTION POLICY TO REDUNDANCY r is enabled, then RMAN only
skips data files when n = r + 1 backups exist.
2. BACKUP ... COPIES n
3. SET BACKUP COPIES n
4. CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n
RMAN skips backup only if at least n backups of an identical file exist on the specified device.
If RMAN does not skip the backup, then it makes the backup exactly as specified.
Archived log
By default, n = 1. RMAN searches for values of n in this order of precedence (that is, values
higher on the list override values lower on the list):
2. SET BACKUP COPIES n.
Backup Optimization Algorithm (continued)

Archived log (continued)
3. CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ... TO n
RMAN skips a backup only if at least n backups of an identical file exist on the specified device.
Backup set
By default, n = 1. RMAN searches for other values of n in this order of precedence (that is,
values higher on the list override values lower on the list):
2. SET BACKUP COPIES n
RMAN skips a backup only if at least n backups of an identical file exist on the specified device.
Example
To see how these rules work in practice, consider the following scenario:
Assume that at 9 a.m. you back up three copies of all existing archived logs to tape:
RMAN> BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;
Later, you enable the following configuration setting:

RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4;
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
Then, you run the following archived log backup at noon:

RMAN> BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
In this case, the BACKUP...COPIES setting overrides the CONFIGURE...COPIES setting,

so RMAN sets n = 2. RMAN skips the backup of a log only if at least two copies of the log exist
on the sbt device. Because three copies of each log exist on sbt of all the logs that were
generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two
copies of all logs that were generated after 9 a.m. because these logs have not yet been backed
up to tape.
At this point, three copies of the logs that were created before 9 a.m. exist on tape, and two
copies of the logs that were created after 9 a.m. exist on tape. Assume that you run the following
backup command at 3 p.m.:
RMAN> RUN
{
SET BACKUP COPIES 3;
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
}
In this case, RMAN sets n = 3 and so will not back up the logs that were created before 9 a.m.
because three copies already exist on tape. However, only two copies of the logs that were
created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Therefore,
RMAN backs up three copies of the logs that were created after 9 a.m.
Duplexed Backups
Duplexed backups can create up to four identical

copies of each backup piece.
Duplexed backups require setting the parameter
BACKUP_TAPE_IO_SLAVES = TRUE.
Backup duplexing works with any media manager.
Datafile
1
Datafile
2
Datafile
1
Datafile
1
Datafile
2
Datafile
2
BACKUP1
BACKUP2
Backup set
3-32
Duplexed Backups
Multiple or duplexed backup copies can be made by using the SET BACKUP COPIES command
when running your backup. Use the SET BACKUP COPIES command before allocating any
channels. The SET BACKUP COPIES command affects all channels that were allocated after
issuing the command. Duplexed backups require a FORMAT specification that guarantees
uniqueness.
%c - copy number (1-4)
%U - new default format; equivalent to %u_%p_%c

Backup duplexing can be used with the DELETE INPUT option to make sure that more than one
backup of an archived log exists before the log is deleted from the disk.
Duplexed Backups
Backup duplexing provides an efficient way to
produce multiple copies of each backup piece.
Duplexing requires the COPIES option:
RMAN> BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE
2> 7 FORMAT '/tmp/%U','?/oradata/%U','?/%U';
3-33
Duplexed backups require setting the parameter

BACKUP_TAPE_IO_SLAVES = TRUE
Duplexed Backups (continued)

RMAN provides an efficient way to produce multiple copies of each backup piece in a backup
set. This functionality is also known as duplexing a backup set. You can create up to four
identical copies of each piece in a backup set. If multiple commands are in effect
simultaneously, then commands that are higher on the list override commands that are lower on
the list. Duplexing under Oracle9i is done by using the COPIES option whereas Oracle8i
requires the use of the SET DUPLEX command. Duplexing can be used with the DELETE
INPUT option to make sure that more than one backup of an archived log exists before the log is
deleted from the disk. Duplexed backups require a FORMAT specification that guarantees
uniqueness.
%c - copy number (1-4)
%U This is the default format; and is equivalent to %u_%p_%c

In the example provided in the slide above, observe that RMAN places the first copy of each
backup piece in /tmp, the second in ?/oradata, and the third in the Oracle home. Note that
RMAN does not produce three backup sets, each with a different unique backup set key. Rather,
RMAN produces one backup set with a unique key, and generates three identical copies of each
backup piece in the set, as shown in the sample LIST output shown in the following page.
Duplexed Backups (continued)

RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size
------ ---- -- ---------1 Full 64K
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ---7 Full 98410 08-MAR-02 /oracle/oradata/trgt/tools01.dbf
Backup Set Copy #1 of backup set 1
Device Type Elapsed Time Completion Time Tag
----------- ------------ --------------- --DISK 00:00:01 08-MAR-02 TAG20020208T152314
List of Backup Pieces for backup set 1 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ---------1 1 AVAILABLE /tmp/01dg9tb2_1_1
----------- ------------ --------------- --DISK 00:00:01 08-MAR-02 TAG20020208T152314
------- --- ----------- ---------2 1 AVAILABLE /oracle/oradata/01dg9tb2_1_2
----------- ------------ --------------- --DISK 00:00:01 08-MAR-02 TAG20020208T152314
------- --- ----------- ---------3 1 AVAILABLE /oracle/01dg9tb2_1_3
Mirrored Backups
Mirrored backups are created by using the SET

BACKUP COPIES command.
Mirrored backups can be customized by:

Allowing a default duplex value
Supporting a multivalued option for duplexed
backups that are stored on a disk
RUN {
SET BACKUP COPIES 3;
BACKUP DATABASE
FORMAT '/u01/backups/%U',
FORMAT '/u02/backups/%U',
FORMAT '/u03/backups/%U';
}
3-35
Mirrored Backups
When making mirrored backups it is possible to specify up to four different locations with the
format option. The second, third, and fourth values are used in conjunction with the SET
BACKUP COPIES command. RMAN will use the first format value for copy 1, the second
format value for copy 2, and so on. If more format values are specified than copies, then the
extra format values will be discarded. If there are more copies specified than format values, then
the format values will be reused starting with the first value. The following example illustrates
this concept:
RMAN> SET BACKUP COPIES 3;
RMAN> BACKUP DATABASE FORMAT '/U01/backups/%U','/U02/backups/%U';
As a result, the first copy is placed in /u01/backups, the second copy is placed in
/u02/backups, and the third copy is placed in /u01/backups.
Proxy Copy
3-36
A proxy copy shifts the backup and restore

overhead away from the Oracle server.
Proxy copies require support from the media
manager because it will take over the entire
backup job.
Files must be placed in backup mode, because an
external utility is reading data files during backup.
Query the V$PROXY_DATAFILE view to look at
proxy copy information.
If a crash leaves some files in the backup mode,
then they will automatically be taken out of the
backup mode.
Proxy Copy
A proxy copy is a special type of backup in which RMAN turns over control of the data transfer
to a media manager that supports this feature. The PROXY option of the BACKUP command
specifies that a backup should be a proxy copy. For each file that you attempt to back up by
using the BACKUP PROXY command, RMAN queries the media manager to determine whether
it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN uses
conventional backup sets to perform the backup. An exception occurs when you use the PROXY
ONLY option, which causes the Oracle server to issue an error message when it cannot proxy
copy.
The Oracle server records each proxy-copied file in the control file. RMAN uses this data to
resynchronize the recovery catalog. Use the V$PROXY_DATAFILE view to obtain the proxy
copy information. Use the CHANGE PROXY command or DELETE PROXY command to change
the status of or delete a proxy backup respectively.
You can monitor the progress of proxy copies, backups, regular copies, and restores by querying
the view V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOPS:
detail and aggregate rows. Detail rows describe the files that are being processed by one job step,
whereas aggregate rows describe the files that are processed by all job steps in an RMAN
command.
Backup Set Backup
This feature allows RMAN to change the location

of a backup set.
The source location for this command must be
disk, however, the destination can be DISK or SBT.
BACKUP... BACKUPSET <key|CompletedTimeSpec|ALL>
RMAN> BACKUP backupSET CREATED BEFORE 'sysdate 1'

2> DELETE INPUT;
3-37
Backing Up Backup Sets

You can back up backup sets from disk to tape or from disk to disk. If RMAN discovers a
corrupt block or missing backup piece during the backup, then RMAN automatically performs
failover to an existing intact copy. The BACKUP BACKUPSET command uses the default disk
channel to copy backup sets from disk to disk. To back up from disk to tape, you must either
manually allocate a channel of DEVICE TYPE SBT or configure an automatic sbt channel.
The BACKUP BACKUPSET command is a useful way to spread backups among multiple media.
For example, you can execute the following BACKUP command weekly as part of the production
backup schedule:
RMAN> BACKUP DEVICE TYPE SBT BACKUPSET ALL;
Now your backups exist on both disk and tape. You can also duplex backups of backup sets
(except for control file autobackups), as in this example:
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
Note: If backup optimization is enabled when you issue the command to back up a backup set
and the identical backup set has already been backed up to the same device type, then RMAN
skips the backup of that backup set.
Archived Log Backups
Data files and archived logs can be backed up

with one command by using PLUS ARCHIVELOG.
RMAN> BACKUP DATAFILE 4 PLUS ARCHIVELOG;
3-38
When backing up to tape, PLUS ARCHIVELOG is the

default behavior.
RMAN will not raise an error if there are no archive
logs to back up.
The BACKUP_COUNT column in V$ARCHIVED_LOG
shows the number of times an archived log was
backed up.
Backing Up Archived Logs

It is now possible to backup data files and archived logs with a single RMAN backup command.
This feature works as follows:
The ALTER SYSTEM ARCHIVE LOG CURRENT command is run.
The BACKUP ARCHIVELOG ALL command is run. If backup optimization is enabled, logs
that are already backed up will be skipped.
Data files specified in the BACKUP command are backed up.
The ALTER SYSTEM ARCHIVE LOG CURRENT command is run again.
Archived logs generated during the backup are also backed up.
If there are no archived logs to back up, then RMAN will not raise an error. This condition is
possible if no archived logs have been generated since the last BACKUP ARCHIVELOG ALL
DELETE INPUT command was issued. Query V$ARCHIVED_LOG and inspect the
BACKUP_COUNT column to see the number of times an archived log was backed up.
Backing up archived logs that need backups
You can use NOT BACKED UP n TIMES clause of the BACKUP ARCHIVELOG command to
back up only those logs that have not been backed up at least n times. This option is a convenient
method to back up archived logs on specified media (for example, you want to keep at least three
copies of each log on tape). This behavior is new to Oracle9i, release 2.
Archived Log Backup Methods

By time, name, archived logs, log sequence, or SCN:
RMAN> backup archivelog
2> from time '01-jan-00' until time '30-jun-00';
2> like 'oracle/arc/dest/log%';
RMAN> backup archivelog all;
2> from logseq 20 until logseq 50 thread 1;
RMAN> backup archivelog from scn 1 until scn 9999;
3-39
Archived Log Backup Methods

Archived logs can be backed up by many methods. These include specifying archivelog by time,
by log sequence and by SCN. The DELETE INPUT option can be used to delete logs from disk
after they have been successfully backed up. For example:
RMAN> backup format 'al_%t_%s_%p' archivelog all delete input;
Please note that only the archivelog backed up is deleted. This is an important issue when using
multiple archivelog destinations.
Long-Term Backups
You can archive backups much longer than the

restrictions that are enforced by the retention
policy.
Enabled with the KEEP option to the BACKUP
command:
BACKUP
[ NOKEEP|
KEEP [UNTIL TIME '...'|FOREVER]
[LOGS|NOLOGS]
]
3-40
Long-Term Backups
The KEEP option can be used with the CHANGE, COPY, or BACKUP commands to allow the
backups to be kept until the time specified by the UNTIL TIME option regardless of the
retention policy.
If the backup should never expire, then use the FOREVER option, but keep in mind that a
recovery catalog is required when this option is used. The use of the LOGS option ensures that
the backup can be recovered to any point in time as the required archive logs will be kept in
support. This is the default behavior. If NOLOGS is specified, then the supporting archive logs
will not be kept. This means that this backup cannot be used in database recovery. The backup
will be limited to restore the database only to the point in time that the backup was performed.
NOKEEP specifies that the backup will not be kept beyond the window that is defined by the
retention policy; this is the default.
Some examples:
RMAN> BACKUP DATABASE KEEP UNTIL TIME
2> "to_date('31-MAR-2002','DD_MM_YYYY)" nologs;
RMAN> BACKUP TABLESPACE SAMPLE KEEP FOREVER NOLOGS;
Performing Test Backups by Using RMAN
The BACKUP...VALIDATE command can be used

to perform test backups.
RMAN> BACKUP VALIDATE DATABASE;
3-41
Check the data files for physical and logical

corruption.
Confirm that all database files exist and are in the
correct locations.
Performing Test Backups by Using RMAN

RMAN does not actually produce backup sets, but scans the specified files to determine whether
they can be backed up. In this sense, the BACKUP VALIDATE command is similar to the
RESTORE VALIDATE command, except for backups rather than restore jobs.
For example, you can validate that all database files and archived redo logs can be backed up by
issuing a command as follows:
RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
If the backup validation discovers corrupt blocks, then RMAN updates the
V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. After a
corrupt block is repaired, the row identifying this block is deleted from the view.
Another important use of BACKUPVALIDATE is to identify corrupt blocks and populate the
V$DATABASE_BLOCK_CORRUPTION view, then use the data to repair the blocks with the
BLOCKRECOVER command like this:
RMAN> BACKUP VALIDATE DATABASE;
RMAN> BLOCKRECOVER CORRUPTION LIST;
Note: You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option or
validate backups of backup sets.
Performing Test Backups by Using RMAN (continued)

RMAN displays the same output that it would if it were really backing up the files. If RMAN
cannot validate the backup of one or more of the files, then it displays an error message. For
example, RMAN may show output that is similar to the following:
RMAN-00571: =====================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: ======================================================
RMAN-03002: failure of backup command at 03/15/2002 14:33:47
ORA-19625: error identifying file /u01/usr02/arch/archive1_5.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Restarting a Backup
RMAN can restart partially completed backups.

The SINCE TIME parameter can be used to
specify a date after which a new backup is
required.
RMAN> BACKUP DATABASE NOT BACKED UP SINCE
2> TIME '03-MAR-02 09:00:00';
3-43
The unit of restartability is the backup set.

RMAN will compare the SINCE TIME date with the
completion time of the last backup of the file.
Restarting a Backup
Using the restartable backup feature, RMAN can back up only those files that have not been
backed up since a specified date. This feature is intended for cases when a backup fails midway
through and you only want to back up the part of the database that was not backed up. Use the
SINCE TIME parameter of the BACKUP command to specify a date after which a new backup is
required. If you do not specify the SINCE parameter, then RMAN only backs up files that have
never been backed up.
To back up only the files that were not backed up after a specified date, specify a valid date in
the SINCE TIME parameter. For example, this command uses the default configured channel to
back up all database files and archived redo logs that have not been backed up in the last two
weeks:
RMAN> BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-14'
2> DATABASE PLUS ARCHIVELOG;
The unit of restartability is a single backup set. If the entire database is backed up into one
backup set, and if a backup fails, then the entire backup has to be rerun. If the backup generates
multiple backup sets, then the backups that completed successfully do not have to be rerun. For
this reason, you can set FILESPERSET to a value much lower than the default so that RMAN
limits the number of files that it places in each backup set.
Default Autolocation for RAC Clusters

RMAN can autolocate the following files in an RAC
environment:
Backup pieces during backup or restore
Archived redo logs during backup
Data file or control file copies during backup or
restore
3-44
Default Autolocation for RAC Clusters

In Oracle9i, release 2, RMAN automatically discovers which nodes of a RAC configuration can
access the files that you want to back up or restore. RMAN can autolocate the following files:
Backup pieces during backup or restore
Archived redo logs during backup
Data file or control file copies during backup or restore
RMAN detects the RAC environment whenever the allocated channels have different PARMS or
CONNECT strings. RMAN will then automatically enable the autolocation feature. Before
Oracle9i, release 2, you had to enable this option manually with SET AUTOLOCATE and the
option applied only to backup pieces.
Summary
Identify the types of backups that are supported
by RMAN
Define a file copy backup, and identify its contents
Define a backup set, its types, contents, and
purpose
Identify the difference between an incremental
backup and a cumulative incremental backup
Outline the RMAN backup algorithm
Demonstrate a working knowledge of the BACKUP
command functionality
3-45
Practice Overview:
Backups with RMAN
Creating a cold backup
Using the CATALOG command
3-46
Creating RMAN backups
Restore and Recovery with RMAN
Objectives
the following:
Identify the tasks that are performed by RMAN
before restoring
Identify the RESTORE functionality
4-2
Explain the restore algorithm that is used by

RMAN
Identify the four distinct phases of recovery by
using RMAN
Explain the RECOVER functionality
The RESTORE Command

The RESTORE command can restore the following from
image copies that are present on a disk or any other
media:
Database
Tablespaces
Data files
Control files
Archived redo logs
Server parameter files
4-3
The RESTORE Command

Use the RESTORE command to restore files from backups or image copies. RMAN can restore
an entire database, a tablespace, a data file, or a control file. By default, RMAN restores files to
their default location. You can use the SET NEWNAME command to restore files to nondefault
locations. RMAN restores backups from disks or tapes and restores image copies from disks
only. Typically, you restore when a media failure has damaged a current data file, control file, or
archived log or before performing a point-in-time recovery. The RESTORE command restores
full backups, incremental backups (level 0 only), or copies of data files, control files, and
archived redo logs. Because the RECOVER command automatically restores archived logs as
needed, you seldom need to restore logs manually.
Steps in the RESTORE Process

1. RESTORE reads only what is needed to restore the
required files.
2. Memory structures and buffers are allocated for
each file that is being restored.
3. The backup set is read until all file headers for all
files that are being restored have been read.
4. RESTORE decides whether to restore blocks.
5. Backup set-relative file numbers are replaced with
correct RDBA file numbers.
4-4
Steps in the RESTORE Process

When performing a restore, RMAN initially allocates memory structures and buffers that it
anticipates will be needed for the operation. The headers of the files to be restored are read and
recovery decisions are made. The backup set relative-file number in the data block address is
then replaced with the tablespace relative-file number. If RMAN is restoring a data file backup
set, then unused block ranges are identified and re-created. When each output buffer is filled, it
is sent to the output device. Input buffers and output buffers do not need to be in sync. Many
input buffers can be processed before an output buffer is filled. The file header is restored last to
ensure that a partially restored file cannot be accidentally used.
RMAN can report if a file has not been completely restored. It knows how many pieces are there
in the set. If all the pieces in the set are completely read and the file header is not encountered,
then DBMS_BACKUP_RESTORE requests another piece, which RMAN knows does not exist.
File Selection When Restoring
RMAN selects the best available backup sets or

image copies when restoring.
RMAN uses the most current backup sets or
copies if there is more than one choice.
Can be limited by the UNTIL clause
RUN {
SET UNTIL TIME '23-JUN-2002 00:00:00';
...
}
The RESTORE command searches for backups or

copies only on configured channels.
Include a DEVICE TYPE clause to override
4-5
File Selection When Restoring

RMAN uses the repository to select the best available backup sets or image copies for use in the
RESTORE operation. It gives preference to image copies rather than backup sets. When multiple
choices are available, RMAN uses the most current backup sets or copies, taking into account
whether you specified an UNTIL clause in the RESTORE command.
All specifications of the RESTORE command must be satisfied before RMAN restores a backup
set or file copy. Unless limited by the DEVICE TYPE clause, the RESTORE command searches
for backups and copies on all device types of configured channels.
If no available backup or copy in the repository satisfies all the specified criteria, then RMAN
returns an error during the compilation phase of the restore job. If you manually allocate
channels, and the file cannot be restored because no backup sets or data file copies exist on the
device types allocated in the job, then create a new job specifying channels for devices
containing the existing backup sets or copies. This problem does not occur when you configure
automatic channels.
Restore Optimization
4-6
RMAN does not restore a file if the header check

succeeds and it is in the right location.
The FORCE option of the RESTORE command
overrides this behavior.
Restore optimization only verifies the file header
and does not inspect the file for corrupted blocks.
Restore Optimization
RMAN restores a file only if the header check does not succeed. By using the FORCE option of
the RESTORE command it is possible to override this behavior and restore the requested files
unconditionally. Understand however, that restore optimization only checks the data file header
and does not the scan the data file body for corrupted blocks.
Restore optimization is particularly useful in cases where a restore only partially completes. For
example, assume that your system or instance crashed during a full database restore. If you start
the same restore after startup, RMAN will only restore the data files that were not restored
during the previous attempt. With the ever-increasing size of databases, this time-saving feature
is extremely important.
Restoring Data Files and Tablespaces
Restore data file backups and copies to either:

The default location
RMAN> RESTORE datafile '/u01/oradata/tools01.dbf';
Or
A new location using the SET NEWNAME command
RUN {
SET NEWNAME FOR datafile
'/u01/oradata/tools01.dbf'
TO '/tmp/tools01.dbf';
RESTORE datafile '/u01/oradata/tools01.dbf';
}
Restore a tablespace:
RMAN> RESTORE TABLESPACE tools;
4-7
Restoring Data Files and Tablespaces

RMAN automates the procedure for restoring files. It is not necessary to copy files manually into
the appropriate directories. When you issue a RESTORE command, RMAN directs a server
session to restore the correct backups and copies to either:
The default location, overwriting the files with the same name currently there, or
A new location, which you can specify with the SET NEWNAME command
To restore a data file, mount the database or keep it open and take the data file to be restored
offline.
SQL> alter database datafile '/u01/oradata/tools01.dbf' offline;
When RMAN performs a restore, the restored files are created as data file copies and recorded in
the repository. If the SWITCH command is run in conjunction with the SET NEWNAME
command, then RMAN updates the data file names in the control file to the names of the
restored files; otherwise this update does not take place. When restoring data files or tablespaces,
the database can be up but the data files or tablespaces must be offline:
RMAN>
RMAN>
RMAN>
RMAN>
SQL "ALTER TABLESPACE tools OFFLINE IMMEDIATE";

RESTORE TABLESPACE tools;
RECOVER TABLESPACE tools;
SQL "ALTER TABLESPACE tools ONLINE";
Restoring to a New Location
4-8

Use the Recovery Wizard to restore and recover your database. You can use the Rename page to
restore the selected datafiles to a new location. When datafiles are restored to a new location,
they are considered datafile copies. Therefore, a switch is automatically performed.
Restoring Archived Logs
To restore archived logs:

restore archivelog {all|like
<filename>|<archivelog range>| );
RMAN automatically restores all archived logs that

are needed during the recovery phase.
Use SET ARCHIVELOG DESTINATION to override
the LOG_ARCHIVE_DEST setting.
4-9
Restoring Archived Logs

RMAN names the restored archived logs by using the LOG_ARCHIVE_FORMAT and the
LOG_ARCHIVE_DEST_1 parameters of the target database. These parameters are combined in
a port-specific way to derive the name of the restored archived log. It is possible to override the
default names by using the SET ARCHIVELOG DESTINATION command. This command
allows manual staging of archived logs to different locations while a database restore is
occurring. During recovery, RMAN knows where to find the restored archived logs. If space is a
concern, consider using the DELETE ARCHIVELOG MAXSIZE command.
Connect to the target database and recovery catalog (if implemented), then start and open the
database:
RMAN> STARTUP;
Within a run command, you can override the LOG_ARCHIVE_DEST location if needed and
restore the archived logs:
RUN
{
SET ARCHIVELOG DESTINATION TO '/u02/tmp_restore';
RESTORE ARCHIVELOG ALL;
# restore datafiles as needed
}
Restoring the Server Parameter File
Using a catalog:
RMAN> RESTORE SPFILE;
Without a catalog:
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
To a nondefault location by using a catalog:

RMAN> RESTORE SPFILE TO'/tmp/spfileTEMP.ora';
To a nondefault location without using a catalog:

RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora'
2> FROM AUTOBACKUP;
4-10
Restoring the Server Parameter File

RMAN can restore the server parameter file either to the default location or to a nondefault
location. RMAN can also restore the server parameter file as a server parameter file or as a
client-side initialization parameter file. If the instance is already started with the server
parameter file, then you cannot overwrite the existing server parameter file.
If the SPFILE must be restored, connect to the target database and the recovery catalog
database, if implemented. If you are connected to a catalog, and if the target database DB_NAME
of the target database is not unique in the catalog, then set the DBID of the target database. For
example:
RMAN> SET DBID 676554321;
Next, shutdown the instance and restart without mounting and restore the SPFILE:
RMAN> STARTUP FORCE NOMOUNT
RMAN> RESTORE SPFILE;
Finally, restart the instance. If the server parameter file was restored to a nondefault location,
then the steps are slightly different.
Restoring the Server Parameter File (continued)

If a catalog is being used, then restore the SPFILE as shown below:
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora';
The SPFILE now resides in a location that is different from what was originally specified in the
initialization parameter file. Create a temporary file with a pointer to the restored SPFILE
location. Using the HOST command, it is possible to create the file without exiting the RMAN
prompt by using the UNIX echo command:
RMAN> HOST 'echo "SPFILE=/tmp/spfileTEMP.ora" > /tmp/init.ora';
Start the instance by using the temporary parameter file and SPFILE:
RMAN> STARTUP FORCE PFILE=/tmp/init.ora;
Restoring the Database to a New Host
With RMAN, you can:

Create a duplicate of the production database
Test the restore of the production database to a
new host
Move the location of the production database to a
new host
To create a duplicate database, use the

DUPLICATE command instead of RESTORE.
RMAN automatically creates a unique DBID for the

duplicate database.
4-12
Restoring the Database to a New Host

Make the target initialization parameter file accessible on the new host by copying it from the
old host to a new host by using an OS utility such as FTP. You must make sure that backups
used for the restore are accessible on the restore host. For example, if the backups were made
with a media manager, then make sure that the tape device is connected to the new host.
You cannot use RMAN to restore disk backups or image copies that are created on one host to a
new host. Again, you can use an OS utility such as FTP. If the files are in the same location in
the new host, then you do not need to recatalog them. If you transfer the files to a new location,
then use the CATALOG command to update the RMAN repository with the new filenames and
use the CHANGE ... UNCATALOG command to uncatalog the old filenames. Because the
restored database will not have the online redo logs of the production database, perform
incomplete recovery up to the lowest SCN of the most recently archived log in each thread and
then open with the RESETLOGS option. Get the SCN for recovery termination by finding the
lowest SCN among the most recent archived logs for each thread.
SQL> SELECT MIN(SCN) FROM (SELECT MAX(NEXT_CHANGE#) SCN
2 FROM V$ARCHIVED_LOG GROUP BY THREAD#);
MIN(SCN)
---------4366578
Restoring the Database to a New Host (continued)

It is possible that you might encounter an RMAN-20240 error when attempting to duplicate a
database to either a local or a remote machine. A sample error stack excerpt is shown below:
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08060: unable to find archivelog
RMAN-08510: archivelog thread=1 sequence=6
...
RMAN-06038: recovery catalog package detected an error
RMAN-20242: specification does not match any archivelog in
the recovery catalog
A common cause of this error is that the data file backups that are being used for the duplication
are inconsistent. Most likely an ALTER SYSTEM ARCHIVE LOG CURRENT command was
not executed after the data file backup is completed. Because of this, RMAN is looking for the
necessary redo records in the online redo logs.
To address this, use the set until command to specify a log sequence number for
incomplete recovery when creating the duplication script. For example, to stop recovery at log
sequence 6, the script might look like this:
run {
set until logseq 6 thread 1;
allocate auxiliary channel dupdb1 type disk;
duplicate target database to dupdb;
}
Create Standby Database with DUPLICATE
RMAN automates these steps of the database

creation:
Restore the standby control file.
Restore the primary data file backups and copies.
RMAN recovers the standby database to:

The specified time
The latest archived redo log generated
The database remains mounted so the user can:

Activate it
Place it in manual or managed recovery mode
Open it in read-only mode
4-14
Create Standby Database with DUPLICATE

When you create a standby database, the procedure differs depending on whether the standby
database is on the same host as the primary database or on a different host. These procedures
assume that you have already completed the standby setup and preparation as outlined in
Oracle9i Data Guard Concepts and Administration. Do not attempt these procedures until you
have made all the necessary initialization parameter settings and network configuration.
After you have performed the steps that are necessary for preparing the standby instance, run the
RMAN DUPLICATE...FOR STANDBY command to create the standby database out of
backups of the primary database. Note that a standby database, unlike a duplicate database
created by DUPLICATE without the FOR STANDBY OPTION, does not get a new DBID.
Therefore, you must not attempt to register the standby database in the repository for the primary
database. Some of the steps that are required for creating the standby database differ depending
on whether you specify that RMAN should recover the standby database after creating it. For a
complete coverage of this topic, please refer to Oracle9i Recovery Manager Users Guide.
Validating Restore of Backups and Copies
The restore can be tested with the

RESTOREVALIDATE command.
RMAN> RESTORE DATABASE VALIDATE;
A restore validation executes a restore test

without actually restoring the files.
Backups or copies can be tested with the
VALIDATE BACKUPSET command.
RMAN> VALIDATE BACKUPSET 218;
4-15
Validating Restore of Backups and Copies

A restore validation executes a restore test run without actually restoring the files. You can test
the restore of either the entire database or individual tablespaces, data files, or control files. The
VALIDATE BACKUPSET command tests whether you can restore backups or copies. The
RESTORE...VALIDATE command tests whether RMAN can restore a specific object from
a backup or copy. RMAN chooses which backups or copies to use. The VALIDATE
BACKUPSET command tests the validity of a backup set that you specify. Use VALIDATE
BACKUPSET to specify which backups to test; use RESTORE...VALIDATE to let RMAN
choose which backups to validate.
To perform the validation, the database can be mounted or open. You do not have to take data
files offline when validating them.
This example validates the restore of the backup control file, SYSTEM tablespace, and all
archived logs:
RMAN> RESTORE CONTROLFILE VALIDATE;
RMAN> RESTORE TABLESPACE SYSTEM VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE;
Validating Restore of Backups and Copies (continued)

If you see an error message stack and then the following message, then you do not have a backup
or copy of one of the files that you are validating:
RMAN-06026: some targets not found - aborting restore
If you see an error message stack and output similar to the following example, then there is a
problem with the restore of the specified file:
RMAN-03009: failure of restore command on c1 channel at 12-DEC-01
23:22:30
ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1"
If you do not see an error stack, then RMAN has successfully validated the files.
Restore Autolocation
In Oracle RAC environments, RMAN searches the

nodes for the backups that are needed for the
restore.
RMAN searches for files on all the configured
channels and restores files from those channels.
Autolocation is enabled automatically when the
channels use:
Different PARMS settings
Different connect strings
4-17
Restore Autolocation
In a Real Application Clusters configuration, RMAN automatically restores backups, control file
copies, and data file copies from channels that can read the files on tape or a local file system. So
long as you configured or manually allocated channels that connect to each node in the cluster,
RMAN hunts for files on all channels and restores files only from those channels that locate the
backup or copy on tape or on a local file system.
For example, if channel 1 that is connected to instance 1 can read log 1000 from its tape drive,
but channel 2 connected to instance 2 cannot read the log from its tape drive, then channel 1
restores the log. Autolocation is automatically enabled when the channels meet any of the
following criteria:
Different PARMS settings
Different connect strings
Restore When All Is Lost
Write a PL/SQL procedure that makes calls to

DBMS_BACKUP_RESTORE.
If target database used a recovery catalog and the

catalog is lost, restore the recovery catalog first.
If the only available backups are in the media
manager, you must know the name of the backup
piece for the control file backup.
4-18
Restoring When All Is Lost

What happens if the recovery catalog and target database are both lost or the target database and
all control files are lost and no recovery catalog is used?
Write a PL/SQL procedure
A PL/SQL procedure will need to be written that makes calls to DBMS_BACKUP_RESTORE. In
most cases, the procedure does not have to restore the entire lost database. It just needs to restore
a control file that contains records for the required backups. Then mount the control file and use
RMAN to restore the database. $ORACLE_HOME/rdbms/admin/dbmsbkrs.sql contains
descriptions of all DBMS_BACKUP_RESTORE functions.
Does the target database use a recovery catalog?
If the target database used a recovery catalog, and the recovery catalog is lost, then the first
priority is to restore the recovery catalog.
Restore When All Is Lost (continued)

Backups in media manager
If the only available backups are in the media manager, you must know the name of the backup
piece for the control file backup. The easiest way to find this is to look at the log from the most
recent backup. If that is not available, most media managers have a way to list the names of the
backup piece in their catalog, but if no listings are available, then you will have to find a control
file by trial and error.
The procedure given below can be used to restore a control file. The instance must be started,
but not mounted to execute this procedure.
declare
devtype varchar2(100);
done boolean;
recid number;
stamp number;
fullname varchar2(80);
begin
devtype :=
dbms_backup_restore.deviceallocate('sbt_tape',params=>'ENV=
(NSR_SERVER=backup_server)');
dbms_backup_restore.restoresetdata file;
dbms_backup_restore.restorecontrolfileto(
'first_control_file');
dbms_backup_restore.restorebackuppiece('backup_piece', done);
dbms_backup_restore.copycontrolfile ('first_control_file',
'second_control_file', recid, stamp,fullname);
-- repeat the above copycontrolfile for each control file
end; /
RMAN Media Recovery Steps

1. Place the database in the appropriate state.
Mount when recovering whole database.
Open the database for online tablespace recovery.
2. Restore necessary files with the RESTORE

command.
3. Recover data files using the RECOVER command.
4. Place the database in its normal state.
4-20
Basic RMAN Media Recovery

If possible, make the recovery catalog available to perform the media recovery. If it is not
available, then RMAN uses metadata from the target database control file. If both the control file
and recovery catalog are lost, then you can still recover the database, assuming that you have
backups of the data files and at least one autobackup of the control file. Consider the following
example of RMAN media recovery. The DBA runs the following commands:
RESTORE DATABASE;
RECOVER DATABASE;
RMAN then queries the repository, which in this example is a recovery catalog. The recovery
catalog obtains its metadata from the target database control file. RMAN then decides which
backup sets to restore and which incremental backups and archived logs to use for recovery. A
server session on the target database instance performs the actual work of restore and recovery.
RMAN Recovery Phases
RMAN divides the RECOVER functions into four

distinct phases:
1. RCV1: Fix the control file and switch to using data
file copies
2. RCV2: Apply incremental backups
3. RCV3: Apply all redo on disk
4. RCV4: Restore archivelogs and apply redo until
complete
4-21
These phase tags appear often in RMAN

debugging output.
RMAN Recovery Phases

RMAN performs recovery in four phases. These can be identified by the tags RCV1, RCV2,
RCV3, RCV4 in the RMAN Log.
RCV1 (Phase 1)
During RCV1, the backup control file is inspected and updated, if necessary. Without doing this,
the recovery process would stop whenever it detects that a new data file was added to the
database. The DBMS_BACKUP_RESTORE.SWITCHTOCOPY procedure is used to update the
control file. Next, implicit switches are performed if required. For example, when the user
indicates restore datafile 3, and the name of the file in the control file does not agree with the
name for that file in the recovery catalog, RMAN will automatically execute a SET NEWNAME
command for that data file.
RCV2 (Phase 2)
Check for any incremental backups and offline ranges that can be applied. Incremental backups
are applied to a level 0 or full backup. If an incremental backup cannot be found, then the control
file view V$ARCHIVED_LOG is searched for the names of archived redo logs to use for
recovery.
RMAN Recovery Phases (continued)

RCV3 (Phase 3)
The Oracle server records an archived log in the control file whenever one of the following
occurs:
The archive process archives a redo log
RMAN restores an archived log
The RMAN COPY command copies a log
The RMAN CATALOG command catalogs a user-managed backup of an archived log
Offline files are always skipped and read-only files are always skipped (provided the headers are
correct) unless CHECK READONLY is specified.
RCV4 (Phase 4)
If the RMAN repository indicates that no copies of a needed log sequence number exist on disk,
then RMAN looks in backups and restores archived redo logs as needed to perform the media
recovery. By default, RMAN restores the archived redo logs to the first local archiving
destination that is specified in the initialization parameter file. If the DELETE ARCHIVELOG
option was specified, then the archived logs are deleted after they are applied.
The media recovery session always runs on the default channel, but the ARCHIVELOG restore
steps can run on any channel, and will take advantage of parallelism if more than one channel is
allocated.
Recover Database with Recovery Wizard
4-23

You can use the Recovery Wizard to restore and recover your database. You can access the
wizard through the Enterprise Manager Console if you are connected to a Management Server.
The state of the database determines which options are available. The wizard guides you through
the specifications and then submits a recovery job through the Enterprise Manager.
Tablespace Recovery with Recovery

Wizard
4-24
Using Enterprise Manager (continued)

You can use the Recovery Wizard to restore and recover your database. On the Recovery
Selection page, you specify tablespace recovery. You can use the Tablespaces page to select the
tablespaces that you want to recover. You can choose from the list of tablespaces that are shown
in the Available tablespaces window.
RMAN Incomplete Database Recovery

1.
2.
3.
4.
Mount the database.

Allocate multiple channels for parallelization.
Restore all datafiles.
Recover the database by using UNTIL TIME,
UNTIL SEQUENCE, or UNTIL SCN.
5. Open the database by using RESETLOGS.
6. Perform a whole database backup.
4-25
Incomplete Database Recovery

RMAN can perform recovery of the database to a past time, SCN, or log sequence number. This
is called incomplete recovery because it does not use all of the available redo. Incomplete
database recovery is also called database point-in-time recovery (DBPITR).
Incomplete recovery of the database requires you to open the database with the RESETLOGS
option. This option gives the online redo logs a new time stamp and SCN, thus eliminating the
possibility of corrupting data files by the application of obsolete archived redo logs. You cannot
recover some data files before the RESETLOGS and others after the RESETLOGS. You must
recover all data files. The only exception is if the data file is offline normal or read-only. You
can bring files in read-only or offline normal tablespaces online after the RESETLOGS because
they do not need any redo.
The easiest method to perform DBPITR is to use the SET UNTIL command because it sets the
desired time for any subsequent RESTORE, SWITCH, and RECOVER commands in the same
RUN job. If you specify a SET UNTIL after a RESTORE and before a RECOVER, then it may
not be possible to recover the database to the desired point in time because the restored files may
already have time stamps that are more recent than the set time. It is recommended that you
specify the SET UNTIL command before the RESTORE command.
DBPITR with Enterprise Manager
4-26
Enterprise Manager and DBPITR

You can use the Recovery Wizard to restore and recover your database to a specific point in
time. On the Range Selection page, you must enter a date and time to restore to a previous point.
You use Instance Management or the Console to open the database after the job has been
completed. You can view the status of the job by selecting the Active and History page tabs in
the Consoles Job window.
Specifying the Sequence
4-27

On the Range Selection page, you must enter the redo log sequence number, which is the upper
limit of the recovery. This redo log will not be used in the recovery. Use Instance Management
or the Console to open the database after the job has been completed. You can view the status of
the job by selecting the Active and History page tabs in the Consoles Job window.
Block Media Recovery (BMR)
A block is the smallest unit of restore and

recovery.
BMR lowers the mean time to recover (MTTR).
BMR increases availability during media recovery.
The data file remains online during recovery
Only blocks being recovered are inaccessible
RMAN must be used for BMR:

Restores individual blocks from available backups
Coordinates with the server to have them recovered
Tape
4-28
Block Media Recovery

BMR reduces the smallest recoverable unit of media recovery from a data file to a block. When
a small number of blocks in the database are known to require media recovery, it is more
efficient to selectively restore and recover just those blocks. Only blocks that are being
recovered need to be unavailable, allowing continuous availability of the rest of the database
during recovery. BMR provides two main benefits over file-level recovery:
Lowers the mean time to recover (MTTR).
Allows increased availability of data during media recovery because the data file that is
being recovered remains online.
BMR uses existing recovery mechanisms to apply changes from the redo stream to block
versions that are restored from suitable backups. RMAN must be used to perform BMR. RMAN
restores individual data blocks from available backups and coordinates with the Oracle server
process to have them recovered. Without block-level recovery, if even a single block is corrupt,
the entire file must be restored and all redo changes must be generated for that file because
backup must be applied. The reduction in MTTR that is realized by using block-level recovery
includes both restore and recovery time. Note that only complete recovery is possible.
Incomplete recovery would render the database logically inconsistent.
The BLOCKRECOVER Command
BMR is implemented through the RMAN

BLOCKRECOVER command.
BLOCKRECOVER identifies the backups containing
the blocks to recover.
The command reads the backups and
accumulates requested blocks into in-memory
buffers.
BLOCKRECOVER manages the block media recovery
session by reading the archive logs from backup if
necessary.
RMAN> BLOCKRECOVER datafile 6 BLOCK 3;
4-29
The RMAN BLOCKRECOVER Command

RMAN supports BMR by means of the new BLOCKRECOVER command. When the user
encounters a block corruption, the error message or the trace files indicate which block is
causing problems. The DBA can then invoke this command to restore only the block in question,
thus saving an enormous amount of down time and data unavailability.
The BLOCKRECOVER command does the following:
Identifies the backups from which to obtain the blocks to recover.
Reads the backups and accumulates requested blocks into in-memory buffers. If any of the
desired blocks are corrupt (either media or logical corruption), RMAN reads the next oldest
backup of that file, looking for a good copy of the block. The UNTIL option limits
selection to backup sets or file copies that are taken at or before the specified time, SCN, or
log sequence; this forces BLOCKRECOVER to use an older backup instead of the most
recent one.
Starts and manages the block media recovery session, reading the archive logs from backup
if necessary.
Always does a complete recovery. No point-in-time recovery is possible by using the
BLOCKRECOVER command.
The RMAN BLOCKRECOVER Command (continued)

Block media recovery is most useful for data losses that affect specific blocks. Typically, this
type of block corruption is reported in these locations:
Oracle error messages in standard output
The alert log
User trace files
Results of the SQL ANALYZE TABLE and ANALYZE INDEX commands
Results of the dbverify utility
Third-party media management output
Block-level data loss usually results from:
Intermittent, random I/O errors that do not cause widespread data loss
Memory corruptions that get written to disk
For example, you may discover the following messages in a user trace file:
ORA-01578:
ORA-01110:
ORA-01578:
ORA-01110:
ORACLE data
datafile 6:
ORACLE data
datafile 2:
block corrupted (file # 6, block # 3)

'/oracle/dbs/tbs_71.f'
block corrupted (file # 2, block # 235)
'/oracle/dbs/tbs_21.f'
You can then specify the corrupt blocks in the BLOCKRECOVER command as follows:
RMAN> BLOCKRECOVER datafile 6 BLOCK 3 datafile 2 BLOCK 235;
RMAN BMR Interface
The list of corrupted database blocks is stored in

the V$DATABASE_BLOCK_CORRUPTION view.
The CORRUPTION LIST clause specifies the
recovery of all blocks that are listed in this view.
RMAN> BLOCKRECOVER CORRUPTION LIST
2> RESTORE UNTIL TIME 'sysdate 10';
RMAN lists corruptions in backup sets and proxy

copies in two views:
V$BACKUP_CORRUPTION
V$COPY_CORRUPTION
4-31
RMAN BMR Interface

By using the CORRUPTION LIST clause, you can recover blocks that are listed in
V$DATABASE_BLOCK_CORRUPTION. After a block has been repaired through block media
recovery (or normal media recovery), V$DATABASE_BLOCK_CORRUPTION will not be
updated until you take a new backup. The UNTIL clause specifies that only backups and copies
that are created before the specified time, SCN, or log sequence number should be restored and
used for the recovery.
Two types of corruption result in rows that are being added to V$BACKUP_CORRUPTION and
V$COPY_CORRUPTION by the BACKUP and COPY commands respectively:
Physical corruption (sometimes called media corruption). The Oracle server does not
recognize the block at all: the checksum is invalid, the block contains all zeros, or the
header and footer of the block do not match. Physical corruption checking is ON by
default, and can be turned off with the NOCHECKSUM option.
Logical corruption. The block has a valid checksum, the header and footer match, and so
forth, but the contents are logically inconsistent. Logical checking is OFF by default, and
can be turned on with the CHECK LOGICAL option.
Trial Recovery
Trial recovery is invoked by adding the TEST

option to any restore command:
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE TEST;

SQL> RECOVER TABLESPACE sales TEST;
SQL> RECOVER DATABASE UNTIL CANCEL TEST
Errors are reported in the alert log.
Media recovery can mark a data block corrupt if

required to proceed.
SQL> RECOVER DATABASE ALLOW 1 CORRUPTION;
4-32
The alert log indicates if the problem can be

skipped.
Trial Recovery
In the past, some problems that might occur during media recovery were not recoverable. For
media recovery, this means that you must restore the backup and recover the database again to
an SCN before the point where the corruption occurred. For a large database, this can take a long
time. The following enhancements are now provided:
If media recovery of a full database encounters a problem, then recovery leaves behind a
consistent database, that is a database that can be opened read-only or with resetlogs.
Database administrators can instruct media recovery to mark a data block as being
corrupted and therefore ignore its inconsistency in order to proceed with recovery. The
block will be inaccessible but the rest of the recovery process will continue.
Using another new option of recovery command, database administrators can invoke Trial
Recovery to investigate if a recovery problem is an isolated problem.
Almost all practical problems during media recovery are recoverable, because of an optimistic
redo application algorithm. Recovery optimistically assumes that no problem will occur during
media recovery. If one does occur, then the Oracle server will roll back the last changes that
caused inconsistency in the recovered database.
Note: Trial recovery is a user-managed recovery option. For more information on Trial
Recovery, refer to the Oracle9i User-Managed Backup and Recovery Guide.
Tablespace Recovery: Example
$ rman target / catalog rman/rman@rcat

RMAN> run {
2> allocate channel t1 type 'sbt_tape';
3> sql 'alter tablespace sample
4> offline immediate';
5> restore tablespace sample;
6> recover tablespace sample;
7> sql 'alter tablespace sample online';
8> }
4-33
Tablespace Recovery: Example

This example illustrates the restoration and recovery of all files in the SAMPLE tablespace. In
this scenario, a channel is manually allocated. Assume that the database is open.
Recover Database: Example

To recover the database with an autobackup of the
control file without using a recovery catalog:
1. Start RMAN and connect to the target database.
2. Start the target instance but do not mount the
database.
3. Set the database identifier for the target database.
4. Restore the autobackup control file, then perform
recovery.
5. Open the database and reset the online logs.
6. Back up the database.
4-34
Database Recovery: Example

1. Start RMAN and connect to the target database. For example, run:
RMAN> CONNECT TARGET /
2. Start the target instance without mounting the database. For example:
STARTUP NOMOUNT;
3. Set the database identifier for the target database. RMAN displays the DBID whenever you
connect to the target. You can also get it by running LIST or querying the catalog.
RMAN> SET DBID 676549873;
4. Restore the autobackup control file, then perform recovery. Specify the most recent
backup time stamp that RMAN can use when searching for a control file autobackup to
restore. If a nondefault format was used to create the control file, then specify a nondefault
format for the restore of the control file. If the channel that created the control file
autobackup was device type sbt, then you must allocate one or more sbt channels.
Because no repository is available, you cannot use automatic channels. However, if the
autobackup was created on a disk channel, then you do not need to allocate a channel
manually.
Database Recovery: Example (continued)

Restore the autobackup of the control file and mount the database. Because the repository
is now available, any automatic channels that you configured are also available. If the
online logs are inaccessible, then restore and recover the database. You must terminate
recovery by setting the UNTIL clause to a time, log sequence, or SCN before the online
redo logs.
In this example, the online redo logs have been lost. This example limits the restore of the
control file autobackup, then performs recovery of the database to log sequence 13243,
which is the most recent archived log:
RMAN> RUN {
# Optionally, set upper limit for time stamps of control file
# backups
# SET UNTIL TIME 03/10/2002 13:45:00;
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
# ?/oradata/%F.bck;
# manually allocate one or more channels
2> ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
3> RESTORE CONTROLFILE FROM AUTOBACKUP
4> MAXSEQ 100 # start at sequence 100 and count down
5> MAXDAYS 180; # start at UNTIL TIME and search back 6 months
6> ALTER DATABASE MOUNT DATABASE;
7> }
# use automatic channels configured in restored control file
RMAN> RESTORE DATABASE UNTIL SEQUENCE 13243;
RMAN> RECOVER DATABASE UNTIL SEQUENCE 13243;
5. If recovery was successful, then open the database and reset the online logs:
RMAN> ALTER DATABASE OPEN RESETLOGS;
6. You should back up the database immediately, with the database mounted. Because the
database is a new incarnation, the backups made before the RESETLOGS are not easily
usable. Enter:
RMAN>
RMAN>
RMAN>
RMAN>
SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
Performing Incomplete Recovery by

Using UNTIL TIME: Example
RMAN>
2>
3>
4>
5>
6>
7>
4-36
RUN {
ALLOCATE CHANNEL c1 TYPE DISK;
ALLOCATE CHANNEL c2 TYPE DISK;
SET UNTIL TIME = '2002-12-09:11:44:00';
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS; }
Performing Incomplete Recovery by Using UNTIL TIME: Example

At 12:00 p.m. on Monday, December 9, 2002, you immediately shut down the database and
begin recovery after determining that the EMPLOYEES table was dropped. The approximate
time of failure is known and the database structure has not changed since 11:44 a.m. You can use
the UNTIL TIME method:
1. If the target database is open, perform a clean shutdown.
2. Mount the target database. Do not back up the database during the recovery.
3. Ensure that NLS_LANG and NLS_DATE_FORMAT environment variables are set
appropriately:
$NLS_LANG=american
$NLS_DATE_FORMAT='YYYY-MM-DD:HH24:MI:SS'

$rman target rman/rman@U01
5. You can allocate multiple channels to improve the performance:

RMAN>
2>
3>
4>
5>
6>
run {allocate channel c1 type DISK;

allocate channel c2 type DISK;
SET UNTIL TIME = '2002-12-09:11:44:00';
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS; }
Performing Incomplete Recovery by Using UNTIL TIME: Example (continued)

6. Specify the time for recovery and restore all datafiles from a backup with RMAN
commands. RMAN chooses the correct files based on the SET UNTIL command:
RMAN> ... set until time = 2001-12-09:11:44:00;
RMAN> ... restore database;
Note: If you need to restore archived redo log files to a new location, then use the RMAN
SET ARCHIVELOG DESTINATION TO <location> command.
7. Recover the database to the time specified in the SET UNTIL command:
RMAN> ... recover database;
8. Open the database by using the RESETLOGS option:

RMAN> ... alter database open resetlogs; }
9. Check whether the table exists and then perform a backup.

10. Notify users that the database is available for use, and that they should reenter any data that
was not committed before system failure.
11. If you are using a recovery catalog, then register the new incarnation of the database:
RMAN> reset database;
Performing Incomplete Recovery by

Using UNTIL SEQUENCE: Example
RMAN>
2>
3>
4>
5>
6>
7>
4-38
RUN {
SET UNTIL SEQUENCE 120 THREAD 1;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE; # recovers through log 119
ALTER DATABASE OPEN RESESTLOGS;
}
Performing Incomplete Recovery by Using UNTIL SEQUENCE: Example

The UNTIL SEQUENCE clause specifies a redo log sequence number and thread as an upper
limit. RMAN selects only files that can be used to recover up to but not including the specified
log sequence number. This example assumes that log sequence 120 was lost due to a disk crash
and the database needs to be recovered by using the available archived redo logs.
Recovering a NOARCHIVELOG
Database: Example
Assume the following scenario:
The database TRGT operates in NOARCHIVELOG
mode.
A recovery catalog is used.
The database is shut down consistently and a
level 0 backup is made to tape on Sunday
afternoon.
The database is shut down consistently and a
level 1 differential incremental backup is made to
tape at 4:00 a.m. on Wednesday and Friday.
4-39
Recovering a Database in NOARCHIVELOG Database: Example

A NOARCHIVELOG database can be recovered with consistent incremental backups. Assume
that the database has a media failure on Saturday, destroying half of the data files as well as the
online redo logs. In this case, you must perform an incomplete media recovery until Friday,
because that is the date of the most recent incremental backup. RMAN uses the level 0 Sunday
backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER
command. You must also specify NOREDO if the online logs are available but the redo cannot be
applied to the incrementals. If the online logs had been available, then you could have run
RECOVER DATABASE without specifying NOREDO. Connect to TRGT and the catalog and
recover the database by using the following commands:
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
STARTUP NOMOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO online redos are lost
ALTER DATABASE OPEN RESETLOGS;
All changes that are generated between the Friday incremental backup and the Saturday failure
are not applied.
Examples of BLOCKRECOVER
4-40
Recovering a group of corrupt blocks

Limiting block media recovery by type of restore
Limiting block media recovery by backup tag
Limiting block media recovery by time, SCN, or log
sequence
Examples of BLOCKRECOVER
1. Recovering a group of corrupt blocks
BLOCKRECOVER datafile 2 BLOCK 12, 13 datafile 7 BLOCK 5, 98, 99
datafile 9 BLOCK 19;
2. This example recovers a series of blocks and restores only from data file copies: RUN {
BLOCKRECOVER datafile 3 BLOCK 1,2,3,4,5
TABLESPACE sales DBA 4194405, 4194409, 4194412
FROM datafile COPY;
}
3. Limiting BMR by backup tag

BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 FROM TAG
"weekly_backup";
4. The following example recovers two blocks in the SYSTEM tablespace and forces the
blocks to be restored from backups that were created at least two days ago:
BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 RESTORE UNTIL
TIME 'SYSDATE-2';
Examples of BLOCKRECOVER (continued)

The following example recovers two blocks and forces the blocks to be restored by using
backups that were made before SCN 100:
BLOCKRECOVER datafile 9 BLOCK 13 datafile 2 BLOCK 19 RESTORE UNTIL SCN
100;
The following example recovers two blocks and forces the blocks to be restored by using
backups that were made before log sequence 7024:
BLOCKRECOVER datafile 9 BLOCK 13 datafile 2 BLOCK 19 RESTORE UNTIL
SEQUENCE 7024;
Summary
Identify the tasks that are performed by RMAN
before restoring
Identify the RESTORE functionality
4-42
Explain the restore algorithm that is used by

RMAN
Identify the four distinct phases of recovery by
using RMAN
Explain the RECOVER functionality
Practice Overview:
Restore and Recovery with RMAN
Familiarizing with DBMS_BACKUP_RESTORE
4-43
Completing recovery from a total failure

Performing incomplete recovery to some time in
the past
RMAN Maintenance
Objectives
the following:
Use the LIST command to display backup data
that is recorded in the catalog or target control file
Use the REPORT command to gather detailed
information about recovery catalog data
Use the CROSSCHECK and DELETE commands
Use the SHOW command to view configuration
details
Use the CHANGE command to alter the status of
object backups
5-2
RMAN Catalog Maintenance
Restore/Recovery
RMAN
Backup
Enterprise
Manager
Target Control file

database
Reporting
REPORT
LIST
Catalog maintenance
CROSSCHECK
DELETEEXPIRED
LIST
CHANGE
5-3
Stored
scripts
Catalog
database
RMAN Catalog Maintenance

RMAN provides the following command sets for catalog maintenance:
CROSSCHECK checks the status of a backup or a copy on disk or tape.
DELETE lists specified backup objects and prompts for confirmation to remove them.
CHANGE is used to alter the status of backup objects in the repository.
LIST shows what CROSSCHECK/DELETE EXPIRED will process.
The CROSSCHECK Command
CROSSCHECK synchronizes backup pieces in the

recovery catalog with their corresponding files.
RMAN> allocate channel for maintenance
2> type 'sbt_tape';
RMAN> crosscheck backup;
5-4
With crosschecks, you can check the status of a

backup or copy on a disk or a tape.
CROSSCHECK only works on items recorded in the
RMAN repository.
The CROSSCHECK Command

Sometimes backups and copies disappear from disk, or tapes in the media management
library become unavailable. Crosschecks can verify the status of backups or file copies on a
disk or a tape. Crosschecks can also update the repository if you delete archived redo logs or
other files by using operating system commands. To ensure that data about backup sets and
image copies in the recovery catalog or control file is synchronized with the actual files on a
disk or in the media management catalog, perform a crosscheck. For files on disk, RMAN
directly verifies that the file exists. For files on SBT_TAPE, RMAN queries the media
management software. The CROSSCHECK command operates only on files that are recorded
in the RMAN repository.
Use CROSSCHECK to check the status of a backup or copy on a disk or a tape. If the backup
or copy is on a disk, then CROSSCHECK checks whether the header of the file is valid. If a
backup is on a tape, then the command checks that the backups exist. Backup sets, pieces,
and copies can be AVAILABLE, EXPIRED, or UNAVAILABLE. You can issue the DELETE
EXPIRED command to delete all expired backups and copies. RMAN removes the record
for the expired file from the repository. If for some reason the file still exists on the media,
then RMAN issues warnings and lists the mismatched objects that cannot be deleted.
The LIST Command
Lists all databases known to the recovery catalog

or incarnations of a database:
RMAN> list incarnation of database;
Lists backup sets or file copies containing a

backup of a specified list of files:
RMAN> list backup of datafile 2;
Lists all data file copies, control file copies, and

archived logs:
RMAN> LIST COPY;
5-5
The LIST Command

The LIST command queries the recovery catalog or control file and produces a listing of
the backups, copies, archived redo logs, and database incarnations recorded there. Every
time you reset the online redo logs of a target database, you create a new incarnation of the
database. View incarnations with the LIST INCARNATION command.
RMAN> list incarnation;
List of Database Incarnations
DB Key
------1
1
Inc Key
------2
73
DB Name
-------U02
U02
DB ID
-----------775813490
775813490
CUR
--NO
YES
Reset SCN
---------1
440227
Reset Time
---------06-MAR-02
27-MAR-02
Some important column descriptions are described below:

DB Key
When combined with the Inc Key, the unique key by which RMAN
identifies the database incarnation in the recovery catalog.
CUR
Whether the incarnation is the current incarnation of the database.
Reset SCN
The SCN at which the incarnation was created.
Reset Time The time at which the incarnation was created.
Note that U02 was opened with the RESETLOGS option at SCN 440227 resulting in a new
database incarnation.
The LIST Command (continued)

By default, RMAN lists backups by backup, which means that it serially lists each backup
set or proxy copy and then identifies the files that are included in the backup.
RMAN> list backup of datafile 2;
List of Backup Sets
===================
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ------- ----------- ------------ --------------45
Full
29M
DISK
00:00:13
24-MAR-02
BP Key: 46
Status: AVAILABLE
Tag:
Piece Name: /u01/ORADATA/u06/01dk630k_1_1
File LV Type Ckp SCN
Ckp Time Name
---- -- ---- ---------- --------- ---2
Full 439498
24-MAR-02 /u01/ORADATA/undo1_01_U02.dbf
Column
----------File
Key
Indicates
-------------------------------------------------------------------------------------------The absolute data file number
A unique key identifying this backup set. If you are connected to a recovery
catalog, then Key is the primary key of the backup set in the catalog. It
corresponds to BS_KEY in the RC_BACKUP_SET view. If you are connected
in NOCATALOG mode, then Key displays the RECID from
V$BACKUP_SET. RECID and STAMP form a concatenated primary key
that uniquely identifies this record in the target control file.
TY
The type of backup: backup set (B) or proxy copy (P)
LV
The backup level: F for non-incrementals, level 0-4 for incrementals
S
The backup set status: available (A), unavailable (U), or expired (X)
Ckp SCN The checkpoint of the data file at the time it was backed up.All database
changes before the SCN have been written to the file; changes after the
specified SCN have not been written to the file.
Ckp Time The checkpoint of the data file at the time it was backed up. All changes
before the time have been written to the file; changes after the specified time
have not been written to the file.
#Piece
The number of backup pieces in the backup set
#Copies The number of copies made of each backup piece in the set. The number
is 1 if no duplexing was performed. Otherwise, the value ranges from 2
through 4.
Tag
The tag applied to the backup set; NULL if none
LIST Command Output
LIST command output is verbose by default.

Specify SUMMARY to see the output in a
summarized format.
RMAN> LIST BACKUP SUMMARY;
RMAN> LIST EXPIRED BACKUP SUMMARY;
Specify the desired objects to summarize with the

listObjectList or recordSpec clause.
5-7
LIST Command Output

By default, the LIST output is highly detailed, but you can also specify that RMAN display
the output in a summarized form. Specify the desired objects with the listObjectList
or recordSpec clause. If you do not specify an object, then LIST BACKUP displays all
backups. By default, RMAN lists backups in the verbose mode. To list backups in the
summary mode: After connecting to the target database and recovery catalog (if you use
one), execute LIST BACKUP. Specify the desired objects and options. For example, you
can enter:
RMAN> LIST BACKUP SUMMARY;
List of Backups
===============
Key
TY LV S
------- -- -- 45
B F A
55
B F A
59
B 1 A
69
B F A
88
B F A
Device Type
----------DISK
DISK
DISK
DISK
DISK
Completion Time
--------------24-MAR-02
24-MAR-02
27-MAR-02
27-MAR-02
27-MAR-02
#Pieces
------1
1
1
1
1
#Copies Tag
------- --1
1
1
1
1
The REPORT Command

The REPORT command reports in more
detail than LIST, and answers questions
such as:
Which are the files that need a backup?
Which are the files that have had
unrecoverable operations performed
on them?
Which are the backups or copies
that are obsolete and can be deleted?
What was the physical schema of the
database at some previous time?
5-8
The REPORT Command

To gain more detailed information from the RMAN repository, generate a report. Use the
REPORT command to answer questions such as the following:
Which are the files that need a backup?
Which are the files that have had unrecoverable operations performed on them?
Which are the backups or copies that are obsolete and can be deleted?
What was the physical schema of the database at some previous time?
Which are the files that have not been backed up recently?
The information that can be obtained from reports can be extremely important for
implementing a backup and recovery strategy. For reports to be accurate, the repository must
be synchronized with the control file and you must have run the CHANGE, UNCATALOG,
and CROSSCHECK commands recently to update the status of all backups and copies.
Report Objects Needing Backup
You can report files that require a backup

according to the retention policy.
RMAN> report need backup
[ redundancy | days | incremental ] n;
Redundancy defaults to 1 if not specified.

To ensure recovery is possible within an
acceptable time:
RMAN> report need backup incremental 3 database;
REPORT NEED BACKUP DAYS = 30 TABLESPACE SYSTEM;
REPORT NEED BACKUP DAYS = 14 DATAFILE
'/u01/user02/ORADATA/u03/users_01_U02.dbf';
5-9
Report Objects Needing Backup

You can report objects that require a backup by specifying the NEED BACKUP keyword. The
REDUNDANCY parameter specifies the minimum number of backups or copies that must
exist for a data file to be considered not in need of a backup. If you do not specify the
parameter, then REDUNDANCY defaults to 1. The DAYS parameter indicates that recovery
must begin by using logs more than integer days old. The INCREMENTAL parameter
indicates that more than integer, incremental backups are required for complete
recovery. If you disable the retention policy, then REPORT NEED BACKUP generates an
error message:
RMAN> report need backup;
RMAN-00571: ================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS=========
RMAN-00571: ================================================
RMAN-03002: failure of report command at 03/28/2002 21:07:27
RMAN-06525: RMAN retention policy is set to none
Report Objects Needing Backup (continued)

To report on objects that need a backup, the following steps outline a typical approach:
1. After connecting to the target database and recovery catalog (if used), run
CROSSCHECK commands to update backups and copies status. The following is a
typical crosscheck session:
RMAN> CROSSCHECK BACKUP;
RMAN> CROSSCHECK COPY;
2. If you have a retention policy configured, then run REPORT NEED BACKUP
without any other options to determine which files need backups.
RMAN> REPORT NEED BACKUP;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- --------------------------------------------2
0
/u01/user02/ORADATA/u02/undo1_01_U02.dbf
3
0
/u01/user02/ORADATA/u03/users_01_U02.dbf
3. If you do not have a retention policy enabled, then run REPORT NEED BACKUP
DAYS n. Any files that are older than the DAYS parameter value need a new backup
because their backups require the specified number of DAYS worth of archived logs
for recovery. For example, run:
RMAN> REPORT NEED BACKUP DAYS = 7 DATABASE; # 7 days of logs to
recover
RMAN> REPORT NEED BACKUP DAYS = 30 TABLESPACE SYSTEM;
4. To determine which files need an incremental backup, specify the INCREMENTAL
parameter. If complete recovery of a data file requires more than the specified
number of incremental backups, then RMAN considers it in need of a new backup.
For example, enter:
RMAN> REPORT NEED BACKUP INCREMENTAL = 1 DATABASE;
RMAN> REPORT NEED BACKUP INCREMENTAL = 3 TABLESPACE SYSTEM;
Report Unrecoverable Backups

and Copies
A data file is unrecoverable if an unrecoverable

operation has been performed against an object in
the data file since the last backup.
Run the REPORT UNRECOVERABLE command
regularly to ensure that recovery is possible.
RMAN> report unrecoverable;
5-11
The absence of a backup of a data file is not

sufficient reason to consider it unrecoverable.
Report Unrecoverable Backups and Copies

It is extremely important to run the REPORT UNRECOVERABLE command regularly to
ensure that the necessary backups are available to perform recovery. Assume that you
perform an unrecoverable operation on the EMPLOYEES table by issuing an ALTER
TABLE EMPLOYEES...NOLOGGING statement. If the EMPLOYEES table is located in
data file 3, then the REPORT command can flag backups of this data file as unrecoverable.
After connecting to the target database and recovery catalog (if you use one) run:
RMAN> REPORT UNRECOVERABLE DATABASE;
The nonexistence of any backup of a data file is not sufficient reason to consider it
unrecoverable. Such data files can be recovered through the use of the CREATE
DATAFILE command, if redo logs starting from when the file was created still exist.
Report Obsolete Backups and Copies
To identify which backups are superfluous, use

the OBSOLETE option:
RMAN> REPORT OBSOLETE REDUNDANCY = 2
DEVICE TYPE sbt;
To list unusable backups and copies, use the

ORPHAN option:
RMAN> REPORT OBSOLETE ORPHAN;
5-12
The RECOVERY WINDOW option specifies a window

during which the database must be recoverable.
Report Obsolete Backups and Copies

You can report on objects that are obsolete, or unneeded, by specifying the OBSOLETE
keyword. If you do not specify any other options, then REPORT OBSOLETE displays the
backups and copies that are marked obsolete by the current retention policy. By default, the
retention policy is configured to REDUNDANCY of 1. The RECOVERY WINDOW option
has been added to specify a window of time during which the database must be recoverable.
This option is mutually exclusive with the REDUNDANCY option. When RECOVERY
WINDOW is specified, then for each data file, one backup that is older than the recovery
window must exist. All backups older than that one are obsolete.
To list backups and copies that are obsolete and are candidates for removal, the following
steps outline a typical approach:
1. Connect to the target database and recovery catalog (if used) and issue CROSSCHECK
commands as needed to update the status of backups and copies. The following is a
possible crosscheck session:
RMAN> CROSSCHECK BACKUP; # crosschecks all backups
RMAN> CROSSCHECK COPY; # crosschecks all copies
2. Use the OBSOLETE option to find backups that are no longer needed for recovery.
RMAN> REPORT OBSOLETE REDUNDANCY = 2 DEVICE TYPE sbt;
Report Obsolete Backups and Copies (continued)

3. Use the ORPHAN option to list unusable backups and copies belonging to an
incarnation that does not directly precede the current incarnation.
RMAN> REPORT OBSOLETE ORPHAN;
4. Optionally, delete backups that are obsolete with the DELETE OBSOLETE
command.
RMAN> DELETE OBSOLETE;
Report Database Schema
To report the database schema:

RMAN> REPORT SCHEMA ;
To report the database schema at a specified point

in time:
RMAN> REPORT SCHEMA AT TIME 'SYSDATE-14';
RMAN> REPORT SCHEMA AT SCN 1000;
RMAN> REPORT SCHEMA AT SEQUENCE 100 THREAD 1;
The AT clause requires that a recovery catalog be

used.
5-14
Report Database Schema

It is not necessary to use dictionary views or recovery catalog views to identify the database
files. The REPORT SCHEMA command will list file names and numbers, size and
tablespace information. If you use a recovery catalog, then you can also generate historical
reports of the database schema as it existed at a previous point in time. You do not need a
recovery catalog, however, to report the current schema.
Connect to the target database and recovery catalog and issue REPORT SCHEMA for a list
of all the data files and tablespaces in the target database at the desired time:
RMAN> REPORT SCHEMA AT SCN 1000;
Report of database schema
File
---1
2
...
8
K-bytes
------307200
20480
Tablespace
---------SYSTEM
UNDOTB
RB segs
------YES
YES
Datafile Name
---------------------------/oracle/oradata/trgt/system01.dbf
/oracle/oradata/trgt/undotb01.dbf
10240
USERS
NO
/oracle/oradata/trgt/users01.dbf
This type of information is useful for incomplete recovery because you can determine the
schema of the database for the time to which you want to recover.
Show RMAN Configuration Settings
The SHOW...command displays specified

configuration values.
RMAN> show controlfile autobackup;
5-15
The SHOW ALL command displays current

CONFIGURE values as well as default values.
Any CONFIGURE command can be returned to its
default setting by running CONFIGURE...CLEAR.
Show RMAN Configuration Settings

The SHOW ALL command displays both the CONFIGURE commands that you have issued as
well as the default configurations of RMAN. Note that you can return any CONFIGURE
command to its default setting by running CONFIGURE...CLEAR.
To show all RMAN configuration settings, connect to the target database and run the SHOW
ALL command:
RMAN> SHOW ALL;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
...
CONFIGURE DATAFILE BACKUP COPIES FOR DISK TO 2;
CONFIGURE DATAFILE BACKUP COPIES FOR SBT TO 1; #default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR SBT TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DISK TO 1; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/dbs/cf_snap.f';
Individual settings can be shown like this:

RMAN> show retention policy;
The CHANGEUNAVAILABLE and

CHANGEAVAILABLE Commands
The CHANGEUNAVAILABLE command updates

availability information in the recovery catalog.
To mark a backup piece, file copy, or archivelog as
unavailable or available for restore or recovery:
RMAN> change archivelog
2> '/u01/arch/al_prd1_123.rdo'
3> unavailable;
5-16
When the maintenance is complete, the

CHANGEAVAILABLE command can be issued.
The CHANGEUNAVAILABLE Command

RMAN can update the repository to show backups and copies as available or unavailable.
For example, you may have several backups on a tape drive that is being upgraded or
replaced. You can use the CHANGE...UNAVAILABLE command to mark these backups
and copies as unavailable for the duration of the maintenance on the drive. RMAN does not
consider UNAVAILABLE backups and copies for its backup and recovery operations.
When the maintenance is complete, you can issue the CHANGE...AVAILABLE command
to inform RMAN that these backups and copies are now available again. Note that this
command does not check for the existence of the files or validates the file in any way: it
merely updates the repository record to AVAILABLE. You can run CROSSCHECK to
validate the file.
The CHANGEUNCATALOG Command
To remove references to a backup piece, file copy,

or archivelog from the recovery catalog:
RMAN> change archivelog
2> '/disk1/archivelog/al_prd1_123.rdo'
3> uncatalog;
5-17
The CHANGEUNCATALOG command does not affect

physical backups and copies.
The CHANGEUNCATALOG Command

This command removes references to a data file copy or archived redo log (but not a backup
piece or backup set) from the recovery catalog, and updates records in the target control file
to status DELETED. The CHANGE...UNCATALOG command does not affect physical
backups and copies. Use this command to notify RMAN when a file is deleted by some
means other than a DELETE command.
RMAN always removes the catalog record rather than marking the object as DELETED.
Therefore, catalog records should only be marked with status DELETED if the catalog has
been upgraded or the catalog was resynchronized from a backup control file. You can
remove all repository records of backups and copies with status DELETED by using the
prgrmanc.sql script, which is located in $ORACLE_HOME/rdbms/admin.
Deleting Specified Backups and Copies

To delete backups and copies and remove their
repository records:
1. Use the LIST command to obtain primary keys of
backups and copies.
2. If you do not have automatic channels configured,
then allocate a channel for maintenance.
3. Run the DELETE command to remove the physical
files and their repository records.
5-18
Deleting Specified Backups and Copies

Use the DELETE command to remove backups and copies that you no longer want to
retain. This command removes the physical files, deletes the catalog records (if you use a
catalog), and updates the status in the target control file to DELETED.
To delete backups and copies and remove their repository records:
1. Run the LIST command to obtain primary keys of backups and copies.
RMAN> LIST BACKUP OF DATABASE ARCHIVELOG ALL;
RMAN> LIST COPY;
2. If you do not have automatic channels configured, then allocate a channel for
maintenance.
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
3. Run the DELETE command to eliminate the specified physical files and their
repository records. You can delete any type of object in the recordSpecclause,
for example:
RMAN>
RMAN>
RMAN>
RMAN>
DELETE
DELETE
DELETE
DELETE
BACKUPPIECE 101;
CONTROLFILECOPY '/tmp/control01.ctl';
NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300;
BACKUP OF TABLESPACE users DEVICE TYPE sbt;
# deletes only tape backups

Deleting Specified Backups and Copies (continued)

RMAN> DELETE COPY OF CONTROLFILE LIKE /tmp/%;
# LIKE specifies name of the copy

RMAN> DELETE BACKUP OF SPFILE COMPLETED BEFORE SYSDATE-7;
RMAN> DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 3 TIMES TO sbt;
# backs up logs only if already backed up three times to tape
Delete Expired or Obsolete Backups
Run CROSSCHECK to make sure backups and

copies are still on the specified media.
Run DELETE EXPIRED command to remove these
backups and their records from the repository.
RMAN> DELETE EXPIRED BACKUP;
Run DELETE OBSOLETE to remove objects and

their records that are obsolete.
RMAN> DELETE OBSOLETE;
5-20
Deleting Expired or Obsolete Backups

You can use the CROSSCHECK command to determine whether backups and copies that
are recorded in the repository still exist on disk or tape. If RMAN cannot locate the backups
and copies, then it updates their records to EXPIRED status. You can then use the DELETE
EXPIRED command to remove these expired records. Note that if for some reason the
expired files still exist, then the DELETE EXPIRED command aborts with an error
message. Use the DELETE OBSOLETE command to remove backups and copies that are
obsolete, as defined by the defined retention policy. The DELETE OBSOLETE command
removes the physical files, deletes the catalog records (if you use a catalog), and updates the
records in the target control file to the status DELETED.
You can run the DELETE OBSOLETE REDUNDANCY or DELETE OBSOLETE
RECOVERY WINDOW commands to delete obsolete backups and copies. The redundancy
or recovery window setting on the DELETE command overrides settings on the
CONFIGURE RETENTION POLICY command. For example, enter:
RMAN> DELETE OBSOLETE REDUNDANCY = 3;
RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;
Stored Script Information
5-21
Use the RC_STORED_SCRIPT command

to list stored scripts.
Use the PRINT SCRIPT command
to display the text of a stored script.
Use the RC_STORED_SCRIPT_LINE
command to display text of
stored scripts.
Catalog
database
Stored Script Information

The RC_STORED_SCRIPT view contains information about all the stored scripts for all
the incarnations of the target databases that are registered in the catalog. Use the PRINT
SCRIPT command to display the text of a stored script. If required, you can save the output
to an RMAN log file. The RC_STORED_SCRIPT_LINE view contains the text of all the
stored scripts for all the incarnations of the target databases that are registered in the
recovery catalog.
To print scripts from RMAN and save the output to a log file:
$ rman TARGET / CATALOG rman/cat@catdb LOG = rman_log
RMAN> PRINT SCRIPT backup_whole;
To view script lines from the RC_STORED_SCRIPT_LINE view, start a SQL*Plus

session and connect to the recovery catalog as RMAN:
$ sqlplus rman/cat@catdb
SQL> SELECT TEXT
2> FROM RC_DATABASE_INCARNATION i, RC_STORED_SCRIPT_LINE s
3> WHERE i.DB_KEY = database_key AND SCRIPT_NAME = 'script_name'
4> AND i.DB_KEY = s.DB_KEY;
Maintenance Required When Not

Using a Recovery Catalog
The following are the tasks that are to be performed
manually when using RMAN without a recovery
catalog:
Monitor the overwriting of control file records
Maintain the control file repository
Backing up and restoring the control file
Target Control file

database
5-22
Maintenance Required When Not Using a Recovery Catalog

When you do not use a recovery catalog, the control file is the only source of information
about RMAN backups and copies. As you make backups and copies, the Oracle server adds
new records to the control file. What happens when the server needs to add new records to
the control file, but the oldest record is less than the value specified in
CONTROL_FILE_RECORD_KEEP_TIME?
The Oracle server attempts to expand the size of the control file, which it can do only if the
underlying operating system file can be expanded. If it cannot expand the control file, then
the server overwrites the oldest record, regardless of whether its age is less than the
CONTROL_FILE_RECORD_KEEP_TIME value and logs this action in the alert log.
Therefore, if you are not using a recovery catalog, then set the
CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file that
you need to keep.
If you use the control file as the only repository of the RMAN metadata, then maintain
alternative control files through multiplexing or operating system mirroring and back up the
control file frequently. If you lose the control file and do not have a backup, then you lose
all information about RMAN backups and copies that are contained in the file. For this
reason, you should set CONFIGURE CONTROLFILE AUTOBACKUP to ON.
Summary
Use the LIST command to display backup data
that is recorded in the catalog or target control file
Use the REPORT command to gather detailed
information about recovery catalog data
Use the CROSSCHECK and DELETE commands
Use the SHOW command to view configuration
details
Use the CHANGE command to alter the status of
object backups
5-23
Practice Overview:
RMAN Maintenance
Using the LIST command
Using the REPORT command
5-24
Deleting expired or obsolete backups

Viewing stored scripts
Using RMAN with a Media Manager
Objectives
the following:
Identify how RMAN makes backups to tape
Describe the Media Management Interface
functionality
Identify the two versions of the SBT interface
Link the Oracle server to a media manager
Describe media manager issues and informational
messages
6-2
Backups to Tape
6-3
The Oracle server can only write backups to disk.

To store backups on tape, RMAN requires a media
manager.
A media manager is a vendor-supplied utility that
can backup data to sequential media.
The System Backup to Tape (SBT) API is provided
to participating vendors.
Backups to Tape
To use tape storage for database backups, RMAN requires a media manager. A media
manager is a utility that loads, labels, and unloads sequential media such as tape drives for
backing up and recovering data. Oracle Corporation publishes a media management API that
third-party vendors can use to build software that works with RMAN. To use RMAN to
make backups to sequential media such as tape, integrate media management software with
your Oracle software. Note that Oracle does not need to connect to the media management
library software when it backs up to disk.
Some media management products can manage the entire data movement between Oracle
data files and the backup devices. Such products may use technologies such as high-speed
connections between storage and media subsystems, which can remove much of the backup
load from the primary database server.
For a list of compliant vendors, and compatibility information, visit the following site:
http://www.oracle.com/database/recovery/index.html?/database/
recovery/backupsp.html
Media Manager
Media Manager architecture
Oracle Media
Server Manager
Session Library
Recovery
Manager
Recovery
Catalog
Control File
6-4
Media
Management
Server
Software
Tape Subsystem
Media Manager Architecture

The Oracle server session is the same type of server session that is used when a client such
as SQL*Plus connects to the database. The media management library (MML) represents
vendor-supplied media management software library that can interface with the Oracle
server. The Oracle server calls MML software routines to back up and restore data files to
and from media controlled by the media manager. When making backups, or restoring data,
the RMAN client connects to the target instance and directs the instance to communicate
with the media manager. No direct communication occurs between the RMAN client and the
media manager; all communication occurs on the target instance.
Media Manager Prerequisites

1. Install and configure the media management
software on the target host.
2. Ensure that non-RMAN backups of operating
system files can be made on the target database.
3. Install the third-party media management module
for integration with the Oracle server.
6-5
Media Manager Prerequisites

Before you can begin using RMAN with a media manager, you must install it and make sure
that RMAN can communicate with it. Instructions for this procedure should be available in
the media manager vendors software documentation. Depending on the product that you are
installing, the following basic steps apply:
1. Install and configure the media management software on the target host or production
network. No RMAN integration is required at this stage.
2. Ensure that you can make non-RMAN backups of operating system files on the target
database host. This step makes troubleshooting later much easier. Refer to your media
management documentation to learn how to back up files to the media manager.
3. Obtain and install the third-party media management module for integration with the
Oracle server. This module must contain the library that the Oracle server loads when
accessing the media manager.
If you have not performed the preceding steps, then do not proceed with the configuration of
media management.
Linking a Media Manager on UNIX

To correctly link the MML software to the Oracle
server:
1. Remove any old libobk.so files or links in
$ORACLE_HOME before installing the software.
2. Check the vendor documentation to determine
where the media management library is installed.
3. Change the name of the media management
library to $ORACLE_HOME/lib/libobk.so
or create a symbolic link to the library
called libobk.so.
6-6
Linking a Media Manager on UNIX

After you install the media management software, the media management library should
already be integrated with the Oracle server. You need not perform further integration.
However, you may choose to follow the procedure in this section to ensure that the media
manager is integrated correctly. Because the specifics of your media management
integration with Oracle depends on both the product as well as the operating system, this
section cannot cover all possible cases. Oracle explicitly loads the library with a
dlopen()call for each RMAN channel allocation.
On UNIX, Oracle accesses the media management library through the UNIX shared library
libobk.so. This file must exist somewhere in the system path. It is recommended that
you place libobk.so in $ORACLE_HOME/lib, which is where Oracle searches first.
Linking a Media Manager on UNIX (continued)

To integrate the media manager on UNIX:
1. If an old libobk.so symbolic link already exists in $ORACLE_HOME/lib,
then remove it before installing the media manager. For example:
$ rm $ORACLE_HOME/lib/libobk.so
2. After installation, check your media management vendor documentation to

determine where the media management library is installed. For example, suppose
that the library is installed as /vendor/lib/oracle_lib.so.
3. You either change the name of the installed media management library to
$ORACLE_HOME/lib/libobk.so, or create a symbolic link to the library
called libobk.so. For example, you can create a symbolic link to the library as
follows:
$ ln -s /vendor/lib/oracle_lib.so $ORACLE_HOME/lib/libobk.so
Alternatively, you can change the name of the library to libobk.so. For example:
$ mv /vendor/lib/oracle_lib.so
$ORACLE_HOME/lib/libobk.so
Linking a Media Manager on NT

1. If an old orasbt.dll exists in the system path,
remove it before installing the media manager.
2. After installation, check the vendor documentation
to find the media management library location.
3. If the library is not called orasbt.dll, then
rename it to %ORACLE_HOME%\bin\orasbt.dll.
6-8
Linking a Media Manager on NT

On Windows NT, Oracle accesses the MML through the library orasbt.dll. This file
must exist somewhere in the system path. Typically, the file is located in the
%ORACLE_HOME%\bin folder of the Oracle home. The dynamic-link library (DLL) is
loaded when a channel is allocated, and unloaded when the channel is released. To integrate
the media manager with RMAN on NT, follow the steps below:
1. If an orasbt.dll already exists in the system path, then remove it before installing
the media manager. For example:
C:\> del %ORACLE_HOME%\bin\orasbt.dll
2. After installation, check your media management vendor documentation to determine

where the media management library is installed. For example, suppose that the library
is installed as D:\vendor\lib\oracle_lib.dll.
3. If the installed library is not called orasbt.dll, then rename the installed media
management library to %ORACLE_HOME%\bin\orasbt.dll. For example, you
can copy the installed library as follows:
D:\> copy D:\vendor\oracle_lib.dll
%ORACLE_HOME%\bin\orasbt.dll
The orasbt.dll file does not have to be in the %ORACLE_HOME\bin folder as

long as the folder containing the library is present in the system PATH variable setting.
Testing the Media Manager Installation

2. Issue an ALLOCATE CHANNEL command.
RMAN> ALLOCATE CHANNEL c1 DEVICE TYPE sbt
2> PARMS='ENV=(NSR_SERVER=tape_srv,
3> NSR_GROUP=oracle_tapes)';
3. If an ORA-27211 error is not raised, then the

shared library has loaded successfully.
6-9
Testing the Media Manager Installation

After integrating the media management library with Oracle, test whether RMAN is able to
load the library.
2. Run the ALLOCATE CHANNEL command with the PARMS required by the media
management software. For example, run this command in a RUN block:
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS='ENV=(NSR_SERVER=tape_srv,NSR_GROUP=oracle_tapes)';
If you do not receive an error message, then Oracle successfully loaded the shared library.
However, the channel allocation can fail raising the ORA-27211 error:
RMAN-03009: failure of allocate command on c1 channel at 13:57:18
ORA-19554: error allocating device, device type: SBT_TAPE
ORA-27211: Failed to load Media Management Library
The ORA-27211 error indicates that the Oracle server was not able to load the media
management library that was installed. In this case, check your media management
installation to make sure that the library is correctly installed and retry. For any other errors,
check the trace file in USER_DUMP_DEST directory for more information.
Performing a Test Backup to Tape
Allocate a channel and issue a BACKUP command

including the correct PARMS for the tape device.
If the backup hangs, then the media manager is

probably waiting for the tape to mount.
See if there are jobs in tape mount request mode
and correct.
6-10
An ORA-19511 is usually indicative of a

configuration error.
Performing a Test Backup to Tape

After testing a channel allocation on the media manager, make a test backup. For example,
to test whether your backup goes successfully to tape, you might execute the following
command in a RUN block:
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS='ENV=(NSR_SERVER=tape_srv,NSR_GROUP=oracle_tapes)';
BACKUP DATAFILE 1;
Also, you should determine which PARMS settings are needed for the ALLOCATE
CHANNEL or CONFIGURE CHANNEL commands as well as the vendor-recommended
FORMAT string for the BACKUP command (if needed). The PARMS parameter sends
instructions to the media manager. For example, the following vendor-specific PARMS
setting instructs the media manager to back up to a volume pool that is called
oracle_tapes:
PARMS='ENV=(NSR_DATA_VOLUME_POOL=oracle_tapes)'
A hanging backup usually indicates that the media manager is waiting to mount a tape.
Check if there are any media manager jobs in the tape mount request mode and fix the
problem. An ORA-19511 or ORA-70 nnn error indicates that the media management
software is not correctly configured.
Testing Automatic Channels and MML

1. Configure a generic channel of DEVICE TYPE SBT.
2. Test by issuing a BACKUP command without a
manual channel allocation.
3. Check your configuration by running the SHOW
CHANNEL command.
RMAN> SHOW CHANNEL DEVICE TYPE sbt;
4. If successful, configure the default device to SBT.

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;
6-11
Automatic Channels and MML

Use the CONFIGURE CHANNEL command to configure automatic channel options for
device type sbt. You can use the same options for CONFIGURE CHANNEL that you used
for ALLOCATE CHANNEL earlier.
1. Configure a generic channel of DEVICE TYPE sbt. In the configuration, type all
parameters that you tested in the previous steps. For example, assume that your media
vendor requires PARMS settings as follows:
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt
2> PARMS='ENV=(NSR_SERVER=tape_svr, NSR_CLIENT=oracleclnt,
3> NSR_GROUP=oracle_tapes)' FORMAT "BACKUP_%U";
2. After configuring the channel, test the backup with the following command:
RMAN> BACKUP DEVICE TYPE sbt DATAFILE 1;
3. Check your configuration by running the following command:

RMAN> SHOW CHANNEL DEVICE TYPE sbt;
4. Configure the default device to sbt. By configuring the device to sbt, RMAN will
automatically send all backups to the media manager. For example:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
Automatic Channels and MML (continued)

5. After configuring the default device, make a test backup to determine whether it is
going through the media manager:
RMAN> BACKUP DATAFILE 1;
6. Check your configuration by running the following command:

RMAN> SHOW DEFAULT DEVICE TYPE;
7. If you use more than one media manager, then you must specify the channel
parallelism. Assume that you want to back up to your media manager by using two
tape drives in parallel. In this case, you can run the following commands:
RMAN> CONFIGURE DEVICE TYPE sbt PARALELLISM 2;
RMAN> BACKUP DATABASE; # Backup goes to tape but in two streams in parallel
(two tapes)
Default SBT Interface
The Oracle Disk SBT interface SBT_TAPE, allows

the user to write to disk.
You can use this interface to simulate tape
backups for troubleshooting purposes.
You must not use it for actual backups.
When using SBT_TAPE, specify BACKUP_DIR and
SBT_LBRARY.
RMAN>
2>
3>
4>
6-13
allocate channel c1
type 'sbt_tape'
'ENV=SBT_LIBRARY=oracle.disksbt,
(BACKUP_DIR=/your/backup/directory)';
Default SBT Interface

On platforms that support third-party media managers through the Oracle Media
Management (SBT) API, the new SBT_LIBRARY parameter controls which media
management library that RMAN uses on channels of DEVICE TYPE sbt. Use
SBT_LIBRARY in the PARMS setting of the ALLOCATE CHANNEL or CONFIGURE
CHANNEL command to specify the filename of the shared library that is to be loaded. You
can also specify SBT_LIBRARY=oracle.disksbt, which causes the server to load
Oracles disk sbt library (formerly called the dummy API). If no SBT_LIBRARY
parameter is specified in PARMS, then the Oracle server attempts to load the dynamic
libraries orasbt.dll on Windows NT and libobk.so on UNIX. If Oracle cannot
locate the library, then the server returns an error.
Note: Do not use the the default SBT interface for production backups. If a real media
manager is later installed, these backups will become unusable. Always use disk channels
for production backups to disk.
Events in a Media Manager Backup

1. When an SBT channel is allocated, RMAN
connects to the Oracle server and starts a server
session.
2. The Oracle server starts the media management
software by calling sbtinit().
3. The Oracle server calls sbtinit2() to pass
additional data to the media manager that was not
passed by sbtinit().
4. sbtbackup() is called to create the backup piece.
5. The Oracle server reads the input database files.
6-14

The current Oracle SBT API version is now 2.0. The following sequence of events occurs in
the SBT API 2.0 backup session:
1. When an SBT channel is allocated, RMAN connects to the Oracle server on the target
host and starts a server session.
2. When started, the Oracle server session initializes the media management software by
calling sbtinit(). The version of SBT API supported by the media management
software is returned. This information is displayed in the RMAN message RMAN08503 message, for example:
RMAN-08503: ... comment=API Version 2.0,MMS Version 3.2.0.0
3. After successfully calling sbtinit(), the Oracle session calls sbtinit2() to

supply additional information to the media management software that was not supplied
by sbtinit().
4. The Oracle session calls sbtbackup() to create a backup piece. In other words, the
sbtbackup() instructs the media manager to prepare to accept a data stream.
5. The Oracle server begins reading the input database files (data files, archived logs, or
control files). The data is sent to the media manager by the sbtwrite2() API call.
The sbtwrite2() function writes the data to the backup media.

6. When Oracle finishes writing the backup piece,
sbtclose() is called to close it.
7. Oracle calls sbtinfo2() to see if the backup
piece is stored in the media manager.
8. When sbtinfo2() finishes, RMAN writes the
name of the backup piece.
9. After the Oracle server sessions backs up all data,
it calls sbtend() to clean up and release
resources.
6-15
Events in a Media Manager Backup (continued)

6. When the Oracle server session finishes writing the backup piece, it calls
sbtclose2() to close it. The sbtclose2() function directs the media manager
to commit data on the backup medium.
7. Oracle calls sbtinfo2()to see whether the backup piece is stored in the media
manager database. The sbtinfo2() function requests the media manager to return
the mediumID, location, and expiration time of the backup medium on which the
backup piece is stored.
8. When sbtinfo2() finishes, RMAN writes the name of the backup piece as in the
following example:
RMAN-08045: channel ORA_SBT_TAPE_1: finished piece 1 at MAR 13
2001 08:48:12
RMAN-08503: piece handle=41ckj865_1_1 comment=API Version
2.0,MMS Version 3.2.0.0
If there is more data to be backed up, then the algorithm returns to step 4.
9. After the Oracle server sessions backs up all data, it calls sbtend() to clean up and
release resources. After sbtend() returns, the channel is released and the server
session terminates.
Events in a Media Manager Restore

1. When an SBT channel is allocated, RMAN
connects to the Oracle server and starts a server
session.
2. The Oracle server session initializes the media
management software by calling sbtinit().
3. The Oracle server calls sbtread() to read data
from the media manager library.
4. The Oracle session calls sbtrestore() to
request the backup piece from the media manager.
6-16

The sequence of events in a SBT API 2.0 restore session occur in the following order:
1. When an sbt channel is allocated, RMAN connects to the Oracle server on the target
host and starts a server session.
2. When started, the Oracle server session initializes the media management software by
calling sbtinit().
3. The Oracle server starts reading data from the media manager library by calling
sbtread().
4. The Oracle session calls the sbtrestore() function to request the backup piece
from the media manager. The sbtrestore() function instructs the media manager
to find and prepare the backup medium containing the requested backup piece. For
example, if the back up was done to tape, this function instructs the media manager to
load the tape into the tape drive and rewind it.

5. The Oracle server starts reading data from the
media manager library by calling sbtread2()
6. Oracle calls sbtclose() when it reaches the end
of the backup piece.
7. If there is more data to be restored, then the
algorithm continues from step 4.
8. After the server sessions restores all data, it calls
sbtend() to clean up and release resources.
6-17
Events in a Media Manager Restore (continued)

5. The Oracle server starts reading data from the media manager library by calling
sbtread2(). The data received from sbtread2() is written to disk.
6. When it reaches the end of the backup piece, Oracle calls sbtclose(). The
sbtclose() function instructs the media manager to stop reading the data from the
tape.
7. If there is more data to be restored, then the algorithm continues from step 4.
8. After the server session restores all data, it calls sbtend(). This function cleans up
and releases resources. After sbtend() returns, the RMAN channel is released and
the server session ends. During this step, a typical media manager library instructs the
session manager to end the restore session and unload the tapes.
Media Manager Diagnostics
sbttest
It tests whether the MML is installed, and can accept
and return an identical data stream.
sbtio.log
This is the trace file that the media management
product may use to write debugging/trace
information.
It is found in USER_DUMP_DEST, or by default on
UNIX systems in $ORACLE_HOME/rdbms/log.
6-18
Media Manager Diagnostics

Oracle provides a diagnostic tool called sbttest. This utility performs a simple test of the
media management software by acting as the Oracle database server and attempting to
communicate with the media manager. On UNIX, the sbttest utility is located in
$ORACLE_HOME/bin. Note that on platforms such as Solaris, you do not have to relink
when using sbttest. However, on other platforms, relinking may be necessary.
Troubleshooting: Media Manager or RMAN

Step 1: Is RMAN integrated with the media manager?
The ORA-27211 indicates the Oracle server session is
unable to load the media management library.
ORA-19557: device error, device
type:SBT_TAPE, device name:
ORA-27211: Failed to load Media Management
Library
6-19

If the media manager is not linked with the Oracle server, or if the Oracle server is unable to
load the media manager library, then ensure that the following requirements are met:
The media manager library name must be $ORACLE_HOME/lib/libobk.so on UNIX
or %ORACLE_HOME%\BIN\ORASBT.DLL on NT. The DLL is loaded when a channel is
allocated, and unloaded when the channel is released, so there is no need to restart the
Oracle instance. You can use the PARMS parameter SBT_LIBRARY to alter location of
the media manager library.
The following example shows a Veritas NetBackup setting:
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS='SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1,
ENV=(NB_ORA_CLASS=oracle_class)';

Step 2: Investigate the RMAN output and trace the
files.
Investigate the RMAN output for SBT errors.
Any error message referring to a sequential file is
an SBT API error.
ORA-19506: failed to create sequential file,
name="4eckrg0_1", parms=""
ORA-27007: failed to open file
ORA-19511: Error received from media manager
layer, error text:
SBT error = 7009, errno = 0, sbtopen: can't
connect with media manager
6-20
Troubleshooting: Media Manager or RMAN (continued)

You should investigate the RMAN output for SBT errors. If an error message refers to a
sequential file, then you have identified an SBT API error. In the example provided in the
slide above, the problem occurs in the SBT API because the ORA-19506 error refers to a
sequential file. On Windows NT and UNIX platforms, all errors involving the write, read,
open, or close of a sequential file indicate that an SBT function has failed.
The text after the ORA-19511 message explains the error according to the data received
from the media manager. The textual error message is only displayed if the SBT API is
version 2.0. The example below shows the failure of an SBT API 2.0 sbtbackup()
function:
ORA-19506:
parms=""
ORA-27028:
ORA-19511:
sbtbackup:
failed to create sequential file, name="4fckrhkv_1_1",

skgfqcre: sbtbackup returned error
Error received from media manager layer, error text:
Failed to open for backup. # SBT API 2.0 textual error message

It also important to look at the trace file in the USER_DUMP_DEST location. This trace
file is created by the Oracle server session process that is performing the back up. In the
trace file, the Oracle server session indicates which SBT function fails:
*** 2002-03-16 11:42:28.852
*** SESSION ID:(14.1) 2002-03-16 11:42:28.799
SKGFQ OSD: Error in function sbtopen on line 691
SKGFQ OSD: Look for SBT Trace messages in file ...log/sbtio.log
If the media manager function causes a core dump, then the trace file contains some of
the SBT functions in the stack trace. For example, if sbtinfo2() core dumps, then the
stack may look like the following:
ssexhd()+380 CALL ksedmp()+0
sigacthandler()+40 PTR_CALL 00000000
free_sbtinfo2_mem PTR_CALL 00000000
sbtinfo2()+744 CALL free_sbtinfo2_mem
skgfgsm()+244 PTR_CALL 00000000
skgfgsi()+184 CALL skgfgsm()+0
skgfcls()+888 CALL skgfgsi()+0
kgffsubmit()+12928 CALL skgfcls()+0
What was happening at the time of failure? Remember, the sbtinfo2() function
requests the media manager to return the mediumID, location, and expiration time of the
backup medium on which the backup piece is stored.

Step 3: Perform a backup to disk and the SBT disk
library.
Back up to disk with FORMAT '/dev/null'
RUN {
ALLOCATE CHANNEL tst TYPE DISK FORMAT '/dev/null';
BACKUP DATABASE;
}
If successful, back up to the SBT disk interface.

RUN {
ALLOCATE CHANNEL tst TYPE SBT FORMAT '%U'
PARMS='ENV=(BACKUP_DIR=/backup_disk)';
BACKUP DATABASE;
}
6-22

In some cases, you may need to isolate the problem to the MML or the RMAN. The easiest
test method is to back up to disk with the FORMAT '/dev/null' (UNIX only). This
indicates that RMAN is functioning correctly. However, this test does not have the same
code path as an SBT API backup. So next, try the backup with the SBT disk library that is
provided by Oracle. For example:
RUN {
ALLOCATE CHANNEL tst TYPE SBT FORMAT '%U'
PARMS='ENV=(BACKUP_DIR=/backup)';
BACKUP DATABASE; }
The SBT disk library provided by Oracle can be loaded without removing the existing MML
and the library can back up to /dev/null. For example:
RUN {
ALLOCATE CHANNEL tst TYPE SBT FORMAT '/dev/null'
PARMS='SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';
BACKUP DATABASE; }
These tests are important when you suspect that the MML is causing problems in Oracle
server functions.

Step 4: Trace the server session to determine if the
error is occurring within the media manager.
Start the backup with the channel option TRACE=1.
RUN {
ALLOCATE CHANNEL tst TYPE DISK TRACE=1 FORMAT
'/dev/null';
BACKUP DATABASE;
}
6-23
The trace is created in the USER_DUMP_DEST

directory.

If the Oracle server session core dump or hangs, verify whether the core dump or hang
occurs inside the media manager library. If you start the backup with channel option
TRACE=1, then Oracle writes all entering and exiting of the SBT API functions in the trace,
which is created in the USER_DUMP_DEST directory.
The trace output may look like the following:
*** SESSION ID:(9.17) 2002-03-16 13:50:21.945
skgfalo(se=0x815ff8c8, ctx=0x262bf98, dev=0x264861c, devparms=,
flags=33554432)
skgfidev(se=0x815ff8c8 ctx=0x262bf98, dev=0x264861c)
entering sbtinit on line 2203
return from sbtinit on line 2213
skgfqsbi(ctx=0x262bf98, vtapi=API Version 1.1, id=MMS Version
2.2.0.1)
skgfqcre(se=0x815ff8c8, ctx=0x262bf98, dev=0x264861c,
file=0x2647f08, fparms=, flags=0x0)
entering sbtopen on line 683
return from sbtopen on line 704
skgfwrt(ctx=0x262bf98, file=0x2647f08, iosb=0x2647cf4,

buf=0x815b0000, numblks=1)
skgfwrt(data=13020000 00000001 0003A1B1 00000104)
entering sbtwrite on line 903
...
The trace output indicates exactly which are the environment variables that are set in the
Oracle Server session. For example, if the channel has the option
PARMS=ENV=(NB_ORA_CLASS=class1), then the trace output displays the
following::
skgfidev(): processing: ENV=(NB_ORA_CLASS=fdfa)
skgfidev(): setting environment variable: NB_ORA_CLASS=fdfa
Running a backup with the TRACE=1 option also indicates whether a function is hanging.
For example:
skgfwrt(ctx=0x262bf98, file=0x2647f08, iosb=0x2647cf4,
buf=0x815b0000, numblks=1)
skgfwrt(data=13020000 00000001 0003A1B1 00000104)
entering sbtwrite on line 903
If there is no more information logged after this, then the function sbtwrite is hung.
Note: The other possible trace levels are 0 and 2. A trace level 0 traces all error
conditions that result in a return code of -1 from an SBT function, except
SBT_ERROR_EOF and SBT_ERROR_NOTFOUND, which are handled by the client. A
trace level 2 traces the entry and exit from each SBT function, the value of all function
parameters, and the first 32 bytes of each read/write buffer, in hexadecimal. The read
buffer is traced upon function entry and the read buffer is traced after it has been filled
with data, before returning to the client.

Step 5: Isolate the server process from the SBT library.
The media manager may be interfering with the
server session.
Isolate the processes that are responsible for
reading and writing.
Enable the BACKUP_TAPE_IO_SLAVES initialization
parameter.
6-25

The media manager can interfere with the reading of files performed by the Oracle server
session. This problem occurs because the media manager library is loaded by the Oracle
server process and the library shares all operating system resources that are dedicated to the
Oracle server process. For example, on rare occasions, the MML can mistakenly close data
file descriptors that are opened by Oracle code in the server process.
You should attempt to separate the process that is responsible for reading from the process
that is responsible for writing (performed by SBT functions in the media management
library). You can separate these processes by setting the BACKUP_TAPE_IO_SLAVES
initialization parameter to True.
Troubleshooting Media Manager
6-26
Determine if operating system backups using the

media manager work.
Determine which API function fails.
Investigate RMAN output.
Investigate the sbtio.log.
Troubleshooting Media Manager

Next, you should test whether the media manager operating system backup module can back
up database files without RMAN. This test helps to determine whether the basic components
of the media manager are correctly installed and configured. If the media manager operating
system backup does not work, then the problem is not related to the Oracle media manager
module. Rather, the problem is in the media manager installation and configuration.
You can identify the problematic SBT API function in both the Oracle trace file (located in
the USER_DUMP_DEST directory) as well as in the RMAN output:
ORA-19511: Error received from media manager layer, error text:
SBT error 7009, errno = 0, sbtopen: can't connect with media
manager
The media manager library can return a text line describing the error. The error text is
written to the RMAN output. Below is an error text line returned by the NetBackup
implementation of SBT API 2.0:
sbtbackup: Failed to open for backup.
Troubleshooting Media Manager (continued)

In some cases, the media manager library returns an undocumented error code. In this
case, Oracle displays the following:
ORA-19506: failed to create sequential file, name="58cl3cdo_1_1",
parms=""
Unknown SBT error code = 0, errno = 0
The media manager library creates the log file sbtio.log. This file is not written by
Oracle. The media manager should write a detailed description of the error in this file.
However, some media managers (for example, NetBackup) do not write to this file at all.
Here is an example of sbtio.log written by Legato LSM:
(24677) LSM 2.2.0.1: 03/19/02 10:26:27 Sbtopen: unable to start
save session with server dlsun1556:
There is no pool named 'fdfa'.
From the preceding text it is obvious that the backup failed because there is no data pool.
The messages that are written in the media manager monitor and logs are also very
helpful if you need support from the media manager software vendor.
SBTINIT and SBTINIT2 Function Errors
These functions are responsible for initializing the

media manager library.
The typical errors might include:
Faulty installation of the media manager
File permissions are incorrect
Insufficient resources to initialize the library
6-28
SBTINIT and SBTINIT2 Function Errors

The sbtinit()and sbtinit2() functions are responsible for initializing the media
manager library. An error that occurs when calling sbtinit() or sbtinit2() indicates
that the media manager library cannot initialize itself.
The common implementations of sbtinit() and sbtinit2() like NetBackup, Legato,
and OmniBack II, initialize only the internal structures of the media management library.
Consequently, errors returned while calling these functions are uncommon. If the
sbtinit() or the sbtinit2() function fails, then the media manager integration
module was not properly installed. For example, the permissions of the configuration files
may be incorrect. The other more remote possibility is that not enough resources are
available for initialization. If the media manager library is not installed in the right directory
or is not linked with the Oracle binaries, then the server sessions call sbtinit() of the
Oracle disk SBT API library. In this case, the following error is reported:
ORA-27000: skgfqsbi: failed to initialize storage subsystem
(SBT)layer
ORA-19511: SBT error = 4110, errno = 0, BACKUP_DIR environment
variable is not set
SBTINIT and SBTINIT2 Function Errors (continued)

RMAN-10031: ORA-19624 occurred during call to
DBMS_BACKUP_RESTORE.DEVICEALLOCATE
At first glance, it would appear that this is a media manager error and it indeed is.
However, if you look closely, you will see that the BACKUP_DIR environment variable
was improperly set. This indicates that this error came from Oracle Corporations
dummy SBT module using the SBT_DISK device.
SBTOPEN or SBTBACKUP Failures
The SBTOPEN()and SBTBACKUP() functions

should create the backup piece and start the
backup session.
The type of failures might include:
Incorrect configuration of the media manager
Incorrect PARMS environment variables
Server session owner may not be a recognized user
in the media manager configuration
6-30
SBTOPEN or SBTBACKUP Failures

These two functions should create a backup piece at the request of RMAN and start the
media manager backup session. If the sbtopen() or the sbtbackup() function fails
during the backup, then the media manager cannot create a backup piece or start a backup
session. The overwhelming majority of problems are caused by incorrect configuration of
the media manager. The following situations are common:
The environment variables that are specified in the PARMS option are incorrect. For
example, in the case of Legato NetWorker, an incorrect media pool might be specified.
The pool, class, or some other media manager configuration entity are not correctly
configured for Oracle backups. For example, in the case of NetBackup, the Class
specified by NB_ORA_CLASS is not an Oracle class. In the case of Legato, the media
pool specified by NSR_DATA_VOLUME_POOL does not exist.
The UNIX or NT user owning the Oracle server sessions is not a valid user in the
media manager configuration. For example, in case of OmniBack II, the user owning
the Oracle session must be included in the OmniBack II UserList.
The media manager library cannot connect to the media manager server daemon
because it is not started.
SBTOPEN or SBTRESTORE Failures
The SBTOPEN() and SBTRESTORE() functions are

called to retrieve an existing backup piece.
The typical failures might include:
The backup piece is not in the media management
database.
The media manager does not have the proper
permissions for the restore.
6-31
Permission errors are common in Oracle Real

Application Clusters environments.
SBTOPEN or SBTRESTORE Failures

The sbtopen() and sbtresotre() functions are used to retrieve an existing backup
piece. If the sbtopen() or the sbtrestore() function fails during the restore, then the
media manager cannot find the requested backup piece or it cannot start the restore session.
There are two primary reasons for these functions to fail during a restore:
The backup piece does not exist in the media management database. For example, the
tape containing the backup is deleted from the media manager database. The easiest
way to check this problem is to look for the backup piece in the media management
database.
The media management library does not have the permissions required to restore the
requested object. This error is common in Real Application Cluster environments in
which each Oracle instance should have access to data that is backed up with other
nodes. For example, the first node in the cluster configurations backs up a backup
piece. During the restore, the second node can ask the media manager library for the
same backup piece. The media manager daemon can be configured in such a way that
node 2 is not allowed to restore the backup piece that is backed up with other nodes.
SBTWRITE or SBTREAD Failures
The SBTWRITE() and SBTREAD() functions

transfer data from the server session to the media
manager library.
The typical failures include:
An I/O error happens while reading from or writing
to the backup media.
The user aborted the media manager backup
session.
The link between the media manager library and the
media manager session is broken.
6-32
SBTWRITE or SBTREAD Failures

The sbtwrite() or sbtread() functions are responsible for the transfer of data from
the Oracle server session to the media manager library. If the sbtwrite() or the
sbtread() function fails during the backup, then the media manager cannot write data to
the backup media (for example, to tape). If the sbtwrite() or sbtwrite2()function
fails during the restore, then the media manager cannot read data from a backup media and
sbtread() will also fail. The following are the primary reasons for these functions to fail
during a backup or a restore:
An I/O error occurs while reading from or writing to the backup media.
The media manager session was aborted by a media manager operator.
The communication link between the media manager library and the media manager
session is broken.
SBT API Return Codes
6-33
The SBT API Version 2 function errors have been

greatly reduced.
The new functions return a simple error code and
a textual message.
The errors that were returned from multiple
functions have been consolidated into a single
error code.
The version 1.1 codes are retained for backward
compatibility only.
Return Codes for SBT API Version 2

In SBT API version 2, the number of different types of errors that may be returned from API
functions has been greatly reduced. The new functions return an error stating that the API
function failed, and provide a textual description of the failure. The common error
conditions that can be returned from more than one function have been consolidated into a
single error code. All the version 1.1 error codes have been retained for backward
compatibility. The following is the list of return codes for SBT API Version 2:
#define SBT_ERROR_OPERATOR 7500 /*Operator intervention requested*/
#define SBT_ERROR_MM 7501 /* Catch-all media manager error */
#define SBT_ERROR_NOTFOUND 7502 /* File Not Found */
#define SBT_ERROR_EXISTS 7503 /* File already exists */
#define SBT_ERROR_EOF 7504 /* End of File */
#define SBT_ERROR_NOPROXY 7505 /* cant proxy copy the file */
#define SBT_ERROR_NOWORK 7506 /* no proxy work in progress */
/* error codes for sbtinit */
#define SBTINIT_ERROR_ARG 7110 /* invalid argument(s) */
#define SBTINIT_ERROR_SYS 7111 /* OS error */
For example, if a function returns SBT_ERROR_MM, then the server session calls
sbterror() to get the error description. The text is then reported (not the numeric code) in
an ORA-19511. Note that some of the return codes are not errors at all like the 7504.
Vendor Differences
There are several media manager issues existing that
must be taken into consideration:
Files created by the Oracle server may be larger
than those supported by the media manager
Include a SET LIMIT clause in the channel
configuration command
ALLOCATE CHANNEL C1 DEVICE TYPE sbt
...
SET LIMIT CHANNEL C1 KBYTES=1000000;
6-34
Uniqueness of backup piece name

Restoring to another node
Vendor Differences
A problem that can be encountered with making backups to tape is the backup file size that
is created by the Oracle server may be much larger than the file size that is supported by the
media manager. This is because RMAN multiplexes multiple input files into one output file.
Some media managers may not return errors in this situation, but fail silently. For this
reason, it is important to determine the maximum file size supported for your media
management software, then use the RMAN keyword KBYTES in a SET LIMIT CHANNEL
command to limit the output file size to be within the supported size for your media
management software.
When writing backups to a media manager, use the substitution variables that are provided
by RMAN to generate unique backup piece names. If the FORMAT parameter is not
specified, then RMAN automatically generates a unique filename using the %U substitution
variable. Make sure that your media manager supports filenames that are generated by %U if
you intend to use the automatic file naming of RMAN. The media manager considers the
name of the backup piece as the filename that is backed up, so this name must be unique in
the media manager catalog. In addition, some media managers only support a 14-character
backup piece name. If you need to restore to a different node, then be sure of this
functionality and also of any license limitations. Check the media management
documentation to be sure.
Summary
RMAN makes backups to tape
Describe the Media Management Interface
functionality
Identify the two versions of the SBT interface
Link the Oracle server to a media manager
Describe media manager issues and informational
messages
6-35
Practice Overview:
Using RMAN with a Media Manager
Configuring RMAN to use a media manager
Investigating media manager errors
6-36
Debugging RMAN
Objectives
the following:
Debug RMAN errors
Debug media manager errors
Debug OS errors occurring in the RMAN stack
7-2
RMAN Message Output

Information about RMAN troubleshooting can be found
in the:
RMAN command output
RMAN trace file
Alert log
Oracle server trace file
sbtio.log file
7-3
RMAN Message Output

The RMAN command output contains actions that are relevant to the RMAN job as well as
error messages that are generated by RMAN, the server, and the media vendor. RMAN error
messages have an RMAN-nnnn prefix. The output is displayed to the terminal (standard
output) but can be written to a file by defining the LOG option or by shell redirection..
The RMAN trace file contains DEBUG output and is used only when the TRACE command
option is used.
The sbtio.log file contains vendor-specific information that is written by the media
management software and can be found in USER_DUMP_DEST. Note that this log does not
contain Oracle server or RMAN errors.
The Oracle trace file contains detailed output that is generated by Oracle server processes.
This file is created when an ORA-600 or ORA-3113 (following an ORA-7445) error
message occurs, whenever RMAN cannot allocate a channel, and when the media
management library fails to load. It can be found in USER_DUMP_DEST.
The alert log contains a chronological log of errors, initialization parameter settings, and
administration operations. Because it records values for overwritten control file records, it
can be useful for RMAN maintenance when operating without a recovery catalog.
The DEBUG Option
The DEBUG option is used to:

View the PL/SQL that is generated
Determine precisely where an RMAN command is
hanging or faulting
The DEBUG option is set in an RMAN command

line, at the RMAN prompt or within a run block.
The DEBUG option creates an enormous amount of
output, so redirect the output to a trace file:
$ rman target / catalog rman/rman
debug trace trace.log
7-4
The DEBUG Option

The DEBUG option displays all SQL statements that are executed during RMAN
compilations and the results of these executions. Any information that is generated by the
recovery catalog PL/SQL packages is also displayed. In the following example, the DEBUG
output is written during the backup of data file 3, but not data file 4:
RMAN> run {
debug on;
allocate channel c1 type disk;
backup datafile 3;
debug off;
backup datafile 4; }
Remember that the DEBUG output can be voluminous, so make sure that you have adequate
disk space for the trace file. This simple backup session that does not generate any errors
creates a trace file that is almost half megabyte in size:
$ rman target / catalog rman/rman debug trace sample.log
RMAN> host "ls l sample.log";
-rw-r--r-1 user02
dba
576270 Apr 6 10:38 sample.log
host command complete
RMAN Code Layer Error Numbers
7-5
5000-5499
RESTORE or RECOVER compilation errors
5500-5999
DUPLICATE compilation errors
6000-6999
General compilation errors
7000-7999
General execution manager
8000-8999
Generated PL/SQL errors and messages
10000-10999
Execution manager server side errors
12000-12999
Catalog package diagnostics
RMAN Code Layer Error Numbers

In the RMAN message stack, you will find errors that are prefixed with RMAN-nnn, ORAnnn, and finally errors that are preceded by the line Additional information. The
RMAN error codes are arranged in the following ranges:
0550 - 0999
Command line interpreter
1000 - 1999
Keyword analyzer
2000 - 2999
Syntax analyzer
3000 - 3999
Main layer
4000 - 4999
Services layer
5000 - 5499
Compilation of RESTORE or RECOVER
5500 - 5999
Compilation of DUPLICATE
6000 - 6999
General compilation
7000 - 7999
General execution
8000 - 8999
PL/SQL programs
9000 - 9999
Low-level keyword analyzer
10000 - 10999
Server-side execution
11000 - 11999
Interface errors between PL/SQL and RMAN
12000 - 12999
Recovery Catalog packages
Media Manager Error Numbers

Media manager error ranges:
7000-7012 SBTOPEN
7020-7025 SBTCLOSE
7040-7044 SBTWRITE
7060-7065 SBTREAD
7080-7086 SBTREMOVE
7090-7095 SBTINFO
7110-7111 SBTINIT
7-6
Media Manager Error Numbers

When RMAN logs errors that occur through the media management API, RMAN returns an
error message number with the Additional information: prefix. The media
manager error codes are ranged by SBT function. A complete list of media manager error
codes can be found in Appendix A. The following is an example of the message format:
SBT error = 7005, errno = 2, sbtopen: system error
Interpreting RMAN Error Stacks
Read the stack from bottom to top.

Look for Additional information.
The RMAN-03009 identifies the failed command.
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03009:
===========================================
======= ERROR MESSAGE STACK FOLLOWS =======
===========================================
failure of backup command on c1 channel at
09/04/2001 13:18:19
ORA-19506: failed to create sequential file,
name="07d36ecp_1_1", parms=""
ORA-19511: Error from media manager layer,error text:
7-7
Interpreting RMAN Error Stacks

Because of the amount of data that RMAN logs, you may find it difficult to identify the
useful messages in the RMAN error stack. Note the following tips and suggestions:
Because many of the messages in the error stack are not meaningful for
troubleshooting, try to identify the one or two errors that are most important.
Check for a line that says Additional information followed by an integer. This
line indicates a media management error. The integer that follows refers to a code that
is explained in the text of the error message.
Read the messages from bottom to top because this is the order in which RMAN issues
the messages. The last one or two errors that are displayed in the stack are often
informative.
Look for the RMAN-03002 or RMAN-03009 message immediately following the
banner. The RMAN-03009 is the same as RMAN-03002 but includes the channel ID.
If the failure is related to an RMAN command, then these messages indicate which
command failed. The syntax errors generate an RMAN-00558 error.
Identify the basic type of error according to the error range chart on page 5. If the error
is still unclear, then refer to Oracle9i Database Error Messages for more details.
The example shown in the slide above is a problem that is related to the media manager
Looking at Appendix A, it can be determined that the 7005 error is related to a busy or
defective tape device.
Interpreting RMAN Errors
Starting backup at 06-APR-02

allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=15 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
RMAN-00571: ========================================
RMAN-00569: ===== ERROR MESSAGE STACK FOLLOWS ======
RMAN-00571: ========================================
RMAN-03002: failure of backup command at 04/06/2002
15:32:42
RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name SANPLE
7-8
Interpreting RMAN Errors

Assume that a backup of the SAMPLE tablespace was attempted. The resultant output is
shown in the slide above. The RMAN-03002 error indicates that an RMAN command has
failed, the BACKUP command, to be specific. When you look at the last two messages in the
stack first, the reason for the command failure is obvious: no tablespace by the name
SANPLE appears in the recovery catalog because the name was mistyped. Another
interesting note here is the warning that is issued when the two channels were allocated for
the backup. As can be seen from the output, the devices were configured to use the Oracle
test disk API to simulate an SBT tape device. Remember that this media manager interface
is provided by Oracle for testing only. The actual backup and recovery by using the
oracle.disksbt library is not recommended or supported.
Interpreting Server Errors
RMAN> RECOVER TABLESPACE SAMPLE;

Starting recover at 04-APR-02
using channel ORA_DISK_1
starting media recovery
media recovery failed
RMAN-00571: ===========================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS =======
RMAN-00571: ===========================================
RMAN-03002: failure of recover at 04/06/2002 10:12:22
RMAN-11003: failure during parse/execution of SQL
statement: alter database recover if
needed tablespace SAMPLE
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 8 - file is in use
or recovery
ORA-01110:data file 7: '/u01/ORADATA/sample01.dbf'
7-9
Interpreting Server Errors

Assume that an attempt to recover the SAMPLE tablespace was initiated. The RESTORE
fails and the resultant output is shown above. What is the cause of the failure?
The error stack is read from bottom to top, as suggested. The ORA-01110 message
explains that there was a problem with the recovery of the datafile sample01.dbf. The
second error indicates that Oracle cannot recover the data file because it is in use or has
already being recovered. The remaining RMAN errors indicate that the recovery session was
cancelled due to the server errors. If you assume that this data file was not previously being
recovered, then the problem must be that the data file is online and needs to be taken offline
and recovered.
The sbttest Utility
The sbttest utility emulates the Oracle server

and tries to communicate with the media manager.
sbttest creates a file and backs it up to the media
manager.
sbttest reads the file to see if it was properly
backed up.
Create a backup file called testfile.f and write

the trace output to sbtio.log:
$ sbttest testfile.f -trace sbtio.log
7-10
The sbttest Utility

On UNIX platforms, Oracle ships a utility called sbttest. This diagnostic tool is used to
test the SBT interface of the third-party vendor. It works by emulating the Oracle server and
initiating a backup by using the installed SBT library. If the program runs without any error,
then it returns a 0. This indicates that the media manager software is installed and can accept
a data stream and return the same data when requested. If any error is encountered, then
sbttest returns a -1. This means the media management software is not installed or
configured correctly. The sbttest utility is found in $ORACLE_HOME/bin. Type
sbttest with no arguments and you should see the command documentation. The
example in the slide above shows the syntax to create a test file called testfile.f and
write the output to sbtio.log. When examining the output, if the program encounters an
error, it provides messages describing the failure. If Oracle cannot find the library
libobk.so, then you will see an output that may look like:
$ sbttest testfile.f -trace sbtio.log
The sbt function pointers are loaded from oracle.static

library.libobk.so could not be loaded. Check that it is
installed.
Checking Backup and Restore Progress

Run this query to check the progress of a backup or
restore:
SQL>
2
3
4
5
6
7
SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,

ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
FROM V$SESSION_LONGOPS
WHERE OPNAME LIKE 'RMAN%'
AND OPNAME NOT LIKE '%aggregate%'
AND TOTALWORK != 0
AND SOFAR <> TOTALWORK;
SID SERIAL# CONTEXT

SOFAR TOTALWORK %_COMPLETE
--- ------- ------- ------- --------- ---------13
75
1
9470
15360
61.65
12
81
1
15871
28160
56.36
7-11
Checking Backup and Restore Progress

Monitor the progress of backups, copies, and restores by querying the view
V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOPS:
detail and aggregate rows. Detail rows describe the files that are being processed by one job
step, whereas aggregate rows describe the files that are processed by all job steps in an
RMAN command. A job step is the creation or restore of one backup set or data file copy.
The detail rows are updated with every buffer that is read or written during the backup step,
so their granularity of update is small. The aggregate rows are updated when each job step is
completed, so their granularity of update is large. The important columns in
V$SESSION_LONGOPS for RMAN include:
SID: The server session ID corresponding to an RMAN channel.
SERIAL# : The server session serial number. This value changes each time a server
session is reused.
OPNAME: A text description of the row. Detail rows include RMAN:datafile copy,
RMAN: full datafile backup, and RMAN: full datafile restore.
CONTEXT: For backup output rows, this value is 2. For all the other rows except proxy
copy (which does not update this column), the value is 1.
Checking Backup and Restore Progress (continued)
SOFAR: For image copies, the number of blocks that have been read. For backup input
rows, the number of blocks that have been read from the files that are being backed up.
For backup output rows, the number of blocks that have been written to the backup
piece. For restores, the number of blocks that have been processed to the files that are
being restored in this one job step. For proxy copies, the number of files that have been
copied.
TOTALWORK: For image copies, the total number of blocks in the file. For backup
input rows, the total number of blocks to be read from all files that are processed in
this job step. For backup output rows, the value is 0 because RMAN does not know
how many blocks that it will write into any backup piece. For restores, the total
number of blocks in all files restored in this job step. For proxy copies, the total
number of files to be copied in this job step.
Monitoring the Media Manager

To monitor the SBT events, run the following query:
SQL>
SQL>
SQL>
SQL>
SQL>
2
3
4
5
6
COLUMN EVENT FORMAT a10

COLUMN SECONDS_IN_WAIT FORMAT 999
COLUMN STATE FORMAT a20
COLUMN CLIENT_INFO FORMAT a30
SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,
STATE, CLIENT_INFO
FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE sw.EVENT LIKE 'sbt%'
AND s.SID=sw.SID
AND s.PADDR=p.ADDR;
SPID EVENT
SECWAIT STATE
CLIENT_INFO
---- --------- ------- ------- --------------------------8642 sbtbackup
600 WAITING rman channel=ORA_SBT_TAPE_1
7-13
Monitoring the Media Manager

You can use the event names in the dynamic performance event views to monitor RMAN
calls to the media management API. The event names have one-to-one correspondence with
the SBT functions such as sbtinit(), sbtopen(), sbtread(), and so on.
Before making a call to any of the functions in the media management API, the server adds
a row in V$SESSION_WAIT, with the STATE column including the string WAIT. The
V$SESSION_WAIT.SECONDS_IN_WAIT column shows the number of seconds that the
server has been waiting for this call to return. After an sbt function is returned from the
media manager, this row disappears.
A row in V$SESSION_WAIT corresponding to an sbt event name does not indicate a
problem, because the server updates these rows at run time. The rows appear and disappear
as calls are made and returned. However, if the SECONDS_IN_WAIT column is high, then
the media manager may be hung.
In the query shown in the slide above, note that RMAN has been waiting for the
sbtbackup function to return for 10 minutes (600/60).
Monitoring RMAN Sessions
To identify the relationship between server

sessions and RMAN channels, query V$SESSION
and V$PROCESS.
If you are monitoring multiple sessions, then set
COMMAND ID after allocating channels and back up
the object.
SQL>
SQL>
SQL>
SQL>
2
3
4
7-14

COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999
SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM V$PROCESS p, V$SESSION s
WHERE p.ADDR = s.PADDR
AND CLIENT_INFO LIKE 'rman%';
Monitoring RMAN Sessions

To identify which server sessions correspond to which RMAN channels, you can query
V$SESSION and V$PROCESS. The SPID column of V$PROCESS identifies the operating
system ID number for the process or the thread. On UNIX, the SPID column shows the
process ID, on NT the SPID column shows the thread ID. There are two basic methods for
obtaining this information, depending on whether you have multiple RMAN sessions active
concurrently. When only one RMAN session is active, execute the following query on the
target database while the RMAN job is running:
SQL>
SQL>
SQL>
SQL>
2
3
4
SID
---15
13

COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999
SELECT s.SID, p.SPID, s.CLIENT_INFO
AND CLIENT_INFO LIKE 'rman%';
SPID
CLIENT_INFO
------------ -----------------------------2714
rman channel=ORA_SBT_TAPE_1
2715
Monitoring RMAN Sessions (continued)

When multiple RMAN sessions are running, it will help to correlate a process with a channel
during a backup by using the SET COMMAND ID command as shown below:
1. In each session, set the COMMAND ID to a different value after allocating the channels
and then back up the desired object. For example, enter the following in session 1:
RUN
{
ALLOCATE CHANNEL c1 TYPE sbt;
SET COMMAND ID TO 'sess1';
BACKUP DATABASE;
}
Set the command ID to a string such as sess2 in the job running in session 2:
RUN
{
ALLOCATE CHANNEL c1 TYPE sbt;
SET COMMAND ID TO 'sess2';
BACKUP DATABASE;
}
2. Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS
views while the RMAN job is being executed. For example, enter:
SELECT SID, SPID, CLIENT_INFO
AND CLIENT_INFO LIKE '%id=sess%';
If you run the SET COMMAND ID command in the RMAN job, then the
CLIENT_INFO column displays in the following format:
id= command_id,rman channel= channel_id
For example, the following shows a sample output:

SID SPID CLIENT_INFO
---- ------------ -----------------------------11 8358 id=sess1
15 8638 id=sess2
14 8374 id=sess1,rman channel=c1
9 8642 id=sess2,rman channel=c1
Determining Which Data Files Require

Recovery
Query V$RECOVER_FILE to determine:

Which files need to be recovered
Why the files need recovery
The beginning SCN and the time needed for
recovery
SQL> SELECT * FROM V$RECOVER_FILE

FILE# ONLINE ONLINE_ ERROR
CHANGE# TIME
----- ------- ------- -------------- ------- ---4 ONLINE ONLINE FILE NOT FOUND
0
5 ONLINE ONLINE FILE NOT FOUND
0
8 OFFLINE OFFLINE OFFLINE
0
7-16
Query V$DATAFILE and V$TABLESPACE to get the

file and the tablespace names.
Determining Which Data Files Require Recovery

You can often use the dynamic performance view V$RECOVER_FILE to determine which
are the files that need to be recovered and why they need to be recovered.
SQL> SELECT * FROM V$RECOVER_FILE
FILE# ONLINE ONLINE_ ERROR
----- ------- ------- --------------4 ONLINE ONLINE FILE NOT FOUND
5 ONLINE ONLINE FILE NOT FOUND
8 OFFLINE OFFLINE OFFLINE
CHANGE#
---------0
0
0
TIME
-------
Query V$DATAFILE and V$TABLESPACE to obtain filenames and tablespace names

for data files requiring recovery. For example, enter:
SQL> SELECT d.NAME, t.NAME FROM V$DATAFILE d, V$TABLESPACE t
2 WHERE t.TS# = d.TS#
3 AND d.FILE# IN (4,5,8); # use values obtained from V$RECOVER_FILE
NAME
---------------------------------/oracle/oradata/trgt/drsys01.dbf
/oracle/oradata/trgt/example01.dbf
/oracle/oradata/trgt/users01.dbf
NAME
--------------DRSYS
EXAMPLE
USERS
Insufficient Privileges
The ORA-1031 error indicates that an attempted

operation is not allowed for the specified user.
Determine the database that is returning the error:
Is this the target, catalog, or auxiliary instance?
Connect to each of the databases separately to
confirm:
$ rman
RMAN> connect target /
RMAN> connect catalog rman_user/pswd@catalog
RMAN> connect auxiliary sys/paswd@aux
7-17
Insufficient Privileges
The RMAN user that was created for the recovery catalog owner needs to be granted the
privileges that are necessary for catalog ownership. Connect to the recovery catalog database
and grant RECOVERY_CATALOG_OWNER to the RMAN user:
SQL> connect system/manager
SQL> grant RECOVERY_CATALOG_OWNER to rman;
Insufficient privileges at the target database is the most common source of the ORA-1031
error. RMAN appends as sysdba to every target connection, so the user must have sysdba
privileges. Before troubleshooting the error at the target, find out where they are running
RMANfrom the target database software installation, or from a different ORACLE_HOME,
or from a different system altogether.
When connecting locally to the target database, the user must be a member of the operating
system group that is responsible for managing SYSDBA privileges, usually DBA. If an
ORA-1031 is logged when connecting locally, then make sure the username that is being
used is a member of the DBA group. When connecting remotely to the target database, you
must specify a username and password, along with a TNS alias, to connect to the target
database.
Insufficient Privileges (continued)

Whenever the listener is being used to make a SYSDBA connection, a password file must be
used at the target instance.
The password file exists as:
%ORACLE_HOME%\database\pwdSID.ora on Windows NT
$ORACLE_HOME/dbs/orapwSID on UNIX
For a password file to be used, the REMOTE_LOGIN_PASSWORDFILE initialization
parameter must be set to SHARED or EXCLUSIVE for the target instance (it is
inconsequential at the catalog database). The password file can be built or rebuilt by using
the command line utility orapwd.
$ orapwd file=$ORACLE_HOME/dbs/orapwSID password=Asecret1
UNIX Tape Backup Failure

The media manager has been linked to Oracle, but
cannot perform backups to SBT_TAPE.
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03002:
==========================================
======ERROR MESSAGE STACK FOLLOWS ========
==========================================
failure of backup command at 04/07/2002
15:42:22
ORA-19554: error allocating device, device type:
SBT_TAPE, device name:
ORA-27000: skgfqsbi: failed to initialize storage
subsystem Additional information: 4110
ORA-19511: Error received from media manager layer,
error text: SBT error = 4110, errno = 0, Oracle Test
Disk API: BACKUP_DIR environment variable is not set
7-19
UNIX Tape Backup Failure

When the media management software is not linked correctly, the most common error is an
ORA-19511 and a 4110 media manager return code. The 4110 error code is issued because
the BACKUP_DIR environment variable is not set for the channel that is servicing the
backup. This indicates that Oracle is linked to the dummy API (oracle.disksbt)
instead of the media manager API. If the user was using the dummy API for testing, then the
BACKUP_DIR location must be set by using the PARMS parameter of the ALLOCATE
CHANNEL command. Otherwise, the media manager was improperly linked.
Issue the SHOW CHANNEL command to look at the tape device settings.
RMAN> show channel;
CONFIGURE CHANNEL DEVICE TYPE DISK RATE 5 M FORMAT
"$HOME/ORADATA/u06/%U" MAXOPENFILES 20;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'SBT_LIBRARY=oracle.disksbt';
This particular example shows the SBT_TAPE device is indeed attempting to use the
dummy disk API, which is not supported for actual backups and the required parameter for
this library; BACKUP_DIR is not defined, causing the 4110.
UNIX Tape Backup Failure (continued)

The easiest way to fix this problem is to use the SBT_LIBRARY option of the CONFIGURE
command to properly define the channel and load the proper library:
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'SBT_LIBRARY=vendors_library';
NT Tape Backup Failure
Media manager has been installed on NT, but does

one of the following when backing up to
SBT_TAPE:
Backs up to the $ORACLE_HOME/database
directory on disk
Returns an SBT error of 4110
Fails to perform the backup
Look for an RMAN-08503 in the RMAN log.

RMAN-08503:comment=API Version 1.0,
MMS Version 1.0.1.2
RMAN-008526: channel tst WARNING: Oracle Test Disk
API
7-21
NT Tape Backup Failure

The symptoms on NT might manifest themselves in one of the following ways:
The backup fails entirely, a 4110 is possibly issued.
The user specifies 'sbt_tape', the backup succeeds but it is written to DISK.
The evidence that the vendor interface is not used can be found in the RMAN log. Look for
an RMAN-08503. This usually means that the default Oracle test disk API software is being
used. The reasons for why the backups are not written to tape when SBT_TAPE is used
include:
Oracle cannot find the library to load, so it uses the dummy disk API instead. Windows
NT searches for a DLL called orasbt.dll in its default directory path (our
developers recommend to the BSP members that they put their library in the
SYSTEM32 system directory).
There is an error in the vendors DLL. Either the DllMain() function returned an
error, or the vendor did not implement all the SBT functions.
The loadsbt.exe utility can be used to diagnose why the DLL cannot be loaded.
RMAN Session Is Hung in the Media

Manager
Possible reasons why backups are not

proceeding:
The backup abnormally terminates
A server side or media management error
One of the channels is waiting for a tape resource
Check for a hung situation by querying

V$SESSION and V$SESSION_WAIT.
SQL>
2
3
4
5
SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,

STATE, CLIENT_INFO
FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE sw.EVENT LIKE 'sbt%' AND s.SID=sw.SID
AND s.PADDR=p.ADDR
7-22
RMAN Session Is Hung in the Media Manager

The best way to terminate RMAN when the connections for the allocated channels are hung
in the media manager is to terminate the Oracle process of the connections. The RMAN
process detects this termination and proceeds to exit, removing all connections except the
target connections that are still operative in the media management layer. To terminate an
Oracle process that is hung in the media manager:
1. Query V$SESSION and V$SESSION_WAIT as illustrated above. The following is a
typical result of the query:
SPID
---8642
8374
EVENT
--------sbtwrite2
sbtwrite2
SEC_WAIT STATE
-------------600 WAITING
600 WAITING
CLIENT_INFO
----------------------------rman channel=ORA_SBT_TAPE_1
2. Terminate the hung processes with an operating system utility. For example, on Solaris
execute a kill -9 command:
$ kill -9 8642 8374
3. Check that the media manager also clears its processes, or else the next backup or
restore may still hang due to the previous hang. In some media managers, the only
solution is to shut down and restart the media manager.
RMAN Session Is Hung in the Media Manager (continued)

If the problem is persistent, you may need to investigate the cause. First, check to see what
the server processes that are performing the backup are doing. Is it only one process that is
hanging, or all the processes? If it is only one process, then check to see what it is doing.
Look at V$SESSION_WAIT and note where wait_time = 0
Check what part of the Oracle code you are in by using oradebug:
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: T1
RMAN-08500: channel T1: sid=12 devtype=SBT_TYPE
SQL> select sid, paddr from v$session where sid = 12;
SID PADDR
--------- -------12 81355388
SQL> select addr, spid from v$process where addr='81355388';
ADDR
SPID
--------- -------81355388 21397
SQL> oradebug setospid 21397
SQL> oradebug event immediate trace name errorstack level 10;
Some systems have OS utilities to show a stack trace from an arbitrary process. On
Solaris, /usr/proc/bin/pstack will provide this information.
$ /usr/proc/bin/pstack 21397
RPC Call Fails
A backup job is started and a Failed to start

RPC call error message is raised:
channel c8: including datafile number 47 in backupset

RPC call appears to have failed to start on channel c9
RPC call ok on channel c9
channel c3: including datafile number 18 in backupset
The message indicates that:

The target database instance is slow
A timing problem occurred
7-24
RPC Call Fails

This is indicative of an internal Oracle timing problem. When RMAN begins an RPC, it
checks the V$SESSION performance view. The RPC updates the information in the view to
indicate when it starts and finishes. Sometimes RMAN checks V$SESSION before the RPC
has indicated that it has started, which in turn generates the following message:
RPC call appears to have failed
This is a problem only if a message stating RPC call ok on channel Chname does
not appear in the output immediately following the message stating:
RPC call appears to have failed.
Failure of Snapshot Control File Creation
The backup fails because RMAN cannot make a

snapshot control file.
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03002:
======================================
==== ERROR MESSAGE STACK FOLLOWS =====
======================================
failure of backup command at
04/07/2002 16:32:21
ORA-00230: operation disallowed: snapshot
controlfile enqueue unavailable
7-25
Usually, the control file is being backed up by

another session.
Failure of Snapshot Control File Creation

When RMAN needs to back up the control file, it first creates a snapshot of the control file.
If one RMAN job is already backing up the control file while another needs to create a new
snapshot control file, then you may see the following message:
waiting for snapshot controlfile enqueue
A typical job waiting for the control file enqueue waits for a brief time and then obtains the
enqueue. RMAN makes up to five attempts to acquire the enqueue and then fails. The
conflict is usually caused when two jobs are both backing up the control file, and the job that
first starts backing up the control file waits for service from the media manager. To
determine which job is holding the conflicting enqueue, perform the following steps:
1. When you see the first message stating RMAN-08512: waiting for
snapshot controlfile enqueue, start a new SQL*Plus session on the target
database:
$ sqlplus 'SYS/oracle@trgt AS SYSDBA'
2. Execute the following query to determine which job is causing the wait:
SQL>
2
3
4
SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE,

ACTION, LOGON_TIME "Logon", l.* FROM V$SESSION s,
V$ENQUEUE_LOCK l WHERE l.SID = s.SID AND l.TYPE = 'CF'
AND l.ID1 = 0 AND l.ID2 = 2;
Failure of Snapshot Control File Creation (continued)

After you have determined the job that is creating the enqueue, you can do one of the
following:
Wait until the job that is creating the enqueue is completed.
Cancel the current job and restart it after the job that is creating the enqueue is
completed.
Cancel the job that is creating the enqueue.
Commonly, enqueue situations occur when a job is writing to a tape drive, but the tape drive
is waiting for a new cassette to be inserted. If you start a new job in this situation, then you
will probably receive the enqueue message because the first job cannot be completed until
the new tape is loaded.
RMAN Cannot Locate an Archived Log
The RMAN-06059 occurs when RMAN tries to back

up an archived log that is not accessible.
This is usually caused by deleting archived logs
with operating system commands.
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03002:
=======================================
===== ERROR MESSAGE STACK FOLLOWS =====
=======================================
failure of backup command at 04/07/2002
15:04:21
RMAN-06059: expected archived log not found, loss of
archived log compromises recoverability
ORA-19625: error identifying file /u01/ORADATA/1_9.dbf
7-27
RMAN Cannot Locate an Archived Log

This problem occurs when the archived log that RMAN is looking for cannot be accessed by
RMAN, or the recovery catalog needs to be resynchronized. Often, this error occurs when
you delete archived logs with an operating system command, which means that RMAN is
unaware of the deletion. The RMAN-6059 error occurs because RMAN attempts to back up
a log that the repository indicates still exists but is no longer there or has permission, user, or
group errors.
Make sure that the archived logs exist in the specified directory and that the RMAN catalog
is synchronized. Check the following:
1. Ensure that the archived log file that is specified by the RMAN-6059 error exists in the
correct directory.
2. Check that the operating system permissions are correct for the archived log. The
owner of the log file should be the owner of the Oracle binaries and the group
associated with the file should be DBA.
3. If the file appears to be correct, then try synchronizing the catalog by running the
RESYNC CATALOG command.
RMAN Cannot Locate an Archived Log (continued)

If you know that the logs are unavailable because you deleted them by using an operating
system utility, then run the following command at the RMAN prompt to update RMAN
metadata:
RMAN> CROSSCHECK ARCHIVELOG ALL;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=15 devtype=DISK
validation failed for archived log
archive log filename=/u01/user02/ORADATA/u05/1_1.dbf recid=3
stamp=457814434
validation succeeded for archived log
stamp=458057563
validation succeeded for archived log
...
stamp=457378699
Crosschecked 14 objects
It is always better to use RMAN to delete logs than to use an operating system utility. The
easiest method to remove unwanted logs is to specify the DELETE INPUT option when
backing up archived logs. For example, enter:
RMAN> BACKUP DEVICE TYPE sbt
2> ARCHIVELOG ALL
3> DELETE ALL INPUT;
Missing Log Causes Duplication Failure

The duplicate database fails, displays the following
error stack:
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03002:
======================================
==== ERROR MESSAGE STACK FOLLOWS =====
======================================
failure of Duplicate Db command at
04/04/2002 21:14:33
RMAN-03015: error occurred in stored script Memory
Script
RMAN-06053: unable to perform media recovery
because of missing log
RMAN-06025: no backup of log thread 1 seq 16 scn
145858 found to restore
7-29
Missing Log Causes Duplication Failure

Assume that you have attempted to duplicate a database with the DUPLICATE command,
but received the error stack as shown in the slide above. The problem is that RMAN is not
able to apply all the archived logs that are needed for complete recovery.
For example, if you only backed up logs through sequence 15, but the most recent archived
log is sequence 16, then the DUPLICATE command fails.
When creating the duplication script, use the SET UNTIL command to specify a log
sequence number for incomplete recovery. For example, to terminate the recovery after
applying the log sequence 15, run the following RMAN block:
RMAN> RUN {
SET UNTIL SEQUENCE 16 THREAD 1; # recovers up to but not including log 16
DUPLICATE TARGET DATABASE TO 'dupdb';
}
Summary
Debug RMAN errors
Debug media manager errors
Debug OS errors occurring in the RMAN stack
7-30
Practice Overview:
Debugging RMAN
Analyzing RMAN errors
Analyzing media manager errors
Analyzing OS errors in the RMAN stack
7-31
RMAN Performance Tuning
Objectives
the following:
Apply general performance tips and techniques
Implement synchronous and asynchronous I/O
Tune the RMAN BACKUP/RESTORE process
8-2
Tuning RMAN
RMAN BACKUP and RESTORE

operations perform the
following tasks:
Read or write data
Process data by copying and
validating blocks
8-3
The slowest of these operations is referred to as a

bottleneck.
Tuning RMAN requires that the bottlenecks be
identified and addressed.
Tuning RMAN
RMAN backup and restore operations perform the following distinct tasks:
Reading or writing input data
Processing data by validating and copying blocks from the input to the output buffers
The slowest of these operations is called a bottleneck. RMAN tuning is the task of
identifying the bottleneck (or bottlenecks) and attempting to make it more efficient by using
RMAN commands, initialization parameter settings, or adjustments to the physical media.
The key to tuning RMAN is understanding I/O. The backup and restore jobs of RMAN use
two types of I/O buffers: disk and tertiary storage (usually tape). When performing a backup,
RMAN reads input files by using disk buffers and writes the output backup file by using
either the disk or the tape buffer. When performing restores, RMAN reverses these roles.
Besides being divided into DISK and SBT, I/O is also divided into synchronous and
asynchronous. Synchronous devices only perform one I/O task at a time. Therefore, you can
easily determine how much time the backup jobs require. In contrast to synchronous I/O
(SIO), asynchronous I/O (AIO) can perform more than one task at a time. To tune RMAN
effectively, you must thoroughly understand the concepts such as synchronous and
asynchronous I/O, disk and tape buffers, and channel architecture. When you understand
these concepts, you can learn how to use fixed views to monitor bottlenecks.
Allocating RMAN Disk Buffer

The buffer allocation algorithm:
Multiplexing Level
Allocation Rule
1 MB buffers are allocated so that the

Less than or equal to 4 total buffer size for all the input files is
16 MB
512 KB are allocated so that the total
Greater than 4 but less
buffer size for all the files is less than
than or equal to 8
16 MB
Greater than 8
8-4
RMAN allocates a fixed 4 disk buffers

of 128 KB for each file, so that the total
size is 512 KB for each file
Allocating RMAN Disk Buffer

RMAN uses two different types of buffers for I/O: disk and tape. To understand how RMAN
allocates disk buffers, you must understand how RMAN multiplexing works. RMAN
multiplexing is the number of files in a backup read simultaneously and then written to the
same backup piece. The degree of multiplexing depends on the FILESPERSET parameter
of the BACKUP command as well as the MAXOPENFILES parameter of the CONFIGURE
CHANNEL or ALLOCATE CHANNEL commands.
For example, assume that you back up two data files with one channel. You set
FILESPERSET to 3 and set MAXOPENFILES to 8. In this case, the number of files in each
backup set is 2 (the lesser of FILESPERSET and the files read by each channel), and so
the level of multiplexing is 2 (the lesser of MAXOPENFILES and the number of files in each
backup set). When RMAN backs up from disk, it uses the algorithm that is described in the
table shown in the slide above.
Allocating Disk Buffer: Example

Data files
8-5
Input disk buffers

1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
1 MB
Channel
FILESPERSET = 4
MAXOPENFILES = 4
Allocating Disk Buffer: Example

In the example shown in the slide above, one channel is backing up four data files.
MAXOPENFILES is set to 4 and FILESPERSET is set to 4. So the level of multiplexing is
4 in this example.The total size of the buffers for each data file is 4 MB. To calculate the
total size of the buffers that are allocated in a backup set, multiply the total bytes for each
data file by the number of data files that are being concurrently accessed by the channel, and
then multiply this number by the number of channels.
Assume that you use one channel to back up four data files, and use the settings that are
shown in the slide above. In this case, multiply as follows to obtain the total size of the
buffers that are allocated for the backup:
4 MB per data file x 1 channel x 4 data files per channel = 16 MB
Set the MAXOPENFILES parameter so that the number of files that are read simultaneously
is just enough to use the output device fully. This consideration is important when the output
device is a tape.
Allocating Tape Buffer
If BACKUP_TAPE_IO_SLAVES = TRUE, then tape

buffers are allocated from the SGA.
Channel
Tape buffers
256 kb 256 kb
256 kb 256 kb
8-6
If BACKUP_TAPE_IO_SLAVES is false, then tape

buffers are allocated from the PGA.
Allocating Tape Buffer

If you make a backup to a tape device, then Oracle allocates four buffers per channel for the
tape writers (or reads if doing a restore). Oracle allocates these buffers only if the channel is
an SBT channel. Typically, each tape buffer is 256 KB. To calculate the total size of buffers
that are used during a backup or restore, multiply the buffer size by four, and then multiply
this product by the number of channels.
As illustrated in the example shown in the slide above, assume that you use one tape channel
and each buffer is 256 KB. In this case, the total size of buffers that are used during a
backup is as follows:
256 KB per buffer x 4 buffers per channel x 1 channel = 1024 KB
RMAN allocates the tape buffers in the System Global Area (SGA) or the Program Global
Area (PGA), depending on whether I/O slaves are used. If the initialization parameter
BACKUP_TAPE_IO_SLAVES is True, then RMAN allocates tape buffers from the SGA or
the large pool if the LARGE_POOL_SIZE initialization parameter is set. If you set the
parameter to False, then RMAN allocates the buffers from the PGA. If you use I/O slaves,
then set the LARGE_POOL_SIZE initialization parameter to set aside SGA memory that is
dedicated to holding these large memory allocations. By doing this, the RMAN I/O buffers
do not compete with the library cache for SGA memory.
Synchronous Versus Asynchronous I/O

Synchronous I/O
1 Server process
writes data to buffer
Server
Process
0100100
0100100
Server process
3 writes data to
new buffer
8-7
2 Server process waits;

tape process writes data
Tape
buffers
4 Tape process
signals finish

When RMAN reads or writes data, the I/O is either synchronous or asynchronous. When the
I/O is synchronous, a server process can perform only one task at a time. When it is
asynchronous, a server process can begin an I/O and then perform other tasks while waiting
for the I/O to complete. It can also begin multiple I/O operations before waiting for the first
to complete.
You can set initialization parameters that determine the type of I/O. If you set
BACKUP_TAPE_IO_SLAVES to True, then the tape I/O is asynchronous. Otherwise, the
I/O is synchronous. The example in the slide above shows synchronous I/O in a backup to
tape. The following steps occur in a synchronous transfer:
1. A server process writes blocks to a tape buffer.
2. The tape process writes data to tape. The server process is idle while the media
manager copies data from the Oracle buffers to the media managers internal buffers.
3. The tape process relays to the server process that it has completed writing.
4. The server process can initiate a new task.

Asynchronous I/O
1 Server process
writes data to buffer
Server
Process
2 Tape process writes data
0100100
0100100
0100100
Tape
buffers
8-8
Server process writes to new

buffer while step 2 completes
Synchronous Versus Asynchronous I/O (continued)

Many operating systems support native asynchronous I/O and Oracle can take advantage of
this feature whenever it is available. It is recommended that you always set
BACKUP_TAPE_IO_SLAVES to True when the platform supports it. On operating systems
that do not support native asynchronous I/O, Oracle can simulate it by using special I/O
slave processes that are dedicated to performing I/O on behalf of another process. You can
control disk I/O slaves by setting the DBWR_IO_SLAVES parameter to a nonzero value.
Oracle allocates four backup disk I/O slaves for any nonzero value of DBWR_IO_SLAVES.
The example in the slide above illustrates asynchronous I/O in a backup to tape. The steps
that occur in an asynchronous exchange are detailed below:
1. A server process writes blocks to a tape buffer.
2. The tape process writes data to the tape. While the tape process is writing, other server
processes are free to process more input blocks and fill more output buffers.
3. The two spawned server processes write to the tape buffers while the initial tape
process writes to the tape.
Setting LARGE_POOL_SIZE
If LARGE_POOL_SIZE is not set, then the Oracle

server tries to get memory from the shared pool.
If LARGE_POOL_SIZE is not big enough, then the
server does not allocate buffers from the shared
pool.
If the server cannot get enough memory,
then it allocates buffers from the local process
memory.
The Oracle server writes a message to the alert log
indicating that synchronous I/O is used for this
backup.
ksfqxcre: failure to allocate shared memory
means sync I/O will be used whenever async
I/O to file not supported natively
8-9
Setting LARGE_POOL_SIZE
The requests for contiguous memory allocations from the shared pool are small, usually
under 5 KB in size. However, it is possible that a request for a large contiguous memory
allocation can either fail or require significant memory housekeeping to release the required
amount of contiguous memory. Although the shared pool may be unable to satisfy this
memory request, the large pool is able to do so. The large pool does not have a least recently
used list so that Oracle does not attempt to age memory out of the large pool.
Use the LARGE_POOL_SIZE initialization parameter to configure the large pool. To see in
which pool (shared pool or large pool) the memory for an object resides, query
V$SGASTAT.POOL. The suggested LARGE_POOL_SIZE is calculated as:
#_of_allocated_channels * (16 MB + ( 4 * size_of_tape_buffer ))
For backups to disk, the tape buffer is obviously 0 so set LARGE_POOL_SIZE to 16 MB.
For tape backups, the size of a single tape buffer is defined by the RMAN channel parameter
BLKSIZE, which defaults to 256 KB. Assume a case in which you are backing up to two
tape drives. If the tape buffer size is 256 KB, then set LARGE_POOL_SIZE to 18 MB. If
you increase BLKSIZE to 512 KB, then increase LARGE_POOL_SIZE to 20 MB.
Performance Monitoring
The following are useful views for monitoring I/O:

V$BACKUP_SYNC_IO
V$BACKUP_ASYNC_IO
The following rows will exist for a backup or

restore:
One row for each data file
One aggregate data file row
One row for each backup piece
8-10
Whether or not I/O is synchronous depends on

how the controlling process views it.
Performance Monitoring
The maximum backup speed is limited by the available hardware. It is not possible to back
up any faster than the aggregate tape bandwidth. One exception to this is if there are many
empty blocks in the data files that need not be backed up.
One component of the backup system is always a bottleneck; unless the speeds of the disk
and tape are exactly matched (which is not likely), I/O at one component will always block,
no matter how many buffers are used. If the bottleneck is the tape drive, and the tape is
streaming, then the backup cannot possibly proceed any faster.
In which view the SBT_TAPE row appears is a good indication of whether the
BACKUP_TAPE_IO_SLAVES parameter is set, and whether AIO or SIO is being used.
This option should definitely cause increased throughput on UNIX. Because of the memory
management model, it is recommended that this be used with care on NT.
Asynchronous I/O Bottlenecks
If LONG_WAITS + SHORT_WAITS is a large part of

IO_COUNT, then the file is probably a bottleneck.
LONG_WAITS = number of times the backup/restore
process told the OS to wait until I/O was complete.
SHORT_WAITS = Calls the backup/restore process
made polling for I/O completion in nonblocking
mode.
8-11
WAITS times should be zero to avoid bottlenecks.
Asynchronous I/O Bottlenecks

The LONG_WAITS column shows the number of times the backup or restore process
directed the OS to wait until an I/O was complete. The SHORT_WAITS column shows the
number of times the backup/restore process made an OS call to poll for I/O completion in a
nonblocking mode. On some platforms, the asynchronous I/O implementation may cause the
calling process to wait for the I/O to complete while performing a nonblocking poll for I/O.
If the SHORT_WAIT_TIME_TOTAL column is equal to or greater than the
LONG_WAIT_TIME_TOTAL column, then your platform probably blocks for I/O
completion when performing nonblocking I/O polling. In cases like this, the
SHORT_WAIT_TIME_TOTAL column represents real I/O time for this file.
If the SHORT_WAIT_TIME_TOTAL is low compared to the total time for this file, then the
delay is most likely caused by other factors, such as process swapping. If possible, tune your
operating system so that the I/O wait time appears in the LONG_WAIT_TIME_TOTAL
column.
Synchronous I/O Bottlenecks
Synchronous I/O is considered to be a bottleneck.

Use DISCRETE_BYTES_PER_SECOND
column from V$BACKUP_SYNC_IO
to see the I/O rate.
Compare this rate with the devices
maximum rate.
If the rate is lower than what the device
specifies, then this is a tuning opportunity.
8-12
Synchronous I/O Bottlenecks

When using synchronous I/O, it can easily be determined how much time the backup jobs
require because devices only perform one I/O task at a time. Oracle I/O uses a polling
mechanism rather than an interrupt mechanism to determine when each I/O request
completes. Because the backup or restore process is not immediately notified of I/O
completion by the operating system, you cannot determine the duration of each I/O.
Use V$BACKUP_SYNC_IO to determine the source of backup or restore bottlenecks and to
determine the progress of backup jobs. V$BACKUP_SYNC_IO contains rows when the I/O
is synchronous to the process (or thread, on some platforms) that is performing the backup.
Tape Backup Speed

The following factors affect the speed of the backup to
tape:
Native transfer rate
Tape compression
Tape streaming
Physical tape block size
8-13
Tape Backup Speed

The tape native transfer rate is the write speed without compression. This speed represents
the upper limit of the backup rate. The upper limit of your backup performance should be
the aggregate transfer rate of all the tape drives. If the backup is performing at that rate, and
an excessive amount of CPU is not being used, then tuning RMAN will not help.
Tape compression greatly affects backup performance. If the tape has good compression,
then the sustained backup rate is faster. For example, if the compression ratio is 2:1 and the
native transfer rate of the tape drive is 6 MB/s, then the resulting backup speed is 12 MB/s.
Almost all tape drives currently in the market are fixed-speed, streaming tape drives. In
other words, these drives can only write data at one speed. As a result, when they run out of
data to write to tape, they must slow down and stop. For example, when the drives buffer
empties, the tape is moving so quickly that it actually overshoots and must rewind past the
point where it stopped writing.
The physical tape block size can affect the backup performance. The block size is the
amount of data that is written by the media management software to a tape in one write
operation. The common rule is that a larger tape block size leads to a faster backup. The
physical tape block size is controlled by the media management software.
Tape Subsystem Performance Rules
The more the tape drives, the faster the backup

and restore.
Allocate one channel per physical device:
If more channels than physical drives are used,
then the backup sets will be intermingled.
This is similar to multiplexing data files.
8-14
If tape drive is not streaming, then increase the

number of files that are multiplexed.
Back up the files that are likely to be restored
together in the same backup set.
Performance Rules
You can speed up the backup and restore processes by buying more tape drives, faster tape
drives, or ideally a combination of the two. It is a waste of system resources to allocate more
than one channel per tape drive. If more channels than physical drives are used, then the
backup sets will be intermingled. This can adversely affect the time it takes to restore
selected files.
If a tape drive is not streaming, increasing the number of files multiplexed together may
help. Remember that if a small subset of files in a backup set must be restored, the restore
will take longer if many files are multiplexed into the backup set. Put just enough files into
each backup set to keep the tape drives streaming. It is better to store files that are likely to
be restored together in the same backup set.
Empty Files and Incremental Backups
When backing up files with many empty blocks,

it may become difficult to keep the buffers full.
This condition will keep the tape drives from
streaming.
8-15
When performing incremental backups, set the

multiplexing level to 50 to keep the tape
streaming.
Full or level 0 backups require a lower
multiplexing value.
Empty Files and Incremental Backups

When performing a full backup of files that are largely empty, or when performing an
incremental backup when few blocks have changed, you may not be able to supply data to
the tape fast enough to keep it streaming. In either case, you can improve performance by
increasing the level of multiplexing. An incremental backup is an RMAN backup in which
only modified blocks are backed up. Incremental backups are not necessarily faster than full
backups because Oracle still reads the entire data file to take an incremental backup. If tape
drives are not locally attached, then incremental backups can be faster. You must consider
how much bandwidth exists for reading the disks compared to the bandwidth for writing to
the tapes. If the tape bandwidth is limited compared to disk, then incremental backups may
help.
If only a few blocks have changed in an incremental backup, then you need to input many
buffers from the data file before you accumulate enough blocks to fill a buffer and write to
tape. Therefore, the tape drive may not stream. If you set the level of multiplexing to a large
value, then you can scan many data files in parallel, the output buffers for the tape drive are
filled quickly, and you can write them frequently to keep the drive streaming. The
FILESPERSET value should be less than or equal to MAXOPENFILES. For example, set
both parameters to 8, and raise this value if the tape drive does not stream.
Empty Files and Incremental Backups (continued)

For an incremental backup, 50 is a good value for the level of multiplexing. For a full or
incremental level 0 backup, the level of multiplexing should be a lower value such as 4 or
8. A good way to test whether your tape backup performance is slow because of empty
files is to try backing up archived logs, which contain nothing but data. In other words,
they do not contain empty space.
Control Tape Buffer Size with BLKSIZE
Adjust the size of the tape buffer to keep the tape

streaming.
Use the BLKSIZE option of PARMS to set the
desired buffer size:
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE
2> PARMS="BLKSIZE=524288";
8-17
Set BLKSIZE to a value that is a little less than the

tape block size of the media manager.
Control Tape Buffer Size with BLKSIZE

If the tape is not streaming, but the problem is not due to an incremental backup or by
backing up empty files, then try adjusting the block size of the tape buffer. You can change
the size of each tape buffer by using the PARMS parameter of the ALLOCATE CHANNEL or
CONFIGURE CHANNEL command. If the BLKSIZE parameter for PARMS is supported on
your platform, then you can set it to the desired size of each buffer. For example, configure
an SBT channel as follows:
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT
PARMS="BLKSIZE=524288";
It is a good practice to set BLKSIZE to a value that is a little less than the tape block size of
the media manager. What a little less means depends on the media manager. For example,
if the tape block size is 512 KB and the media manager has a header of size 16 KB, then you
can set BLKSIZE=49600.
Note that it is also a good idea to increase the media management physical tape block size.
For example, you do not want to set the BLKSIZE parameter to 512 KB and leave the
physical tape block size as 32 KB.
Channel Tuning
Use the CONFIGURE CHANNEL and ALLOCATE CHANNEL
commands to:
Limit the size of backup pieces
Prevent RMAN from consuming too much disk
bandwidth
Determine the level of multiplexing for each
channel
8-18
Channel Tuning
You can set various channel limit parameters that apply to operations that are performed by
the allocated server session in the CONFIGURE CHANNEL and ALLOCATE CHANNEL
commands.
The MAXPIECESIZE parameter specifies the maximum size of a backup piece. Use this
parameter to make RMAN create multiple backup pieces in a backup set. RMAN creates
each backup piece with a size that is no larger than the value that has been specified in the
parameter.
The RATE parameter specifies the bytes per second that RMAN reads on the channel. This
parameter is useful in preventing RMAN from consuming excessive disk bandwidth and
degrading OLTP performance. For example, by setting RATE=1500K, each disk drive
delivers 3 MB per second and RMAN leaves some disk bandwidth available to the online
system.
The MAXOPENFILES parameter determines the maximum number of input files that a
backup or copy can have open at a given time. If not set manually, then the value defaults to
8. The level of RMAN multiplexing is partially determined by MAXOPENFILES. The level
of multiplexing in turn determines how RMAN allocates disk buffers. Multiplexing is the
number of input files that are simultaneously read and then written into the same backup
piece.
Tuning the BACKUP Command
8-19
MAXSETSIZE prevents RMAN from writing a single

backup set to multiple volumes.
FILESPERSET prevents RMAN from reading from
too many disks at once.
DISKRATIO limits the number of disk drives that
are read from simultaneously.
Tuning the BACKUP Command

The MAXSETSIZE parameter specifies the maximum size in bytes of a backup set. This
parameter is used to prevent a single backup set from spanning multiple volumes.
The FILESPERSET parameter specifies the maximum number of files to place in a
backup set. If you allocate only one channel, then you can use this parameter to make
RMAN create multiple backup sets. For example, if you have 50 input data files and two
channels, you can set FILESPERSET=5 to create 10 backup sets. This strategy can prevent
you from splitting a backup set among multiple tapes.
The DISKRATIO parameter specifies the number of drives to include in the backup.
Assume that the data files are located on five disks, each disk supplies data at 10 bytes per
second, and the tape drive requires 20 bytes per second to keep streaming. If you set
DISKRATIO=2, then RMAN reads from two drives at a time, thereby distributing the
backup load.
Summary
Apply general performance tips and techniques
Implement synchronous and asynchronous I/O
Tune the RMAN BACKUP/RESTORE process
8-20
__________
Appendix A
__________
RMAN Catalog Views and Corresponding Control File Views

Recovery Catalog View
Corresponding V$ View
View Description
RC_ARCHIVED_LOG
V$ARCHIVED_LOG
Archived and unarchived redo logs
RC_BACKUP_CONTROLFILE
V$BACKUP_DATAFILE
Control files in backup sets
RC_BACKUP_CORRUPTION
V$BACKUP_CORRUPTION
Corrupt block ranges in datafile

backups
RC_BACKUP_DATAFILE
V$BACKUP_DATAFILE
Datafiles in backup sets
RC_BACKUP_PIECE
V$BACKUP_PIECE
Backup pieces
RC_BACKUP_REDOLOG
V$BACKUP_REDOLOG
Archived redo logs in backup sets
RC_BACKUP_SET
V$BACKUP_SET
Backup sets for all incarnations of

the database
RC_BACKUP_SPFILE
V$BACKUP_SPFILE
Server parameter files in backups

Deprecated in favor of
RC_RESYNC
RC_CHECKPOINT
RC_CONTROLFILE_COPY
V$DATAFILE_COPY
Control file copies on disk
RC_COPY_CORRUPTION
V$COPY_CORRUPTION
Control file copies on disk
RC_DATABASE_BLOCK_
CORRUPTION
V$DATABASE_BLOCK_
CORRUPTION
Database blocks marked as

corrupted in the most recent
RMAN backup or copy
RC_DATABASE_
INCARNATION
V$DATABASE_
INCARNATION
Database incarnations that are

registered in the recovery catalog
RC_DATAFILE
V$DATAFILE
Datafiles registered in the recovery

catalog
RC_DATAFILE_COPY
V$DATAFILE_COPY
Datafile copies on disk
Oracle9i Database: Advanced Backup and Recovery Using RMAN A-2
RC_LOG_HISTORY
V$LOG_HISTORY
Online redo log history indicating

when log switches occurred
RC_OFFLINE_RANGE
V$OFFLINE_RANGE
Offline ranges for datafiles
RC_PROXY_CONTROLFILE
V$PROXY_DATAFILE
Control file backups that were

taken by using the proxy copy
functionality
RMAN Compatibility Matrix

Target Database
RMAN Executable
Catalog Database
Catalog Schema
8.0.3
8.0.3
greater/equal to 8.x
8.0.3
8.0.4
8.0.4
greater/equal to 8.0.4
8.0.5
8.0.5
8.0.6
8.0.6
8.0.6
8.0.6
8.0.6
greater/equal to 8.1.x
8.1.5
8.1.5
8.1.6
8.0.6.1
8.0.6
8.1.6
8.0.6.1
8.1.6
8.1.
5 greater/equal to
8.1.x
greater/equal to
RMAN executable
8.1.6
8.1.
6 greater/equal to
8.1.x
greater/equal to
RMAN executable
8.1.7
8.0.6.1
8.0.6
8.1.7
8.0.6.1
8.1.7
8.1.x
greater/equal to
RMAN executable
9.0.1
9.0.1
greater/equal to
RMAN executable
9.2.0
greater/equal to
RMAN executable
Deprecated RMAN Commands

Deprecated In
Deprecated Syntax
Preferred Current Syntax
9.2
REPLICATE
RESTORE CONTROLFILE FROM ...
9.2
SET AUTOLOCATE
Now enabled by default.
9.0.1
ALLOCATE CHANNEL FOR

DELETE
Not available
9.0.1
ALLOCATE CHANNEL ...

TYPE
CONFIGURE CHANNEL ... DEVICE

TYPE
9.0.1

KBYTES
CONFIGURE CHANNEL ...

MAXPIECESIZE
9.0.1

READRATE
CONFIGURE CHANNEL ... RATE
9.0.1 ...
ARCHIVELOG ...
LOGSEQ ...
ARCHIVELOG ... SEQUENCE
9.0.1
BACKUP ... SETSIZE
BACKUP ... MAXSETSIZE
9.0.1
CHANGE ... CROSSCHECK
CROSSCHECK
9.0.1
CHANGE ... DELETE
DELETE
9.0.1
REPORT ... AT LOGSEQ
REPORT ... AT SEQUENCE
9.0.1
SET AUXNAME
CONFIGURE AUXNAME
__________
Appendix B
Practices
__________
Lesson 2 Practices
1. Put your database in archivelog mode. Ensure that the archived logs are written to
$HOME/ORADATA/ARCHIVE1.
2. On your database Unn, create a tablespace called RCVCAT that will contain the schema for
the repository tables, views, and so on. Make the datafile 20 MB in size and place it in
$HOME/ORADATA/u04. Create a Recovery Manager user called RMAN and set the users
default tablespace to RCVCAT. Let the RMAN user have unlimited quota on this tablespace.
Set the temporary tablespace to TEMP. Grant the role RECOVERY_CATALOG_OWNER to this
user. Create the catalog and register the target database.
3. Create a persistent configuration for the recovery catalog. Use the following specifications as
a guide:
Automatically back up the control file
Make DISK the default device type
Set the level of parallelization for the DISK device to 2
Configure two disk channels and specify the file format to be

$HOME/ORADATA/u06/C#_%U
Create a seven-day recovery window

Name the snap controlfile $HOME/ORADATA/u06/cfcp/snapcf_SID.f
Start Enterprise Manager and connect to your database. Verify your persistent RMAN
configuration.
Oracle9i Database: Advanced Backup and Recovery Using RMAN B-2
Lesson 3 Practices
1. By using operating system commands, make a complete cold backup into the directory
DONTTOUCH. This is done to provide a point-of-disaster recovery, if all else fail. Confirm
the copy when finished. Query the recovery catalog to see if RMAN knows about this
backup.
2. Use the CATALOG command to advise the repository of the backup that was taken
previously. Then confirm by examining the appropriate tables.
3. Use RMAN to make a datafile copy of all the files of the database. Put the files in
$HOME/BACKUP/RMAN. Then confirm that the repository was automatically updated
with the knowledge of this backup.
4. Make a full or incremental 0 backup of the database and put the backup files in the BACKUP
directory. Put all files into one set, but restrict the size of each piece to 20 MB. Confirm
whether the backup has occurred by examining the appropriate tables in the repository.
5. Perform a database backup by using automatic channel allocation. Ensure that the backup
command behaves as specified in your persistent configuration.
6. By using Enterprise Manager, perform a level 1 database backup.
Lesson 4 Practices
Complete recovery from a total failure
1. Delete all the datafiles and controlfiles that are associated with the target database. Use the
V$DATAFILE and V$CONTROLFILE views to get the filenames. You can do this
individually, or by using the spool command to make a script to run. It is suggested that the
recover database validate command be run first to ensure that the database can be
recovered to the current point in time.
Incomplete recovery to some time in the past
2. This practice simulates the need to recover a database to some point in the past because of
the introduction of questionable data. Create a table called HR.DEPARTMENTS2 as select
* from HR.DEPARTMENTS and perform some inserts, noting the time before committing
the inserts. Start Enterprise Manager and use this time (less 5 minutes) to recover the
database to a point in time before the new data was introduced.
Recover a single block
3. Using the DEPARTMENTS table, corrupt a block in the object with the corrupt.sh script
and use the BLOCKRECOVER command to fix the corruption. Run the script as shown below:
$ corrupt.sh
The script will corrupt a block in the DEPARTMENTS table. Immediately after running the
script, start a SQL*Plus session and perform a select against the DEPARTMENTS table:
SQL> select * from DEPARTMENTS;
Note the error output and use it with the BLOCKRECOVER command to correct the
corruption. Verify whether the table has been repaired.
Lesson 5 Practices
1. Use the LIST command to:
Get the current status of your backups
List backups by datafile
Identify the current database incarnation and identify the SCN at which it changed
2. Use CONFIGURE to change the REDUNDANCY to two. Using REPORT:
Identify files that have less than four redundant backups.
Identify files whose recovery needs more than seven days of archived logs.
Identify backups that are obsolete according to the new retention policy
View your database schema
3. Delete obsolete backups as identified by the redundancy value that was set in practice 2.
4. Create a stored script called whole_bkup that allocates a disk channel and backs up the
entire database. Run the script to be sure it works properly. Query the appropriate view to see
the script lines. Next, use the PRINT command to view the stored script lines.
Lesson 6 Practices
Configure the channel SBT_TAPE to use Oracles SBT dummy disk API. Use the
SBT_LIBRARY parameter to direct RMAN to load the proper library. Configure the
SBT_TAPE channel to be the default channel. Test the SBT configuration by performing a
backup. Troubleshoot the configuration if unsuccessful.
Lesson 7 Practices
1. Use RMAN to start a backup. While the backup is running log on to the target database by
using another telnet session and examine the view V$SESSION_LONGOPS. By using this
view you can determine if the backup is progressing, or hanging. If the backup is
progressing, the time_remaining column should be decreasing.
2. Using RMAN perform another backup by using the DEBUG option. On completion of the
backup script, examine the trace file that is produced by DEBUG.
3. Run the shell script les07_03.sh. After doing this, perform a database backup by using the
SBT_TAPE device. Use the error stack to identify the problem. If it is indeterminate, look at
the files (trace files, sbtio.log) in USER_DUMP_DEST or use debug to gather more
information. Correct the error and rerun the backup to verify the repair.
4. Run the shell script les07_04.sh. After doing this, perform a database backup by using
the persistent configuration. Investigate the alert log and trace files for any clues. If this does
not work, then use debug to gather more information. Correct the condition and run the
backup.
__________
Appendix C
Solutions
__________
Lesson 2 Practices
1. Put your database in archivelog mode. Ensure that the archived logs are written to
$HOME/ORADATA/ARCHIVE1.
To switch a databases archiving mode between NOARCHIVELOG and ARCHIVELOG
mode, edit your initialization parameter file and set LOG_ARCHIVE_DEST to
$HOME/ORADATA/ARCHIVE1 and LOG_ARCHIVE_START to TRUE. The database
should not be running.
$ cd $HOME/ADMIN/PFILE
$ vi initUnn.ora
LOG_ARCHIVE_DEST=$HOME/ORADATA/ARCHIVE1
LOG_ARCHIVE_START=TRUE
Start the instance and mount, but do not open, the database.
$sqlplus /nolog
SQL> startup mount pfile=$HOME/oracle/dbs/initUnn.ora
Switch to archivelog mode and then open the database:

SQL> alter database archivelog;
SQL> alter database open;
2. On your database Unn, create a tablespace called RCVCAT that will contain the schema for
the repository tables, views, and so on. Make the datafile 20 MB in size and place it in
$HOME/ORADATA/u04. Create a Recovery Manager user called RMAN and set the users
default tablespace to RCVCAT. Let the RMAN user have unlimited quota on this tablespace.
Set the temporary tablespace to TEMP. Grant the role RECOVERY_CATALOG_OWNER to
this user. Create the catalog and register the target database.
Use the create tablespace command. Name the file rcvcat.dbf and place it in
$HOME/ORADATA/u04.
SQL> create tablespace rcvcat
2 datafile '$HOME/ORADATA/u04/rcvcat.dbf'
3 size 20m;
Tablespace created.
Oracle9i Database: Advanced Backup and Recovery Using RMAN C-2
Create the RMAN user. Make RCVCAT the default tablespace and TEMP the temporary
tablespace. Give RMAN unlimited quota in RCVCAT.
NOTE: To connect to your target database the target user must be identified as a
SYSDBA.
SQL>
2
3
User
create user rman identified by rman

DEFAULT TABLESPACE rcvcat QUOTA UNLIMITED ON rcvcat
temporary tablespace temp;
created.
Grant RECOVERY_CATALOG_OWNER and any other privileges that are needed to the
RMAN user:
SQL> grant RECOVERY_CATALOG_OWNER, connect, resource, sysdba
Grant succeeded.
TO rman;
Start RMAN and connect to the target database and the catalog. Create the catalog and
register the database.
SQL> exit
connected to target database: U221 (DBID=4278320558)
recovery catalog is not installed
RMAN> CREATE CATALOG
RMAN> create catalog
recovery catalog created
RMAN> register database;
database registered in recovery catalog
Starting full resync of recovery catalog
full resync complete
3. Create a persistent configuration for the recovery catalog. Use the following specifications as
a guide:
Automatically back up the control file
Make DISK the default device type
Set the level of parallelization for the DISK device to 2
Configure two disk channels and specify the file format to be

$HOME/ORADATA/u06/C#_%U
Create a seven-day recovery window

Name the snap controlfile $HOME/ORADATA/u06/snapcf_SID.f
Verify your configuration
From the RMAN prompt, issue the show all command.

RMAN> show all;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u03/ora9ir2/dbs/snapcf_U01.f';# default
Run the appropriate configure commands to create the persistant configuration. Note
that DISK is already the default device type. Remember that the show all command
output was designed to allow easy cut and past operations to modify parameters.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'$HOME/ORADATA/u05/%F'
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$HOME/ORADATA/u06/snapcf_U01.f';
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C1_%U';
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C2_%U';
Confirm that the necessary changes have been made by issuing the show all command
again and comparing the output with the practice requirements.
RMAN> show all;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'$HOME/ORADATA/u05/%F';
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT
'$HOME/ORADATA/u06/C1_%U';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$HOME/ORADATA/u06/snapcf_U01.f';
Lesson 3 Practices
1. By using operating system commands, make a complete cold backup into the directory
DONTTOUCH. This is done to provide a point-of-disaster recovery, if all else fail. Confirm the
copy when finished. Query the recovery catalog to see if RMAN knows about this backup.
Shutdown your database and copy the datafiles located in the ORADATA directory to the
DONTTOUCH directory. The datafiles are on different disks (simulated) so that the find
command is useful for copying files from multiple locations and consolidating them into
a single directory, DONTTOUCH, in this case. Please note that there is no space between
the French braces.
$ sqlplus /nolog
SQL> shutdown immediate;
SQL> exit
$ cd
$ find $HOME/ORADATA exec
$ ls l $HOME/DONTTOUCH
total 821824
-rw-r----1 user01
dba
-rw-r----1 user01
dba
-rw-r----1 user01
dba
...
-rw-r----1 user01
dba
cp
{}
$HOME/DONTTOUCH
\;
954368 Apr 14 17:16 control01.ctl

26214912 Apr 14 17:17 example01.dbf
26214912 Apr 14 17:17 indx01.dbf.rdo
15732736 Apr 14 17:17 users01.dbf
Query the CDF table in the RMAN schema. The backups that are listed include ALL
blocks and are like an operating system backup. In this case, there is no history of the
backup at all.
SQL> column fname format a50
SQL> select file#, fname, completion_time from rman.cdf;
no rows selected
2. Use the CATALOG command to advise the repository of the backup that was taken
previously. Then, confirm by examining the appropriate tables.
Run each catalog individually from the RMAN prompt or include them in a run block.
Use the output from the list command that was performed earlier to get the names of the
datafile copies.
SQL> exit
$ rman target / catalog
RMAN> run {
2> catalog datafilecopy
}
rman/rman
'$HOME/DONTTOUCH/indx01.dbf';
'$HOME/DONTTOUCH/rcvcat.dbf';
'$HOME/DONTTOUCH/example01.dbf';
'$HOME/DONTTOUCH/system01.dbf';
'$HOME/DONTTOUCH/undotbs01.dbf';
'$HOME/DONTTOUCH/users01.dbf';
To confirm RMAN is aware of the cataloged datafile copies, query the CDF table as done
previously.
$ sqlplus rman/rman
SQL> select file#, fname, completion_time from cdf;
FILE# FNAME
COMPLETIO
---------- -------------------------------------------------- --------1 /home1/user01/DONTTOUCH/system01.dbf
14-APR-02
4 /home1/user01/DONTTOUCH/indx01.dbf
14-APR-02
...
3 /home1/user01/DONTTOUCH/users01.dbf
14-APR-02
6 rows selected.
3. Use RMAN to make a datafile copy of all the files of the database. Put the files in
$HOME/BACKUP/RMAN. Then, confirm that the repository was automatically updated
with the knowledge of this backup.
Query V$DATAFILE to get the file numbers and filenames that are needed to perform
the RMAN datafile backup.
SQL> column name format a45;
SQL> select file#, name from v$datafile;
FILE #
NAME
------------------------------------------------1
/home1/user01/ORADATA/u01/system01.dbf
2
/home1/user01/ORADATA/u02/undotbs01.dbf
3
/home1/user01/ORADATA/u03/users01.dbf
4
/home1/user01/ORADATA/u03/indx01.dbf
5
/home1/user01/ORADATA/u02/example01.dbf
6
/home1/user01/ORADATA/u04/rcvcat.dbf
Using the information from V$DATAFILE execute RMAN, connecting to the catalog
and the target database and perform the backup.
RMAN> run {
2> copy datafile 1 to '$HOME/BACKUP/RMAN/system01.dbf';
3> copy datafile 2 to '$HOME/BACKUP/RMAN/undotbs01.dbf';
4> copy datafile 3 to '$HOME/BACKUP/RMAN/users01.dbf';
5> copy datafile 4 to '$HOME/BACKUP/RMAN/indx01.dbf';
6> copy datafile 5 to '$HOME/BACKUP/RMAN/example01.dbf';
7> copy datafile 6 to '$HOME/BACKUP/RMAN/rcvcat.dbf';
8> }
Starting copy at 14-APR-02
channel ORA_DISK_1: copied datafile 1
output filename=/home1/user01/BACKUP/RMAN/system01.dbf recid=7

stamp=459206051
Finished copy at 14-APR-02
output filename=/home1/user01/BACKUP/RMAN/undotbs01.dbf recid=8
stamp=459206064
...
output filename=/home1/user01/BACKUP/RMAN/rcvcat.dbf recid=12
stamp=459206088
Starting Control File Autobackup at 14-APR-02
piece handle=/home1/user01/ORADATA/u05/c-0574317449-20020414-01
comment=NONE
Finished Control File Autobackup at 14-APR-02
Note that the control file has been backed up automatically.

Query the CDF table in the RMAN schema and compare the results with the query that
was performed earlier. You should see a second datafile backup.
RMAN> exit
$ sqlplus rman/rman
SQL> column completion_time format a15
SQL> select file#, fname, completion_time from cdf;
FILE#
---------1
4
6
5
2
3
1
2
3
4
5
FNAME
COMPLETION_TIME
--------------------------------------------- --------------/home1/user01/DONTTOUCH/system01.dbf
14-APR-02
/home1/user01/DONTTOUCH/indx01.dbf
14-APR-02
/home1/user01/DONTTOUCH/rcvcat.dbf
14-APR-02
/home1/user01/DONTTOUCH/example01.dbf
14-APR-02
/home1/user01/DONTTOUCH/undotbs01.dbf
14-APR-02
/home1/user01/DONTTOUCH/users01.dbf
14-APR-02
/home1/user01/BACKUP/RMAN/system01.dbf
14-APR-02
/home1/user01/BACKUP/RMAN/undotbs01.dbf
14-APR-02
/home1/user01/BACKUP/RMAN/users01.dbf
14-APR-02
/home1/user01/BACKUP/RMAN/indx01.dbf
14-APR-02
/home1/user01/BACKUP/RMAN/example01.dbf
14-APR-02
FILE# FNAME
COMPLETION_TIME
---------- --------------------------------------------- --------------6 /home1/user01/BACKUP/RMAN/rcvcat.dbf
14-APR-02
12 rows selected.
4. Make a full or incremental 0 backup of the database and put the backup files in the BACKUP
directory. Put all files into one set, but restrict the size of each piece to 20 MB. Confirm
whether the backup has occurred by examining the appropriate tables in the repository.
Use the backup full command as shown in the example.
RMAN> run {
2> allocate channel c1 type disk;
3> set limit channel c1 kbytes=20000;
4> backup full
5> (database format '$HOME/BACKUP/back_%p%d.%s');
6> release channel c1;
7> }
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home1/user01/ORADATA/u01/system01.dbf
...
input datafile fno=00003 name=/home1/user01/ORADATA/u03/users01.dbf
channel c1: starting piece 1 at 14-APR-02
channel c1: finished piece 1 at 14-APR-02
piece handle=/home1/user01/BACKUP/back_1U01.3 comment=NONE
...
channel c1: starting piece 7 at 14-APR-02
channel c1: finished piece 7 at 14-APR-02
piece handle=/home1/user01/BACKUP/back_7U01.3 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:33
Finished backup at 14-APR-02
comment=NONE
Again, note the autobackup of the control file.

5. Perform a database backup by using automatic channel allocation. Ensure that the backup
command behaves as specified in your persistent configuration.
Start RMAN and connect to the catalog and the target database. Issue the backup
database command. If the persistent configuration has been set up properly, then the
RMAN output should be similar to the example shown below. Please note the two disk
channels that are allocated and the creation of the backup piece.

channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00005 name=/home1/user01/ORADATA/u02/example01.dbf
...
channel ORA_DISK_2: starting piece 1 at 14-APR-02
channel ORA_DISK_1: finished piece 1 at 14-APR-02
piece handle=/home1/user01/ORADATA/u06/C1_0gdlvhm2_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
channel ORA_DISK_2: finished piece 1 at 14-APR-02
piece handle=/home1/user01/ORADATA/u06/C2_0hdlvhm2_1_1 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:25
comment=NONEFinished Control File Autobackup at 14-APR-02
Take note of the channel allocation. Does the number of channels allocated match the degree of
parallelization that is specified for the DISK device in the persistent configuration? Note the files
that were created by channels 1 and 2. Do the format and the file location match the persistent
configuration created earlier? In the output above, the channels are automatically allocated as
desired and the backup pieces are written in the correct format and location.
Lesson 4 Practices
Complete recovery from a total failure
1. Delete all the datafiles and controlfiles that are associated with the target database. Use the
V$DATAFILE and V$CONTROLFILE views to get the filenames. You can do this
individually, or by using the spool command to make a script to run. It is suggested that the
recover database validate command be run first to ensure that the database can be
recovered to the current point in time.
Run recover database validate to ensure that we can recover the database. If
this fails, then back up the database again and try again.
RMAN> restore database validate;
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_2: starting validation of datafile backupset
channel ORA_DISK_1: restored backup piece 1
...
channel ORA_DISK_2: validation complete
Finished restore at 15-APR-02
Query V$DATAFILE and V$CONTROLFILE to find the location of the control file and
datafiles and delete them. Do not delete your backups.
SQL> select name from v$datafile;
NAME
--------------------------------------------/home1/user01/ORADATA/u01/system01.dbf
6 rows selected.
SQL> select name from v$controlfile;
NAME
------------------------------------------/home1/user01/ORADATA/u01/ctrl01.ctl
Shut down the database and remove the control file and datafiles.
SQL>
$ cd
$ rm
$ rm
$ rm
$ rm
$ rm
exit
$HOME/ORADATA
u01/*.dbf
u01/*.ctl
u02/*.dbf
u03/*.dbf
u04/*.dbf
Start RMAN and connect to the target database only because the recovery catalog resides
in the database and is unavailable. Start the database in nomount mode. The first thing
that must be done is to restore the control file. List the controlfiles in the autobackup
location and find the most recent one. Then use the restore controlfile from
filename command to do this.
$ sqlplus /nolog
$connect / as sysdba
SQL> startup nomount;
SQL> exit
$ rman target /
RMAN> host ls l $HOME/ORADATA/u05;
total 13328
-rw-r----1 ora9i dba
963072 Apr
963072 Apr
963072 Apr
963072 Apr
963072 Apr
963072 Apr
963072 Apr
host command complete
14
14
14
14
14
15
15
20:59
21:14
21:46
21:51
23:51
12:41
14:17
c-0574317449-20020414-00
c-0574317449-20020414-01
c-0574317449-20020414-02
c-0574317449-20020414-03
c-0574317449-20020414-05
c-0574317449-20020415-00
c-0574317449-20020415-01
RMAN> restore controlfile from '$HOME/ORADATA/u05/c-0574317449-20020415-01';

Starting restore at 15-APR-02
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete
RMAN>
By using RMAN, restore the datafiles and recover the database. At the end of the
recovery, you will need to reset the database and make a complete backup because the
database will need to be opened by using the resetlogs option.
RMAN> alter database mount;
RMAN> restore database;
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home1/user01/ORADATA/u01/system01.dbf
restoring datafile 00003 to /home1/user01/ORADATA/u03/users01.dbf
restoring datafile 00004 to /home1/user01/ORADATA/u03/indx01.dbf
piece handle=/home1/user01/ORADATA/u06/C2_0kdlvnad_1_1 tag=null
params=NULL

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00002 to /home1/user01/ORADATA/u02/undotbs01.dbf
restoring datafile 00005 to /home1/user01/ORADATA/u02/example01.dbf
restoring datafile 00006 to /home1/user01/ORADATA/u04/rcvcat.dbf
pi or from recovery catalog database: ORA-01033: ORACLE initialization
orece handle=/home1/user01/ORADATA/u06/C1_0jdlvnad_1_1 tag=null
params=NULL
RMAN> recover database;
archive log thread 1 sequence 11 is already on disk as file
/home1/user01/ORADATA/u03/redo01.rdo
archive log filename=/home1/user01/ORADATA/u03/redo01.rdo thread=1
sequence=11
media recovery complete
Finished recover at 15-APR-02
Exit
RMAN> alter database open resetlogs;
database opened
RMAN> exit
RMAN> exit
Incomplete recovery to some time in the past

2. This practice simulates the need to recover a database to some point in the past because of
the introduction of questionable data. Create a table called HR.DEPARTMENTS2 as select
* from HR.DEPARTMENTS and perform some inserts, noting the time before committing
the inserts. Use this time (less five minutes) to recover the database to a point in time before
the new data was introduced.
As user SYSTEM create the table HR.DEPARTMENTS2 as select * from departments.
Confirm that the table exists, and record the total number of rows. After creating the
table, get the time and date. View the active log by querying V$LOG. Perform a log
switch when finished.
$ sqlplus system/manager
SQL> create table hr.departments2 as select * from hr.departments;
SQL> select count(*) from hr.departments2;

COUNT(*)
---------27
SQL> !date
Tue Apr 16 17:05:50 EDT 2002
SQL> select sequence#, status from v$log;
SEQUENCE#
---------3
4
STATUS
---------------INACTIVE
CURRENT
SQL> alter system switch logfile;

System altered.
Query V$LOG again to confirm the switch and then insert three lines into
DEPARTMENTS2 and commit. Confirm the number of rows in the table. These inserts
represent the introduction of questionable data into the table.
SQL> select sequence#, status from v$log;
SEQUENCE#
---------5
4
STATUS
---------------CURRENT
ACTIVE
SQL> insert into hr.departments2 values (280, 'DUMMY1','','');

SQL> commit
COUNT(*)
---------30
Shut down the database, and restart it in mount mode.

SQL> startup mount;
ORACLE instance started.
SQL> exit
By using RMAN perform an incomplete recovery until the date and time recorded in the
previous step, less 5 minutes. Use the set until time clause to the time reported in
the first step and then recover the database.
$ rman target /
RMAN> run {
2> set until time "TO_DATE('02-APR-16:17:00:00','YY-MON-DD:HH24:MI:SS')";
3> restore database;
4> recover database;
5> }
executing command: SET until clause
using target database controlfile instead of recovery catalog
...
/home1/user01/ORADATA/ARCHIVE1/1_3.dbf
/home1/user01/ORADATA/ARCHIVE1/1_4.dbf
archive log filename=/home1/user01/ORADATA/ARCHIVE1/1_3.dbf thread=1
sequence=3
Finished recover at 16-APR-02
RMAN> exit
Open the database with the resetlogs option and get a row count for the DEPARTMENTS2
table. If it returns the same count as step 1, then the recovery was successful. Always
perform a reset and a backup after opening the database with the resetlogs option. Finally,
bounce the database.
SQL> alter database open resetlogs;
COUNT(*)
---------27
SQL> exit
RMAN> shutdown immediate;
RMAN> startup;
Recover a single block

3. Using the DEPARTMENTS table, corrupt a block in the object with the corrupt.sh script
and use the BLOCKRECOVER command to fix the corruption. The script needs two arguments;
the absolute filename and block number and should be run like the example below:
$ corrupt.sh $HOME/ORADATA/u02/example01.dbf 417
First, find the location of the DEPARTMENTS table. Query the V$DBA_EXTENTS table.
Ensure that you have write privileges on the data file. If not, use the chmod command
to correct this.
SQL> select file_id, block_id from dba_extents
2 where segment_name = 'DEPARTMENTS';
FILE_ID
BLOCK_ID
---------- ---------5
417
SQL> select file#, name from v$datafile;
FILE# NAME
---------- -------------------------------------------1 /home1/user01/ORADATA/u01/system01.dbf
2 /home1/user01/ORADATA/u02/undotbs01.dbf
3 /home1/user01/ORADATA/u03/users01.dbf
4 /home1/user01/ORADATA/u03/indx01.dbf
5 /home1/user01/ORADATA/u02/example01.dbf
6 /home1/user01/ORADATA/u04/rcvcat.dbf
SQL> exit
$ ls l $HOME/ORADATA/u02/example01.dbf
-rw-rw----
1 ora9i
dba
31461376 May
9 22:45 example01.dbf
Corrupt the block identified in the query above (in this case 417 in example01.dbf) by
using the corrupt.sh shell script. Bounce the database to clear the buffer cache.
SQL> !
$ corrupt.sh /home1/user01/ORADATA/u02/example01.dbf 417
0+1 records in
0+1 records out
$ exit
SQL> startup
Perform a select against the DEPARTMENTS table to verify the corruption.

SQL> select * from hr.departments;
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 417)
ORA-01110: data file 5: '/home1/user01/ORADATA/u02/example01.dbf'
Use the BLOCKRECOVER command to fix the corruption.

RMAN> blockrecover datafile 5 block 417;
Starting blockrecover at 17-APR-02
...
restoring blocks of datafile 00005
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/u03/ora9ir2/dbs/03dm4rji_1_1 tag=null params=NULL
channel ORA_DISK_1: block restore complete
Finished blockrecover at 17-APR-02
RMAN> exit
Verify whether the corruption is repaired.

$ exit
SQL> select * from hr.departments;
DEPARTMENT_ID DEPARTMENT_NAME
MANAGER_ID LOCATION_ID
------------- ------------------------------ ---------- ----------10 Administration
200
1700
20 Marketing
201
1800
...
250 Retail Sales
1700
260 Recruiting
1700
270 Payroll
1700
27 rows selected.
Lesson 5 Practices
1. Use the LIST command to:
Get the current status of your backups
List backups by datafile
Identify the current database incarnation and identify the SCN at which it changed
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------19
Full
928K
DISK
00:00:00
17-APR-02
BP Key: 20
Status: AVAILABLE
Tag:
Piece Name: /home1/user01/ORADATA/u05/c-0574317449-20020417-00
Controlfile Included: Ckp SCN: 163384
Ckp time: 17-APR-02
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------23
Full
45M
DISK
00:00:24
17-APR-02
BP Key: 25
Status: AVAILABLE
Tag:
Piece Name: /u03/ora9ir2/dbs/03dm4rji_1_1
Ckp Time Name
---- -- ---- ---------- --------- ---2
5
6
Full 163636
Full 163636
Full 163636
17-APR-02 /home1/user01/ORADATA/u02/undotbs01.dbf
17-APR-02 /home1/user01/ORADATA/u02/example01.dbf
17-APR-02 /home1/user01/ORADATA/u04/rcvcat.dbf
BS Key Type LV Size

------- ---- -- ---------- ----------- ------------ --------------24
Full
90M
DISK
00:00:24
17-APR-02
BP Key: 26
Status: AVAILABLE
Tag:
Piece Name: /u03/ora9ir2/dbs/04dm4rjj_1_1
Ckp Time Name
---- -- ---- ---------- --------- ---1
3
4
Full 163637
Full 163637
Full 163637
17-APR-02 /home1/user01/ORADATA/u01/system01.dbf
17-APR-02 /home1/user01/ORADATA/u03/users01.dbf
17-APR-02 /home1/user01/ORADATA/u03/indx01.dbf
...
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------50
Full
928K
DISK
00:00:00
17-APR-02
BP Key: 51
Status: AVAILABLE
Tag:
Ckp time: 17-APR-02
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------66
Full
928K
DISK
00:00:00
17-APR-02
BP Key: 67
Status: AVAILABLE
Tag:
Ckp time: 17-APR-02
RMAN> list backup by file;

List of Datafile Backups
========================
File Key
---- ------1
473
415
381
274
259
...
5
473
382
274
259
6
473
382
274
259
TY
B
B
B
B
B
LV
-F
F
F
F
F
S
A
A
A
A
A
Ckp SCN
---------74588
74176
70420
69997
69942
Ckp Time
--------28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
#Pieces
------1
1
1
1
1
#Copies
------1
1
1
1
1
Tag
--TAG20020528T145408
WKLY_BKUP
TAG20020528T115053
TAG20020528T113959
TAG20020528T113852
B
B
B
B
B
B
B
B
F
F
F
F
F
F
F
F
A
A
A
A
A
A
A
A
74588
70421
69997
69942
74588
70421
69997
69942
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
28-MAY-02
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
TAG20020528T145408
TAG20020528T115053
TAG20020528T113959
TAG20020528T113852
TAG20020528T145408
TAG20020528T115053
TAG20020528T113959
TAG20020528T113852
S
A
A
A
#Pieces
------1
1
1
List of Archived Log Backups

============================
Thrd
---1
1
1
Seq
------1
2
3
Low SCN
---------70236
74241
74293
Low Time
--------28-MAY-02
28-MAY-02
28-MAY-02
BS Key
------441
440
454
RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key DB Name DB ID
------- ------- -------- -----------1
2
U02
775813490
1
73
U02
775813490
CUR
--NO
YES
#Copies
------1
1
1
Reset SCN
---------1
440227
Tag
--TAG20020528T144920
TAG20020528T144920
TAG20020528T144927
Reset Time
---------06-MAR-02
27-MAR-02
2. Use CONFIGURE to change the REDUNDANCY to two. Using REPORT:

Identify files that have less than four redundant backups.
Identify files whose recovery needs more than seven days of archived logs.
Identify backups that are obsolete according to the new retention policy
View your database schema
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY = 2;
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters:

new RMAN configuration parameters are successfully stored
RMAN> report need backup redundancy = 4;
Report of files with less than 4 redundant backups
File #bkps Name
---- ----- ----------------------------------------------------1
3
/home1/user01/ORADATA/u01/system01.dbf
2
3
3
3
4
3
5
3
6
3
RMAN> report need backup days = 7;
Report of files whose recovery needs more than 7 days of archived logs
File Days Name
---- ----- ----------------------------------------------------RMAN> report obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 2
Report of obsolete backups and copies
Type
Key
Completion Time
Filename/Handle
-------------------- ------ ------------------ -------------------Backup Set
19
17-APR-02
Backup Piece
20
17-APR-02
/home1/user01/ORADATA/u05/c0574317449-20020417-00
...
Backup Set
Backup Piece
50
51
17-APR-02
17-APR-02
/home1/user01/ORADATA/u05/c-
0574317449-20020417-02
RMAN> report schema;

Report of database schema
File K-bytes
Tablespace
---- ---------- -------------1
102400 SYSTEM
2
56320 UNDOTBS
3
15360 USERS
4
46080 INDX
5
71680 SAMPLE
6
20480 RCVCAT
RB segs
------YES
YES
NO
NO
NO
NO
Datafile Name
------------------/home1/user01/ORADATA/u01/system01.dbf
3. Delete obsolete backups as identified in practice 2.

RMAN> delete obsolete;
Deleting the following obsolete backups and copies:
Type
Key
Completion Time
Filename/Handle
-------------------- ------ ------------------ -------------------Backup Set

66
17-APR-02
Backup Piece
67
17-APR-02
/home1/user01/ORADATA/u05/c-0574317449-20020417-03
Datafile Copy
54
17-APR-02
/home1/user01/BACKUP/RMAN/system01.dbf
...
Datafile Copy
64
17-APR-02
/home1/user01/BACKUP/RMAN/rcvcat.dbf
Do you really want to delete the above objects (enter YES or NO)? y
deleted backup piece
backup piece handle=/home1/user01/ORADATA/u05/c-0574317449-20020417-03
recid=8 stamp=459448496
...
deleted datafile copy
datafile copy filename=/home1/user01/BACKUP/RMAN/rcvcat.dbf recid=6
stamp=459448494
Deleted 7 objects
4. Create a stored script called whole_bkup that allocates a disk channel and backs up the
entire database. Run the script to be sure it works properly. Query the appropriate view to see
the script lines. Next, use the PRINT command to view the stored script lines.
Create and store the script.
RMAN> create script whole_bkup
2> {
3> ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/%U';
4> backup database;
5> }
Test the script to be sure it works properly.

RMAN> run {execute script whole_bkup;}
allocated channel: d1
channel d1: sid=14 devtype=DISK
...
piece handle=/home1/user01/ORADATA/u05/c0574317449-20020417-06
comment=NONE
released channel: d1
RMAN>
Issue the RMAN print script command to view the stored script lines.
RMAN> print script whole_bkup;
printing stored script: whole_bkup
{
ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/%U';

backup database;
}
A query against RC_STORED_SCRIPT_LINE will also show the stored script.

RMAN> exit
$ sqlplus rman/rman
SQL> SELECT TEXT FROM RC_STORED_SCRIPT_LINE
2 WHERE SCRIPT_NAME = 'whole_bkup';
TEXT
------------------------------------------------------------------------{
ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/%U';
backup database;
}
Lesson 6 Practices
Configure the channel SBT_TAPE to use Oracles SBT dummy disk API. Use the
SBT_LIBRARY parameter to direct RMAN to load the proper library. Configure the
SBT_TAPE channel to be the default channel. Test the SBT configuration by performing a
backup. Troubleshoot the configuration if unsuccessful.
First, issue the show all command to view the current configuration.
RMAN> show all;
CONFIGURE DEFAULT DEVICE TYPE TO 'DISK';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'$HOME/ORADATA/u05/%F';
'/home1/user01/ORADATA/u06/C1_%U';
'/home1/user01/ORADATA/u06/C2_%U';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home1/user01/ORADATA/u06/snapcf_U01.f';
Issue the configure channel command to configure the SBT_TAPE channel. Set
the SBT_LIBRARY parameter to oracle.disksbt. Configure SBT_TAPE as the
default channel.
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS="SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/home1/user01/ORADATA/u06)";
...
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
...
Back up the database to test the configuration.

channel ORA_SBT_TAPE_1: starting full datafile backupset
channel ORA_SBT_TAPE_1: specifying datafile(s) in backupset
input datafile fno=00005 name=/home1/user01/ORADATA/u02/example01.dbf
input datafile fno=00002 name=/home1/user01/ORADATA/u02/undotbs01.dbf

input datafile fno=00004 name=/home1/user01/ORADATA/u03/indx01.dbf
input datafile fno=00006 name=/home1/user01/ORADATA/u04/rcvcat.dbf
input datafile fno=00003 name=/home1/user01/ORADATA/u03/users01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 18-APR-02
channel ORA_SBT_TAPE_1: finished piece 1 at 18-APR-02
piece handle=0qdm7743_1_1 comment=API Version 2.0,MMS Version 8.1.3.0
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:25
piece handle=c-0574317449-20020418-01 comment=API Version 2.0,MMS Version
8.1.3.0
If you receive an error, then troubleshoot the configuration. The following are a few
common configuration errors.
The failure to set the BACKUP_DIR parameter (required by the Oracle SBT Disk API)
will produce the following error stack:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27000: skgfqsbi: failed to initialize storage subsystem (SBT) layer
ORA-19511: Error received from media manager layer, error text:SBT error = 4110,
errno = 0, Oracle Test Disk API: BACKUP_DIR environment variable is not set
The failure to write the backup piece and the initial SBT catalog will result in this error.
Make sure that BACKUP_DIR can be written by the owner of the Oracle binaries or by
members of the DBA group.
RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_SBT_TAPE_1 channel at 04/18/2002
09:58:44
ORA-19506: failed to create sequential file, name="0ndm75aj_1_1", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
sbtpvt_catalog_open: file $HOME/ORADATA/u06/Oracle_Disk_SBT_Catalog, open
error, errno = 2
An improperly configured default device will produce an error stack like this:
RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
ORA-19569: no device is allocated to this session
RMAN-00600: internal error, arguments [6027] [1] [] [] []
Mismatched quotes or parenthesis will produce an error stack like this:

RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
ORA-27207: syntax error in device PARMS - parentheses mismatch or missing
Lesson 7 Practices
1. Use RMAN to set a backup in progress. While the backup is running, log on to the target
database by using another telnet session and examine the view V$SESSION_LONGOPS. By
using this view you can determine if the backup is progressing, or hanging. If the backup is
progressing, the time_remaining column should be decreasing.
Start RMAN and back up the database.
From another session:

Before backup starts:
SQL> select sid, start_time, elapsed_seconds, time_remaining from
v$session_longops;
no rows selected
Just after backup starts:

v$session_longops;
SID START_TIM ELAPSED_SECONDS TIME_REMAINING
---------- --------- --------------- -------------10 19-APR-02
0
About 5 seconds later:

v$session_longops;
SID
---------10
15
15
START_TIM ELAPSED_SECONDS TIME_REMAINING

--------- --------------- -------------19-APR-02
0
19-APR-02
8
15
19-APR-02
8

v$session_longops;
SID
---------10
15
15

--------- --------------- -------------19-APR-02
0
19-APR-02
11
10
19-APR-02
11

v$session_longops;
SID START_TIM ELAPSED_SECONDS TIME_REMAINING
---------- --------- --------------- -------------10 19-APR-02
0
15 19-APR-02
14
5
15 19-APR-02
14

v$session_longops;
SID
---------10
15
15

--------- --------------- -------------19-APR-02
0
19-APR-02
20
0
19-APR-02
20
0
About 5 seconds later (controlfile autobackup has just started):

v$session_longops;
SID
---------10
15
15
13

--------- --------------- -------------19-APR-02
25
0
19-APR-02
20
0
19-APR-02
20
0
19-APR-02
0
0
Backup has finished:

v$session_longops;
SID
---------10
15
15
13
10

--------- --------------- -------------19-APR-02
31
0
19-APR-02
20
0
19-APR-02
20
0
19-APR-02
0
0
19-APR-02
0
0
The decreasing TIME_REMAINING value indicates that this backup is progressing normally.
It is also interesting to see the server processes starting as the backup progresses. You can see
the initial process started when the backup is initiated, you can see the process that is
associated with the media manager starting and processing the backup and finally, the
process associated with the control file autobackups, which are done to disk.
2. Using RMAN perform another backup by using the DEBUG option. On completion of the
backup script, examine the trace file that is produced by DEBUG.
$ rman target / catalog rman/rman trace $HOME/rman.out
RMAN> run {
2> debug on;
3> backup database;
4> debug off;
5> }
Debugging set to level=9, types=ALL
using channel ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: starting full datafile backupset
channel ORA_SBT_TAPE_1: specifying datafile(s) in backupset
...
Debugging turned off
RMAN> exit
$ vi rman.out
Recovery Manager: Release 9.2.0.0.0 - Beta
(c) Copyright 2001 Oracle Corporation.
All rights reserved.
ORACLE_HOME = /u03/ora9ir2
System name:
SunOS
Node name:
stc-sun02
Release:
5.8
Version:
Generic_108528-05
Machine:
sun4u
Starting with debugging set to level=9, types=ALL
DBGSQL: EXEC SQL AT TARGET select decode(status,'OPEN',1,0) into :b1 from
v$instance
DBGSQL:
sqlcode=0
DBGSQL:
:b1 = 1
...
# Version Setting
DBGSQL: EXEC SQL AT TARGET declare vsn varchar2 ( 20 ) ; begin vsn :=
dbms_rcvman . getPackageVersion ; :pkg_vsn:pkg_vsn_i := vsn ;
if vsn is not null then :pkg_vsnub4 := to_number ( substr ( vsn , 1 , 2 ) ||
substr ( vsn , 4 , 2 ) || substr ( vsn , 7 , 2 ) ) ; en
d if ; end ;
DBGSQL:
sqlcode=0
DBGSQL:
:b1 = "08.00.04"
DBGSQL:
:b3 = 80004
...
DBGSQL: EXEC SQL AT TARGET declare vsn varchar2 ( 20 ) ; begin vsn :=
dbms_rcvman . getPackageVersion ; :pkg_vsn:pkg_vsn_i := vsn ;
if vsn is not null then :pkg_vsnub4 := to_number ( substr ( vsn , 1 , 2 ) ||
substr ( vsn , 4 , 2 ) || substr ( vsn , 7 , 2 ) ) ; en
d if ; end ;
DBGSQL:
sqlcode=0
DBGSQL:
:b1 = "09.02.00"
DBGSQL:
:b3 = 90200
...
DBGSQL: EXEC SQL AT RCVCAT select user into :b1 from dual
DBGSQL:
sqlcode=0
DBGSQL:
:b1 = "RMAN"
# Encoding the backup request
RMAN> 2> 3> 4> 5>
DBGMISC: Node # 1
DBGMISC: run
DBGMISC:
1 JCL
DBGMISC:
1 DEBUG
DBGMISC:
1 ON
DBGMISC:
2 backup
DBGMISC:
1 BSLIST
DBGMISC:
1 BSPEC
DBGMISC:
1 DBASE
DBGMISC:
3 DEBUG
DBGMISC:
1 OFF
...
Debugging set to level=9, types=ALL
DBGMISC: EXITED krmice on [04/19/2002 14:25:12]
...
# Finishing up
DBGRPC:
krmqgns: no work found for channel ORA_SBT_TAPE_1 (krmqgns)
DBGRPC:
(krmqgns)
DBGRPC:
EXITED krmqgns with status 1 on [04/19/2002 14:25:46]
DBGMISC:
EXITED krmice on [04/19/2002 14:25:46]
DBGMISC:
ENTERED krmice on [04/19/2002 14:25:46]
DBGMISC:
command to be compiled and executed is: DEBUG
DBGMISC:
command after this command is: NONE (krmice)
Debugging turned off
(krmice)
3. Run the shell script les07_03.sh. After doing this, perform a database backup by using the
SBT_TAPE device. Use the error stack to identify the problem. If it is indeterminate, look at
the files (trace files, sbtio.log) in USER_DUMP_DEST or use debug to gather more
information. Correct the error and rerun the backup to verify the repair.
From the operating system prompt, run the les07_03.sh script. Start RMAN and back up
the database, observing any errors.
$ les07_03.sh
starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on t1 channel at 05/07/2002
13:42:26
ORA-27211: Failed to load Media Management Library
This appears to be a media management problem but more information is necessary to

determine the cause. Looking at the latest trace file, unn_ora_nnn.trc in
USER_DUMP_DEST gives a clue to the problem:
*** SESSION ID:(15.22) 2002-05-07 13:55:44.577
Failed to load SBT library phony.disksbt
This is not correct. The SBT library that needs to be loaded is defined by the SBT_LIBRARY
parameter of the configure channel command. Use the show command to see how it
is currently defined:
RMAN> show channel;
"SBT_LIBRARY=phony.disksbt,ENV=(BACKUP_DIR=$HOME/ORADATA/u06)";
...
Use the configure command to change the SBT_LIBRARY parameter to

oracle.disksbt and rerun the backup to confirm the correction. If you have difficulty,
then refer to the $HOME/les07_03.log file, which contains your original consistent
configuration.
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS="SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=$HOME/ORADATA/u06)";
old RMAN configuration parameters:
"SBT_LIBRARY=phony.disksbt,ENV=(BACKUP_DIR=$HOME/ORADATA/u06)";
new RMAN configuration parameters:
"SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/home1/user01/ORADATA/u06)";
starting full resync of recovery catalog
Starting backup at 07-MAY-02
...
Finished backup at 07-MAY-02
4. Run the shell script les07_04.sh. After doing this, perform a database backup by using
the persistent configuration. Investigate the alert log and trace files for any clues. If this does
not work, then use debug to gather more information. Correct the condition and run the
backup.
After running the les07_04.sh shell script, use RMAN to perform a backup and
observe the error:
...
RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/30/2002 17:536
ORA-19504: failed to create file "/home1/user01/ORADATA/u06/C1_0udppd9k_1_1"
ORA-27040: skgfrcre: create error, unable to create file
SVR4 Error: 13: Permission denied
The error SVR4 Error: 13: Permission denied is an operating system error.
Running the backup again with the debug option may provide some useful information.
$ rman target / catalog rman/rman debug trace $HOME/rman.out
RMAN> exit
$ vi rman.out
...
RMAN-00571: ===========================================================
RMAN-00571: ===========================================================
RMAN-10035: exception raised in RPC:
RMAN-10031: RPC Error: ORA-19624 occurred during call to DBMS_BACKUP_RESTORE.BE
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/30/2002 17:547
RMAN-10032: unhandled exception during execution of job step 1:
ORA-19624: operation failed, retry possible
ORA-19504: failed to create file "/home1/user01/ORADATA/u06/C1_10dppdat_1_1"
ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 625
ORA-06512: at line 255
RMAN-10035: exception raised in RPC:
ORA-19624: operation failed, retry possible
ORA-19504: failed to create file "/home1/user01/ORADATA/u06/C1_10dppdat_1_1"
...
OS raises the SVR4 (Unix System V Kernel Release 4) exception. This looks like a
permissions issue. Using cd, navigate ORADATA and inspect the u06 directory.
$ pwd
/home1/user01
$ cd ORADATA
$ ls -la
total 21316
drwxrwxr-x 10
drwxrwxrwx 10
drwxrwsr-x
2
-rw-rw---1
drwxrwsr-x
2
drwxrwsr-x
2
drwxrwsr-x
2
drwxrwsr-x
2
drwxrwsr-x
2
drwxrwsr-x
2
dr-xr-s--2
user01
user01
user121
user121
user121
user121
user121
user121
user121
user121
user121
dba
dba
class7
class7
class7
class7
class7
class7
class7
class7
class7
512
512
96
4096
96
96
8192
8192
96
8192
8192
May
May
May
May
May
May
May
May
May
May
May
7
7
29
29
28
30
30
30
30
29
29
17:32
17:23
17:52
14:26
16:33
06:23
06:23
06:23
06:23
17:59
17:58
.
..
ARCHIVE1
ARCHIVE15_193_0_60083.bkd
ARCHIVE2
u01
u02
u03
u04
u05
u06
Notice that there are no write privileges on u06 where the backup pieces are to be
written. Use chmod to give write privileges to the user and the group and retest the
backup.
$ chmod 770 u06
$ ls -ld u06
drwxrws--2 user01
dba
...
Finished backup at 07-MAY-02
512 May
7 16:18 u06

Oracle9i Database - Advanced Backup and Recovery Using RMAN - Student Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle9i Database - Advanced Backup and Recovery Using RMAN - Student Guide

Uploaded by

Copyright:

Available Formats

Oracle9i Database: Advanced Backup

and Recovery Using RMAN

Copyright Oracle Corporation, 2003. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is

Restricted Rights Legend

1 Overview of Recovery Manager (RMAN)

Catalog Maintenance Commands 2-16

Algorithm Behavior for Archivelog Backup Sets 3-27

RMAN BMR Interface 4-31

Troubleshooting: Media Manager or RMAN 6-19

Asynchronous I/O Bottlenecks 8-11

Overview of Recovery Manager (RMAN)

Copyright 2003, Oracle. All rights reserved.

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-2

It is an Oracle utility that can back up, restore, and

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-3

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-4

Corrupt block detection

Copyright 2003, Oracle. All rights reserved.

RMAN Features (continued)

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-5

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-6

The RMAN Environment

Copyright 2003, Oracle. All rights reserved.

The RMAN Environment

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-7

RMAN and Enterprise Manager

Copyright 2003, Oracle. All rights reserved.

Using Enterprise Manager

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-8

RMAN Version Compatibility

Copyright 2003, Oracle. All rights reserved.

RMAN Version Compatibility

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-9

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-10

Copyright 2003, Oracle. All rights reserved.

RMAN Components (continued)

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-11

RMAN Utility Executable

Copyright 2003, Oracle. All rights reserved.

RMAN Utility Executable

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-12

RMAN does not work without recover.bsq.

The recover.bsq file location is port-specific.

recover.bsq is also called the RMAN library file

Copyright 2003, Oracle. All rights reserved.

The recover.bsq File

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-13

The recovery catalog consists of the following

Base tables and indexes

All information in the recovery catalog originates

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-14

Both the V$ views and X$ tables can be queried

Copyright 2003, Oracle. All rights reserved.

Control File Table and Views

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-15

It is a fixed package that is linked to the kernel so

Copyright 2003, Oracle. All rights reserved.

Oracle9i Database: Advanced Backup and Recovery Using RMAN 1-16