Oracle 9i - Database Supporting Recovery Manager - RMAN - Student Guide

Oracle9i Database: Supporting
Recovery Manager
Student Guide
n l y
e O
U s
A I
O
l &
na
te r
D13929GC10 I n
l e
Production 1.0
c
June 2002
a
D34786
r
O
Author Copyright © Oracle Corporation, 2002. 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
Technical Contributors is also protected by copyright law. Reverse engineering of the software is prohibited.
and Reviewers 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
Agustin Amador applicable:
Darren Price
Donna Keesling Restricted Rights Legend
Harald van Breederode
Use, duplication or disclosure by the Government is subject to restrictions for
Jaime Figueroa commercial computer software and shall be deemed to be Restricted Rights software
Janet Stern under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Lex De Haan Rights in Technical Data and Computer Software (October 1988).
Matthew Arrocha
This material or any portion of it may not be copied in any form or by any means
Matthew Hart without the express prior written permission of Oracle Corporation. Any other copying
Muthu Olagappan is a violation of copyright law and may result in civil and/or criminal penalties.
Petter Stene
If this documentation is delivered to a U.S. Government Agency not within the
Ravinder Ransi Department of Defense, then it is delivered with “Restricted Rights,” as defined in
Ric Van Dyke FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
Sharmila Kulasekaram
Vicki Obrien 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.
Publisher Oracle Corporation does not warrant that this document is error-free.
Glenn Austin
Oracle and all references to 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Contents
1 Overview of Recovery Manager

Objectives 1-2
Recovery Manager 1-3
RMAN Features 1-4
RMAN Architecture 1-6
The RMAN Environment 1-7
RMAN Version Compatibility 1-8
RMAN Components 1-9
Recovery Manager Utility Executable 1-11
Recovery Manager Executable: The recover.bsq File 1-12
Recovery Catalog 1-13
Target Database: Controlfile Tables and Views 1-14
Target Database: SYS.DBMS_RCVMAN 1-15
Target Database: DBMS_BACKUP_RESTORE 1-16
Channels and Media Manager Server 1-18
Running RMAN Commands 1-19
Simple Backup and Recovery Concepts 1-20
Database Inconsistency 1-22
Comparing Redo and Undo 1-24
Redo and Undo Generation 1-25
Recovery Concepts 1-26 n l y
Crash and Media Recovery Differences 1-27
Stuck Recovery 1-29
e O
NOLOGGING and Recovery 1-30
U s
2
Summary 1-31
Configuring RMAN
A I
Objectives 2-2
O
RMAN Configuration Decisions 2-3
Issues to Consider 2-4
l &
a
Using RMAN Without a Recovery Catalog 2-5
n
te r
Steps to Create the Recovery Catalog 2-6
Creating an RMAN User 2-7
I n
Creating the Repository 2-8
Recovery Catalog Strategy 2-9
l e
RMAN Backup Strategy Guidelines 2-10
c
Ways to Start RMAN 2-11
r a
Oracle Real Application Clusters 2-12
Connecting to an Auxiliary Database 2-13
O 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
CONFIGURE RETENTION POLICY Command 2-25
Automatic Channel Allocation 2-26
The CONFIGURE CHANNEL Command 2-27
CONFIGURE CONTROLFILE AUTOBACKUP 2-28
CONFIGURE SNAPSHOT CONTROLFILE and CONFIGURE AUXNAME 2-29
Other Configuration Commands 2-30
Calling Configuration Sets 2-31
CATALOG Command 2-32
Catalog of Consistent and Inconsistent Copies 2-33
Recovery Catalog Compatibility 2-34
Determine the Schema Version of the Recovery Catalog 2-35
Upgrading Recovery Catalog 2-36
Dropping the Recovery Catalog 2-37
Summary 2-38
3
Practice Overview: Configuring RMAN 2-39
Backups with RMAN n l y

Objectives 3-2
RMAN Backups 3-3
e O
Running the BACKUP Command 3-4
Backup Tags 3-6
U s
RMAN Managed Backups 3-7
Parallelization of File Copies 3-8 A I
Backup Set 3-9 O
Backup Set Example 3-10
Archivelog Backup Sets 3-11
l &
n a
Parallelization of Backup Sets 3-12
Backup Pieces 3-13
te r
Backup Piece Contents 3-14
I n
Incremental Data File Backup 3-15
Cumulative Incremental Backups 3-16
l e
SCN and Incremental Backups 3-17
c
Basic Backup Algorithm 3-18
r a
Algorithm Rules 3-19
O Advanced Algorithm 3-21

Algorithm Behavior for Standard Backup Sets 3-22
Algorithm Behavior for Archivelog Backup Sets 3-24
iv
Algorithm Behavior for File Copies 3-25
Backup Optimization 3-26
Backup Optimization Algorithm 3-27
Duplexed Backups 3-29
Mirrored Backups 3-32
Proxy Copy 3-33
Backup Set Backup 3-34
Archived Log Backups 3-35
Archivelog Backup Methods 3-36
Long Term Backups 3-37
Test Backups Using RMAN 3-38
Restarting a Backup 3-40
Default Autolocation for Oracle Real Application Clusters 3-41
Summary 3-42
Practice Overview: Backups With Recovery Manager 3-43
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
Restore Concepts 4-7
Restoring Data Files and Tablespaces 4-8
Restoring Archived Logs 4-9
Restoring the Server Parameter File 4-10
n l y
Parallelization of RESTORE 4-12
Restoring the Database to a New Host 4-13
Restoring the Database to a New Host 4-14
e O
Create Standby Database with DUPLICATE 4-16
Validating Restore of Backups and Copies 4-17
U s
Restore Autolocation 4-19
Restore When All Is Lost 4-20
A I
Recovery Types 4-22
Recovery Concepts 4-23 O
Basic RMAN Media Recovery 4-24
l &
RMAN Recovery Phases 4-25
n
Parallelization of Recovery 4-27a
te r
Incomplete Database Recovery 4-28
Block Media Recovery 4-29
I n
Other BMR Benefits 4-30
The BLOCKRECOVER Command 4-31
l e
RMAN BMR Interface 4-33
c
Trial Recovery 4-34
r a
Tablespace Recovery Example 4-35
Recover Database Example 4-36
O Recover a NOARCHIVELOG Database Example 4-38
DBPITR Example 4-39
BLOCKRECOVER Examples 4-40
v
Summary 4-42
Practice Overview: Restore and Recovery with RMAN 4-43
5 RMAN Maintenance
Objectives 5-2
Oracle9i Command Unification 5-3
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 CHANGE…UNAVAILABLE and CHANGE…AVAILABLE Commands 5-16
CHANGE…UNCATALOG Command 5-17
Deleting Specified Backups and Copies 5-18
Deleting Expired or Obsolete Backups 5-20
Stored Script Information 5-21
Maintenance Required When Not Using a Recovery Catalog 5-22
Summary 5-23
6
Practice Overview: RMAN Maintenance 5-24
Using RMAN with a Media Manager

n l y
Objectives 6-2
Backups to Tape 6-3
e O
Media Manager 6-4
Media Manager Prerequisites 6-5
U s
Linking a Media Manager on UNIX 6-6
Linking a Media Manager on NT 6-8
A I
O
Testing the Media Manager Installation 6-9
Perform a Test Backup to Tape 6-10
l &
Automatic Channels and Media Manager 6-11
Default SBT Interface 6-13
n a
te r
Events in a Media Manager Backup 6-14
Events in a Media Manager Restore 6-16
I n
Media Manager Diagnostics 6-18
Troubleshooting: Media Manager or RMAN 6-19
l e
Troubleshooting Media Manager 6-26
c
SBTINIT and SBTINIT2 Function Errors 6-28
r a
SBTOPEN or SBTBACKUP Failures 6-30
SBTOPEN or SBTRESTORE Failures 6-31
O SBTWRITE or SBTREAD Failures 6-32
SBT API Return Codes 6-33
vi
Media Manager 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 Recovery Manager 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 Media Manager 7-22
RPC Call Fails 7-24
Snapshot Control File Creation Failure 7-25
RMAN Cannot Locate an Archived Log 7-27 n l y
Missing Log Causes Duplication Failure 7-29
Summary 7-30
e O
Practice Overview: Debugging RMAN 7-31
U s
8 RMAN Performance Tuning
Objectives 8-2
A I
Tuning RMAN 8-3
RMAN Disk Buffer Allocation 8-4 O
l
Disk Buffer Allocation Example 8-5&
Tape Buffer Allocation 8-6
n a
te r
Synchronous Versus Asynchronous I/O 8-7
Synchronous Versus Asynchronous I/O 8-8
Setting LARGE_POOL_SIZE 8-9
I n
Performance Monitoring 8-10
l e
Asynchronous I/O Bottlenecks 8-11
c
Synchronous I/O Bottlenecks 8-12
r a
Tape Backup Speed 8-13
Tape Subsystem Performance Rules 8-14
O Empty Files and Incremental Backups 8-15
Control Tape Buffer Size with BLKSIZE 8-17
vii
Channel Tuning 8-18
Tuning the BACKUP Command 8-19
Summary 8-20
Appendix A
Appendix B
Appendix C
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
viii
Preface
Profile
Before You Begin This Course
Before you begin this course, you should have the following qualifications:
• Thorough knowledge of Oracle database administration and backup and

recovery concepts.
• Working experience with Recovery Manager
Prerequisites
• Oracle9i Database Administration Fundamentals I and II or similar.
How This Course Is Organized
Oracle9i Release 2 Database: Supporting Recovery Manager is an instructor-led

course featuring lecture and hands-on exercises. Online demonstrations and
written practice sessions reinforce the concepts and skills introduced.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Copyright Oracle Corporation, 2002. All rights reserved.
Preface-1
Related Publications
Oracle Publications
Title Part Number
Oracle8i Online Generic Documentation CD-ROM A87860
Oracle9i Online Generic Documentation CD-ROM
Additional Publications
• System release bulletins
• Installation and user’s guides
• Selected WebIV Notes
• read.me files
• Oracle Magazine
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Preface-2
Typographic Conventions
Typographic Conventions in Text
Convention Element Example

Bold italic Glossary term (if The algorithm inserts the new key.
there is a glossary)
Caps and Buttons, Click the Executable button.

lowercase check boxes, Select the Can’t Delete Card check box.
triggers, Assign a When-Validate-Item trigger to the
windows ORD block.
Open the Master Schedule window.
Courier new, Code output, Code output: debug.set (‘I”, 300);

case sensitive directory names, Directory: bin (DOS), $FMHOME (UNIX)
(default is filenames, Filename: Locate the init.ora file.
lowercase) passwords, Password: User tiger as your password.
pathnames, Pathname: Open c:\my_docs\projects
URLs, URL: Go to http://www.oracle.com
user input,
User input: Enter 300
usernames
Username: Log on as scott
Initial cap Graphics labels

(unless the term is a
Customer address (but Oracle Payables)
n l y
proper noun)
e O
Italic Emphasized words
and phrases,
Do not save changes to the database.
U s
For further information, see Oracle7 Server
titles of books and
courses,
variables
I
SQL Language Reference Manual.
A
Enter user_id@us.oracle.com,
where user_id is the name of the user.
Quotation Interface elements
O
Select “Include a reusable module component”
marks with long names
that have only &
and click Finish.
l
initial caps;
n
lesson and chapter a This subject is covered in Unit II, Lesson 3,
“Working with Objects.”
te
references
r
titles in cross-
Uppercase I n
SQL column Use the SELECT command to view
c l e names, commands,
functions, schemas,
information stored in the LAST_NAME
column of the EMP table.
r a table names
OConvention
Arrow
Element
Menu paths
Example
Select File > Save.
Preface-3
Brackets Key names Press [Enter].
Commas Key sequences Press and release keys one at a time:

[Alternate], [F], [D]
Plus signs Key combinations Press and hold these keys simultaneously:
[Ctrl]+[Alt]+[Del]
Typographic Conventions in Code
Convention Element Example

Caps and Oracle Forms When-Validate-Item
lowercase triggers
Lowercase Column names, SELECT last_name
table names FROM s_emp;
Passwords DROP USER scott

IDENTIFIED BY tiger;
PL/SQL objects OG_ACTIVATE_LAYER
(OG_GET_LAYER
(‘prod_pie_layer’))
Lowercase Syntax variables CREATE ROLE role

italic
Uppercase SQL commands and
functions
SELECT userid
FROM emp;
n l y
Typographic Conventions in Navigation Paths
e O
This course uses simplified navigation paths, such as the following example, to
direct you through Oracle Applications.
U s
A I
(N) Invoice > Entry > Invoice Batches Summary (M) Query > Find (B) Approve
This simplified path translates to the following: O

1.
l &
(N) From the Navigator window, select Invoice > Entry > Invoice Batches
Summary.
n a
2.
te r
(M) From the menu, select Query > Find.
3.
I n
(B) Click the Approve button.
l
Notations :
c e
r a
(N) = Navigator
O (M) = Menu
(T) = Tab
Preface-4
(I) = Icon
(H) = Hyperlink
(B) = Button
Typographical Conventions in Help System Paths
This course uses a “navigation path” convention to represent actions you perform
to find pertinent information in the Oracle Applications Help System.
The following help navigation path, for example—
(Help) General Ledger > Journals > Enter Journals
—represents the following sequence of actions:
1. In the navigation frame of the help system window, expand the General
Ledger entry.
2. Under the General Ledger entry, expand Journals.
3. Under Journals, select Enter Journals.
4. Review the Enter Journals topic that appears in the document frame of the
help system window.
n l y
Getting Help
e O
Oracle Applications provides you with a complete online help facility.
Whenever you need assistance, simply choose an item from the Help menu to U s
pinpoint the type of information you want.
A I
To display help for a current window:
O
1.
l &
Choose Window Help from the Help menu, click the Help button on the
a
toolbar, or hold down the Control key and type 'h'.
n
te r
A web browser window appears, containing search and navigation frames on
the left, and a frame that displays help documents on the right.
I n
The document frame provides information on the window containing the
l e
cursor. The navigation frame displays the top-level topics for your
c
responsibility, arranged in a tree control.
r
2. a
If the document frame contains a list of topics associated with the window,
O click on a topic of interest to display more detailed information.
Preface-5
3. You can navigate to other topics of interest in the help system, or choose
Close from your web browser's File menu to close help.
Searching for Help
You can perform a search to find the Oracle Applications help information you
want. Simply enter your query in the text field located in the top-left frame of the
browser window when viewing help, then click the adjacent Find button.
A list of titles, ranked by relevance and linked to the documents in question, is

returned from your search in the right-hand document frame. Click on whichever
title seems to best answer your needs to display the complete document in this
frame. If the document doesn't fully answer your questions, use your browser's
Back button to return to the list of titles and try another.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Preface-6
Overview of Recovery Manager
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives
After completing this lesson, you should be able to do

the following:
• Understand the fundamentals of the Recovery
Manager (RMAN) architecture and its components
• Understand the features, components, and tasks
of RMAN
• Understand the basic concepts of consistency
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Oracle9i Database: Supporting Recovery Manager 1-2
Recovery Manager
• Recovery Manager (RMAN) 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 provides a powerful scripting language that can
be used in an interactive or batch mode.
• It is operating system independent.
n l y
e O
Recovery Manager
U s
I
RMAN is a tool that manages the process of creating backups and the process of restoring and
recovering from these backups. The product is a feature of the Oracle database server and does
A
not require separate installation. RMAN is a client/server application that uses database server
O
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.
l
n a
You can invoke RMAN as a command line executable from the operating system prompt or use
some RMAN features through the Enterprise Manager GUI.
te r
I n
c l e
r a
O
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
• Better performance during recovery
• No generation of extra redo during open database
backups
n l y
e O
RMAN Features
U s
I
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
A
for each data file, copy them to the correct place using operating system commands, and choose
which logs to apply, RMAN manages these tasks automatically. O
&
RMAN especially simplifies the backup and restore process when using Oracle Managed Files.
l
n a
When you use Oracle Managed Files, Oracle names and manages your data files, control files,
and online redo logs. This simplifies your management of these files. However it may be harder
te r
for you to keep track of the filenames of the various database files because you have not named
them yourself. By using RMAN, it handles all record keeping. For example, the addition of a
I n
data file will automatically be detected, and included within the next backup.
l e
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
c
r a
database after a consistent shutdown. You can restore the database by using incremental
backups, which means that you can restore a NOARCHIVELOG database.
O
RMAN Features
• Corrupt block detection

• Handles fractured blocks
• Automatic parallelization of backup, restore, and
recovery to improve performance
• Backups can be restricted to limit reads per file or
per second to avoid interfering with OLTP work
n l y
e O
RMAN Features (continued)
U s
I
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
A
executing SQL are also performed when backing up or restoring. RMAN also omits blocks that
O
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.
l
n a
When backing up online files, RMAN rereads fractured data blocks to get a consistent read. You
do not need to place online tablespaces in backup mode when performing backups. In addition,
te r
RMAN can limit the number of open files to overcome O/S limits on concurrent files opened and
limit the size of a backup piece. Users can limit reads per file per second so the backups effect on
I n
OLTP work can be minimized. Configuration of automatic parallelization of backup, restore, and
recovery functions greatly improve performance and ease of use. This is important as a backup
l e
piece size can easily be over the maximum file size allowed by the operating system or media
c
management software.
r a
O
RMAN Architecture
Target Target
Instance Controlfile
Server
session Fixed
(default) sys.dbms_rcvman tables and
views
Enterprise Recovery sys.dbms_backup_restore
Manager Manager
Server
media management layer
session
Server (polling)
session
(Catalog) Disk
Server
dbms_rcvcat session
dbms_rcvman (channel) Target
Database
Catalog Server Files
tables and Media Manager session
views (channel)
Recovery Tertiary
Catalog Storage
n l y
e O
RMAN Architecture
U s
The RMAN executable can run on any machine, with Oracle9i Net Services connections being
A I
made to the databases. The Recovery Catalog is a simple database schema residing in a database
separate from the target. Relevant information is obtained from the control file if a catalog is not
used. Using the Recovery Catalog is optional.
O
l &
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:
n a
te r
• Two sessions for administrative purposes. These will make use of several packages in the
database, which are installed when catproc.sql runs.
I n
• One session for every allocated channel. Channels transfer the actual database data.
• The control file is also stores schema, backup and recovery information. The control file
c l e
and the recovery catalog information are synchronized with RMAN.
• The Media Management Library (MML) is software that connects to a particular vendor’s
r a
tape backup system. This is linked into the Oracle executable at installation.
Backup disks must reside on the same machine as the target database. If you are working with a
O
tape system, it may reside anywhere. The MML software component ensures connectivity
between RMAN and the tape subsystem. Using Oracle Enterprise Manager to control RMAN is
optional.

The RMAN Environment
A typical RMAN environment utilizes the following

items:
• RMAN executable
• Target database
• Recovery catalog database
• Media management software
n l y
e O
The RMAN Environment
U s
I
The RMAN environment consists of the utilities and databases that play a role in a backup and
recovery strategy. Of the components listed above, only the RMAN executable and target
database are required. A
O
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
l
n a
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 you need in the catalog.
te r
I n
c l e
r a
O
RMAN Version Compatibility
• Four separate items must be compatible with one

another:
– The RMAN executable
– The target database
– The recovery catalog
– The database containing the recovery catalog
• RMAN cannot be used in any way with an Oracle7
database.
n l y
e O
RMAN Version Compatibility
U s
I
These four components listed above must be compatible. Please note that not all combinations
are supported. The RMAN executable of a later Oracle database version may expect to use some
A
feature in the target database that is not present in a lower version of the database. There are
three general rules: O
l &
• The RMAN catalog schema version (meaning version of RMAN that created or updated
the schema) should be equal or later than the catalog database version.
a
• The version RMAN catalog schema should be equal or later than the version of RMAN,
n
te r
that is, the RMAN catalog is backwards compatible to backup target databases. For
example, a catalog created with RMAN from Oracle9i works with RMAN of Oracle8i or
Oracle8.
I n
• Use the same version of the RMAN executable as the target database.
l e
RMAN does allow you to create multiple catalog schemas in a single 9i recovery catalog to store
c
all metadata of different releases like 8.1.5, 9.0.1, 9.0.2.
r a
Note: RMAN cannot be used in any way with an Oracle7 database.
O
For more details, see Note 73431.1 RMAN Compatibility Matrix and Guide.

RMAN Components
The RMAN tool consists of the following components:

• Recovery Manager executable (RMAN)
– RMAN library file: recover.bsq
• Recovery Catalog
– Tables
– Views
• RMAN Packages
– DBMS_RCVMAN
– DBMS_RCVCAT
– DBMS_BACKUP_RESTORE
n l y
e O
Recover Manager Executable (RMAN)
U s
I
The executable translates RMAN commands into a sequence of steps, which operate on 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. A
Recovery Catalog O
l &
The recovery catalog is a repository storing information relating to the target database obtained
a
from the target database control file. It contains information about the physical schema of the
n
te r
target database, data file, archivelog backup sets and pieces, data file copies, archived redo logs,
and stored scripts. If the recovery catalog is not used, RMAN queries the target database’s
RMAN Packages I n
control file to decide what actions to perform.
c l e
The DBMS_RCVMAN and DBMS_RCVCAT packages are used respectively by RMAN to query
r a
and update the recovery catalog. DBMS_BACKUP_RESTORE is the RPC interface to the code
that physically performs the backup, restore, and recovery actions
O
The recover.bsq File
The recover.bsq file is is also called the RMAN library file.

RMAN Components
• Target Database
• Control file fixed tables and views
• Channel (Server Sessions)
• Media management interface module
• Media Manager Server
n l y
e O
Target Database
U s
Control File Fixed Tables and Views
A I
The database on which the specified backup, restore, and recover actions will be executed.
O
The control file contains data used by RMAN to populate the recovery catalog.
Channel
l &
backup, restore, or recovery.
n a
For each channel, RMAN creates an Oracle Server process on the target database to perform the
Media Manager Interface

te r
I n
The media manager interface is an optional third-party media management interface module
linked with Oracle Server
c l e
Media Manager Server
r a
A non-Oracle product that communicates with the interface module to manage tertiary storage.
O
Recovery Manager
Utility Executable
The RMAN executable is responsible for:

• Parsing Recovery Manager command syntax
• Performing name translations relative to any time
specifications such as point-in-time recovery or
user specified tags
• Generating PL/SQL programs which make remote
procedure code (RPC) calls to the above packages
• Coordinating execution of PL/SQL calls on
channels allocated
• Updating the recovery catalog
n l y
e O
Recovery Manager Executable
U s
I
RMAN takes Recovery Manager command syntax, parses it for correctness, then translates these
commands into one or more PL/SQL programs. Each PL/SQL program is a step, with each step
A
having a status. For example, a backup command is broken down into steps, one per backup set.
O
For example, if there are five sets to create, and there are five channels allocated, then each
channel allocated will create a set.
l &
n a
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
$ORACLE_HOME/bin.
te r
executables. On UNIX systems, for example, the RMAN executable is located in
I n
To start the executable, simply enter the filename on the command line. For example, on a UNIX
system, enter:
$ rman
c l e
r a
O
Recovery Manager Executable:
• RMAN cannot function without the recover.bsq

file.
• The recover.bsq file contains a version number
that must match that of the RMAN executable or
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
• The recover.bsq file is is also called the RMAN
library file and each item it contains is called a
library member.
n l y
e O
U s
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 A I
• SQL statements O
l &
• PL/SQL package specifications and bodies used for CREATE CATALOG
• RMAN code fragments, used for recursive RMAN invocation during commands such as
a
DUPLICATE DATABASE and tablespace point-in-time recovery
n
te r
• External commands such as the export/import used by TSPITR
Many library members contain substitution variables (&args&) that are replaced with real
I n
values during compilation. Please see the example below:
e
define ‘kbytes’
<<<
c l
r a
sys.dbms_backup_restore.setLimit(
sys.dbms_backup_restore.kbytes,&args&);
O >>>

Recovery Catalog
• The Recovery Catalog consists of the following

components:
– Base tables and indexes
– RC_* views
– DBMS_RCVMAN package
– DBMS_RCVCAT package
• All information in the recovery catalog originates
in the target database control file.
n l y
e O
Recovery Catalog
U s
I
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 consist of several
components, which include: A
O
• Base tables and indexes: These tables and indexes should not need to be queried.
later lesson.
l &
• RC_* views: RC_* views can be queried. These views will be covered in more detail in a
a
• DBMS_RCVMAN package: RMAN queries the recovery catalog tables via the procedures in
n
views.
te r
this package. RMAN never selects data directly from the recovery catalog tables, it uses the
I n
• DBMS_RCVCAT package: RMAN updates the recovery catalog tables via the procedures
in this package. RMAN never updates the recovery catalog tables directly.
c l e
r a
O
Target Database:
Controlfile Tables and Views
• Both the V$ views and X$ tables can be queried

when the database is mounted but not open.
• All V$ control file fixed views are based on
underlying X$ fixed tables.
• Use V$FIXED_VIEW_DEFINITION to see the
underlying X$ tables used by the views.
n l y
e O
Controlfile Table and Views
U s
I
The control file data can be viewed from a collection of views. This data is the source of
information used by RMAN to populate the recovery catalog. Below is a partial list of available
tables and views: A
• V$BACKUP_ASYNC_IO O
• V$BACKUP_CORRUPTION
• V$BACKUP_DATAFILE
l &
• V$BACKUP_DEVICE
n a
• V$BACKUP_PIECE
• V$BACKUP_REDOLOG
te r
• V$BACKUP_SET
I n
• V$CONTROLFILE_RECORD_SECTION
l e
• V$COPY_CORRUPTION
• V$DATABASE
c
r a
• V$DATAFILE
O
Target Database:
SYS.DBMS_RCVMAN
The SYS.DBMS_RCVMAN functions read data from the

control file fixed views.
• This is an alternate implementation of the
DBMS_RCVMAN package.
• The package specification is the same as the one
that is used to access the recovery catalog.
• RMAN is insulated from having to know whether it
is accessing the control file or a recovery catalog.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
Target Database:
DBMS_BACKUP_RESTORE
• It is a fixed package, linked into the kernel so that

it can be called when the database is not open.
• It updates the target database’s control file with
information as to what actions have been
completed.
• The package specification is in dbmsbkrs.sql.
n l y
e O
SYSDBMS_BACKUP_RESTORE
U s
SYS.DBMS_BACKUP_RESTORE is the RPC interface to the code that physically performs the
backup, restore, and recovery actions that are requested by RMAN.
A I
O
Because it is linked into the Oracle executable, DBMS_BACKUP_RESTORE is callable whenever
an instance is started. The database does not need to be mounted or open.
l &
Note: Whenever Oracle documentation indicates to run a restore operation under circumstances
n a
such as with no recovery catalog or no control file, it indicates contacting support. What is meant
by this is that support will indicate which DBMS_BACKUP_RESTORE calls to make to recover a
te r
control file and RMAN can automate the restore from that point.
I n
c l e
r a
O
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;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Channels and Media Manager Server
• A channel represents one stream of data to a

device type.
• For each channel, RMAN creates an Oracle Server
process on the target database to perform the
backup, restore, or recovery.
• The Media Manager Server communicates with the
interface module to manage tertiary storage.
• Proxy copy is available through the media
manager.
n l y
e O
Channels
U s
I
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
A
recovery commands. Each channel establishes a connection from the RMAN executable to a
O
target or auxiliary database instance by starting a server session on the instance. The server
l &
session performs the backup, restore, and recovery operations. Only one RMAN session
communicates with the allocated server sessions. New with Oracle9i is automatic channel
a
allocation which relieves the user from the step of explicitly allocating a channel in a
n
te r
backup/restore or maintenance session.
Oracle has integrated proxy copy functionality into its media management API. Vendors can use
I n
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,
l e
which in turn makes all decisions regarding how and when to move the data.
c
r a
O
Running RMAN Commands
• Type them into the RMAN command line interface

– Individually:
RMAN> backup database;
– In a RUN block:
RMAN> run {
2> allocate channel c1 type disk;
3> copy datafile 10 to
4> '/oracle/prod/backup/prod_10.dbf';
5> }
• Invoking an RMAN command file:
RMAN> @copy_10.rcv
n l y
e O
Running RMAN Commands
U s
A I
RMAN commands can be run by several methods. The commands can be typed in manually
from an RMAN prompt as illustrated 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.. O
l &
The commands can also be stored in the recovery catalog as a stored script. A stored script is
n a
only associated with 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
te r
catalog and target database, issue a RUN command to execute the desired script. For example:
RMAN> RUN { EXECUTE SCRIPT backup_full; }
I n
Note that you do not need to run ALLOCATE CHANNEL if you already did so within the
c l e
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
r a
later lesson.
O
Simple Backup and Recovery Concepts
• Crash recovery versus media recovery

• Cold (offline) versus hot (online) backups
• Restore and recovery
• Read-only tablespaces
• Offline tablespaces
n l y
e O
Backup and Recovery Concepts
U s
I
A crashed database is a database that was not shut down in an orderly fashion. Crash recovery
occurs automatically when the database is reopened after an abrupt termination such as power
A
failure or SHUTDOWN ABORT. Only the online redo log files will be used. Deferred rollback of
O
any uncommitted transaction takes place after the database is open. Deferred rollback means
may even be done in parallel.

l &
that the rollback that used to take place before the database was open now takes place after and
n a
Media recovery occurs when the RECOVER command is used. It can use archive log files and the
te r
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
I n
closed normally. Deferred rollback of any uncommitted transaction occurs when the database is
opened.
c l e
A cold or offline backup is taken when the database is closed. With manual cold backups the
r a
instance can be shutdown, with RMAN offline backups the instance must be in MOUNT mode.
Although you can use a backup taken of a crashed database in a recovery scenario, it is not
O
recommended.

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 involved tablespaces must be placed in backup mode.
With RMAN online backups, a the re-reading of fractured blocks ensures block consistency.
Thus you do not place tablespaces into any special mode for backup.
There are usually two steps to a perform a media recovery: The optional first step 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 is to avoid taking repeated backups of data that does not change, and not 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 to the other data files. You do not perform media recovery on a read-only
tablespace’s 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
l
There may be reasons for only having a partial set of the database available. Offlining a
n y
tablespace causes the server to close the data files, thus freeing them for some operation (for
e O
example, moving to shelf storage). At some later time, the data files are returned to their original
location and can be made online again. If the tablespace is offlined IMMEDIATE, which requires
U s
ARCHIVELOG mode, then it will require media recovery as the related files were not closed
normally (the data in the buffer cache was not flushed). This occurs regardless of whether or not
A I
data was in the cache. Note that if you offline files, as opposed to offline tablespaces, you do not
get a choice. The process is “immediate,” thus requiring recovery when placing the tablespace
online again.
O
l &
n a
te r
I n
c l e
r a
O
Database Inconsistency
• Constraint inconsistency
• Logical inconsistency
• Structural inconsistency
• Physical inconsistency
– At the block level
– At the inter-block level
n l y
e O
When Is the Database Inconsistent?
U s
I
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. A
O
This might happen when no constraints are used, only implied. This is called a logical
&
inconsistency. It might happen if an older version of a table (that participates in a relation with
l
other tables) is imported.
n a
If the database does not contain the files the dictionary says it should, then there is a gross
te r
structural inconsistency. Normally the database will refuse to start until the fault is remedied.
I n
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, this can be described
l e
as physical inconsistency. Some pointers refer to another block. If they point to the wrong block,
c
or if the other block does not have the content it should have, then there is physical inconsistency
a
between blocks.
r
O
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 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 blocks on disk, and perhaps than other blocks in memory. The database is
therefore inconsistent, and anything other than a controlled (graceful) 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Comparing Redo and Undo
• 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.
n l y
e O
Redo and Undo
U s
I
It is imperative for understanding the recovery architecture 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. A
O
Only undo is directly associated to a transaction, while redo is implicitly associated to a
&
transaction. Some redo is not part of the transaction with which it appears to be associated, for
l
n a
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.
te r
Redo is stored in separate files in Oracle, the online redo log files, while undo is stored inside
normal data files in the special undo tablespace or the special (rollback) segments.
I n
The words “rollback” and “undo” are synonyms. For more information on the generation, use,
l e
and analysis of undo data, see the courses DSI402e: Data Types and Block Structures and
c
DSI402: Space and Transaction Management.
r a
Redo is the heart of the recovery system and is covered in more detail in the course DSI403:
O
Backup and Recovery Processes.

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
– Can be partially suppressed (NOLOGGING)
• Undo is generated whenever user or data
dictionary data changes:
– Table data and associated indexes
– LOBs do not generate undo
n l y
e O
Redo Generation
U s
I
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). A
O
As 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
l
n a
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”.
te r
Undo Generation
I n
Undo cannot be suppressed. It is the same mechanism regardless of whether you use automatic
l e
undo management or manually managed rollback segments.You can see the amount of undo
c
generated in V$ROLLSTAT under the column WRITES, and V$TRANSACTION under the
r a
columns USED_UBLK and USED_UREC.
O
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.
– 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
n l y
e O
Recovery Concepts
U s
For all redo vectors:
• The block (DBA) specified in the vector is read into the cache.
A I
• If the block has the same time as the redo record (SCN and SEQ fields match), then the
redo vector is applied. O
cache.
l &
• The block is written out by a recovery checkpoint at a log switch or when aged out of
n a
The method that determines whether or not a block needs recovery allows for the normal
te r
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
I n
also allows for recovery being reapplied repeatedly, or restarted after a crash while applying
redo. Only if the redo and block match in time will the redo be applied. Note that the word
l e
“time” refers to the logical time line as given by the SCN and SEQ and not to any timestamp.
c
This also makes the recovery process safe against changes of the clock, such as daylight savings
r a
time. There is no redo generated while performing recovery. The control file is also modified,
O
tracking the progress of the recovery.

Crash and Media Recovery Differences
Crash recovery:
• Two pass reading
– Scan BWR records in redo stream
– Reread redo stream and apply only required redo
• Database consistent and complete
Media recovery:
• Recovery checkpoints
• Incomplete or complete, but consistent
n l y
e O
Differences Between Crash and Media Recovery
U s
Crash recovery is automatic and uses the online redo logs that are CURRENT or ACTIVE. Media
A I
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
O
one thread. For media recovery the redo records of all threads are taken in SCN/SEQ order as the
&
data file(s) may have been modified by several instances.
l
Two Pass Recovery in Crash Recovery
n a
The ordinary cache aging and the incremental checkpoint system have probably written a
te r
number of blocks to disk, without the file headers being updated. When the DBWn completes a
data block write operation, it also adds a redo record that states that the block has been written.
I n
This is called a Block Written Record (BWR). During crash recovery, the online redo log is read
twice.
c l e
The first read of the redo builds a list of blocks that are mentioned in the redo. Some of the redo
r a
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
O
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 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. You can suppress two pass crash recovery with
_TWO_PASS=FALSE.
Media Recovery
During media recovery, the blocks are in the buffer cache waiting to be written out to the data
file(s). 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 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Stuck Recovery
• A block is older than the redo 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 log files.
– Corrupt the block.
n l y
e O
Stuck Recovery
U s
Stuck recovery should cause a trace or a dump, typically ORA-600[3020]. To progress past a
about what the block content should be. A I

stuck recovery, the block must be marked corrupt because there is no consistent information
O
In Oracle9i this is performed with either ALLOW 1 CORRUPTIONS, or with TEST in the
recover command.
l &
accomplish this Before Oracle9i,
n a
The hidden parameter _CORRUPT_BLOCKS_ON_STUCK_RECOVERY was needed to
Test Recovery
te r
I n
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
l e
recovery, if there is any serious error the recovery will stop. After correcting the error, recovery
c
is attempted again, only to fail at the next error. Test recovery is used to see how many such
r a
serious errors might occur. Depending on the answer, a different recovery scenario might be
O
attempted. Test recovery can also mark blocks as corrupt. Data cannot be retrieved from such
blocks, but can be skipped.

NOLOGGING and Recovery
• Data manipulated in NOLOGGING mode cannot be

crash or media recovered.
• Blocks that do not have complete redo are marked
invalid on recovery.
• Temporary tables, sort segments are always
“NOLOGGING”.
n l y
e O
NOLOGGING and Recovery
U s
Data manipulated in NOLOGGING mode cannot be crash or media recovered. When a bulk data
A I
operation is performed on an object marked NOLOGGING, the range of blocks affected will be
noted as invalidated in the redo record. On recovery the data blocks will be marked as soft
O
corrupt in the data file. This avoids issues with old blocks in the data file, perhaps being reused
l &
as segments are dropped and the space allocated to other objects seeing “old data,” or determine
which blocks lack redo due to repeatedly switching between LOGGING and NOLOGGING.
n a
When a user attempts to retrieve data from such a table or index they receive:
te r
ORA-26040: Data block was loaded using the NOLOGGING option
I n
Versions before Oracle8i may report:
ORA-1578: ORACLE data block corrupted (file nn, block nn)
l e
Blocks belonging to sort segments, temporary tables and any block in a temporary tablespace
c
will not generate any redo. As these blocks contain data that only has a lifetime of a statement or
r a
session, then the data is not needed if there is a crash which either aborts the statement or the
O
session.

Summary
In this lesson, you should have learned how to:

• Understand the fundamentals of the RMAN
architecture and its components
• Understand basic backup structures
• Identify the features, components, and tasks of
RMAN
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Configuring RMAN
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Understand RMAN configuration decisions
• Outline the steps taken in creating a recovery
catalog
• Create/grant privileges to a 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
• Upgrade and drop a recovery catalog
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
RMAN Configuration Decisions
Decisions to be made prior to configuring RMAN:

• Whether to use a recovery catalog
• Whether Oracle password files will be used
• How and when to backup O/S files
• The name for the snapshot control file
n l y
e O
RMAN Configuration Decisions
U s
file, note these advantages of using the catalog:
• Some RMAN commands and operations function only with a catalog. A I
Although RMAN can conduct all major backup and recovery operations using just the control
O
• The recovery catalog retains historical backup information that can get overwritten in the
control file.
l &
• The recovery catalog stores information about backups from different incarnations of the
database.
n a
te r
RMAN automatically propagates information about the database structure, archived redo logs,
backup sets, and data file copies into the recovery catalog from the target database's control file.
I n
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
l e
the owner of the recovery catalog.
c
r a
Decide which database you will use to install the recovery catalog schema, and also how you
will back up this database. You should not install the catalog in the target database: this tactic
O
defeats the purpose of the catalog. Also, decide whether to operate the catalog database in
ARCHIVELOG mode, which is recommended.

Issues to Consider
Some issues to ponder when deciding whether or not

to use a Recovery Catalog:
• If the control file is lost and a need to restore and
recover the database (Oracle8i) arises, the
customer will require the assistance of Oracle
Worldwide Customer Support Services
• Point-in-time recovery (PITR) can be difficult or
impossible
• The overhead of a recovery catalog
n l y
e O
Issues to Consider
U s
file. Some implications of not using a recovery catalog include:
A I
RMAN can be configured to use a recovery catalog in addition to the target database’s control
• Losing a control file with a need to restore and recover. If the database is pre Oracle9i,
O
Support can only help if the user maintains excellent records (that is, RMAN message log
backup pieces.
l &
files) of which files were backed up, the date the backup occurred, and the names of the
a
• Point-in-time recovery may be more difficult if the database schema has changed since the
n
te r
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
I n
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
l e
performance is better with a recovery catalog. If not using a recovery catalog, multiple backups
c
of the control file should be kept on different disks, tapes, and/or machines. These backups must
r a
be restorable without RMAN.
O
Using RMAN Without a Recovery Catalog
If you choose to operate without a recovery catalog,

the following commands will not be available:
CREATE, UPGRADE, or DROP CATALOG

CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT,
PRINT SCRIPT
LIST INCARNATION
REGISTER DATABASE
REPORT SCHEMA AT TIME
RESET DATABASE
RESYNC CATALOG
n l y
e O
Using RMAN Without a Recovery Catalog
U s
I
If you choose not to use a recovery catalog, then you can still use RMAN effectively.
Remember, RMAN obtains the information it needs from the control file of the target database.
A
Nevertheless, some commands are not available when you use the control file as the sole
repository of RMAN metadata. O
&
With the advent of Oracle9i, the importance of the recovery catalog is diminished. The needed
l
containing many databases.
n a
functionality is provided with the control file store except when dealing with environments
te r
Note: LIST INCARNATION is supported in Oracle9i Release 2 databases running in
nocatalog mode.
I n
c l e
r a
O
Steps to Create the Recovery Catalog
1. Decide in which database to create the catalog.

2. Decide the frequency of backup and resync.
3. Create a RMAN tablespace.
4. Create and grant privileges to a RMAN user.
5. Connect as the RMAN user.
6. Create the repository with the CREATE CATALOG
command.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Creating an RMAN User
• Create RMAN user.

SQL> create user RMAN identified by RMAN
2> temporary tablespace TEMP
3> default tablespace RCVCAT
4> quota unlimited on RCVCAT;
• Grant a role to maintain and query the recovery

catalog to the RMAN user.
• Grant other roles as needed.
n l y
e O
Create the RMAN User and Schema
U s
I
At this point, you are ready to create the RMAN user and schema. In this example, the user
RMAN is created and the default tablespace that will store the user’s schema is assigned. Next,
A
grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user
with privileges to maintain and query the recovery catalog. O
SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
l &
a
Grant other desired privileges to the RMAN user as needed.
n
SQL> connect / as sysdba
te r
SQL> grant dba, connect, resource, sysdba TO rman;
I n
c l e
r a
O
Creating the Repository
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 - Beta
(c) Copyright 2001 Oracle Corporation.
connected to recovery catalog database
RMAN> create catalog
n l y
e O
Creating the Repository
U s
The recovery catalog is created by issuing the RMAN command and connecting to the RMAN
issuing the CREATE CATALOG command. A I

database (if you chose to create a separate database for the recovery catalog) as user RMAN and
$ rman catalog rman/rman O

Recovery Manager: Release 9.2.0.0.0
l &
(c) Copyright 2001 Oracle Corporation. All rights reserved.
n
a
RMAN>
te r
recovery catalog is not installed

I n
recovery catalog created
c l e
r a
O
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 catlog will be backed up
• How often to resync the recovery catalog
• How to automate catalog resyncs
n l y
e O
Recovery Catalog Strategy
U s
I
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
A
may lose the metadata in the catalog. Avoid this unpleasant scenario by deciding how to back up
and recover the recovery catalog. O
&
Back up the recovery catalog with the same frequency that the target database is backed up. If
l
n a
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
target backup.
te r
the target backup preceding it, so if you need to restore the catalog you can use it to restore a
I n
When the RMAN resync catalog command is issued, the tables in the catalog database
c l e
will be updated with any new information stored in the control file such as the new backup sets
created or new stored scripts.
r a
O
RMAN Backup Strategy Guidelines
• 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.
n l y
e O
RMAN Backup Strategies
U s
I
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
A
for the recovery catalog is the control file in the catalog database. With this strategy, the control
O
file autobackup feature ensures that the recovery catalog database can always be recovered.
l &
n a
te r
I n
c l e
r a
O
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 rcvcat rman/rman@rcat
RMAN> connect target
n l y
e O
Starting RMAN
U s
I
There are many ways that a user can start RMAN depending on how RMAN was configured and
of course the user’s current needs. In addition to the methods demonstrated above, RMAN can
additionally be started in the following ways: A
O
• By connecting to a target instance (either locally or remotely) when using a password file
l &
and specifying a TNS alias in the target connect string while using a recovery catalog:
$ rman target_db internal/secret@prod rcvcat rman/rman@rcat
a
• By connecting to a target database (either locally or remotely) when using a password file
n
te r
and specifying a TNS alias in the target connect string, no recovery catalog:
$ rman target scott/tiger@prod nocatalog
I n
c l e
r a
O
Oracle Real Application Clusters
• RMAN can connect to only one Real Application

Clusters 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
Oracle Real Application Clusters instance.
– This method allows the entire database to be
backed up with one command.
n l y
e O
Connecting to Oracle Real Application Cluster Databases
U s
I
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
A
instances in an Oracle Real Application Clusters configuration. You can connect to the target
O
database using only one of these net service names. For example, you can connect as follows:
&
$ rman TARGET SYS/oracle@RAC2 CATALOG rman/rman@catdb
l
n a
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.
te r
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
I n
automatic channels to connect to each instance then make a whole database backup by running
c l e
the BACKUP DATABASE command.
r a
O
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
n l y
e O
Connecting to an Auxiliary Database
U s
To use the DUPLICATE command or to perform tablespace point-in-time recovery with RMAN,
A I
you need to connect to an auxiliary instance. If the auxiliary database uses password files for
authentication, then you can connect using a password for either local or remote access. If you
O
are connecting remotely through a net service name, then authentication through a password file
is mandatory.
l &
n a
The examples above demonstrate the command syntax necessary to connect to an auxiliary
database and simultaneously a target, catalog, and auxiliary database respectively. Alternatively,
$ rman
te r
you can start RMAN and connect to the databases individually from the RMAN prompt:
I n
RMAN> CONNECT TARGET SYS/oracle@trgt
e
RMAN> CONNECT CATALOG rman/cat@catdb
l
RMAN> CONNECT AUXILIARY SYS/aux@auxdb
c
r a
O
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
n l y
e O
Using Pipes with RMAN
U s
I
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. A
O
RMAN does not permit the pipe interface to be used with public pipes as they are a potential
&
security problem. With a public pipe, any user who knows the name of the pipe can send
l
n a
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
te r
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
I n
as a public pipe, and RMAN returns an error if it is told to use a public pipe.
l e
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
c
a
that can be used to generate unique pipe names.
r
O
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 you connect to will be the
database registered in the catalog.
RMAN> register database;
• The register command identifies the database to

the recovery catalog.
• Information about the target database’s structure
is propagated from the target database’s control
file.
n l y
e O
Registering a Database in a Recovery Catalog
U s
I
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
A
given catalog schema. Because RMAN distinguishes databases by unique database identifier
O
(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.
l
n a
However, each database does not have 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
te r
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
I n
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
l e
to change the DBID (or the database name) of any Oracle database. DBNEWID is useful when
c
you have already created multiple databases with the same DBID and you now want to register
r a
them all in the same recovery catalog.
O
Catalog Maintenance Commands
• The RESYNC CATALOG command synchronizes the

recovery catalog with the target database’s control
file.
• The CONFIGURE command allows the user to
adjust persistent configuration parameters in
Oracle9i.
• The CATALOG command allows user-managed
backups to be managed by RMAN.
n l y
e O
Catalog Maintenance Commands
U s
I
There are a number of RMAN commands provided that allow maintenance of information in the
recovery catalog. The RESYNC command compares the catalog and target control file and brings
A
them back to a state of “agreement.” The CONFIGURE command is a new feature of Oracle9i
O
and allows the user to create and manage a set of configuration parameters that greatly enhance
l &
the useability of RMAN. The CATALOG command allows user-managed data file and archived
log file backups to be cataloged in the RMAN repository.
n a
te r
I n
c l e
r a
O
RESYNC CATALOG Command
• The RESYNC CATALOG command causes RMAN to

compare the recovery catalog to the target
database’s control file.
RMAN> resync catalog;
• RMAN copies data from the V$ views in the target
database control file to the recovery catalog.
• Resyncs are initiated in two ways:
– Manual resyncs happen when requested by the
user, with the resync catalog command.
– Automatic resyncs happen when needed, at the
start and/or end of an RMAN command.
n l y
e O
RESYNC CATALOG Command
U
The RESYNC CATALOG catalog command causes RMAN to compare the recovery catalog to
s
A I
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
O
the control file, and updates the recovery catalog with information that is missing or changed. If
l &
the target database is open, it also registers information about which tablespaces contain rollback
segments. This is used for tablespace point-in-time-recovery (TSPITR), to ensure all tablespaces
a
with rollback segments in them are restored for the TSPITR to be successful.
n
te r
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.
I n
c l e
Following is a list of records that are resynced:
• Log history archivelog copy (archivelog copy, or archivelog backupset restore)
r a
• Backup history (backup or copy performed not already in the catalog)
• Physical schema (MUST have current control file mounted)
O
If syncing from control file copy, 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.
• Non-circular reuse
– Resync requires a read-consistent image of the
control file, thus a need for snapshot.
n l y
e O
Circular Reuse
U s
I
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
a logical ring. When all available slots are full, the control file is either expanded to make room
O
for the new record or the oldest record is overwritten. The parameter that determines which of
l &
these two options will be used is CONTROLFILE_RECORD_KEEP_TIME. Examples include
log history, archived log, backup record, offline ranges.
Noncircular Reuse
n a
te r
For information that is not changed often and because be overwritten, because it is critical for
n
production operation. Examples include data files, redo threads, online redo logs.
I
c l e
r a
O
Recovery Catalog Resync Types
There are two types of recovery catalog resync:

• Partial resync
– Used when only circular reuse records need to be
resynced
• Full resync
– Used when some noncircular reuse records need to
be resynced
– The RESYNC CATALOG command always does a full
resync
n l y
e O
Partial Resync
U s
I
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
A
RMAN automatic resync, and when RMAN detects that a full resync is not needed.
Full Resync O
l &
Because full resyncs are used when some noncircular reuse records need to be resynced, a read-
a
consistent image of the control file is needed. A full resync reads from the snapshot control file,
n
te r
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
I n
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
l e
executes the operation as needed. You can also force a full resynchronization by issuing a
c
RESYNC CATALOG command.
r a
O
When to Run a RESYNC CATALOG
The RESYNC CATALOG command should be

performed:
• Each time the physical database structure
changes
• When data files are added or resized
• When a tablespace is dropped
• When rollback segments are created or dropped
• At least once per each ten archived logs
n l y
e O
When to Run the RESYNC CATALOG Command
U s
I
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
A
periodically propagated to the recovery catalog. To ensure that the catalog stays current, run the
O
RESYNC CATALOG command periodically. A good rule of thumb is to run it at least once per
l &
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.
n a
te r
I n
c l e
r a
O
Resync and Snapshot Control Files
• 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 when
making a backup of the current control file.
• Created the same way as ALTER DATABASE
BACKUP CONTROLFILE.
n l y
e O
Resync and Snapshot Control Files
U s
I
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
A
view of the control file. Because the snapshot control file is intended for RMAN's short-term use,
O
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.
l
n a
The Oracle9i 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
te r
with each other’s use of the snapshot control file.
The default value for the snapshot control file is platform specific. The default filename on some
I n
UNIX platforms in Oracle9i is $ORACLE_HOME/dbs/snapcf_@.f.
c l e
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
a
snapshot control files that RMAN creates use the specified filename.
r
O
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 file name 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Persistent RMAN
Configuration Parameters
• Customizable configuration parameters simplify

formerly complicated RMAN operations.
• Default settings are set once and reused for
subsequent jobs.
• The default parameters can be overridden with the
new Oracle9i CONFIGURE command.
• The configuration values are stored in the control
file and written to the recovery catalog when
resynced.
n l y
e O
Persistent RMAN Configuration Parameters
U s
It is possible to create a persistent backup configuration. Once these parameters are configured
A I
RMAN will continue to reuse the configured options for subsequent backups unless you override
the option within your script or disable it. With 9i RMAN you use the show command to see
the currently configured options.
O
&
RMAN> show all;
RMAN configuration parameters are:
a l
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
r n
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
te
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
n
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR TYPE DISK TO '%F';
# default
I
e
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
l
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
# default
c
r a
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
# default
O
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/9.0.2/dbs/snapcf_U02.f'; # default

Retention Policies
• A retention policy describes which backups will be

kept and for how long.
• There are two types of retention policy:
– Recovery window: 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 in excess of
this can be deleted
• These policies are mutually exclusive and can be
set with the CONFIGURE command.
n l y
e O
Retention Policies
U s
A retention policy describes which backups will be kept and for how long. The value of the
A I
retention policy is set by the new 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
O
objects by doing a point-in-time recovery to just before the error occurred. This period of time is
l &
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
n a
te r
For example if the policy were set as follows:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
I n
Then for each file there must be a backup that satisfies:
c l e
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
r a
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.
O
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.

CONFIGURE RETENTION
POLICY Command
• Setting a recovery window policy

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY
WINDOW OF 5 DAYS;
• Setting a redundancy policy
RMAN> CONFIGURE RETENTION POLICY TO
REDUNDANCY 5;
• Setting no retention policy
RMAN> CONFIGURE RETENTION POLICY TO NONE;
n l y
e O
CONFIGURE RETENTION POLICY Command
The CONTROL_FILE_RECORD_KEEP_TIME parameter determines when the records or U s
A I
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 required to do a valid restore. If the value
O
specified for the recovery window is greater than the CONTROL_FILE_RECORD_KEEP_TIME
parameter, a recovery catalog is required.
l &
The DELETE OBSOLETE command is used to delete obsolete backup sets based on the retention
n a
policy. Backup sets that are identified to never expire are not affected by the retention policy or
DELETE OBSOLETE command.
te r
RMAN cannot implement an automatic retention policy if backups are deleted using non-RMAN
I n
methods. One such method is the media manager’s tape retention policy. Ideally, the media
c l e
manager will never expire a tape until all RMAN backups residing on that tape have been
removed from the media manager’s repository.
r a
There is a difference between CONFIGURE RETENTION POLICY TO NONE and
CONFIGURE RETENTION POLICY TO DEFAULT. The first means that there is no
O
retention policy: backups will never expire, and DELETE OBSOLETE will give an error. The
second means that the default retention policy (REDUNDANCY 1) will be in effect.

Automatic Channel Allocation
• 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.
n l y
e O
Automatic Channel Allocation
U s
I
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
A
channel number. RMAN is aware of the command being run and allocates the proper channel
type. For example: O
ORA_DISK_1
ORA_SBT_TAPE_2
l &
n a
Automatic channel allocation also applies to maintenance commands. If you manually allocate a
te r
maintenance channel by using ALLOCATE CHANNEL FOR MAINTENANCE, then RMAN
uses the following convention for channel naming: ORA_MAINT_devicetype_n.
I n
For example, RMAN uses these names for two manually allocated disk channels:
c l e
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
r
channels. a
allocated. For restores, RMAN knows which device types are required, allocating all necessary
O
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
n l y
e O
The CONFIGURE CHANNEL Command
U
The CONFIGURE CHANNEL command gives the DBA the capability to substitute parameter
s
MAXPIECESIZE, and SEND to be used when RMAN needs I/O.
A I
option values automatically such as NAME, PARMS, CONNECT STRING, DEBUG, FORMAT,
O
When parallelizing channels, it may be necessary for each channel to be uniquely identified. An
example of this is in a Oracle Real Application Clusters architecture. In this environment, online
each node to backup the archived logs.

l &
redo logs are archived to different nodes in a cluster. It is necessary for RMAN to connect to
a
If the channel number [n] is specified, the settings apply just to the channel. Otherwise, the
n
te r
settings apply to all channels of the specified type.
Example of settings for all channels:
I n
CONFIGURE CHANNEL TYPE SBT;
Example of settings for a specific channel:
l e
CONFIGURE CHANNEL 1 TYPE SBT CONNECT 'node1';
c
In this example the channel is set to make backups in a particular directory:
r a
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT
O '/u01/backup/U01_%U';
FORMAT Substitution Variables
The following substitution variables are available in FORMAT strings to aid in generating unique
filenames. The formatting of this information varies by platform.

CONFIGURE CONTROLFILE AUTOBACKUP
• Under Oracle9i Release 2, CONFIGURE

CONTROLFILE AUTOBACKUP causes RMAN to back
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;
n l y
e O
CONFIGURE CONTROLFILE AUTOBACKUP
U s
A I
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. This behavior is new to Oracle9i Release 2. The purpose of the control file
O
autobackup is to provide a way to restore the backup repository contained in the control file
l &
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:
n a
te r
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
If CONFIGURE CONTROLFILE AUTOBACKUP is ON then RMAN automatically backs up
I n
the control file and the current server parameter file in the following circumstances:
• After every BACKUP or COPY command issued at the RMAN prompt
l e
• Whenever a BACKUP or COPY command within a RUN block is followed by a
c
command that is neither BACKUP nor COPY
r a
• After database structural changes such as dropping a table
O
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 old 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';
n l y
e O
CONFIGURE SNAPSHOT CONTROLFILE
U s
These command name changes are consistent with the rule that CONFIGURE sets persistent
The old syntax is still supported for backward compatibility. A I

options that last across RMAN sessions and SET controls options for a single RMAN session.
O
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
l
n a
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
te r
home. For example, the default filename on some UNIX platforms in Oracle9i is
$ORACLE_HOME/dbs/snapcf_@.f.
I n
In general, you should only need to set the control file location in these situations:
l e
• In an Oracle Real Application Clusters configuration and need a snapshot control file
c
accessible by each node
r a
• You are upgrading from a pre-8.1.7 release. In pre-8.1.7 releases, the default location for
the snapshot control file was not dependent on the Oracle home
O
If you are performing TSPITR or using the DUPLICATE command, setting AUXNAME allows
you to preconfigure the filenames for use on the auxiliary database without manually specifying
the auxiliary filenames during the procedure.

Other Configuration Commands
Other useful persistent configuration parameters that

can be modified with the CONFIGURE command
include:
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;
n l y
e O
Other Configuration Commands
U s
The CONFIGURE BACKUP COPIES command provides additional database file protection by
A I
allowing the use 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:
O
RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT TO 3;
The CONFIGURE EXCLUDE command excludes tablespaces from whole database backups.
system tablespace may not be excluded.

l &
This is useful in preventing repeated backups of read-only or offline tablespaces. Note that the
a
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE SAMPLE;
n
te r
The CONFIGURE command allows the user to 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:
I n
RMAN> CONFIGURE DEVICE TYPE SBT PARALLELISM 2;
The CONFIGURE DEFAULT DEVICE command specifies which device type is used for
l e
automated backups. Valid values for device_type_spec are: DISK or SBT The default
c
value is DISK.
r a
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;
Many elements of RMAN scripts are repetitive and are usually identical in every script. It is
O
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 RETENTION POLICY TO REDUNDANCY 3;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
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';
}
n l y
e O
Calling Configuration Sets
U s
I
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
A
within a run block to change more then one parameter or just change a single parameter at a time
O
from the RMAN prompt not using the run block. You can save the configuration to a script and
&
call it when performing a backup that requires the configuration changes.
l
n a
te r
I n
c l e
r a
O
CATALOG Command
• 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
'/U01/archlog/al_U01_1234.rdo';
n l y
e O
CATALOG Command
U s
I
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
A
the catalog. If you have to restore a control file backup, and if you change the archiving
O
destination or format during recovery, then the repository will not have information about
for recovery.
l &
archived logs needed for recovery. Hence, you must catalog these logs if you want to use them
n a
When you make user-managed copies, the repository has no record of them. You must manually
te r
notify RMAN when you make copies with an operating system utility such as the UNIX cp
command. Run the RMAN CATALOG command when:
I n
• Adding information about a user-managed data file copy, archived redo log copy, or
control file copy to the recovery catalog and control file
l e
• Cataloging a data file copy as a level 0 backup, thus enabling you to perform an
c
incremental backup later by using the data file copy as the base of an incremental backup
r a
strategy
O
• Recording the existence of user-managed copies of Oracle release 8.0 and later databases
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
archived redo log copy
n l y
e O
Cataloging Consistent and Inconsistent Copies
U s
I
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
A
conjunction with an OS copy command to make data file copies of an online tablespace.
O
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.
l
n a
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
te r
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.
I n
c l e
r a
O
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.
n l y
e O
Recovery Catalog Compatibility
U s
The RMAN environment can contain the following components:
• RMAN executable
• Recovery catalog database A I
• Recovery catalog schema in the recovery catalog database O
• Target database
l &
• Auxiliary database (that is, a duplicate or standby database)
n a
Each component has a release number. For example, you can use a release 9.0.1 RMAN
executable with:
te r
• A release 9.0.1 target database
I n
• A release 9.0.1 duplicate database
• A release 8.1.5 recovery catalog database whose catalog tables were created with RMAN
l e
release 9.0.1
c
r a
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 a
O
release 9i version of the RMAN executable with a release 8i. 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
n l y
e O
Determining the Schema Version of the Recovery Catalog
U s
In the example above, the select on the RCVER table retrieves a single row. If the table displays
A I
multiple rows however, 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
O
example, assume that the SELECT operation on the RCVER table displays the following rows:
VERSION
l &
a
------------
08.01.07
09.00.01
r n
09.02.00
I n te
These rows indicate that the catalog was created with a release 8.1.7 executable, then upgraded
is 9.2.0.
c l e
to release 9.0.1, and finally upgraded to release 9.2.0. The current version of the catalog schema
r a
O
Upgrading Recovery Catalog
To upgrade the catalog, start RMAN.

• An error will occur 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 release required by this version
of the RMAN executable.
RMAN> UPGRADE CATALOG;
recovery catalog owner is rman
enter UPGRADE CATALOG command again to
confirm catalog upgrade
n l y
e O
Upgrading Recovery Catalog
U s
You will receive an error when issuing UPGRADE CATALOG if the recovery catalog is already at
A I
a version greater than that required by the RMAN executable. RMAN permits the UPGRADE
CATALOG command to be run if the recovery catalog is current and does not require upgrading,
O
however, so that you can re-create packages at any time if necessary. Check the message log for
l &
error messages 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:
n a
RMAN> UPGRADE CATALOG;
te r
recovery catalog upgraded to version 09.02.00
I n
DBMS_RCVMAN package upgraded to version 09.02.00
l e
DBMS_RCVCAT package upgraded to version 09.02.00
c
r a
O
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;
n l y
e O
Dropping Recovery Catalog
U s
The DROP CATALOG command must be entered twice to confirm that it is what you really want
A I
to do. All backups for all target databases managed by this catalog will become unusable.
Removing the catalog does not remove the copies from disk or backup sets from the media they
are stored on. Just the catalog tables are removed. O
l &
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
n a
recovery catalog. Hence, if you have no backups of the recovery catalog schema, then all
te r
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
I n
catalog that has multiple target databases registered. If you try to delete the metadata for one
c l e
target database by dropping the catalog, then you delete the metadata for all target databases.
r a
O
Summary

• Understand RMAN configuration decisions
• Outline the steps taken in creating a recovery
catalog
• Create/grant privileges to a RMAN user
• Start RMAN and register a database in a recovery
catalog
• Demonstrate the use of recovery catalog
maintenance commands like RESYNC, CONFIGURE,
and CATALOG
• Upgrade and drop a recovery catalog
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
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
• Query relevant views in the repository
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Backups with RMAN
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Identify the types of backups 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 and
cumulative incremental backup
• Outline the Recovery Manager backup algorithm
• Demonstrate a working knowledge of the BACKUP
command functionality
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
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
n l y
e O
RMAN Backups
U s
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 A I
• Tablespace
O
• Data file (current or image copy)
• Archived redo log
l &
• Control file (current or image copy)
n a
• Backup set
te r
• Server parameter file (currently in use only)
I n
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
l e
backup pieces, the number of files to go in each set, and which channel should operate on
c
each input file. You can make RMAN backups when the database is open or closed. Closed
r a
backups can be consistent or inconsistent, depending on how the database was shut down.
O
RMAN backups are further divided into full and incremental backups. Full backups are non-
incremental; 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
n l y
e O
Running the BACKUP Command
Interactive Mode
U s
command-line interface.
A I
To run RMAN commands interactively, start RMAN and then enter commands into the
$ rman TARGET SYS/oracle@prod1 CATALOG rman/cat@catdb

O
RMAN> BACKUP DATABASE;
l &
After the RMAN prompt is displayed, you can enter commands such as the following:
Stored Scripts
n a
te r
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.
I n
You must be connected to a target database and recovery catalog. Below is an example of
stored script creation and execution:
l e
CREATE SCRIPT backup_whole_db
{
c
r
BACKUP a
# back up whole database and archived logs
O
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 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, you must furnish 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
n l y
$ rman TARGET / @/u01/backups/cmd_files/backup_db.rman
The example below runs a command file from the RMAN prompt:
e O
RMAN> @/u01/backups/cmd_files/backup_db.rman
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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.
BACKUP DEVICE TYPE DISK DATAFILE 1 TAG
"wkly_bkup";
• Under Oracle9i Release 2, RMAN will automatically
provide a name if one is not specified.
– Control file autobackups are the exception.
• A tag applies to each backup piece in a given copy
of a backup set.
n l y
e O
Backup Tags
U s
A character string called a tag may be assigned to backup sets and image copies. A tag is a
A I
case-insensitive 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.
O
l &
If you are using Oracle9i Release 2, RMAN will create a tag for backups and copies (if you
do not specify a tag name)) in the format TAGYYYYMMDDTHHMMSS, where YYYY is the
n a
year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the
te r
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
I n
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.
l e
Tags do not need to be unique, so multiple backup sets or image copies can have the same
c
r a
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
O
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
created by the COPY command.
– A file copy can only be written to 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.
n l y
e O
File Copies
U s
File copies can be done through RMAN or the host operating system. Operating system
A I
backups on disk can be cataloged in the recovery catalog for immediate use. Once the O/S
backups have been cataloged, they can then be backed up by RMAN to disk or via the
O
Media Management Layer. The LEVEL 0 option to the CATALOG command allows O/S
l &
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
a
of this, all copies are considered to be LEVEL 0.
n
run {
te r
allocate channel d1 type disk;
I n
copy level 0 datafile 1 to ‘/oracle/prod/backup/file1.dbf’;
}
Backup Sets
c l e
r a
A backup set consists of one or more physical output files called backup pieces. Backup sets
usually contain multiple source files that are multiplexed in the output. It can be written to
O
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
Parallelization of file copies is achieved by copying

multiple files within one copy command, as well as
allocating multiple channels.
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’;
}
n l y
e O
Parallelization of File Copies
U
RMAN executes commands serially. The previous command must finish before the next
s
A I
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 completes. Therefore
O
you should always attempt to increase parallelism to speed backups. The example in the
l &
slide shows manual channel allocation to achieve the desired level of parallelization. With
Oracle9i the channels can be configured and stored in the persistent configuration along with
a
the default level of parallelization. These settings will be used whenever a backup is
n
te r
executed unless overridden manually with a series of allocate channel commands
Note: The greater the degree of parallelism, the higher the machine resource but the shorter
the duration.
I n
c l e
r a
O
Backup Set
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
n l y
e O
Backup Sets
U s
You can back up data files, control files, archived redo logs, and the current server
A I
parameter file (Oracle9i only). 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
O
backup to tape, or an image copy. For example, you can issue commands such as the

l &
following, each of which uses an automatic channel configuration:
n
RMAN> BACKUP TABLESPACE users, tools;
a
te r
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
I n
database cleanly. If the database is in NOARCHIVELOG mode, then you must close it
cleanly before making a backup.
c l e
Data file backup sets do not include empty blocks. An empty block is a block that has never
r a
contained data. If a block has been used but is no longer part of an allocated extent, it is still
backed up because the backup process does not have access to space management
O
information. This is a source of some confusion as some think that RMAN will omit blocks
that do not currently contain data. For example if a table is dropped, RMAN will continue to
back up the blocks even though the extents 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;
}
n l y
e O
Data File Backup Set Example
U s
The syntax in the example above illustrates a full database backup of a database with 10
A I
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
O
multiplexed. If two channels are allocated, two sets can be created in parallel. RMAN will
l &
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
a
sbtopen(). Some common format identifiers include:
n
te r
• %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
I n
and repeatable generated name.
• %p specifies the piece number within the backup set. This value starts at 1 for each
l e
backup set and is incremented by 1 as each backup piece is created.
c
• %t specifies the backup set time stamp, which is a 4-byte value derived as the number
r a
of seconds elapsed since a fixed reference time.
O
This is a partial list of format identifiers. For a more complete treatment, see 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.
• As with data file backup sets, archivelog backups
are automatically distributed across the number of
channels specified.
backup format ‘al_%t_%s’ archivelog all
delete input;
n l y
e O
Archive Log Backup Sets
U s
As RMAN has access to control file information, it knows what logs have been archived.
A I
This prevents a common problem experienced by users, of not knowing whether an archive
log has been completely copied out to the archive log destination before attempting to back
it up.
O
l &
n a
te r
I n
c l e
r a
O
Parallelization of Backup Sets
Parallelization of backup sets can be done by

allocating multiple channels or using the configure
command for automatic channel allocation.
• Manual allocation:
run {
allocate channel t1 type ‘sbt_tape’;
allocate channel t2 type ‘sbt_tape’;
backup
...
}
• Automatic allocation:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
n l y
e O
Parallelization of Backup Sets
U s
Parallelization of backup sets is achieved by allocating multiple channels. Each channel gets
enough data files to make each backup set roughly the same size.
A
The CONFIGURE DEVICE TYPE ... PARALLELISM command specifies the number
I
O
of channels that RMAN uses when allocating automatic channels for a specified device type.
l &
For example, if you configure parallelism to 3, then RMAN allocates three channels of the
default device type whenever it uses automatic channels.
n a
When parallelizing backups, RMAN always allocates channels in numerical order beginning
te r
with 1 and ending with the parallelism setting. For example, if the device type is sbt and
parallelization is set to 4, then RMAN allocates as follows:
ORA_SBT_TAPE_1
I n
l
ORA_SBT_TAPE_2
c
ORA_SBT_TAPE_3 e
r a
ORA_SBT_TAPE_4
O
You can change a parallelism setting by issuing another CONFIGURE DEVICE TYPE...
PARALLELISM command.

Backup Pieces
• A backup piece consists of one or more physical

output files contained within a backup set.
• A backup set usually has only one backup piece.
• The only time a backup set has more than one
piece is when the maximum piece size is limited
by the user.
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK
MAXPIECESIZE = 2G;
RMAN> BACKUP DATAFILE 1;
n l y
e O
Backup Pieces
U s
Each backup set contains at least one backup piece. If you do not restrict the backup piece
A I
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
O
ALLOCATE CHANNEL commands. This option limits backup piece size to the specified
l &
number of bytes. 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
a
uses the %U substitution variable to generate a unique name.
n
te r
RMAN automatically generates unique names for the backup pieces. The FORMAT
parameter provides substitution variables that you can use to generate unique filenames. For
I n
example, you can run a command as follows:
c l e
BACKUP TABLESPACE users FORMAT = ’/tmp/users_%u%p%c’;
Format can be specified in three places, and will be used in the following precedence:
r a
• BACKUP OBJECT
• BACKUP COMMAND
O
• ALLOCATE/CONFIGURE CHANNEL

Backup Piece Contents
• Each piece in a set has a piece header located in

the first block.
• The first block in the piece header includes:
– Database ID
– Piece number
– Set stamp, set count
– Type of backup
– How many directory blocks follow the piece header
n l y
e O
Backup Piece Contents
U s
The directory contains metadata about each file in the backup set. A directory entry contains
A I
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
O
size of the files being backed up. Data file directory entries include:
• Creation SCN
l &
• Absolute and relative file number for the file
• Resetlogs SCN
n a
• Checkpoint SCN
• Incremental-start SCN
te r
I n
Archivelog directory entries include:
• Thread
l
• Sequence
c
• Low SCN
e
r a
• Next SCN
O • Resetlogs SCN
Following the header and directory are the blocks for the files 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 Enterprise Edition.
Changed
blocks
All non-
empty
blocks
Level 0 2 2 1 2 2 2 0
Day Sun Mon Tue Wed Thu Fri Sat Sun
n l y
e O
Incremental Data File Backup
U s
An incremental data file backup is a backup of a data file that only copies out Oracle blocks
that have been modified since a previous incremental backup.
A I
An incremental backup at level N, where N is greater than zero, backs up all blocks
O
modified since the previous incremental at all levels that are less than or equal to N.
l &
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.
n a
te r
I n
c l e
r a
O
Cumulative Incremental Backups
• A cumulative incremental backup at level N (where

N is greater than 0) backs up all blocks modified
since the previous incremental at a level less
than N.
• Cumulative incremental backups are provided for
recovery speed.
Changed
blocks
All non-
empty
blocks
Level 0 2 2C 1 2 2C 2C 0
Day Sun Mon Tue Wed Thu Fri Sat Sun
n l y
e O
Cumulative Incremental Backups
U s
Cumulative incremental backups duplicate work performed by other cumulative incremental
A I
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
O
previously backed up at the same level, they may take longer and will write more blocks
than non-cumulative.
l &
Fewer backups at each level must be applied when recovering. Basically, a cumulative
n a
incremental backups supersede incremental backups at the same level as itself. If you took a
te r
level 2, then a cumulative level 2, the second level 2 would backup all the blocks modified,
including those backed up by the first level 2. This means that only one incremental backup
I n
of any level is needed to completely recover.
c l e
r a
O
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 SCN's greater than or
equal to the INCREMENTAL_CHANGE#
n l y
e O
SCN and Incremental Backups
U s
CHECKPOINT_CHANGE#
A I
The data file’s checkpoint SCN at the time the backup began. This is the checkpoint that the
file will have after this incremental is applied.
INCREMENTAL_CHANGE# O
l &
The checkpoint SCN for the data file as it was in the backup this one is based on. The
a
INCREMENTAL_CHANGE# is also known as the incremental-start SCN.
n
Incremental level greater than 0
te r
All blocks with SCN’s greater than or equal to the INCREMENTAL_CHANGE# are backed
I n
up when the incremental level is greater than 0. That is, all blocks which were modified
since the first file was checkpointed and blocks at the same checkpoint as the file (as they
l e
may have been modified more than once at the same SCN in between being written out).
c
r a
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.
O
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, which limits the
number of files for a backup set
• The MAXSETSIZE parameter (specified on the
CONFIGURE and BACKUP commands), which
specifies a maximum backup set size
n l y
e O
Basic Backup Algorithm
U s
The total number and size of backup sets depends on which algorithm RMAN uses: the
A I
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:
O
• You are backing up files other than data files or control files.
l &
• 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.
a
• You manually set the DISKRATIO parameter of the BACKUP command to 0.
n
te r
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.
I n
c l e
r a
O
Algorithm Rules
The most important rules in the algorithm for backup

set creation 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 not set.
• RMAN detects which physical drives a data file is
located on, and tries to make each backup set
read from about the same number of disk drives.
n l y
e O
Algorithm Rules
U s
The basic backup algorithm follows several important tenants when creating backup sets.
A I
Each allocated channel that performs work in the backup job—that is, each channel that is
not idle generates at least one backup set. By default, this backup set contains one backup
O
piece. RMAN always tries to divide the backup load so that all allocated channels have
roughly the same amount of work to do.
l &
The basic algorithm determines the number and size of the backup pieces by balancing the
n a
FILESPERSET and MAXSETSIZE (if used) parameters of the BACKUP command. The
te r
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
I n
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
l e
140 files and allocating 2 channels, RMAN divides 140 by two, compares the resultant 70 to
c
64 and chooses 64 as the value for FILESPERSET.
r a
The maximum size of a backup set is determined by the MAXSETSIZE parameter of the
O
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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Advanced Algorithm
• The advanced algorithm considers DISKRATIO in

addition to FILESPERSET and MAXSETSIZE
• If DISKRATIO is not set, it defaults to the same
value of FILESPERSET.
• If neither DISKRATIO or FILESPERSET not set, the
value of DISKRATIO defaults to 4.
n l y
e O
Advanced Algorithm
U s
The advanced algorithm uses the same factors as the basic algorithm to determine the
A I
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
O
read data from at least n disk drives. RMAN uses file location information obtained from the
l &
database server to determine which data files are on which disk drives.
If you set FILESPERSET but not DISKRATIO, then DISKRATIO defaults to the same
n a
value as FILESPERSET. If you specify neither parameter, then DISKRATIO defaults to 4.
te r
RMAN compares DISKRATIO to the number of devices and uses the lowest value.
Assume that a database contains 50 data files spread across 6 disks, and the operating system
I n
is able to deliver this disk contention information to the server. You configure a single sbt
channel and then run BACKUP DATABASE.
c l e
RMAN will use the advanced algorithm because the basic algorithm indicates that because
r a
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
O
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
• Allocates memory structures and I/O buffers for

each file in the set
• Orders the files to be backed up in a channel in
descending size order
• Files in the set are checkpointed at the same SCN
• Read, validate, and save each file’s header block
• Multiplex the files together
n l y
e O
Algorithm Behavior for Standard Backup Sets
U s
The algorithm allocates memory structures and I/O buffers for each file in the set. Input
A I
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
O
with a level greater than 0. The files to be backed up are inspected and arranged in the
channel based on size in descending order.
l &
At this time all the files in the backup set are checkpointed at the same SCN and the file
header blocks are validated.
n a
te r
I n
c l e
r a
O
Algorithm Behavior for Standard
Backup Sets
• For each buffer, it is decided whether to include

blocks.
– If incremental, check SCN in block to see if it
qualifies for inclusion
– If full or level 0, check to see whether the block has
ever contained data
• Check for physical and logical corruption and
calculate checksum.
• Replace the file number in RDBA with a backup
set relative file number.
n l y
e O
Algorithm Behavior for Standard Backup Sets (continued)
U s
While processing the buffer contents, decisions are made as to the inclusion of the blocks. If
A I
an incremental backup is being performed, the block SCN is queried. If a full backup is
performed, the block is checked to see if it is empty. If a file contains many empty blocks,
O
for each total_number_of_input_blocks (four times the number of blocks per buffer) in the
performance.
l &
buffer, only one empty block is actually copied out. This specifically addresses restore
n a
During this process, the blocks are checked for physical and logical corruption. It is possible
te r
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 that is
I n
the absolute file number within the set. This number is stored in the file’s directory entry.
l e
When restoring files from backup sets, the file header is written last to ensure that the file
has not been truncated before the restore completed.
c
r a
When the output buffer is filled, it is sent to the output device. When the input buffer is
empty, a read ahead is performed. Finally, the file header is written into the backup set and
O
the control file is updated.

Algorithm Behavior for Archivelog
Backup Sets
• Archived logs are included in a backup set

ordered by descending size
• Similar process to the data file backup algorithm
• Sequence number is converted to a backup-set
relative file number
• No blocks are skipped
• Any corruptions detected causes the backup to be
terminated
• When the backup is complete, control file is
updated
n l y
e O
Algorithm Behavior for Archivelog Backup Sets
U s
When RMAN is creating archivelog backup sets all blocks are copied out. There is no
A I
provision to skip “empty” blocks. All blocks are multiplexed, similar to data file backups.
The input and output buffers are in sync, as all blocks are included. Any corruptions
O
encountered during an archivelog backup will cause the backup to be terminated.
l &
n a
te r
I n
c l e
r a
O
Algorithm Behavior for File Copies
• A single server process operates on one file at a

time.
• No blocks are skipped.
• Checks for physical and logical corruption and
calculates checksum.
• File header is written last.
• The control file is updated when the copy is
complete.
n l y
e O
Algorithm Behavior for File Copies
U s
When RMAN performs a file copy, no data movement takes place; the buffers are shared. A
blocks are skipped. A I

single server process works on one file at a time. As with the archivelog backup sets, no
O
l &
n a
te r
I n
c l e
r a
O
Backup Optimization
• The BACKUP command will skip a file if an identical

copy already exists.
• 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, channels
of type DISK and SBT may not be mixed.
n l y
e O
Backup Optimization
U s
If you enable backup optimization, then the BACKUP command skips the backup of a file
A I
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
O
skipping. However, RMAN must do further checking to determine whether to skip the file,
l &
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.
n a
te r
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
I n
back up all files whether or not they have changed, specify the FORCE option on the
BACKUP command. To enable or disable backup optimization, specify ON or OFF with the
l e
CONFIGURE BACKUP OPTIMIZATION command.
c
r a
O
Backup Optimization Algorithm
Algorithm criteria used to determine identical files:

• Data file
– Same DBID, checkpoint SCN, RESETLOGS SCN and
time
– The 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
n l y
e O
Backup Optimization Algorithm
Data File Backups
U s
A I
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 window. If you did not configure a recovery
O
window, then RMAN sets n = 1 and searches for values of n in this order of precedence:
l &
• If CONFIGURE RETENTION POLICY TO REDUNDANCY r is enabled, then RMAN
only skips data files when n = r + 1 backups exist.
• BACKUP ... COPIES n
n a
• SET BACKUP COPIES n
te r
• CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n
I n
RMAN skips backup only if at least n backups of an identical file exist on the specified
c
Archived Logl e
device. If RMAN does not skip the backup, then it makes the backup exactly as specified.
r a
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):
O• BACKUP ... COPIES n
• SET BACKUP COPIES n.

Backup Optimization Algorithm (continued)
Archived Log (continued)
• CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ...
TO n
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):
• BACKUP ... COPIES n
• SET BACKUP COPIES n
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:
BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;
Later, you enable the following configuration setting:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4;
CONFIGURE BACKUP OPTIMIZATION ON;
Then, you run the following archived log backup at noon:
n l y
BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
e
In this case, the BACKUP...COPIES setting overrides the CONFIGURE...COPIES
O
U s
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
A I
generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up
two copies of all logs generated after 9 a.m. because these logs have not yet been backed up
to tape.
O
l &
At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of
the logs created after 9 a.m. exist on tape. Assume that you run the following backup
command at 3 p.m.:
n a
RUN
{
te r
I
SET BACKUP COPIES 3;
n
}
c l e
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
r a
In this case, RMAN sets n = 3 and so will not back up the logs created before 9 a.m. because
three copies already exist on tape. However, only two copies of the logs created after 9 a.m.
O
exist on tape, so RMAN does not optimize backups of these logs. Therefore, RMAN backs
up three copies of the logs created after 9 a.m.

Duplexed Backups
• Duplexed backups can create up to four identical

copies of each backup piece.
• Duplexed backups require a FORMAT specification
that guarantees uniqueness.
– %c - copy number (1-4)
– %U - new default format; equivalent to %u_%p_%c
• Duplexed backups require setting the parameter
BACKUP_IO_SLAVES = TRUE.
• Backup duplexing works with any media manager.
n l y
e O
Duplexed Backups
U s
A I
Multiple or duplexed backup copies can be made by using the SET DUPLEX command
when running your backup. Use the SET DUPLEX command before allocating any
channels. The SET DUPLEX command affects all channels allocated after issuing the
command. O
&
Backup duplexing can be used with the DELETE INPUT option to make sure more than
l
a
one backup of an archived log exists before the log is deleted from disk.
n
te r
I n
c l e
r a
O
Duplexed Backups
Backup duplexing provides an efficient way to

produce multiple copies of each backup piece.
• Duplexing under Oracle9i using the COPIES
option:
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7
FORMAT ’/tmp/%U’,’?/oradata/%U’,’?/%U’;
• Duplexing under Oracle8i is done using the SET

DUPLEX command
– The SET DUPLEX command must occur before
channels are allocated
• Duplexed backups require setting the parameter
BACKUP_IO_SLAVES = TRUE
n l y
e O
Duplexed Backups
U s
A I
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
O
simultaneously, then commands higher on the list override commands that are lower on
l &
the list. Duplexing under Oracle9i is done using the COPIES option while Oracle8i
requires the use of the SET DUPLEX command. Duplexing can be used with the
a
DELETE INPUT option to make sure more than one backup of an archived log exists
n
that guarantees uniqueness.
te r
before the log is deleted from disk. Duplexed backups require a FORMAT specification
I n
• %c - copy number (1-4)
• %U – This is the default format; and is equivalent to %u_%p_%c
l e
In the slide example, observe that RMAN places the first copy of each backup piece in
c
/tmp, the second in ?/oradata, and the third in the Oracle home. Note that RMAN
r a
does not produce three backup sets, each with a different unique backup set key.
O
Duplexed Backups (continued)
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 this sample LIST output:
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
n l y
O
e
----------- ------------ --------------- ---
DISK 00:00:01 08-MAR-02 TAG20020208T152314
U s
A I
------- --- ----------- ----------
O
l &
2 1 AVAILABLE /oracle/oradata/01dg9tb2_1_2
n a
te r
----------- ------------ --------------- ---
I n
DISK 00:00:01 08-MAR-02 TAG20020208T152314
l e
c
------- --- ----------- ----------
r a
3 1 AVAILABLE /oracle/01dg9tb2_1_3
O
Mirrored Backups
• Mirrored backups are created by using the SET

DUPLEX command.
• Oracle9i provides extra functionality by:
– Allowing a default duplex value
– Supporting a multivalued option for duplexed
backups stored on disk
RUN {
SET BACKUP COPIES 3;
BACKUP DATABASE
FORMAT '/u01/backups/%U',
FORMAT '/u02/backups/%U',
FORMAT '/u03/backups/%U';
}
n l y
e O
Mirrored Backups
U s
When making mirrored backups it is possible to specify up to four different locations with
A I
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
O
format value for copy 2, and so on. If more format values are specified than copies, the extra
l &
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 example below illustrates
this concept:
n a
SET BACKUP COPIES 3
te r
BACKUP DATABASE FORMAT '/U01/backups/%U','/U02/backups/%U';
I n
As a result, the first copy is placed in /u01/backups, the second copy is placed in
c l e
/u02/backups, and the third copy is placed in /u01/backups.
r a
O
Proxy Copy
• A proxy copy shifts the backup and restore

overhead away from the Oracle server.
• Proxy copies require support from the media
manager as 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 backup mode, they
will automatically be taken out of backup mode.
n l y
e O
Proxy Copy
U s
A proxy copy is a special type of backup in which RMAN turns over control of the data
A I
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
O
back up using the BACKUP PROXY command, RMAN queries the media manager to
l &
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
a
when you use the PROXY ONLY option, which causes Oracle to issue an error message when
n
it cannot proxy copy.
te r
Oracle records each proxy-copied file in the control file. RMAN uses this data to
I n
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
l e
to change the status of or delete a proxy backup.
c
r a
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
O
V$SESSION_LONGOPS; detail and aggregate rows. Detail rows describe the files being
processed by one job step, while aggregate rows describe the files processed by all job steps
in an RMAN command.

Backup Set Backup
• This Oracle9i 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>;
BACKUPDEVICE TYPE SBT

BACKUP SET
CREATED BEFORE 'sysdate – 1'
DELETE INPUT
n l y
e O
Backing Up Backup Sets
U s
You can now back up backup sets from disk to tape or from disk to disk. If RMAN discovers
A I
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
O
default disk channel to copy backup sets from disk to disk. To back up from disk to tape,
automatic sbt channel.

l &
you must either manually allocate a channel of DEVICE TYPE SBT or configure an
n a
The BACKUP BACKUPSET command is a useful way to spread backups among multiple
production backup schedule:

te r
media. For example, you can execute the following BACKUP command weekly as part of the
I n
BACKUP DEVICE TYPE SBT BACKUPSET ALL;
c l e
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:
r a
BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
O
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
• Oracle9i allows data files and archived logs to be

backed up with one command with the PLUS
ARCHIVELOG option of BACKUP.
RMAN> BACKUP DATAFILE 4 PLUS ARCHIVELOG;
• When backing up to tape, PLUS ARCHIVELOG is the
default behavior.
• RMAN will not raise an error if there are no archive
logs to backup.
• The BACKUP_COUNT column in V$ARCHIVED_LOG
shows the number of times an archived log was
backed up.
n l y
e O
Backing Up Archived Logs
U s
Under Oracle9i, it is now possible to backup data files and archived logs with a single
RMAN backup command. This new feature works as follows:
• The ALTER SYSTEM ARCHIVE LOG CURRENT command is run. A I
O
• The BACKUP ARCHIVELOG ALL command is run. If backup optimization is enabled,
l &
logs that are already backed up will be skipped.
• Backs up data files specified in the BACKUP command
a
• Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command once again
n
te r
• Backs up any archived logs generated during the backup
If there are no archived logs to back up, RMAN will not raise an error. This condition is
I n
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
l e
BACKUP_COUNT column to see the number of times an archived log was backed up.
c
r a
Backing Up Archived Logs That Need Backups
You can use NOT BACKED UP n TIMES clause of the BACKUP ARCHIVELOG command to
O
back up only those logs that have not been backed up at least n times. This option is a
convenient way 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.

Archivelog Backup Methods
• By time:
RMAN> backup archivelog from time ‘01-jan-00’
until time ‘30-jun-00’;
• By name:
RMAN> backup archivelog like
‘oracle/arc/dest/log%’;
• By archived logs:
RMAN> backup archivelog all;
• By log sequence:
RMAN> backup archivelog from logseq 20 until
logseq 50 thread 1;
• By SCN:
RMAN> backup archivelog from scn 1 until scn 9999;
n l y
e O
Archived Log Backup Methods
U s
Archived logs can be backed up by many methods. These include specifying archivelog by
from disk after they have been successfully backed up. For example: A I
time, by log sequence and by SCN. The DELETE INPUT option can be used to delete logs
backup format ‘al_%t_%s_%p’ archivelog all delete input; O

l &
Please note that only the archivelog backed up is deleted. This is an issue for multiple
archivelog destinations.
n a
te r
I n
c l e
r a
O
Long Term Backups
• It is possible to archive backups much longer than

the restrictions enforced by the retention policy.
• Enabled with the KEEP option to the BACKUP
command:
BACKUP ...
KEEP [UNTIL TIME
'date'|forever][NOLOGS|LOGS];
• The default behavior is NOKEEP.

• The NOLOGS option cannot be used in conjunction
with online backups.
n l y
e O
Long Term Backups
Under Oracle9i the KEEP option can be used with the CHANGE, COPY, or BACKUP
U s
option regardless of the retention policy. A I
commands to allow the backups to be kept until the time specified by the UNTIL TIME
O
If the backup should never expire, use the FOREVER option but keep in mind that a recovery
l &
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
n a
support. This is the default behavior. If NOLOGS is specified, the supporting archive logs
te r
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
I n
performed. NOKEEP specifies that the backup will not be kept beyond the the window
defined by the retention policy.
l
Some examples:
c e
r a
RMAN> BACKUP DATABASE KEEP UNTIL TIME "to_date('31-MAR-
2002','DD_MM_YYYY)" nologs;
O
RMAN> BACKUP TABLESPACE SAMPLE KEEP FOREVER NOLOGS

Test Backups Using RMAN
• The BACKUP...VALIDATE command can be used

to perform test backups.
BACKUP VALIDATE DATABASE;
• Check data files for physical and logical

corruption.
• Confirm that all database files exist and are in the
correct locations.
n l y
e O
Test Backups Using RMAN
U s
RMAN does not actually produce backup sets, but scans the specified files to determine
A I
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.
O
For example, you can validate that all database files and archived redo logs can be backed
up by issuing a command as follows:
l &
a
RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
n
te r
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.
I n
Another important use of BACKUP…VALIDATE is to identify corrupt blocks and populate
l e
the V$DATABASE_BLOCK_CORRUPTION view, then use the data to repair the blocks with
c
the BLOCKRECOVER command like this:
r a
RMAN> BACKUP VALIDATE DATABASE;
O
RMAN> BLOCKRECOVER CORRUPTION LIST;
Note: You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option
or validate backups of backup sets.

Test Backups 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 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Restarting a Backup
• With the introduction of Oracle9i, 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 UP SINCE
2> TIME '03-MAR-02 09:00:00';
• 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.
n l y
e O
Restarting a Backup
U s
Using the restartable backup feature, RMAN can back up only those files that have not been
A I
backed up since a specified date. This feature is intended for cases when a backup fails
partway through and you only want to back up the part of the database that did not finish..
O
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.
l &
a
To only back up files that were not backed up after a specified date, specify a valid date in
n
te r
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:
I n
RMAN> BACKUP NOT BACKED UP SINCE TIME ’SYSDATE-14’
l e
2> DATABASE PLUS ARCHIVELOG;
c
The unit of restartability is a single backup set. If the entire database is backed up into one
r a
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
O
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 Oracle Real
Application Clusters
RMAN can autolocate the following files in an Oracle

Real Application Clusters environment:
• Backup pieces during backup or restore
• Archived redo logs during backup
• Data file or control file copies during backup or
restore
n l y
e O
Default Autolocation for Real Application Clusters
U s
With the introduction of Oracle9i Release 2, RMAN now automatically discovers which
A
want to back up or restore. RMAN can autolocate the following files:
I
nodes of an Oracle Real Application Clusters configuration can access the files that you
• Backup pieces during backup or restore

O
• Archived redo logs during backup
l &
• Data file or control file copies during backup or restore
n a
RMAN detects the Real Application Clusters environment whenever the allocated channels
te r
have different PARMS or CONNECT strings. RMAN will then automatically enable the
autolocation feature. Prior to Oracle9i Release 2, you had to enable this option manually
n
with SET AUTOLOCATE and the option applied only to backup pieces.
I
c l e
r a
O
Summary

• Identify the types of backups 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 and
cumulative incremental backup
• Outline the Recovery Manager backup algorithm
• Demonstrate a working knowledge of the BACKUP
command functionality
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Practice Overview:
Backups With Recovery Manager

• Creating a cold backup
• Using the CATALOG command
• Creating RMAN backups
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Restore and Recovery with RMAN
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Identify tasks performed by RMAN before
restoring
• Understand important RESTORE functionality
• Understand the restore algorithm used by RMAN
• Identify the four distinct phases of recovery using
RMAN
• Understand important RECOVER functionality
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
The RESTORE Command
The RESTORE command can restore the following

types of files from image copies on disk or other
media:
• Database (all data files)
• Tablespaces
• Data files
• Control files
• Archived redo logs
• Server parameter files
n l y
e O
The RESTORE Command
U s
You use the RESTORE command to restore files from backups or image copies. RMAN can
A I
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
O
files to nondefault locations. RMAN restores backups from disk or tape and restores image
l &
copies from disk only. Typically, you restore when a media failure has damaged a current
data file, control file, or archived log or prior to performing a point-in-time recovery. The
a
RESTORE command restores full backups, incremental backups (level 0 only), or copies of
n
te r
data files, control files, and archived redo logs. Because the RECOVER command
automatically restores archived logs as needed, you should seldom need to restore logs
manually.
I n
c l e
r a
O
Steps in the RESTORE Process
• RESTORE reads only what is needed to restore the

required files.
• Allocates memory structures and buffers for each
file being restored
• Continues to read the backup set until all file
headers for all files being restored have been read
• Decides whether to restore blocks
• Checks for corruption and replaces backup set-
relative file numbers with correct RDBA file
numbers
n l y
e O
Steps in the RESTORE Process
U s
A I
When performing a restore, RMAN initially allocates memory structures and buffers 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
O
block address is then replaced with the tablespace relative-file number. If RMAN is
l &
restoring a data file backup set, 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
n a
do not need to be in sync. Many input buffers can be processed before an output buffer is
accidentally used.
te r
filled. The file header is restored last to ensure that a partially restored file cannot be
I n
RMAN can tell if a file has not been completely restored. It knows how many pieces are
in the set. If all pieces in the set are completely read and the file header is not
l e
encountered, DBMS_BACKUP_RESTORE requests another piece, which RMAN knows
c
a
does not exist.
r
O
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.
– This can be overridden by including a DEVICE TYPE
clause
n l y
e O
File Selection When Restoring
U s
RMAN uses the repository to select the best available backup sets or image copies for use in
A I
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
O
into account whether you specified an UNTIL clause in the RESTORE command.
l &
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
n a
command searches for backups and copies on all device types of configured channels.
te r
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
I n
allocate channels, and the file cannot be restored because no backup sets or data file copies
l e
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
c
a
you configure automatic channels.
r
O
Restore Optimization
• RMAN under Oracle9i 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.
n l y
e O
Restore Optimization
U s
In releases prior to Oracle9i, RMAN always restored the requested files. In Oracle9i, RMAN
A I
only restores a file if the header check does not succeed. This is now the default behavior.
By using the FORCE option of the RESTORE command it is possible to override this
O
behavior and restore the requested files unconditionally. Understand however, that restore
corrupted blocks.
l &
optimization only checks the data file header and does not the scan the data file body for
n a
Restore optimization is particularly useful in cases where a restore only partially completes.
te r
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
I n
restored during the previous attempt. With the ever-increasing size of databases today, this
time-saving feature is extremely important.
c l e
r a
O
Restore Concepts
RMAN performs several tasks prior to the restore

process:
• Queries the recovery catalog:
– To determine the configuration of the database
– Identify the backups available for use
• Decides what backups are optimal to restore the
specified files
• Compiles lists of files to restore, taking into
consideration the following items:
– Time specifications (point-in-time restore)
– Any tags specified by users
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Restoring Data Files and Tablespaces
• Restore data file backups and copies to either:

– The default location, overwriting the files with the
same name currently there
RMAN> RESTORE data file '/u01/oradata/tools01.dbf';
– A new location set with the SET NEWNAME command

RUN {
SET NEWNAME FOR data file '/u01/oradata/tools01.dbf'
TO '/tmp/tools01.dbf';
RESTORE data file '/u01/oradata/tools01.dbf';
}
• Restore a tablespace:
RMAN> RESTORE TABLESPACE tools;
n l y
e O
Restoring Data Files and Tablespaces
U s
RMAN automates the procedure for restoring files. It is not necessary to copy files manually
server session to restore the correct backups and copies to either:

A I
into the appropriate directories. When you issue a RESTORE command, RMAN directs a
O
• The default location, overwriting the files with the same name currently there
• A new location, which you can specify with the SET NEWNAME command
l &
To restore a data file, mount the database or keep it open and take the data file to be restored
offline.
n a
offline;
te r
SQL> alter database data file '/u01/oradata/tools01.dbf'
I n
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
l e
NEWNAME command, RMAN updates the data file names in the control file to the names of
c
the restored files; otherwise this update does not take place. When restoring data files or
r a
tablespaces, the database can be up but the data files or tablespaces must be offline:
O
RMAN> SQL "ALTER TABLESPACE tools OFFLINE IMMEDIATE";
RMAN> RESTORE TABLESPACE tools;
RMAN> RECOVER TABLESPACE tools;
RMAN> SQL "ALTER TABLESPACE tools ONLINE";

Restoring Archived Logs
To restore archived logs:

restore archivelog {all|like
<filename>|<archivelog range>|… );
• Archived logs can be manually restored but
generally, this is not needed.
– RMAN automatically restores all archived logs that
are needed during the recovery phase.
• Use SET ARCHIVELOG DESTINATION to override
the target database's LOG_ARCHIVE_DEST setting.
n l y
e O
Restoring Archived Logs
RMAN names the restored archived logs by using the LOG_ARCHIVE_FORMAT and the
U s
A I
LOG_ARCHIVE_DEST_1 parameters of the target database. These parameters are
combined in a port-specific fashion to derive the name of the restored archived log. It is
O
possible to override the default names by using the SET ARCHIVELOG DESTINATION
command. This command allows manual staging of archived logs to different locations
l &
while a database restore is occurring. During recovery, RMAN knows where to find the
restored archived logs.
n a
Connect to the target database and recovery catalog (if implemented), then start and open
the database:
te r
n
RMAN> STARTUP;
e I
Within a run command, you can override the LOG_ARCHIVE_DEST location if needed and
restore the archived logs:
RUN
c l
{
r a
SET ARCHIVELOG DESTINATION TO '/u02/tmp_restore';
O
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 using a catalog:
RMAN> RESTORE SPFILE TO'/tmp/spfileTEMP.ora';
• To a nondefault location without a catalog:
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM
2> AUTOBACKUP;
n l y
e O
Restoring the Server Parameter File
U s
RMAN can restore the server parameter file either to the default location or to a nondefault
A I
location. RMAN can also restore the server parameter file as a server parameter file or as a
client-side initialization parameter (INIT.ORA) file. If the instance is already started with
O
the server parameter file, then you cannot overwrite the existing server parameter file.
l &
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
n a
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;
te r
I n
Next, shutdown the instance and restart without mounting and restore the SPFILE:
l e
RMAN> STARTUP FORCE NOMOUNT
c
RMAN> RESTORE SPFILE;
r a
Finally, restart the instance. If the server parameter file was restored to a nondefault
O
location, the steps are slightly different.

Restoring the Server Parameter File (continued)
If a catalog is being used, restore the SPFILE as shown below:
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora';
The SPFILE now resides in a location different than originally specified in the initialization
parameter (INIT.ORA) file. Create a temporary one 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 INIT.ORA and SPFILE:
RMAN> STARTUP FORCE PFILE=/tmp/init.ora;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Parallelization of RESTORE
• Parallelization of RESTORE is controlled by:

– The number of channels allocated
– The number of backup sets that are required for
RESTORE
• This is true for full backups (level 0) as well as
incremental backups of levels greater than 0.
• RMAN minimizes tape scanning by restoring files
in the same order that they were backed up.
n l y
e O
Parallelization of RESTORE
U s
If there are multiple backup sets that need to be read to restore the whole database, it is
A I
faster to allocate an equal number of channels, thereby increasing the degree of
parallelization. However, if there is only one backup set that needs to be read to restore the
O
whole database, other channels would not be necessary and would not be used at all, even if
allocated.
l &
n a
te r
I n
c l e
r a
O
Restoring the Database to a New Host
With RMAN, you can:

• Create a duplicate version 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
n l y
e O
U s
RMAN supports several scenarios when restoring a database to a new host. For example, it
is possible to:
A I
• Create a duplicate version of the production database for testing or other purposes,
O
while retaining the production database on the original host.
l
production database on the original host.&
• Test the restore of the production database to a new host, while retaining the
a
• Move the location of the production database to a new host. The target must be
n
te r
mounted or open to duplicate the database to the auxiliary database.
To create a duplicate database for testing while maintaining the original database, use the
I n
DUPLICATE command instead of the RESTORE command. RMAN automatically creates a
unique database identifier for the duplicate database. To test the restore of a database to a
l e
new host or to move the database to a new host, run the RESTORE…DATABASE TEST
c
command. If you perform a test restore only, then you should do the following to prevent
r a
overwriting the target records in the recovery catalog:
O• Run RMAN in the default NOCATALOG mode when restoring the data files.
• If you must use a recovery catalog, then export the catalog and import it into a
different schema or database and use the copied recovery catalog for the test restore.

• The target initialization parameter file must be

available on the new host.
• The backups needed for the restore must be
accessible on the new host.
• RMAN cannot restore the initialization parameter
file, disk backups, or image copies to the new
host.
• The restored database will not have the online
redo logs of the production database.
• Do incomplete recovery up to the lowest SCN of
the newest archived log in each thread.
• Open with RESETLOGS.
n l y
e O
Restoring the Database to a New Host (continued)
U s
Make the target initialization parameter file accessible on the new host by copying it from
A I
the old host to a new host by using an OS utility like FTP. You must also make sure backups
used for the restore are accessible on the restore host. For example, if the backups were
O
made with a media manager, then make sure the tape device is connected to the new host.
l &
You cannot use RMAN to restore disk backups or image copies created on one host to a new
host. Again, you can use an OS utility like FTP. If the files are in the same location in the
n a
new host, then you do not need to recatalog them. If you transfer the files to a new location,
te r
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.
I n
Because the restored database will not have the online redo logs of the production database,
l e
perform incomplete recovery up to the lowest SCN of the most recently archived log in each
thread and then open with the RESETLOGS option. Obtain the SCN for recovery
c
a
termination by finding the lowest SCN among the most recent archived logs for each thread.
r
O
Restoring the Database to a New Host (continued)
Start SQL*Plus and use the following query to determine the necessary SCN:
SQL> SELECT MIN(SCN)
2 FROM (SELECT MAX(NEXT_CHANGE#) SCN
3 FROM V$ARCHIVED_LOG
4 GROUP BY THREAD#);
MIN(SCN)
----------
4366578
It is possible that you might encounter an RMAN-20240 error when attempting to
duplicate a database to either a local or 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
n l y
A common cause of this error is that the data file backups being used for the duplication
are inconsistent. Most likely an ALTER SYSTEM ARCHIVE LOG CURRENT
O
command was not executed after the data file backup completed. Because of this, RMAN
e
U s
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
at log sequence 6, the script might look like this::

A I
incomplete recovery when creating the duplication script. For example, to stop recovery
run {
set until logseq 6 thread 1; O
l &
allocate auxiliary channel dupdb1 type disk;
}
n a
duplicate target database to dupdb;
te r
For more detailed information on handling database duplication errors, refer to WebIV
Note:145620.1 “RMAN: Database Duplication Fails with RMAN-20240”.
I n
c l e
r a
O
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.
• Optionally, RMAN recovers the standby database
after the control file has been mounted up to:
– The specified time
– The latest archived redo log generated
• RMAN leaves the database mounted so the user
can
– Activate it
– Place it in manual or managed recovery mode
– Open it in read-only mode
n l y
e O
Create Standby Database with DUPLICATE
U s
When you create a standby database, the procedure differs depending on whether the
A I
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
O
outlined in Oracle9i Data Guard Concepts and Administration. Do not attempt these
network configuration.
l &
procedures until you have made all necessary initialization parameter settings and
a
After you have performed the steps necessary for preparing the standby instance, run the
n
te r
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
I n
database created by DUPLICATE without the FOR STANDBY OPTION, does not get a
new DBID. Therefore, you should not attempt to register the standby database in the
l e
repository for the primary database. Some of the steps for creating the standby database
c
differ depending on whether you specify that RMAN should recover the standby database
r a
after creating it. For a compete coverage of this topic, please refer to Oracle9i Recovery
Manager User’s Guide.
O
Note: It is possible that you may encounter problems creating the standby redo logs. This
is Bug 2312344. Please see WebIV Note 185076.1 for a workaround. The bug has been
corrected in Oracle9i Release 2.

Validating Restore of Backups and Copies
• A restore validation executes a restore test

without actually restoring the files
• The restore of the database, individual
tablespaces, data files, or control files can be
tested with the RESTORE…VALIDATE command.
RMAN> RESTORE DATABASE VALIDATE;
• Backups or copies can be tested with the
VALIDATE BACKUPSET command.
RMAN> VALIDATE BACKUPSET 218;
n l y
e O
Validating Restore of Backups and Copies
U s
A I
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
O
backups or copies. The RESTORE...VALIDATE command tests whether RMAN can
l &
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
a
you specify. Use VALIDATE BACKUPSET to specify which backups to test; use
n
te r
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
I n
data files offline when validating them.
c l e
1. Validate the restore of the backup sets and copies
This example validates the restore of the backup control file, SYSTEM tablespace, and all
r a
archived logs:
O
RMAN> RESTORE CONTROLFILE VALIDATE;
RMAN> RESTORE TABLESPACE SYSTEM VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE;

Validating Restore of Backups and Copies (continued)
2. Check the output
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, for 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 successfully validated the files.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Restore Autolocation
• Under Oracle9i, RMAN discovers which nodes of

an Oracle Real Application Clusters configuration
contain the backups you want to restore.
• RMAN searches for files on all configured
channels and restores files from those channels
only.
• Autolocation is enabled automatically when the
channels use:
– Different PARMS settings
– Different connect strings
n l y
e O
Restore Autolocation
U s
A I
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
O
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.
l
n a
For example, if channel 1 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
the following criteria:

te r
1 restores the log. Autolocation is automatically enabled when the channels meet any of
I n
• Different PARMS settings
• Different connect strings
c l e
r a
O
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 backup piece name
for the control file backup.
n l y
e O
Restoring When All Is Lost
U s
What happens if the recovery catalog and target database are both lost or the target
Write a PL/SQL Procedure A I

database and all control files are lost and no recovery catalog is used?
O
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
l
n a
entire lost database. It simply 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.
te
DBMS_BACKUP_RESTORE functions.
r
$ORACLE_HOME/rdbms/admin/dbmsbkrs.sql contains descriptions of all
I n
Does the Target Database Use a Recovery Catalog?
l e
If the target database used a recovery catalog, and the recovery catalog is lost, then the
c
first priority is to restore the recovery catalog.
r a
O
Restore When All Is Lost (continued)
Backups in Media Manager
If the only available backups are in the media manager, you must know the backup piece
name 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
backup piece names in their catalog, but if no listings are available, you will have to find
a control file by trial and error.
The procedure 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',
n l y
done);
dbms_backup_restore.copycontrolfile
e O
('first_control_file', 'second_control_file', recid,
stamp,fullname);
U s
end; /
A I
-- repeat the above copycontrolfile for each control file
Support Note
O
l &
Note: 60545.1 “How to Extract Control Files, Data Files, and Archived Logs from SMR
Backupsets” describes in great detail the process of manually extracting objects from
RMAN backups.
n a
te r
I n
c l e
r a
O
Recovery Types
• Complete recovery
– A recovery where all changes made to the database
since the restored backup have been applied
(including changes recorded in the online redo
logs)
• Incomplete Recovery
– A recovery where the recovery is stopped before all
changes made to the database since this backup
was applied
n l y
e O
Recovery Types
U s
A I
The concept of data file media recovery is the application of online or archived redo logs
or incremental backups to a restored data file in order to update it to the current time or
some other specified time. Use the RMAN RECOVER command to perform media
O
recovery and apply logs or incremental backups automatically. For our purposes, recovery
recoveries are performed:

l &
fall under two categories; complete recovery and incomplete recovery. Incomplete
n a
• To undo a user error (recover to the point-in-time before the error occurred)
te r
• When all redo information to complete the recovery is not available
• When the online logs are lost, and are not mirrored
I n
A “time” to recover to may be specified as a time, log sequence number, or SCN. Time
and log sequence are first resolved to an SCN before recovery is done. All files must be
l e
recovered to the same point-in-time.
c
r a
O
Recovery Concepts
• If the database is in ARCHIVELOG mode, it is

possible to:
– Completely recover the database
– Recover the database to any arbitrary point-in-time
(incomplete recovery)
• For NOARCHIVELOG mode databases, recovery is
not usually possible.
• If a database is closed during recovery, all the files
must be consistent before the database can be
opened.
n l y
e O
Recovery Concepts
U s
ARCHIVELOG Mode
A I
If the database is in ARCHIVELOG mode, it is possible to either completely recover the
O
database, or recover the database to any arbitrary point-in-time (incomplete recovery).
NOARCHIVELOG Mode
l &
For NOARCHIVELOG mode databases, complete recovery is not usually possible. The
a
only option is to restore from a consistent whole database backup.
n
te r
State of Database and Recovery
If a database is closed during recovery, all files in that database must be consistent with
I n
each other before the database can be opened. If a database is open during a tablespace or
data file recovery, the tablespace or data file must be consistent with the remaining data
l e
files before it can be brought online (implying that incomplete recovery is not possible in
c
a
this scenario).
r
O
Basic RMAN Media Recovery
RMAN basic media recovery steps:

1. Place the database in the appropriate state.
– Mount the database when recovering whole
database.
– Open the database for online tablespace recovery.
2. For incomplete recovery, use SET UNTIL to
specify the time, SCN, or log sequence number at
which recovery terminates.
3. Restore necessary files using the RESTORE
command.
4. Recover the data files using the RECOVER
command.
5. Place the database in its normal state.
n l y
e O
Basic RMAN Media Recovery
U s
A I
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—
O
assuming that you have backups of the data files and at least one autobackup of the
the following commands:

l &
control file. Consider the following example of RMAN media recovery. The DBA runs
RESTORE DATABASE;
n a
RECOVER DATABASE;
te r
I n
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
l e
decides which backup sets to restore, and which incremental backups and archived logs to
c
use for recovery. A server session on the target database instance performs the actual
r a
work of restore and recovery.
O
RMAN Recovery Phases
• RMAN divides the RECOVER functions into four

distinct phases:
– RCV1: Fix the control file and switch to using data
file copies
– RCV2: Apply incremental backups
– RCV3: Apply all redo on disk
– RCV4: Restore archivelogs and apply redo until
complete
• These phase tags appear often in RMAN
debugging output.
n l y
e O
RMAN Recovery Phases
U s
RCV2, RCV3, RCV4 in the RMAN Log.
A I
RMAN performs recovery in four phases. These can be identified by the tags RCV1,
RCV1 (Phase 1)
O
During RCV1, the backup control file is inspected and updated, if necessary. Without
l &
doing this, recovery would stop whenever it detects that a new data file was added to the
n a
database. The DBMS_BACKUP_RESTORE.SWITCHTOCOPY procedure is used to
update the control file. Next, implicit switches are performed if required. For example,
te r
when the user indicates “restore data file 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
I n
automatically execute a SET NEWNAME command for that data file.
l
RCV2 (Phase 2)
c e
Check for any incremental backups and offline ranges that can be applied. Incremental
r a
backups are applied to a level 0 or full backup. If an incremental backup cannot be found,
O
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)
Oracle records an archived log in the control file whenever one of the following occurs:
• The archiver 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 specified in the initialization parameter file. If the DELETE
ARCHIVELOG option was specified, then the archived logs are deleted after restoring
and applying them.
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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Parallelization of Recovery
• The parallelization of applying incremental

backups is controlled by:
– The number of channels allocated
– The number of incremental backup sets needed for
recovery
• Redo Application
– Can be parallelized by setting the INIT.ORA
parameter RECOVERY_PARALLELISM
– RMAN will restore archived redo logs automatically
as they are required.
– Alternatively, archived logs can be manually
restored to disk in preparation for recovery.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Incomplete Database Recovery
• Incomplete recovery is stopped before the

database is fully recovered to its current state.
• Also known as database point-in-time recovery
(DBPITR).
• DBPITR is typically performed when a user error
requires the database to be recovered to a point-
in-time before the error occurred.
• The database backup used by the restore must
have completed before the time being recovered
to.
n l y
e O
Incomplete Database Recovery
U
RMAN can perform recovery of the database to a past time, SCN, or log sequence
s
A I
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).
O
l &
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,
a
eliminating the possibility of corrupting data files by the application of obsolete archived
n
te r
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
I n
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.
l e
The easiest method to perform DBPITR is to use the SET UNTIL command because it
c
sets the desired time for any subsequent RESTORE, SWITCH, and RECOVER commands
r a
in the same RUN job. If you specify a SET UNTIL after a RESTORE and before a
RECOVER, it may not be possible to recover the database to the desired point in time
Obecause the restored files may already have time stamps more recent than the set time. It
is recommended that you specify the SET UNTIL command before the RESTORE
command.

Block Media Recovery
• Oracle9i introduced 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
• RMAN must be used for BMR:
– Restores individual data blocks from available
backups
– Coordinates with the server to have them recovered
Tape
n l y
e O
Block Media Recovery
U s
A I
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
O
blocks. Only blocks being recovered need to be unavailable, allowing continuous
l &
availability of the rest of the database during recovery. Block media recovery (BMR)
provides two main benefits over file-level recovery:
n a
• Lowering the mean time to recover (MTTR)
te r
• Allowing increased availability of data during media recovery as the data file being
recovered remains online.
I n
BMR uses existing recovery mechanisms to apply changes from the redo stream to block
versions restored from suitable backups. RMAN must be used to perform BMR. RMAN
l e
restores individual data blocks from available backups and coordinates with the Oracle
c
r a
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 generated for that
O
file because backup must be applied. The reduction in MTTR 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.

Other BMR Benefits
• Increased availability during media recovery:

– The data file where the blocks are being recovered
remains online.
– Only blocks undergoing media recovery are
inaccessible.
• Ability to skip over missing or corrupt redo:
– Corrupted redo records are ignored if they do not
pertain to blocks being recovered.
– BMR defers signaling stuck recovery failure
because missing redo changes may refer to a block
that could be renewed later in the redo stream.
n l y
e O
Other BMR Benefits
U s
Data blocks undergoing media recovery are inaccessible to queries or DML because they
A I
are media corrupt, but the data file itself remains online. This is a significant availability
improvement over file-level recovery, where the entire data file is offline for the duration
of the recovery.
O
l &
BMR may be able to survive gaps in the redo stream if it is evident that the missing redo
records do not pertain to blocks being recovered. This does not help if the redo stream is
a
unreadable, but provides some degree of fault tolerance to missing or corrupt redo
n
te r
records. BMR requires an unbroken set of redo changes only for the blocks being
recovered, which is a weaker requirement than the unbroken redo stream currently
I n
required by data file/database media recovery. Failure status for each block in the set
being recovered is independent, so BMR may be successful for a subset of the recovery
set.
c l e
BMR can defer signaling stuck recovery failure when missing redo changes are first
r a
detected. When a block is renewed all previous redo for that block becomes irrelevant,
because the redo applies to a defunct incarnation of the block. BMR can optimistically
O
defer failure if a redo change needed for a block is missing or corrupt, because the block
may be renewed at some later point in the redo stream. For example, the Oracle server
can renew a block when users delete all the rows recorded in the block or drop the table.

The BLOCKRECOVER Command
• BMR is implemented through the RMAN

BLOCKRECOVER command.
• Identifies the backups from which to obtain the
blocks to recover
• Reads the backups and accumulates requested
blocks into in-memory buffers
• Starts and manages the block media recovery
session, reading the archive logs from backup if
necessary
RMAN> BLOCKRECOVER data file 6 BLOCK 3;
n l y
e O
The RMAN BLOCKRECOVER Command
U s
A I
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
O
question saving an enormous amount of down time and data unavailability.
The BLOCKRECOVER command does the following:
l &
n a
• Identifies the backups from which to obtain the blocks to recover
• Reads the backups and accumulates requested blocks into in-memory buffers. If any
te r
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
I n
option limits selection to backup sets or file copies taken at or before the specified
time, SCN, or log sequence; this forces BLOCKRECOVER to use an older backup
l e
instead of the most recent one.
c
r a
• Starts and manages the block media recovery session, reading archive logs from
backup if necessary.
O • Always does a complete recovery. No point-in-time recovery is possible 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: ORACLE data block corrupted (file # 6, block # 3)
ORA-01110: data file 6: '/oracle/dbs/tbs_71.f'
ORA-01578: ORACLE data block corrupted (file # 2, block
# 235)
ORA-01110: data file 2: '/oracle/dbs/tbs_21.f‘
You can then specify the corrupt blocks in the BLOCKRECOVER command as follows:
RMAN> BLOCKRECOVER data file 6 BLOCK 3 data file 2 BLOCK
235;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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 listed in this view.
RMAN> BLOCKRECOVER CORRUPTION LIST RESTORE
UNTIL TIME 'sysdate – 10';
• RMAN lists corruptions in backup sets and proxy
copies in two views:
– V$BACKUP_CORRUPTION
– V$COPY_CORRUPTION
n l y
e O
RMAN BMR Interface
U s
A I
Using the CORRUPTION LIST clause in Oracle9i recovers blocks listed in
V$DATABASE_BLOCK_CORRUPTION. After a block has been repaired through block
media recovery (or normal media recovery), V$DATABASE_BLOCK_CORRUPTION
O
will not be updated until you take a new backup. The UNTIL clause specifies that only
l
should be restored and used for the recovery. &
backups and copies created before the specified time, SCN, or log sequence number
n a
Two types of corruption result in rows being added to V$BACKUP_CORRUPTION and
te r
V$COPY_CORRUPTION by the BACKUP and COPY commands respectively:
• Physical corruption (sometimes called media corruption). The Oracle server does
I n
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
l e
ON by default, and can be turned off with the NOCHECKSUM option.
c
r a
• 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
O default, and can be turned on with the CHECK LOGICAL option.

Trial Recovery
• In Oracle9i, trial recovery is invoked by adding the

TEST option to any restore command:
RMAN> RECOVER DATABASE USING BACKUP CONTROLFILE TEST;
RMAN> RECOVER TABLESPACE sales TEST;
RMAN> RECOVER DATABASE UNTIL CANCEL TEST
– Errors are reported in the alert log.
• Media recovery can mark a data block corrupt if
required to proceed.
RMAN> RECOVER DATABASE ALLOW 1 CORRUPTION;
– The alert log indicates if the problem can be

skipped.
• The database is left in a consistent state and when
recovery stops, the database can always be
opened.
n l y
e O
Trial Recovery
U s
In the past, some problems that can occur during media recovery were not “recoverable.”
A I
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
O
can take a long time. The following enhancements are now provided:
l &
• If media recovery of a full database encounters a problem, recovery always leaves
behind a consistent database, a database that can be opened read-only or with
resetlogs.
n a
te r
• 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.
I n
• Using another new option of recovery command, database administrators can invoke
c l e
Trial Recovery in order to investigate if a recovery problem is an isolated problem.
With these enhancements, almost all practical problems during media recovery are
r a
recoverable thanks to an optimistic redo application algorithm. Recovery optimistically
assumes that no problem will occur during media recovery. If one does occur, the Oracle
O
server will rollback 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 internal/secret@prod rcvcat

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> }
n l y
e O
Tablespace Recovery Example
U s
A I
This example illustrates the restoration and recovery of all files in the SAMPLE
tablespace. In this scenario, a channel is manually allocated. Assume the database is open.
O
l &
n a
te r
I n
c l e
r a
O
Recover Database Example
To recover the database with an autobackup of the

control file without a recovery catalog:
1. Start RMAN and connect to the target database.
2. Start the target instance but don’t 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.
n l y
e O
Database Recovery Example
1. Start RMAN and connect to the target database. For example, run:
U s
RMAN> CONNECT TARGET /
A I
2. Start the target instance without mounting the database. For example:
STARTUP NOMOUNT;
O
l &
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.
n a
RMAN> SET DBID 676549873;
te r
4. Restore the autobackup control file, then perform recovery. Specify the most recent
I n
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
l e
nondefault format for the restore of the control file. If the channel that created the
c
control file autobackup was device type sbt, then you must allocate one or more
r a
sbt channels. Because no repository is available, you cannot use automatic
channels. If the autobackup was created on a disk channel, however, then you do not
O 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 n l y
months
6> ALTER DATABASE MOUNT DATABASE;
e O
7> }
# use automatic channels configured in restored control
U s
file
RMAN> RESTORE DATABASE UNTIL SEQUENCE 13243;
A I
RMAN> RECOVER DATABASE UNTIL SEQUENCE 13243;
O
l
RMAN> ALTER DATABASE OPEN RESETLOGS;&
5. If recovery was successful, then open the database and reset the online logs:
a
6. You should back up the database immediately, with the database mounted. Because
n
te r
the database is a new incarnation, the backups made before the RESETLOGS are
not easily usable. Enter:
I n
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
l e
c
RMAN> ALTER DATABASE OPEN;
r a
O
Recover 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.
n l y
e O
Recovering a Database in NOARCHIVELOG Mode: Example
A NOARCHIVELOG database can be recovered with consistent incremental backups.
U s
A I
Assume 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
O
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.
l &
Because the online redo logs are lost, you must specify the NOREDO option in the
n a
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
te r
you could have run RECOVER DATABASE without specifying NOREDO. Connect to
TRGT and the catalog and recover the database using the following command:
I n
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent
backup
c l e
ALTER DATABASE MOUNT;
r a
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO online redos are
O
lost
ALTER DATABASE OPEN RESETLOGS;
All changes generated between the Friday incremental backup and the Saturday failure
are not applied.

DBPITR Example
Database Point-In-Time Recovery

$ rman target internal/secret@prod rcvcat
rman/rman@rcat
RMAN> startup nomount
RMAN> run {
2> set until time "to_date('2002/02/23 16:00:00',
3> 'YYYY/MM/DD HH24:MI:SS')";
4> allocate channel t1 type 'SBT_TAPE';
5> allocate channel t2 type 'SBT_TAPE';
6> restore controlfile;
7> sql 'alter database mount';
8> restore database;
9> recover database;
10> }
n l y
e O
DBIPTR Example
U s
A I
The above example illustrates the restore of the whole database, including control file (to
the original locations) until time ‘2002/02/23 16:00:00’. This example assumes the
database is stopped. Note the startup command is done from RMAN.
O
l &
n a
te r
I n
c l e
r a
O
BLOCKRECOVER Examples
1. Recovering a group of corrupt blocks

2. Limiting block media recovery by type of restore
3. Limiting block media recovery by backup tag
4. Limiting block media recovery by time, SCN, or log
sequence
n l y
e O
BLOCKRECOVER Examples
1. Recovering a group of corrupt blocks
U s
BLOCKRECOVER datafile 2 BLOCK 12, 13 datafile 7 BLOCK 5,
98, 99 datafile 9 BLOCK 19;
A I
O
2. This example recovers a series of blocks and restores only from data file copies:
RUN {
l &
BLOCKRECOVER data file 3 BLOCK 1,2,3,4,5
a
TABLESPACE sales DBA 4194405, 4194409, 4194412
n
}
FROM data fileCOPY;
te r
I n
3. Limiting BMR by backup tag
BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 FROM
l e
TAG "weekly_backup";
c
4. The following example recovers two blocks in the SYSTEM tablespace and forces
r a
the blocks to be restored from backups created at least two days ago:
BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405
O RESTORE UNTIL TIME 'SYSDATE-2';

BLOCKRECOVER Examples (continued)
The following example recovers two blocks and forces the blocks to be restored using
backups made before SCN 100:
BLOCKRECOVER data file 9 BLOCK 13 data file 2 BLOCK 19
RESTORE UNTIL SCN 100;
The following example recovers two blocks and forces the blocks to be restored using
backups made before log sequence 7024:
BLOCKRECOVER data file 9 BLOCK 13 data file 2 BLOCK 19
RESTORE UNTIL SEQUENCE 7024;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Summary

• Identify tasks performed by RMAN before
restoring
• Understand important RESTORE functionality
• Understand the restore algorithm used by RMAN
• Identify the four distinct phases of recovery using
RMAN
• Understand important RECOVER functionality
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview:
Restore and Recovery with RMAN

• Familiarity with DBMS_BACKUP_RESTORE
• Complete recovery from a total failure
• Incomplete recovery to some time in the past
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
RMAN Maintenance
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Use the LIST command to display backup data
recorded in the catalog or target control file
• Use the REPORT command to gather detailed
information regarding 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Oracle9i Command Unification
• RMAN has four related command sets for catalog

maintenance: LIST, CROSSCHECK, CHANGE, and
DELETE…EXPIRED.
• A number of changes have been implemented to
provide greater consistency:
– Unified actions
– Similar syntax
– Shared output style and status codes when
possible
• The old syntax is still supported for backwards
compatibility.
n l y
e O
Oracle9i Command Unification
U s
the command sets:
• CROSSCHECK and DELETE...EXPIRED deal with all object types. A I
The following changes have been implemented to provide greater consolidation among
O
• CROSSCHECK, DELETE, and LIST can process smaller object sets like CHANGE
does.
l &
a
• CROSSCHECK sets status to 'X' if a data file copy, control file copy, and so on is
n
te r
not available and skips any objects that are unavailable.
• CROSSCHECK and DELETE functions have been consolidated.
I n
• UNCATALOG function has been removed.
• DELETE lists and prompts for confirmation unless NOPROMPT is specified.
l e
• CHANGE syntax enhanced to be more consistent with DELETE/CROSSCHECK and
c
r a
supports larger object list.
• LIKE (fileNamePattern) added to CROSSCHECK/DELETE/CHANGE for pattern
O matching.
• LIST shows what CROSSCHECK/DELETE EXPIRED will process.

CROSSCHECK Command
• The CROSSCHECK command synchronizes backup

pieces in the recovery catalog with their
corresponding files.
RMAN> allocate channel for maintenance
2> type 'sbt_tape';
RMAN> crosscheck backup;
• Use the crosscheck feature to check the status of
a backup or copy on disk or tape.
• Crosscheck will work only on items that are
recorded in the RMAN repository.
• Addresses auto-expiration by the media manager
n l y
e O
The CROSSCHECK Command
U s
A I
Sometimes backups and copies disappear from disk, or tapes in the media management
library become unavailable. Crosschecks can also update the repository if you delete
archived redo logs or other files using operating system commands. To ensure that data
O
about backup sets and image copies in the recovery catalog or control file is synchronized
l &
with actual files on 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
a
queries the media management software. The CROSSCHECK command operates only on
n
te r
files that are recorded in the RMAN repository.
Use CROSSCHECK to check the status of a backup or copy on disk or tape. If the backup
I n
or copy is on disk, then CROSSCHECK checks whether the header of the file is valid. If a
backup is on tape, then the command checks that the backups exist. Backup sets, pieces,
l e
and copies can be AVAILABLE, EXPIRED, or UNAVAILABLE. You can issue the
c
DELETE EXPIRED command to delete all expired backups and copies. RMAN removes
r a
the record for the expired file from the repository. If for some reason the file still exists on
Othe media, then RMAN issues warnings and lists the mismatched objects that cannot be
deleted.

The LIST Command
The LIST command displays the contents of the

RMAN repository (control file or recovery catalog).
• List all databases known to the recovery catalog
or incarnations of a database:
RMAN> list incarnation of database;
• List backup sets or file copies containing a

backup of a specified list of files:
RMAN> list backup of datafile 2;
• List all data file copies, control file copies, and
archived logs:
RMAN> LIST COPY;
n l y
e O
The LIST Command
U s
The LIST command queries the recovery catalog or control file and produces a listing of
A I
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
O
the database. View incarnations with the LIST INCARNATION command.
RMAN> list incarnation;
List of Database Incarnations
l &
DB Key
-------
Inc Key
-------
DB Name
--------
n a
DB ID
------------
CUR
---
Reset SCN
----------
Reset Time
----------
1
1
2
73
U02
U02
te r 775813490
775813490
NO
YES
1
440227
06-MAR-02
27-MAR-02
I n
Some important column descriptions are described below:
DB Key When combined with the Inc Key, the unique key by which RMAN
c l e identifies the database incarnation in the recovery catalog.

Whether the incarnation is the current incarnation of the database.
a
CUR
r
Reset SCN
O
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 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/user02/ORADATA/u06/01dk630k_1_1
---- -- ---- ---------- --------- ----
2 Full 439498 24-MAR-02 /u01/user02/ORADATA/u02/undo1_01_U02.dbf

------- ---- -- ---------- ----------- ------------ ---------------
59 Incr 1 29M DISK 00:00:09 27-MAR-02
Piece Name: /u01/user02/ORADATA/u06/03dkd96e_1_1
---- -- ---- ---------- --------- ----
2
Column
0 Incr 439828
Indicates
27-MAR-02 /u01/user02/ORADATA/u02/undo1_01_U02.dbf
n l y
File The absolute data file number
e O
----------- --------------------------------------------------------------------------------------------
Key
s
A unique key identifying this backup set. If you are connected to a recovery
U
catalog, then Key is the primary key of the backup set in the catalog. It
A
in NOCATALOG mode, then Key displays the RECID fromI
corresponds to BS_KEY in the RC_BACKUP_SET view. If you are connected
V$BACKUP_SET. RECID and STAMP form a concatenated primary key that

O
uniquely identifies this record in the target control file.
TY
LV
l &
The type of backup: backup set (B) or proxy copy (P)
The backup level: F for non-incrementals, level 0-4 for incrementals
S
a
The backup set status: available (A), unavailable (U), or expired (X)
n
te r
Ckp SCN The checkpoint of the data file at the time it was backed up.All database
changes prior to the SCN have been written to the file; changes after the
I n
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
c l e
prior to the time have been written to the file; changes after the specified time
have not been written to the file
r a
#Pieces The number of backup pieces in the backup set
#Copies The number of copies made of each backup piece in the set. The number
O
Tag
is 1 if no duplexing was performed. Otherwise, the value ranges from 2 to 4
The tag applied to the backup set; NULL if none

LIST Command Output
• LIST command output is verbose by default.

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

The REPORT Command
The REPORT command reports data in more detail than

LIST and can answer questions such as:
• What files need a backup?
• Which files have had unrecoverable operations
performed on them?
• Which backups or copies are obsolete and can be
deleted?
• What was the physical schema of the database at
some previous time?
n l y
e O
The REPORT Command
U s
REPORT command to answer questions such as the following:
• Which files need a backup? A I
To gain more detailed information from the RMAN repository, generate a report. Use the
O
• Which files have had unrecoverable operations performed on them?
l &
• Which backups or copies are obsolete and can be deleted?
• What was the physical schema of the database at some previous time?
n a
• Which files have not been backed up recently?
te r
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
I n
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
l
and copies.
c e
r a
O
Report Objects Needing Backup
• Reports files needing 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';
n l y
e O
Report Objects Needing Backup
U s
A I
You can report on 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
O
not specify the parameter, REDUNDANCY defaults to 1. The DAYS parameter indicates
l &
that recovery must begin by using logs more than integer days old. The
INCREMENTAL parameter indicates that more than integer incremental backups are
a
required for complete recovery. If you disable the retention policy, then REPORT NEED
n
RMAN> report need backup;
te r
BACKUP generates an error message:
I n
RMAN-00571: ================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS=========
l e
RMAN-00571: ================================================
c
RMAN-03002: failure of report command at 03/28/2002 21:07:27
r a
RMAN-06525: RMAN retention policy is set to none
O
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. 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, run REPORT NEED BACKUP DAYS.
Any files 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
n l y
RMAN> REPORT NEED BACKUP DAYS = 30 TABLESPACE SYSTEM;
O
4. To determine which files need an incremental backup, specify the INCREMENTAL
e
parameter. If complete recovery of a data file requires more than the specified
For example, enter: U s

number of incremental backups, then RMAN considers it in need of a new backup.
A
RMAN> REPORT NEED BACKUP INCREMENTAL = 1 DATABASE;
RMAN REPORT NEED BACKUP INCREMENTAL = 3 TABLESPACE
I
SYSTEM;
O
l &
n a
te r
I n
c l e
r a
O
Report Unrecoverable Backups
and Copies
• Run the REPORT UNRECOVERABLE command

regularly to ensure that recovery is possible.
RMAN> report unrecoverable;
• A data file is unrecoverable if an unrecoverable

operation has been performed against an object in
the data file since the last backup.
• The absence of a backup of a data file is not
sufficient reason to consider it unrecoverable.
n l y
e O
Report Unrecoverable Backups and Copies
U s
A I
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
O
TABLE EMPLOYEES...NOLOGGING statement. If the EMPLOYEES table is located
unrecoverable.
l &
in data file 3, then the REPORT command can flag backups of this data file as
n a
After connecting to the target database and recovery catalog (if you use one) and run:
te r
RMAN> REPORT UNRECOVERABLE DATABASE;
The nonexistence of any backup of a data file is not sufficient reason to consider it
I n
unrecoverable. Such data files can be recovered through the use of the CREATE
c l e
DATAFILE command, if redo logs starting from when the file was created still exist.
r a
O
Report Obsolete Backups and Copies
• Use the OBSOLETE option to identify which

backups are superfluous.
RMAN> REPORT OBSOLETE REDUNDANCY = 2
DEVICE TYPE sbt;
• Use the ORPHAN option to list unusable backups

and copies.
RMAN> REPORT OBSOLETE ORPHAN;
• The RECOVERY WINDOW option specifies a window

during which the database must be recoverable.
– This option was introduced with Oracle9i
n l y
e O
Report Obsolete Backups and Copies
U s
You can report on objects that are obsolete,or unneeded, by specifying the OBSOLETE
A I
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
O
default, the retention policy is configured to REDUNDANCY of 1. A new option,
l &
RECOVERY WINDOW, has been added in Oracle9i to specify a window of time during
which the database must be recoverable. This option is mutually exclusive with the
a
REDUNDANCY option. When RECOVERY WINDOW is specified, then for each data file,
n
one are obsolete.
te r
one backup that is older than the recovery window must exist. All backups older than that
I n
To list backups and copies that are obsolete and are candidates for removal, the following
steps outline a typical approach:
c l e
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.
r a
Following is a possible crosscheck session:
RMAN> CROSSCHECK BACKUP; # crosschecks all backups
O RMAN> CROSSCHECK COPY; # crosschecks all copies

2. Use the OBSOLETE option to find backups that are no longer needed for recovery.
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;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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.
n l y
e O
Report Database Schema
U s
A I
It is not necessary to use V$ 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
O
historical reports of the database schema at a past time. You do not need a recovery
catalog, however, to report the current schema
l &
n a
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:
te
RMAN> REPORT SCHEMA AT SCN 1000;
Report of database schema
r
File K-bytes
I n
Tablespace RB segs Datafile Name
----
1
-------
cl
307200 e ----------
SYSTEM
-------
YES
----------------------------
/oracle/oradata/trgt/system01.dbf
a
2 20480 UNDOTBS YES /oracle/oradata/trgt/undotbs01.dbf
O
8 r
...
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;
• The SHOW ALL command displays current
CONFIGURE values as well as RMAN’s default
configurations.
• Any CONFIGURE command can be returned to its
default setting by running CONFIGURE…CLEAR.
n l y
e O
Show RMAN Configuration Settings
U s
The SHOW ALL command displays both the CONFIGURE commands that you have issued
command to its default setting by running CONFIGURE...CLEAR. A I

as well as RMAN’s default configurations. Note that you can return any CONFIGURE
O
To show all RMAN configuration settings, connect to the target database and run the
SHOW ALL command:
RMAN> SHOW ALL;
l &
n
a
CONFIGURE
... r
RETENTION POLICY TO REDUNDANCY 1; # default
te
n
CONFIGURE DATAFILE BACKUP COPIES FOR DISK TO 2;
CONFIGURE
CONFIGURE
e I
DATAFILE BACKUP COPIES FOR SBT TO 1; #default
ARCHIVELOG BACKUP COPIES FOR SBT TO 1; # default
CONFIGURE
c
CONFIGURE l ARCHIVELOG BACKUP COPIES FOR DISK TO 1; # default
SNAPSHOT CONTROLFILE NAME TO ’/oracle/dbs/cf_snap.f’;
r a
Individual settings can be shown like this:
O
RMAN> show retention policy;

The CHANGE…UNAVAILABLE and
CHANGE…AVAILABLE Commands
• The CHANGE…UNAVAILABLE command is used to

update the 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;
• When the maintenance is complete, the
CHANGE…AVAILABLE command can be issued.
n l y
e O
The CHANGE…UNAVAILABLE Command
U s
A I
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
O
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.
l
n a
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
te r
that this command does not check for the existence of the files or validate the file in any
way: it merely updates the repository record to AVAILABLE. You can run CROSSCHECK
I n
to validate the file.
c l e
r a
O
CHANGE…UNCATALOG Command
• To remove references to a backup piece, file copy,

or archivelog from the recovery catalog if it was
for example deleted by an O/S utility
RMAN> change archivelog
2> '/disk1/archivelog/al_prd1_123.rdo'
3> uncatalog;
• The CHANGE…UNCATALOG command does not touch

physical backups and copies.
n l y
e O
The CHANGE…UNCATALOG Command
U s
A I
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 touch
O
physical backups and copies. Use this command to notify RMAN when a file is deleted
by some means other than a DELETE command.
l &
n a
In releases prior to Oracle9i, RMAN sometimes updated the status of records to
DELETED in the recovery catalog rather than removing the records altogether. In
te r
Oracle9i, RMAN always removes the catalog record rather than marking it as DELETED.
Therefore, catalog records should only be marked with status DELETED if the catalog has
I n
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 using the
l e
prgrmanc.sql script, which is located in $ORACLE_HOME/rdbms/admin.
c
r a
O
Deleting Specified Backups and Copies
To delete backups and copies and remove their

repository records:
• Use the LIST command to obtain primary keys of
backups and copies.
• Allocate a channel for maintenance if you don’t
have an automatic one configured.
• Run the DELETE command to remove the physical
files and their repository records.
n l y
e O
Deleting Specified Backups and Copies
U
Use the DELETE command to remove backups and copies that you no longer want to
s
A I
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.
O
To delete backups and copies and remove their repository records:
l &
1. Run the LIST command to obtain primary keys of backups and copies.
RMAN> LIST BACKUP OF DATABASE ARCHIVELOG ALL;
RMAN> LIST COPY;
n a
channel.
te r
2. If you do not have automatic channels configured, then allocate a maintenance
I n
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
3. Run the DELETE command to eliminate the specified physical files and their
c l e
repository records. You can delete any type of object in the recordSpecclause,
for example:
r a
RMAN> DELETE BACKUPPIECE 101;
RMAN> DELETE CONTROLFILECOPY ’/tmp/control01.ctl’;
O RMAN> DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300;

RMAN> DELETE 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Deleting 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 in the repository.
RMAN> DELETE EXPIRED BACKUP;
• Run the DELETE OBSOLETE command with no
options to delete backups, copies, and their
records that are obsolete as defined by the
retention policy.
RMAN> DELETE OBSOLETE;
n l y
e O
Deleting Expired or Obsolete Backups
U s
A I
You can use the CROSSCHECK command to determine whether backups and copies
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
O
DELETE EXPIRED command to remove these expired records. Note that if for some
l &
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
a
that are obsolete, as defined by the defined retention policy. The DELETE OBSOLETE
n
te r
command removes both the physical files, deletes the catalog records (if you use a
catalog), and updates the records in the target control file to status DELETED.
I n
You can run the DELETE OBSOLETE REDUNDANCY or DELETE OBSOLETE
RECOVERY WINDOW commands to delete obsolete backups and copies. The
l e
redundancy or recovery window setting on the DELETE command overrides settings on
c
the CONFIGURE RETENTION POLICY command. For example, enter:
r a
RMAN> DELETE OBSOLETE REDUNDANCY = 3;
O
RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;

Stored Script Information
• List stored scripts by querying

RC_STORED_SCRIPT.
• Use the PRINT SCRIPT command to display the
text of a stored script.
• Display text of stored scripts by querying
RC_STORED_SCRIPT_LINE.
n l y
e O
Stored Script Information
U s
A I
The RC_STORED_SCRIPT view contains information about all stored scripts for all
incarnations of the target databases registered in the catalog. Use the PRINT SCRIPT
command to display the text of a stored script. If desired, you can save the output to an
O
RMAN log file. The RC_STORED_SCRIPT_LINE view contains the text of all stored
&
scripts for all incarnations of the target databases registered in the recovery catalog.
l
a
To print scripts from RMAN and save the output to a log file:
n
te r
$ rman TARGET / CATALOG rman/cat@catdb LOG = rman_log
RMAN> PRINT SCRIPT backup_whole;
I n
To view script lines from the RC_STORED_SCRIPT_LINE view, start a SQL*Plus
session and connect to the recovery catalog as RMAN:
c l e
$ sqlplus rman/cat@catdb
r a
SQL> SELECT TEXT
2 FROM RC_DATABASE_INCARNATION i, RC_STORED_SCRIPT_LINE s
O 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
Tasks 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
n l y
e O
Maintenance Required
U s
A I
When you do not use a recovery catalog, the control file is the sole 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
O
records to the control file, but the oldest record is less than the value specified in
CONTROL_FILE_RECORD_KEEP_TIME?
l &
n a
The Oracle server attempts to expand the size of the control file, which it can only do if
the underlying operating system file can be expanded. If it cannot expand the control file,
te r
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.
I n
Hence, if you are not using a recovery catalog, then set the
CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file
l e
that you need to keep.
c
r a
If you use the control file as the sole repository of the RMAN metadata, maintain
alternate control files through multiplexing or operating system mirroring and back up the
O
control file frequently. If you lose the control file and do not have a backup, you lose all
information about RMAN backups and copies contained in the file. For this reason, you
should set CONFIGURE CONTROLFILE AUTOBACKUP to ON.

Summary

• Use the LIST command to display backup data
recorded in the catalog or target control file
• Use the REPORT command to gather detailed
information regarding 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Practice Overview:
RMAN Maintenance

• Using the LIST command
• Using the REPORT command
• Deleting expired or obsolete backups
• View stored scripts
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Identify how RMAN makes backups to tape
• Understand how the Media Management Interface
works
• Identify the two versions of the SBT interface
• Discuss linking the Oracle server with a media
manager
• Discuss media manager issues and informational
messages
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Backups to Tape
• 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 and restore to sequential media.
• The System Backup to Tape (SBT) API is provided
to participating vendors.
n l y
e O
Backups to Tape
U s
A I
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 publishes a media management API that third-
O
party vendors can use to build software that works with RMAN. To use RMAN to make
l &
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
n a
management library software when it backs up to disk.
te r
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
I n
connections between storage and media subsystems, which can remove much of the
backup load from the primary database server.
c l e
For a list of compliant vendors,and compatibility information reference the following site:
r a
http://www.oracle.com/database/recovery/index.html?/database
/recovery/backupsp.html
O
Media Manager
Media Manager Architecture
Media
Oracle Media
Recovery Management
Manager Server Manager
Server
Session Library
Software
Recovery
Catalog
Control File Tape Subsystem
n l y
e O
Media Manager Architecture
U s
A I
The Oracle server session is the same type of server session 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 Oracle.
O
Oracle calls MML software routines to back up and restore data files to and from media
l &
controlled by the media manager. When doing backups or restores, the RMAN client
connects to the target instance and directs the instance to talk to its media manager. No
n a
direct communication occurs between the RMAN client and the media manager; all
r
communication occurs on the target instance.
te
I n
c l e
r a
O
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.
n l y
e O
Media Manager Prerequisites
U s
A I
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 vendor’s software documentation. Depending on the
O
product that you are installing, the following basic steps apply:
l &
1. Install and configure the media management software on the target host or
production network. No RMAN integration is required at this stage.
n a
2. Ensure that you can make non-RMAN backups of operating system files on the
te r
target database host. This step makes later troubleshooting much easier. Refer to
your media management documentation to learn how to back up files to the media
manager.
I n
3. Obtain and install the third-party media management module for integration with
l e
the Oracle server. This module must contain the library that Oracle loads when
c
accessing the media manager.
r a
If you have not performed the preceding steps, then do not proceed with the media
O
management configuration.

Linking a Media Manager on UNIX
Suggested steps to correctly link the Media

Management software the Oracle server:
• Remove any old libobk.so files or links in
$ORACLE_HOME before installing the software.
• Check the vendor documentation to determine
where the media management library is installed.
• 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.
n l y
e O
Linking a Media Manager on UNIX
U s
A I
After you install the media management software, the media management library should
already be integrated with the Oracle server. You should not have to perform further
integration. However, you may choose to follow the procedure in this section to ensure
O
that the media manager is integrated correctly. Because the specifics of your media
l &
management integration with Oracle depends on both the product and the operating
system, this section cannot cover all possible cases. In Oracle8i, the operating system
n a
implicitly loads the library at the start of any Oracle server session. In Oracle9i, Oracle
te r
explicitly loads the library with a dlopen(3X)call for each RMAN channel allocation.
On UNIX, Oracle accesses the media management library through the UNIX shared
I n
library libobk.so. This file must exist somewhere in the system path. It is highly
recommended that you place libobk.so in $ORACLE_HOME/lib, which is where
l e
Oracle searches first.
c
r a
O
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. Either change the name of the installed media management library to
$ORACLE_HOME/lib/libobk.so, or created 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 simply change the name of the library to libobk.so. For
example:
$ mv /vendor/lib/oracle_lib.so
$ORACLE_HOME/lib/libobk.so
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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.
n l y
e O
Linking a Media Manager on NT
U
On Windows NT, Oracle accesses the media management library through the library s
A I
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. In Oracle 8.x, the DLL
is loaded by the operating system once when the Oracle service starts up. In Oracle9i, the
O
DLL is loaded when a channel is allocated, and unloaded when the channel is released.
l &
You do not need to start or shut down the instance when installing the media management
library. To integrate the media manager with RMAN on NT, follow the steps below:
n
media manager. For example: a
1. If an orasbt.dll already exists in the system path, then remove it before installing the
te r
C:\> del %ORACLE_HOME%\bin\orasbt.dll
2. After installation, check your media management vendor documentation to
I n
determine where the media management library is installed. For example, suppose
that the library is installed as D:\vendor\lib\oracle_lib.dll.
l e
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
c
r a
can copy the installed library as follows:
D:\> copy D:\vendor\oracle_lib.dll
O %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 in the system PATH variable setting.

Testing the Media Manager Installation
1. Start RMAN and connect to the target database.

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

shared library loaded successfully.
n l y
e O
Testing the Media Manager Installation
U s
After integrating the media management library with Oracle, test whether RMAN is able
to load the library.
1. Start RMAN and connect to the target database. A I
O
2. Run the ALLOCATE CHANNEL command with the PARMS required by the media
ALLOCATE CHANNEL c1 DEVICE TYPE sbt

l &
management software. For example, run this command in a RUN block:
a
PARMS=’ENV=(NSR_SERVER=tape_srv,NSR_GROUP=oracle_tapes)’;
n
te r
If you do not receive an error message, then Oracle successfully loaded the shared library.
However, channel allocation can fail with the ORA-27211 error:
13:57:18
I n
RMAN-03009: failure of allocate command on c1 channel at
l e
ORA-19554: error allocating device, device type: SBT_TAPE
c
ORA-27211: Failed to load Media Management Library
r a
The ORA-27211 error indicates that Oracle was not able to load the media management
O
library that was installed. In this case, check your media management installation to make
sure that the library is correctly installed and redo. For any other errors, check the trace
file in USER_DUMP_DEST directory for more information.

Perform 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, the media manager is
probably waiting for the tape to mount.
– See if there are jobs in "tape mount request" mode
and correct.
• An ORA-19511 is usually indicative of a
configuration error.
– Check and retest the configuration.
n l y
e O
Perform a Test Backup
U s
A I
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 O
BACKUP DATAFILE 1;
l &
PARMS=’ENV=(NSR_SERVER=tape_srv,NSR_GROUP=oracle_tapes)’;
n a
Also, you should determine which PARMS settings are needed for the ALLOCATE
te r
CHANNEL or CONFIGURE CHANNEL commands as well as the vendor recommended
FORMAT string for the BACKUP command (if needed). The PARMS parameter sends
I n
instructions to the media manager. For example, the following vendor-specific PARMS
setting instructs the media manager to back up to a volume pool called oracle_tapes:
c l e
PARMS=’ENV=(NSR_DATA_VOLUME_POOL=oracle_tapes)’
r a
A hanging backup usually indicates that the media manager is waiting to mount a tape.
Check if there are any media manager jobs in “tape mount request” mode and fix the
O
problem. An ORA-19511 or ORA-70 nnn error indicates that the media management
software is not correctly configured. Ensure that the steps covered previously have been
followed.

Automatic Channels and Media Manager
1. Configure a generic channel of DEVICE TYPE SBT.

2. Test by issuing a BACKUP command without a
manual channel allocation.
3. If successful, configure the default device to SBT.
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;
n l y
e O
Automatic Channels and Media Manager
U s
A I
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.
O
1. Configure a generic channel of DEVICE TYPE sbt. In the configuration, type all
l &
parameters you tested in the previous steps. For example, assume that your media
vendor requires PARMS settings as follows:
n a
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt
te r
2> PARMS=’ENV=(NSR_SERVER=tape_svr, NSR_CLIENT=oracleclnt,
3> NSR_GROUP=oracle_tapes)’ FORMAT "BACKUP_%U";
I n
2. After configuring the channel, test the backup with the following command:
RMAN> BACKUP DEVICE TYPE sbt DATAFILE 1;
l e
3. Check your configuration by running the following command:
c
RMAN> SHOW CHANNEL DEVICE TYPE sbt;
r a
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:
O RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;

Automatic Channels and Media Manager (continued)
5. After configuring the default device, make a test backup to determine whether it is
really going to 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 using two
tape drives in parallel. In this case, you can run the following commands:
RMAN> CONFIGURE DEVICE TYPE sbt PARALELLISM 2;
# backup goes to tape but in two streams in parallel
(two tapes)
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Default SBT Interface
It is possible to write to disk using the Oracle Disk SBT

interface.
• This is useful for simulating tape backups for
troubleshooting purposes.
• This is not supported for actual backups.
• For Oracle9i use SBT_TAPE, specify BACKUP_DIR
and SBT_LBRARY.
RMAN> allocate channel c1
2> type ‘sbt_tape’
3> ‘ENV=SBT_LIBRARY=oracle.disksbt,
4> (BACKUP_DIR=/your/backup/directory)’;
n l y
e O
Default SBT Interface
U s
A I
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
O
SBT_LIBRARY in the PARMS setting of the ALLOCATE CHANNEL or CONFIGURE
l &
CHANNEL command to specify the filename of the shared library to be loaded. You can
also specify SBT_LIBRARY=oracle.disksbt, which causes the server to load
a
Oracle’s disk sbt library (formerly called the "dummy API"). If no SBT_LIBRARY
n
te r
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
I n
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
l e
manager is later installed, these backups will become unusable. Always use DISK
c
a
channels for production backups to disk.
r
O
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. Oracle calls sbtinit2() to pass additional data
to the media manager not passed by sbtinit().
4. Oracle calls sbtbackup() to create the backup
piece.
5. The Oracle Server reads the input database files.
n l y
e O
U s
API version 2.0 is supplied with Oracle8i and Oracle9i. The following sequence of events
occurs in the SBT API 2.0 backup session:
A I
1. When an SBT channel is allocated, RMAN connects to the Oracle server on the
target host and starts a server session.
O
2. When started, the Oracle server session initializes the media management software
&
by calling sbtinit(). The version of SBT API supported by the media
l
n a
management software is returned. This information is displayed in the RMAN
message RMAN-08503 message, for example:
3.2.0.0
te r
RMAN-08503: ... comment=API Version 2.0,MMS Version
I n
3. After successfully calling sbtinit(), Oracle calls sbtinit2() to supply
additional information to the media management software that was not supplied by
l
sbtinit().
c e
4. The Oracle session calls sbtbackup() in order to create a backup piece. In other
r a
words, the sbtbackup() instructs the media manager to get ready to accept a
stream.
O 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.
n l y
e O
Events in a Media Manager Backup (continued)
U
6. When the Oracle server session finishes writing the backup piece, it calls
s
to commit data on the backup medium. A I
sbtclose2() to close it. The sbtclose2() function tells the media manager
O
7. Oracle calls sbtinfo2() to see if the backup piece is stored in the media
l &
manager database. The sbtinfo2() function requests the media manager return
the mediumID, location, and expiration time of the backup medium on which the
backup piece is stored.
n a
te
the following example: r
8. When sbtinfo2() finishes, RMAN writes the name of the backup piece as in
I n
RMAN-08045: channel ORA_SBT_TAPE_1: finished piece 1 at
MAR 13 2001 08:48:12
l e
RMAN-08503: piece handle=41ckj865_1_1 comment=API
c
Version 2.0,MMS Version 3.2.0.0
r a
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
O 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.
n l y
e O
U s
A I
The sequence of events in a SBT API 2.0 restore session occurs 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.
O
2. When started, the Oracle server session initializes the media management software
by calling sbtinit().
l &
3. The Oracle server starts reading data from the media manager library by calling
sbtread().
n a
te r
4. The Oracle session calls the sbtrestore() function to request the backup piece
from the media manager. Essentially, the sbtrestore() instructs the media
I n
manager to find and prepare the backup medium containing the requested backup
piece. For example, if the backup was done to tape, this function instructs the media
l e
manager to load the tape into the tape drive and rewind it.
c
r a
O
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.
n l y
e O
Events in a Media Manager Restore (continued)
U s
5. The Oracle server starts reading data from the media manager library by calling
A I
sbtread2(). The data received from sbtread2() is written to disk.
6. When it reaches the end of the backup piece, Oracle calls sbtclose(). The
O
sbtclose() function instructs the media manager to stop reading data from the
tape.
l &
7. If there is more data to be restored, then the algorithm continues from step 4.
a
8. After the server sessions restores all data, it calls sbtend(). This function cleans
n
te r
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
n
instructs the session manager to end the restore session and unload the tapes.
I
c l e
r a
O
Media Manager Diagnostics
• sbttest
– A stand-alone program that tests if the media
management software is installed and can accept a
data stream 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.
– Found in the location specified by USER_DUMP_DEST
or by default on UNIX systems in
$ORACLE_HOME/rdbms/log
n l y
e O
Media Manager Diagnostics
U s
A I
On specific platforms, 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
O
sbttest utility is located in $ORACLE_HOME/bin. Note that on platforms such as
may be necessary.
l &
Solaris, you do not have to relink when using sbttest. On other platforms, relinking
n a
te r
I n
c l e
r a
O
Troubleshooting: Media Manager or RMAN
Step 1: Is RMAN integrated with the media manager?

• The RMAN-08526 indicates the Oracle8i server is
not linked with the media manager library.
RMAN-08526: channel ORA_SBT_TAPE_1: WARNING:
Oracle Test Disk API
• In Oracle9i, 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
n l y
e O
U s
If the media manager is not linked with the Oracle server, or if the Oracle server is unable
A I
to load the media manager library, then ensure that the following requirements are met:
• On UNIX, in Oracle8i the name of the media manager library must be
O
$ORACLE_HOME/lib/libobk.so. The exception is Oracle 8.1.6 on Solaris,
l &
where the media manager library should be
$ORACLE_HOME/lib/libdsbtsh8.so (see bug 1252142). After renaming,
n a
the database instance should be restarted.
• The media manager DLL should be %ORACLE_HOME%\BIN\ORASBT.DLL. in
te r
Oracle8i on NT.You should restart the services. Sometimes a reboot is required.
• In Oracle9i, the only requirement is that media manager library name must be
I n
$ORACLE_HOME/lib/libobk.so on UNIX or
%ORACLE_HOME%\BIN\ORASBT.DLL on NT. In Oracle9i, the DLL is loaded
l e
when a channel is allocated, and unloaded when the channel is released, so there is
c
no need to restart the Oracle instance. You can use the PARMS parameter
r a
SBT_LIBRARY to alter location of the media manager library.
O
The following example shows a Veritas NetBackup setting:
CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS=’SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1,
ENV=(NB_ORA_CLASS=oracle_class)’;

Step 2: Investigate RMAN output and trace 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
n l y
e O
Troubleshooting: Media Manager or RMAN (continued)
U s
A I
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 above, the
problem occurs in the SBT API because the ORA-19506 error refers to a sequential file.
O
On Windows NT and UNIX platforms, all errors involving the write, read, open, or close
&
of a sequential file indicates that an SBT function has failed.
l
n a
The text after the ORA-19511 message explains the error according to data received
from the media manager. The textual error message is only displayed if the SBT API is
function:
te r
version 2.0. The example below shows the failure of an SBT API 2.0 sbtbackup()
I n
c l e
name="4fckrhkv_1_1", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
r
text: a
ORA-19511: Error received from media manager layer, error
O
sbtbackup: 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 doing backup. 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 something 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
l y
If you paste the stack above into the stack trace interpreter available on WebIV, you will
find that a sequential file was being closed when sbtinfo() was called. The
n
ssexhd() and ksedmp() functions are error dump routines and
O
sigacthandler() is a signal handling function so these can be ignored. This gives
e
the analyst something to proceed with.
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Step 3: Do a backup to disk and the SBT disk library.

• Prove that the problem is caused by the media
manager software rather than by RMAN.
• Back up to disk with the 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;
}
n l y
e O
U s
A I
In some cases, you need to prove to the customer that the problem is caused by the media
manager software rather than by RMAN. The easiest test to back up to disk with the
FORMAT '/dev/null' (UNIX only). This indicates that RMAN is functioning
O
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 provided by Oracle. For example:
l
a
RUN {
r n
ALLOCATE CHANNEL tst TYPE SBT FORMAT ’%U’
PARMS=’ENV=(BACKUP_DIR=/backup)’;
BACKUP DATABASE; }
I n te
In Oracle9i, the SBT disk library provided by Oracle can be loaded without removing the
RUN {
c l e
existing media manager library and the library can back up to /dev/null. For example:
r a
ALLOCATE CHANNEL tst TYPE SBT FORMAT ’/dev/null’
PARMS=’SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)’;
O
BACKUP DATABASE; }
These tests are important when you suspect that the media manager library is causing
problems in Oracle server functions.

Step 4: Trace the server session to determine if the

error is occurring within media manager.
• Start the backup with channel option TRACE=1
RUN {
ALLOCATE CHANNEL tst TYPE DISK TRACE=1 FORMAT
'/dev/null';
BACKUP DATABASE;
}
• The trace is created in the USER_DUMP_DEST
directory.
n l y
e O
U s
If the Oracle server session core dump or hangs, verify whether the core dump or hang
A I
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.
O
l
*** SESSION ID:(9.17) 2002-03-16 13:50:21.945&
The trace output looks something like the following:
n a
skgfalo(se=0x815ff8c8, ctx=0x262bf98, dev=0x264861c,
devparms=, flags=33554432)
te r
skgfidev(se=0x815ff8c8 ctx=0x262bf98, dev=0x264861c)
I n
entering sbtinit on line 2203
return from sbtinit on line 2213
l e
skgfqsbi(ctx=0x262bf98, vtapi=API Version 1.1, id=MMS
c
Version 2.2.0.1)
r a
skgfqcre(se=0x815ff8c8, ctx=0x262bf98, dev=0x264861c,
file=0x2647f08, fparms=, flags=0x0)
O
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 environment variables 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 if 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 nothing after this then the function sbtwrite is hung.
Note: 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
n l y
e O
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
returning to the client.

U s
function entry and the read buffer is traced after it has been filled with data, prior to
A I
O
l &
n a
te r
I n
c l e
r a
O
Step 5: Isolate the server process from the SBT library.

• The media manager may be interfering with the
server session.
• Isolate the processes responsible for reading and
writing.
• Enable the BACKUP_TAPE_IO_SLAVES initialization
parameter.
n l y
e O
U s
A I
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 dedicated to the
O
Oracle server process. For example, the media manager library can mistakenly close data
&
file descriptors opened by Oracle code in the server process (see bug 1554531).
l
n a
You should attempt to separate the process responsible for reading from the process
responsible for writing (performed by SBT functions in the media management library).
te r
You can separate these processes by setting the BACKUP_TAPE_IO_SLAVES
initialization parameter to true.
I n
c l e
r a
O
Troubleshooting Media Manager
1. Determine if OS backup with media manager

works.
2. Determine which API function fails.
3. Investigate RMAN Output.
4. Investigate the sbtio.log.
n l y
e O
Troubleshooting Media Manager
U s
The customer should test whether the media manager operation system backup module
A I
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
O
manager operating system backup does not work, then the problem is not related to the
and configuration.
l &
Oracle media manager module. Rather, the problem is in the media manager installation
a
You can identify the problematic SBT API function in both in the Oracle trace file
n
te r
(located in the USER_DUMP_DEST directory) and in the RMAN output:
text:
I n
SBT error 7009, errno = 0, sbtopen: can’t connect with media
manager
c l e
The media manager library (SBT API 2.0) can return a text describing the error. The error
r a
text is written to the RMAN output. The below example displays the error text returned
by the NetBackup implementation of SBT API 2.0:
O
text:
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:
name="58cl3cdo_1_1", parms=""
text:
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 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 written in the media manager monitor and logs are also very helpful for
vendor support. Ask the customer to collect the data.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
SBTINIT and SBTINIT2 Function Errors
• These functions are responsible for initializing the

media manager library.
• Typical errors might include:
– Faulty installation of the media manager
– File permissions are incorrect
– Insufficient resources to initialize the library
n l y
e O
SBTINIT and SBTINIT2 Function Errors
U
The sbtinit()and sbtinit2() functions are responsible for initializing the media
s
indicates that the media manager library cannot initialize itself. A I
manager library. An error that occurs when calling sbtinit() or sbtinit2()
O
Common implementations of sbtinit() and sbtinit2() like NetBackup, Legato,
l &
and OmniBack II, simply initialize the internal structures of the media management
library. Consequently, this error is uncommon. If sbtinit() or sbtinit2() fails,
n a
then the media manager integration module was not properly installed. For example, it
te r
could be that permissions of the configuration files are not correct. The other more remote
possibility is that not enough resources are available for initialization In Oracle8, if the
I n
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
l e
library. In this case, the following error is reported:
c
ORA-27000: skgfqsbi: failed to initialize storage subsystem
r a
(SBT)layer
O
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 is. If you look
closely, however, you will see that the BACKUP_DIR environment variable was
improperly set. This indicates that this error came from Oracle's “dummy” SBT module
using the SBT_DISK device.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
SBTOPEN or SBTBACKUP Failures
• SBTOPEN()and SBTBACKUP() should create the

backup piece and start the backup session.
• Failures might include:
– Incorrect configuration of the media manager
– Incorrect PARMS environment variables
– The OS owner of the server session may not be a
recognized user in the media manager
configuration
n l y
e O
SBTOPEN or SBTBACKUP Failures
U s
A I
These two functions should create a backup piece at RMAN’s request and start the media
manager backup session. If sbtopen() or sbtbackup() fails during the backup,
then the media manager cannot create a backup piece or start a backup session. The
O
overwhelming majority of problems are caused by incorrect configuration of the media
l &
manager. The following situations are common:
• The environment variables specified in PARMS option are incorrect. For example,
n a
in the case of Legato NetWorker, a wrong media pool is specified. In case of
te r
NetBackup, the "Class" setting could be wrong.
• The pool, class, or some other media manager configuration entity is not correctly
I n
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
l e
media pool specified by NSR_DATA_VOLUME_POOL does not exist.
c
• The UNIX or NT user under which Oracle server sessions are running is not a valid
r a
user in the media manager configuration. For example, in case of OmniBack II, the
O user under which Oracle is running 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.
• 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.
• Permission errors are common in Oracle Real
Application Clusters environments.
n l y
e O
SBTOPEN or SBTRESTORE Failures
U s
A I
The sbtopen() and sbtresotre() functions are used to retrieve an existing backup
piece. If the sbtopen() or sbtresotre() function fails during the restore, then the
media manager cannot find the requested backup piece or it cannot start the restore
O
session. There are two primary reasons for these functions to fail during a restore:
l &
• 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
n a
easiest way to check this problem is to look for the backup piece in the media
management database.
te r
• The media management library does not have the permissions required to restore the
I n
requested object. This error is common in Real Application Cluster environments in
which each Oracle instance should have access to data backed up with other nodes.
l e
For example, the first node in the cluster configurations backs up a backup piece.
c
During the restore, the second node can ask the media manager library for the same
r a
backup piece. The media manager daemon can be configured in such way that node
O 2 is not allowed to restore the backup piece backed up with other nodes.

SBTWRITE or SBTREAD Failures
• SBTWRITE() and SBTREAD() transfer data from

the server session to the media manager library.
• 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.
n l y
e O
SBTWRITE or SBTREAD Failures
U
The sbtwrite() or sbtread() functions are responsible for the transfer of data
s
A I
from the Oracle server session to the media manager library. If the sbtwrite() or
sbtread() functions fail during the backup, then the media manager cannot
O
write data to a backup media (for example, to tape). If the sbtwrite() or
l &
sbtwrite2() fails during the restore, then the media manager cannot read data from a
backup media and sbtread() will fail also. The following are the primary reasons for
a
these functions to fail during a backup or restore:
n
te r
• An I/O error happen while reading or writing the backup media.
• The media manager session was aborted by a media manager operator.
I n
• The communication link is broken between the media manager library and the
media manager session manager.
c l e
r a
O
SBT API Return Codes
• SBT API Version 2 function errors have been

greatly reduced.
• The new functions return a simple error code and
a textual message.
• Errors returned from more than one function have
been collapsed into a single error code.
• Version 1.1 codes are retained for backward
compatibility only.
n l y
e O
Return Codes for SBT API Version 2
U s
In SBT API version 2, the number of different types of errors that may be returned from
A I
API functions has been greatly reduced. The new functions return an error stating that the
API function failed, and a textual description of the failure. Common error conditions
O
which can be returned from more than one function have been consolidated into a single
error code. All of the version 1.1 error codes have been retained for backwards
l &
compatibility. Following is the list of return codes for SBT API version V2:
#define SBT_ERROR_OPERATOR 7500 /*Operator intervention
requested*/
n a
te r
#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 */
I n
#define SBT_ERROR_EOF 7504 /* End of File */
#define SBT_ERROR_NOPROXY 7505 /* cant proxy copy the file */
l e
#define SBT_ERROR_NOWORK 7506 /* no proxy work in progress */
c
/* error codes for sbtinit */
r a
#define SBTINIT_ERROR_ARG 7110 /* invalid argument(s) */
#define SBTINIT_ERROR_SYS 7111 /* OS error */
O
If a function returns SBT_ERROR_MM for example, 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.

Media Manager Vendor Differences
Several media manager issues exist and must be taken

into consideration:
• Maximum supported file sizes
• Uniqueness of backup piece name
• Restoring to another node
• Reconciling RMAN and the media manager's
catalog
n l y
e O
Media Manager Vendor Differences
U s
A I
A problem that can be encountered with making backups to tape is the backup file size
created by the Oracle Server may be much larger than the file size supported by the media
manager. This is because RMAN multiplexes multiple input files into one output file.
O
Some media managers may not return errors in this situation, but fail silently. For this
l &
reason, it is important to determine the maximum supported file size for your media
management software, then use the RMAN keyword KBYTES in a SET LIMIT
a
CHANNEL command to limit the output file size to be within the supported size for your
n
media management software.
te r
Use the substitution variables provided by RMAN to generate unique backup piece names
I n
when writing backups to a media manager. If the FORMAT parameter is not specified,
RMAN automatically generates a unique filename using the %U substitution variable.
l e
Make sure your media manager supports filenames generated by %U if you intend to use
c
r a
RMAN automatic file naming. The media manager considers the backup piece name as
the filename backed up, so this name must be unique in the media manager catalog. In
O
addition some media managers only support a 14-character backup piece name. If you
need to restore to a different node, be sure of this functionality and also of any license
limitations. Check the media management documentation to be sure.

Summary

• Identify how Oracle makes backups to tape
• Understand how the Media Management Interface
works
• Identify the two versions of the SBT interface
• Link the Oracle server with a media manager
• Identify media manager issues and informational
messages
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview:

• Configuring RMAN to use a media manager
• Investigating media manager errors
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Debugging RMAN
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Debug RMAN errors
• Debug media manager errors
• Debug OS errors occurring in the RMAN stack
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
RMAN Message Output
RMAN troubleshooting information can be found

in the:
• RMAN command output
• RMAN trace file
• The alert log
• Oracle server trace file
• The sbtio.log file
n l y
e O
RMAN Message Output
U s
A I
RMAN command output contains actions relevant to the RMAN job as well as error
messages 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)
O
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
l
command option is used.
n a
The sbtio.log file contains vendor-specific information written by the media
te r
management software and can be found in USER_DUMP_DEST. Note that this log does
not contain Oracle server or RMAN errors.
I n
The Oracle trace file contains detailed output generated by Oracle server processes. This
l e
file is created when an ORA-600 or ORA-3113 (following an ORA-7445) error message
c
occurs, whenever RMAN cannot allocate a channel, and when the media management
a
library fails to load. It can be found in USER_DUMP_DEST.
r
O
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:

– See the generated PL/SQL
– Determine precisely where an RMAN command is
hanging or faulting
• The DEBUG option can be executed from 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
DEBUG output/redirected
target to a trace file:
catalog rman/rman debug trace
trace.log
n l y
e O
The DEBUG Option
U s
The DEBUG option displays all SQL statements executed during RMAN compilations and
A I
the results of SQL statement executions. Any information generated by the recovery
catalog PL/SQL packages is displayed also. In the example below, DEBUG output is
O
written during the backup of data file 3, but not data file 4:
&
RMAN> run {
debug on;
allocate channel c1 type disk;
a l
backup datafile 3;
debug off;
r n
I te
backup datafile 4; }
n
Keep in mind that DEBUG output can be voluminous so make sure you have adequate disk
space for the trace file. This simple backup session that generates no errors creates a trace
l e
file that is almost a half megabyte in size:
c
$ rman target / catalog rman/rman debug trace sample.log
r a
RMAN> host "ls –l sample.log";
O
-rw-r--r-- 1 user02
host command complete
dba 576270 Apr 6 10:38 sample.log

RMAN Code Layer Error Numbers
Important RMAN code layer error ranges:

• 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
n l y
e O
RMAN Code Layer Error Numbers
U s
In the RMAN message stack, you will find errors prefixed with RMAN-nnn, ORA-nnn,
error codes are arranged in the following ranges: A I

and finally errors preceded by the line Additional information:. The RMAN
0550 - 0999 Command line interpreter

O
1000 - 1999
2000 - 2999
Keyword analyzer
Syntax analyzer
l &
3000 - 3999 Main layer
n a
4000 - 4999
5000 - 5499
te r
Services layer
Compilation of RESTORE or RECOVER
5500 - 5999
6000 - 6999 I n
Compilation of DUPLICATE
General compilation
l
7000 - 7999
c e General execution
r a
8000 - 8999
9000 - 9999
PL/SQL programs
Low-level keyword analyzer
O
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
n l y
e O
Media Manager Error Numbers
U s
A I
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
O
manager error codes can be found in Appendix A. Below is an example of the message
format:
l &
a
text:
r n
I n te
SBT error = 7005, errno = 2, sbtopen: system error
c l e
r a
O
Interpreting RMAN Error Stacks
• Read stack from bottom to top.

• Look for "Additional information".
• The RMAN-03009 identifies the failed command.
RMAN-00571: ===========================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS =======
RMAN-00571: ===========================================
RMAN-03009: failure of backup command on c1 channel at
09/04/2001 13:18:19
name="07d36ecp_1_1", parms=""
ORA-19511: Error from media manager layer,error text:
n l y
e O
Interpreting RMAN Error Stacks
U s
Because of the amount of data that RMAN logs, you may find it difficult to identify the
A I
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
O
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.
l &
This line indicates a media management error. The integer that follows refers to a
n a
code that is explained in the text of the error message.
• Read the messages from the bottom up because this is the order in which RMAN
informative.
te r
issues the messages. The last one or two errors displayed in the stack are often
I n
• 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
l e
ID. If the failure is related to an RMAN command, these messages indicate which
c
command failed. Syntax errors generate an RMAN-00558 error.
r a
• 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
O detail.
The example shown above is obviously a media manager problem. 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
n l y
e O
RMAN Errors
U s
A I
Assume that a backup of the SAMPLE tablespace was attempted. The resultant output is
shown in the slide above. What happened? The RMAN-03002 error indicates that an
RMAN command has failed, the BACKUP command, to be specific. Look at the last two
O
messages in the stack first and immediately the reason for the command failure is
l &
obvious: no tablespace SAMPLE appears in the recovery catalog because the name was
mistyped. Another interesting note here is the warning issued when the two channels were
n a
allocated for the backup. As can be seen from the output, the devices were configured to
te r
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. Actual backup and recovery
n
using the oracle.disksbt library is not recommended or supported.
I
c l e
r a
O
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/user02/ORADATA/sample01.dbf'
n l y
e O
Interpreting Server Errors
U s
A I
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?
O
The error stack is read from the bottom up, as suggested. The ORA-01110 message
explains there was a problem with the recovery of datafile sample01.dbf. The second
&
error indicates that Oracle cannot recover the data file because it is in use or already being
l
n a
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
and recovered.
te r
recovered, the problem must be that the data file is online and needs to be taken offline
I n
c l e
r a
O
The sbttest Utility
• Oracle provides sbttest to test the SBT interface.

• sbttest 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
trace output to sbtio.log:
$ sbttest testfile.f -trace sbtio.log
n l y
e O
The sbttest Utility
U s
On UNIX platforms, Oracle ships a utility called sbttest. This diagnostic tool is used
A I
to test the third-party vendor’s SBT interface. It works by emulating the Oracle server and
initiating a backup using the installed SBT library. If the program runs without error, it
O
returns a 0. This indicates the media manager software is installed and can accept a data
l &
stream and return the same data when requested. If any error is encountered, sbttest
returns a -1. This means the media management software is not installed or configured
n a
correctly. The sbttest utility is found in $ORACLE_HOME/bin. If sbttest is not
available, download stksbt2.c at ftp://dlsun336.us.oracle.com/pub/sdk. It
te r
can be compiled and run on any supported UNIX platform.
I n
Type sbttest with no arguments and you should see the command documentation. The
example above shows the syntax to create a test file called testfile.f and write the
c l e
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
r a
you will see something like the following:
$ sbttest testfile.f -trace sbtio.log
O
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> SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
2 ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
3 FROM V$SESSION_LONGOPS
4 WHERE OPNAME LIKE 'RMAN%'
5 AND OPNAME NOT LIKE '%aggregate%'
6 AND TOTALWORK != 0
7 AND SOFAR <> TOTALWORK;
SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE

------ -------- --------- ---------- ---------- ---------
13 75 1 9470 15360 61.65
12 81 1 15871 28160 56.36
n l y
e O
Checking Backup and Restore Progress
Monitor the progress of backups, copies, and restores by querying the view
U s
V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOPS:
A I
detail and aggregate rows. Detail rows describe the files being processed by one job step,
O
while aggregate rows describe the files processed by all job steps in an RMAN command. A
l &
job step is the creation or restore of one backup set or data file copy. Detail rows are updated
with every buffer that is read or written during the backup step, so their granularity of update
a
is small. Aggregate rows are updated when each job step completes, so their granularity of
n
te r
update is large. Important columns in V$SESSION_LONGOPS for RMAN include:
• SID: The server session ID corresponding to an RMAN channel.
I n
• SERIAL# : The server session serial number. This value changes each time a server
session is reused.
l e
• OPNAME: A text description of the row. Detail rows include RMAN:datafile copy,
c
RMAN: full datafile backup, and RMAN: full datafile restore.
r a
• CONTEXT: For backup output rows, this value is 2. For all other rows except proxy
copy (which does not update this column), the value is 1.
O
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 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 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Monitoring the Media Manager
To monitor the SBT events, run the following query:

SQL> COLUMN EVENT FORMAT a10
SQL> COLUMN SECONDS_IN_WAIT FORMAT 999
SQL> COLUMN STATE FORMAT a20
SQL> COLUMN CLIENT_INFO FORMAT a30
SQL> SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,
2 STATE, CLIENT_INFO
3 FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
4 WHERE sw.EVENT LIKE 'sbt%'
5 AND s.SID=sw.SID
6 AND s.PADDR=p.ADDR;
SPID EVENT SEC_WAIT STATE CLIENT_INFO

---- --------- -------- ------- ---------------------------
8642 sbtbackup 600 WAITING rman channel=ORA_SBT_TAPE_1
n l y
e O
Monitoring the Media Manager
U s
A I
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 like sbtinit(), sbtopen(), sbtread(), and so on.
O
Before making a call to any of the functions in the media management API, the server
l &
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
n a
that the server has been waiting for this call to return. After an sbt function is returned
te r
from the media manager, this row disappears.
A row in V$SESSION_WAIT corresponding to an sbt event name does not indicate a
I n
problem, because the server updates these rows at runtime. The rows appear and
disappear as calls are made and returned. However, if the SECONDS_IN_WAIT column
l e
is high, then the media manager may be hung.
c
r a
In the query executed above, note that RMAN has been waiting for the sbtbackup
function to return for ten minutes (600/60).
O
Monitoring Recovery Manager Sessions
To identify what a server session is doing, correlate a

process with a channel during a backup:
• Start RMAN and connect to the target database
and recovery catalog database.
• If monitoring multiple sessions, set COMMAND ID
after allocating channels and backup the object.
• Query the joined V$SESSION and V$PROCESS
views while the backup is executing.
n l y
e O
Monitoring Recovery Manager Sessions
U s
To identify which server sessions correspond to which RMAN channels, you can query
A I
V$SESSION and V$PROCESS. The SPID column of V$PROCESS identifies the
operating system ID number for the process or thread. On UNIX the SPID column
O
shows the process ID, on NT the SPID column shows the thread ID. There are two basic
l &
methods for obtaining this information, depending on whether you have multiple RMAN
sessions active concurrently. When only one RMAN session is active, execute the
a
following query on the target database while the RMAN job is running:
n
te
SQL> COLUMN SID FORMAT 999 r
SQL> COLUMN CLIENT_INFO FORMAT a30
I n
SQL> COLUMN SPID FORMAT 9999
SQL> SELECT s.SID, p.SPID, s.CLIENT_INFO
l e
2 FROM V$PROCESS p, V$SESSION s
c
3 WHERE p.ADDR = s.PADDR
r a
4 AND CLIENT_INFO LIKE 'rman%';
SID SPID CLIENT_INFO
O
---- ------------ ------------------------------
15 2714 rman channel=ORA_SBT_TAPE_1
13 2715 rman channel=ORA_SBT_TAPE_2

Monitoring Recovery Manager Sessions (continued)
When multiple RMAN sessions are running, it will help to correlate a process with a
channel during a backup 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 executing. For example, enter:
SELECT SID, SPID, CLIENT_INFO
FROM V$PROCESS p, V$SESSION s
n l y
WHERE p.ADDR = s.PADDR
AND CLIENT_INFO LIKE '%id=sess%';
e
If you run the SET COMMAND ID command in the RMAN job, then the
O
CLIENT_INFO column displays in the following format:
U s
id= command_id,rman channel= channel_id
For example, the following shows sample output:
SID SPID CLIENT_INFO A I
O
---- ------------ ------------------------------
11 8358 id=sess1
15 8638 id=sess2
l &
n a
14 8374 id=sess1,rman channel=c1
r
9 8642 id=sess2,rman channel=c1
te
I n
c l e
r a
O
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 time needed for recovery
SQL> SELECT * FROM V$RECOVER_FILE
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
----- ------- ------- ---------- ---------- ---------
4 ONLINE ONLINE FILE NOT 0
FOUND
5 ONLINE ONLINE FILE NOT 0
FOUND
8 OFFLINE OFFLINE OFFLINE 0
• Query V$DATAFILE and V$TABLESPACE to get file

and tablespace names.
n l y
e O
Determining Which Data Files Require Recovery
You can often use the dynamic performance view V$RECOVER_FILE to determine
U s
SQL> SELECT * FROM V$RECOVER_FILE
A I
which files need to be recovered and why they need to be recovered.
FILE# ONLINE ONLINE_ ERROR

O CHANGE# TIME
4 ONLINE ONLINE FILE NOT FOUND

l &
----- ------- ------- --------------- ---------- -------
0
5 ONLINE ONLINE FILE NOT FOUND
n a 0
te r
8 OFFLINE OFFLINE OFFLINE 0
Query V$DATAFILE and V$TABLESPACE to obtain filenames and tablespace names
I n
for data files requiring recovery. For example, enter:
SQL> SELECT d.NAME, t.NAME FROM V$DATAFILE d, V$TABLESPACE t
l e
2 WHERE t.TS# = d.TS# AND d.FILE# IN (4,5,8);
c # use values obtained from V$RECOVER_FILE query
r
NAME
a
---------------------------------- ---------------
NAME
O/oracle/oradata/trgt/drsys01.dbf
/oracle/oradata/trgt/example01.dbf EXAMPLE
DRSYS
/oracle/oradata/trgt/users01.dbf USERS

Insufficient Privileges
• The ORA-1031 error indicates that an attempted

operation is not allowed for the user specified.
• First determine which database is returning the
error:
– Is this the target, catalog, or auxiliary instance?
– Connect to each separately to confirm:
$ rman
RMAN> connect target /
RMAN> connect catalog rman_user/pswd@catalog
RMAN> connect auxiliary sys/paswd@aux
n l y
e O
Insufficient Privileges
U s
A I
The RMAN user created for the recovery catalog owner needs to be granted the privileges
necessary for catalog ownership. Connect to the recovery catalog database and grant
RECOVERY_CATALOG_OWNER to the RMAN user:
SQL> connect system/manager O
SQL> grant RECOVERY_CATALOG_OWNER to rman;
l &
n a
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
te r
sysdba privileges. Prior to troubleshooting the error at the target, find out where they are
running RMAN—from the target database software installation, or from a different
I n
Oracle_Home or a different system altogether.
c l e
When connecting locally to the target database, the user must be a member of the
operating system group responsible for managing SYSDBA privileges, usually DBA. If
r a
an ORA-1031 is logged when connecting locally, make sure the username being used is
a member of the DBA group. When connecting remotely to the target database, you must
O
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 utilized, 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 using
the command line utility orapwd.
$ orapwd file=$ORACLE_HOME/dbs/orapwSID password=Asecret1
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
UNIX Tape Backup Failure
The media manager has been linked with Oracle, but

cannot perform backups to SBT_TAPE.
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 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
n l y
e O
UNIX Tape Backup Failure
U s
A I
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 servicing the
O
backup. This indicates that Oracle is linked with the dummy API (oracle.disksbt)
l &
instead of the media manager API. If the customer was really using the dummy API for
testing , they must set the BACKUP_DIR location by using the PARMS parameter of the
a
ALLOCATE CHANNEL command. Otherwise the media manager was improperly linked.
n
te r
On UNIX, in Oracle8i the name of the media manager library must be
$ORACLE_HOME/lib/libobk.so. The exception is Oracle 8.1.6 on Solaris, where
I n
the media manager library should be $ORACLE_HOME/lib/libdsbtsh8.so (see
bug 1252142). To fix this on 8.1.6, shutdown your database. Then follow the steps below:
c l e
cd $ORACLE_HOME/lib
r a
mv libdsbtsh8.so libdsbtsh8.soORIG
ln -s <media vendor library> libdsbtsh8.so
O
On Oracle9i, have the customer use SHOW CHANNEL to look at the tape device settings.
RMAN> show channel;

UNIX Tape Backup Failure (continued)
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 that indeed the device SBT_TAPE is 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. 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';
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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
n l y
e O
NT Tape Backup Failure
U s
• The backup fails entirely, a 4110 is possibly issued.
A I
The symptoms on NT might manifest themselves in one of several ways:
• The user specifies ‘sbt_tape’, the backup succeeds but the backup is written to
DISK O
&
Evidence that the vendor interface is not used can be found in the RMAN log. Look for an
l
n a
RMAN-08503, this usually means the default Oracle test disk API software is being used.
Reasons why the backups are not written to tape when SBT_TAPE is used include:
te r
• Oracle cannot find the library to load, so it uses the dummy disk API instead.
Windows NT searches for the dll called orasbt.dll in its default directory path
I n
(our developers recommend to the BSP members that they put their library in the
SYSTEM32 system directory).
l e
• There is an error in the vendor’s DLL. Either the DllMain() function returned an
c
r a
error, or the vendor did not implement all of the SBT functions.
The loadsbt.exe utility can be used to diagnose why the DLL cannot be loaded. It is
O
available for download at ftp://dlsun336.us.oracle.com/pub/sdk.

RMAN Session Is Hung
in 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 hang situation by querying
V$SESSION and V$SESSION_WAIT.
SQL> SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,
2 STATE, CLIENT_INFO
3 FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
4 WHERE sw.EVENT LIKE ’sbt%’ AND s.SID=sw.SID
5 AND s.PADDR=p.ADDR
n l y
e O
RMAN Session Is Hung in Media Manager
U s
A I
The best way to terminate RMAN when the connections for the allocated channels are
hung in the media manager is to kill the Oracle process of the connections. The RMAN
process detects this termination and proceeds to exit, removing all connections except
O
target connections that are still operative in the media management layer. To terminate an
l &
Oracle process that is hung in the media manager:
1. Query V$SESSION and V$SESSION_WAIT as illustrated above. Below is a
n
typical result of the query: a
SPID
----
EVENT
---------
te r
SEC_WAIT STATE
--------------
CLIENT_INFO
-----------------------------
8642
8374
I n
sbtwrite2
sbtwrite2
600 WAITING
600 WAITING
rman channel=ORA_SBT_TAPE_1
rman channel=ORA_SBT_TAPE_2
l e
2. Kill the hung processes with an operating system utility. For example, on Solaris
c
execute a kill -9 command:
r a
$ kill -9 8642 8374
O 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 Media Manager (continued)
If the problem is persistent, you may need to investigate the cause. First, check to see
what the server processes performing the backup are doing. Is it only one process
hanging, or all? If only one, 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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:

– The target database instance is slow
– A timing problem occurred
n l y
e O
RPC Call Fails
U s
This is indicative of an internal Oracle timing problem. When RMAN begins an RPC, it
A I
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
O
RPC has indicated it has started, which in turn generates the following message:
RPC call appears to have failed
l &
n a
This is only a real problem if a message stating "RPC call ok on channel
CHname" does not appear in the output immediately following the message stating:
te r
"RPC call appears to have failed".
I n
c l e
r a
O
Snapshot Control File Creation Failure
• Backup fails because RMAN cannot make a

snapshot control file.
RMAN-00571: ============================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS ========
RMAN-00571: ============================================
16:32:21
ORA-00230: operation disallowed: snapshot controlfile
enqueue unavailable
• Usually, the control file is being backed up by

another session.
n l y
e O
Snapshot Control File Creation Failure
U s
When RMAN needs to back up the control file, it first creates a snapshot of the control
A
a new snapshot control file, then you may see the following message:
I
file. If one RMAN job is already backing up the control file while another needs to create
waiting for snapshot controlfile enqueue

O
l &
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
a
conflict is usually caused when two jobs are both backing up the control file, and the job
n
te r
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
I n
snapshot controlfile enqueue", start a new SQL*Plus session on the
c l e
target database:
$ sqlplus ’SYS/oracle@trgt AS SYSDBA’
r a
2. Execute the following query to determine which job is causing the wait:
SQL> SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE,
O 2 ACTION, LOGON_TIME "Logon", l.* FROM V$SESSION s,

3 V$ENQUEUE_LOCK l WHERE l.SID = s.SID AND l.TYPE = 'CF'
4 AND l.ID1 = 0 AND l.ID2 = 2;

Snapshot Control File Creation Failure (continued)
After you have determined which job is creating the enqueue, you can do one of the
following:
• Wait until the job creating the enqueue completes
• Cancel the current job and restart it after the job creating the enqueue completes
• Cancel the job 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 complete
until the new tape is loaded.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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: ======== ERROR MESSAGE STACK FOLLOWS =======
RMAN-00571: ============================================
15:04:21
RMAN-06059: expected archived log not found, lost of
archived log compromises recoverability
ORA-19625: error identifying file
/u01//ORADATA/u05/1_9.dbf
n l y
e O
RMAN Cannot Locate an Archived Log
U s
A I
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
O
RMAN is unaware of the deletion. The RMAN-6059 error occurs because RMAN
has permission, user, or group errors.

l &
attempts to back up a log that the repository indicates still exists but is no longer there or
n a
Make sure that the archived logs exist in the specified directory and that the RMAN
te r
catalog is synchronized. Check the following:
1. Make sure the archived log file that is specified by the RMAN-6059 error exists in
I n
the correct directory.
2. Check that the operating system permissions are correct for the archived log. The
l e
owner of the log file should be the owner of the Oracle binaries and the group
c
r a
associated with the file should be DBA.
3. If the file appears to be correct, then try synchronizing the catalog by running the
O 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
archive log filename=/u01/user02/ORADATA/u05/1_2.dbf recid=4
stamp=458057563
validation succeeded for archived log
...
archive log filename=/u01/user02/ORADATA/u05/1_29.dbf
recid=2 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; n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Missing Log Causes Duplication Failure
Duplicate database fails with the following error stack:

RMAN-00571: ============================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS ========
RMAN-00571: ============================================
RMAN-03002: 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
n l y
e O
Missing Log Causes Duplication Failure
U
The customer attempted to duplicate a database with the DUPLICATE command, but
s
all the archived logs needed for complete recovery. A I
received the error stack as shown above. The problem is that RMAN is not able to apply
O
For example, if the customer only backed up logs through sequence 15, but the most
l &
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
a
sequence number for incomplete recovery. For example, to terminate recovery after
n
RMAN> RUN {
te r
applying log sequence 15, run the following RMAN block:
I n
SET UNTIL SEQUENCE 16 THREAD 1; # recovers up to but not including log 16
e
DUPLICATE TARGET DATABASE TO ’dupdb’;
}
c l
r a
O
Summary

• Debug RMAN errors
• Debug media manager errors
• Debug OS errors occurring in the RMAN stack
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview:
Debugging RMAN

• Analyzing RMAN errors
• Analyzing media manager errors
• Analyzing OS errors on the RMAN stack
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
RMAN Performance Tuning
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

the following:
• Discuss general performance tips and techniques
• Discuss and implement synchronous and
asynchronous I/O
• Tune the RMAN BACKUP/RESTORE process
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Tuning RMAN
• RMAN BACKUP and RESTORE operations have the

following components:
– Reading or writing data
– Processing data by copying and validating blocks
• The slowest of these operations is the bottleneck.
• Tuning RMAN requires that the bottlenecks be
identified and addressed.
n l y
e O
Tuning RMAN
RMAN backup and restore operations have the following distinct components: U s
• Reading or writing input data
A I
• Processing data by validating and copying blocks from the input to the output
buffers
O
l &
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
a
using RMAN commands, initialization parameter settings, or adjustments to physical
n
te r
media. The key to tuning RMAN is understanding I/O. RMAN’s backup and restore jobs
use two types of I/O buffers: disk and tertiary storage (usually tape). When performing
I n
a backup, RMAN reads input files using disk buffers and writes the output backup file by
using either disk or tape buffers. When performing restores, RMAN reverses these roles.
c l e
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. Hence, you can
r a
easily determine how much time 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
O
effectively, you must thoroughly understand concepts such as synchronous and
asynchronous I/O, disk and tape buffers, and channel architecture. When you understand
these concepts, then you can learn how to use fixed views to monitor bottlenecks.

RMAN Disk Buffer Allocation
The buffer allocation algorithm:

Multiplexing Level Allocation Rule
Less than or equal to 4 1 MB buffers are allocated so that
the total buffer size for all the input
files is 16 MB
Greater than 4 but less 512 KB are allocated so that the
than or equal to 8 total buffer size for all the files is
less than 16 MB
Greater than 8 RMAN allocates a fixed 4 disk
buffers of 128 KB for each file, so
that the total size is 512 KB for each
file
n l y
e O
RMAN Disk Buffer Allocation
U s
A I
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
O
written to the same backup piece. The degree of multiplexing depends on the
l &
FILESPERSET parameter of the BACKUP command as well as the MAXOPENFILES
parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands.
n a
For example, assume that you back up two data files with one channel. You set
te r
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),
I n
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
l e
described in the table above.
c
r a
O
Disk Buffer Allocation Example
Data files Input Disk Buffers
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB Channel
FILESPERSET = 4
MAXOPENFILES = 4
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB
n l y
e O
Disk Buffer Allocation Example
U s
A I
In the example shown 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
O
of the buffers allocated in a backup set, multiply the total bytes for each data file by the
number by the number of channels.

l &
number of data files being concurrently accessed by the channel, and then multiply this
n a
Assume that you use one channel to back up four data files, and use the settings shown in
the backup:
te r
above. In this case, multiply as follows to obtain the total size of the buffers allocated for
I n
4 MB per data file x 1 channel x 4 data files per channel = 16 MB
c l e
Set the MAXOPENFILES parameter so that the number of files read simultaneously is
just enough to utilize the output device fully. This consideration is especially important
a
when the output device is tape.
r
O
Tape Buffer Allocation
If BACKUP_TAPE_IO_SLAVES = TRUE, tape

buffers are allocated from the SGA.
Channel
Tape Buffers
256 kb 256 kb
256 kb 256 kb
DIGITAL DATA STORAGE
If BACKUP_TAPE_IO_SLAVES is false, tape

buffers are allocated from the PGA.
n l y
e O
Tape Buffer Allocation
U s
If you make a backup to a tape device, then Oracle allocates four buffers for each channel
A I
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
O
size of buffers used during a backup or restore, multiply the buffer size by 4, and then
l &
multiply this product by the number of channels.
As illustrated in the example above, assume that you use one tape channel and each buffer
a
is 256 KB. In this case, the total size of buffers used during a backup is as follows:
n
te r
256 KB per buffer x 4 buffers per channel x 1 channel = 1024 KB
RMAN allocates the tape buffers in the SGA or the PGA, depending on whether I/O
I n
slaves are used. If the initialization parameter BACKUP_TAPE_IO_SLAVES = TRUE,
then RMAN allocates tape buffers from the SGA or the large pool if the
l e
LARGE_POOL_SIZE initialization parameter is set. If you set the parameter to false,
c
then RMAN allocates the buffers from the PGA. If you use I/O slaves, then set the
r a
LARGE_POOL_SIZE initialization parameter to set aside SGA memory dedicated to
holding these large memory allocations. By doing this, the RMAN I/O buffers do not
O
compete with the library cache for SGA memory.

Synchronous Versus Asynchronous I/O
Synchronous I/O
1. Server process writes 2. Server process waits; tape

data to buffer process writes data
Server 0100100
Process 0100100
Tape
4. Server process 3. Tape process
writes data to
Buffers signals finish
new buffer
n l y
e O
U s
A I
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 work while
O
waiting for the I/O to complete. It can also begin multiple I/O operations before waiting
for the first to complete.
l &
n a
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,
te r
the I/O is synchronous. The example above shows synchronous I/O in a backup to tape.
The following steps occur in a synchronous transfer:
I n
1. A server process writes blocks to a tape buffer.
c l e
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 manager’s internal
r a
buffers.
3. The tape process relays to the server process that it has completed writing.
O 4. The server process can initiate a new task.

Asynchronous I/O
1. Server process writes 2. Tape process writes data

data to buffer
Server 0100100
Process 0100100 0100100
Tape
Buffers
3. Server process writes to new

buffers while step 2 completes
n l y
e O
Synchronous Versus Asynchronous I/O (continued)
U s
A I
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
O
systems that do not support native asynchronous I/O, Oracle can simulate it by using
l &
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
n a
a nonzero value. Oracle allocates four backup disk I/O slaves for any nonzero value of
DBWR_IO_SLAVES.
te r
The example above illustrates asynchronous I/O in a backup to tape. The steps that occur
I n
in an asynchronous exchange are detailed below:
1. A server process writes blocks to a tape buffer.
l e
2. The tape process writes data to tape. While the tape process is writing, other server
c
r a
processes are free to process more input blocks and fill more output buffers.
3. Two spawned server processes write to tape buffers as the initial tape process writes
O to tape.

Setting LARGE_POOL_SIZE
• If LARGE_POOL_SIZE is not set, the Oracle server

tries to get memory from the shared pool.
• If LARGE_POOL_SIZE is not big enough, the server
does not allocate buffers from the shared pool.
• If the server cannot get enough memory, it
allocates buffers from 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
n l y
e O
Setting LARGE_POOL_SIZE
U s
A I
Requests for contiguous memory allocations from the shared pool are small, usually
under 5 KB in size. It is possible however, that a request for a large contiguous memory
allocation can either fail or require significant memory housekeeping to release the
O
required amount of contiguous memory. Although the shared pool may be unable to
l &
satisfy this memory request, the large pool is able to do so. The large pool does not have a
least recently used list so Oracle does not attempt to age memory out of the large pool.
n a
Use the LARGE_POOL_SIZE initialization parameter to configure the large pool. To
te r
see in which pool (shared pool or large pool) the memory for an object resides, query
V$SGASTAT.POOL. The Oracle9i suggested LARGE_POOL_SIZE is calculated as:
I n
number_of_allocated_channels * (16 MB + ( 4 *
l e
size_of_tape_buffer ))
c
For backups to disk, the tape buffer is obviously 0 so set LARGE_POOL_SIZE to 16
r a
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
Oup 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
• 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
• Whether or not I/O is synchronous depends on
how the controlling process views it.
n l y
e O
Performance Monitoring
U s
A I
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 do not need to be backed up.
O
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
l
n a
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.
te r
Which view the SBT_TAPE row appears in is a good indication of whether the
BACKUP_TAPE_IO_SLAVES parameter is set and of course, whether AIO or SIO is
I n
being used. This option should definitely cause increased throughput on UNIX. Because
c l e
of the memory management model, it is recommended that this be used with care on NT.
r a
O
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
• WAITS times should be zero to avoid bottlenecks.
n l y
e O
Asynchronous I/O Bottlenecks
U
The LONG_WAITS column shows the number of times the backup/restore process told
s
A I
the O/S to wait until an I/O was complete. The SHORT_WAITS column shows the
number of times the backup/restore process made an O/S call to poll for I/O completion in
O
a non-blocking 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 non-blocking
poll for I/O.
l &
n a
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
te r
completion when performing non-blocking I/O polling. In cases like this, the
SHORT_WAIT_TIME_TOTAL column represents real I/O time for this file.
I n
If the SHORT_WAIT_TIME_TOTAL is low compared to the total time for this file, then
c l e
the delay is most likely caused by other factors, such as process swapping. If possible,
tune your operating system so the I/O wait time appears in the
a
LONG_WAIT_TIME_TOTAL column.
r
O
Synchronous I/O Bottlenecks
• It is hard to identify specific bottlenecks because

all 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 device's maximum rate.
– If the rate is lower than the device specifies, this is a
tuning opportunity.
n l y
e O
Synchronous I/O Bottlenecks
U s
A I
When using synchronous I/O, it can easily be determined how much time 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
O
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.
l
n a
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
r
I/O is synchronous to the process (or thread, on some platforms) performing the backup.
te
I n
c l e
r a
O
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
n l y
e O
Tape Backup Speed
U
The tape native transfer rate is the write speed without compression. This speed
s
A I
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
O
that rate, and an excessive amount of CPU is not being used, then tuning RMAN will not
help.
l &
Tape compression greatly affects backup performance. If the tape has good compression,
a
then the sustained backup rate is faster. For example, if the compression ratio is 2:1 and
n
MB/s.
te r
native transfer rate of the tape drive is 6 MB/s, then the resulting backup speed is 12
I n
Almost all tape drives currently on 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
l e
of data to write to tape, they must slow down and stop. For example, when the drive's
c
buffer empties, the tape is moving so quickly that it actually overshoots and must rewind
a
past the point where it stopped writing.
r
O
The physical tape block size can affect backup performance. The block size is the amount
of data written by 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 tape drives, the faster the backup and

restore.
• The faster the tape drives, the faster the backup.
• Allocate one channel per physical device:
– If more channels than physical drives are used,
then the backup sets will be intermingled
– Similar to multiplexing data files
• If tape drive is not streaming, increase the number
of files multiplexed.
• Back up files that are likely to be restored together
in the same backup set.
n l y
e O
Performance Rules
U s
A I
It may sound obvious to some, but you can speed the backup and restore process by
buying more tape drives, faster tape drives, or ideally a combination of the two. Generally
speaking, it is a waste of system resources to allocate more than one channel per tape
O
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.
l
n a
If a tape drive is not streaming, increasing then number of files multiplexed together may
help. Be aware that if a small subset of files in a backup set must be restored, the restore
te r
will take longer if many files are multiplexed into the backup set. Put only enough files
into each backup set to keep the tape drives streaming.It is better to store files that are
I n
likely to be restored together in the same backup set.
c l e
r a
O
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.
• When doing incremental backups, set multiplexing
level to 50 to keep tape streaming.
• Full or level 0 backups require a lower
multiplexing value.
n l y
e O
Empty Files and Incremental Backups
U s
A I
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
O
increasing the level of multiplexing. An incremental backup is an RMAN backup in
l &
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
n a
backup. If tape drives are not locally attached, then incremental backups can be faster.
te r
You must consider how much bandwidth exists for reading the disks compared to the
bandwidth for writing to the tapes. If tape bandwidth is limited compared to disk, then
I n
incremental backups may help.
If only a few blocks have changed in an incremental backup, then you need to input many
l e
buffers from the data file before you accumulate enough blocks to fill a buffer and write
c
r a
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
O
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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Control Tape Buffer Size with BLKSIZE
• Adjusting the size of the tape buffer can help to

keep 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";
• Set BLKSIZE to a value that is a little less than the

tape block size of the media manager.
n l y
e O
Control Tape Buffer Size with BLKSIZE
U s
A I
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 using the PARMS parameter of the ALLOCATE
O
CHANNEL or CONFIGURE CHANNEL command. If the BLKSIZE parameter for
l &
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:
n
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT a
PARMS="BLKSIZE=524288";
te r
A good rule of thumb is to set BLKSIZE to a value that is a little less than the tape block
I n
size of the media manager. What "a little less" means depends on the media manager. For
c l e
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.
r a
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
Othe physical tape block size as 32 KB.

Channel Tuning
Use CONFIGURE CHANNEL/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
n l y
e O
Channel Tuning
U s
A I
You can set various channel limit parameters that apply to operations performed by the
allocated server session in the CONFIGURE CHANNEL and ALLOCATE CHANNEL
commands.
O
The MAXPIECESIZE parameter specifies the maximum size of a backup piece. Use this
&
parameter to force RMAN to create multiple backup pieces in a backup set. RMAN
l
n a
creates each backup piece with a size no larger than the value specified in the parameter.
The RATE parameter specifies the bytes per second that RMAN reads on the channel.
te r
This parameter is useful in preventing RMAN from consuming excessive disk bandwidth
and degrading OLTP performance. For example, by setting RATE=1500K, each disk
I n
drive delivers 3 MB per second and RMAN leaves some disk bandwidth available to the
online system.
c l e
The MAXOPENFILES parameter determines the maximum number of input files that a
r a
backup or copy can have open at a given time. If not set manually, the value defaults to 8.
The level of RMAN multiplexing is partially determined by MAXOPENFILES. The level
O
of multiplexing in turn determines how RMAN allocates disk buffers. Multiplexing is the
number of input files simultaneously read and then written into the same backup piece.

Tuning the BACKUP Command
• 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.
n l y
e O
Tuning the BACKUP Command
U s
A I
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.
O
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 fifty input data files and
l
n a
two channels, you can set FILESPERSET=5 to create ten backup sets. This strategy can
prevent you from splitting a backup set among multiple tapes.
te r
The DISKRATIO parameter specifies the number of drives to include in the backup.
Assume the data files are located on five disks, each disk supplies data at 10 bytes per
I n
second, and the tape drive requires 20 bytes per second to keep streaming. If you set
c l
backup load. e
DISKRATIO=2, then RMAN reads from two drives at a time, thereby distributing the
r a
O
Summary

• Apply general performance tips and techniques
• Implement synchronous and asynchronous I/O
• Tune the RMAN BACKUP/RESTORE process
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
__________
Appendix A
__________
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
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
n l y
Server parameter files in backups
RC_CHECKPOINT
e O
Deprecated in favor of
s
RC_RESYNC
U
RC_CONTROLFILE_COPY V$DATAFILE_COPY
A I Control file copies on disk
RC_COPY_CORRUPTION V$COPY_CORRUPTION
O Control file copies on disk
RC_DATABASE_BLOCK_CO
l &
V$DATABASE_BLOCK_COR Database blocks marked as
RRUPTION RUPTION
n a corrupted in the most recent
te r RMAN backup or copy
I n
RC_DATABASE_INCARNATI V$DATABASE_INCARNATI Database incarnations registered in
ON
c l e ON the recovery catalog
r a
RC_DATAFILE V$DATAFILE Datafiles registered in the recovery
catalog
O
RC_DATAFILE_COPY V$DATAFILE_COPY Datafile copies on disk
Oracle9i Database: Supporting Recovery Manager Appendix 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 using the proxy copy
functionality
RMAN Compatability 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.x greater/equal to 8.0.4
8.0.5 8.0.5 greater/equal to 8.x n l y

greater/equal to 8.0.5
e O
8.0.6 8.0.6
s
greater/equal to 8.x
U
8.0.6
8.0.6 8.0.6
I
greater/equal to 8.1.x
A
greater/equal to 8.1.x
8.1.5 8.1.5
O
greater/equal to 8.1.x greater/equal to 8.1.5
8.1.6 8.0.6.1
l & greater/equal to 8.x 8.0.6
n a
8.1.6 8.0.6.1
te r greater/equal to 8.1.x greater/equal to 8.1.x
8.1.6
I n8.1. 5 greater/equal to
8.1.x
greater/equal to
RMAN executable
c l e
8.1.6
r a 8.1. 6 greater/equal to
8.1.x
greater/equal to
RMAN executable
O
8.1.7 8.0.6.1 greater/equal to 8.x 8.0.6

8.1.7 8.0.6.1 greater/equal to 8.1.x greater/equal to 8.1.x
8.1.7 8.1.x greater/equal to 8.1.x greater/equal to

RMAN executable
9.0.1 9.0.1 greater/equal to 8.1.x greater/equal to

RMAN executable
9.2.0 greater/equal to 9.0.3 greater/equal to 8.1.x greater/equal to

RMAN executable
Depricated RMAN Commands
Deprecated In Deprecated Syntax Preferred Current Syntax
9.2 REPLICATE RESTORE CONTROLFILE FROM ...
n l y
9.2 SET AUTOLOCATE Now enabled by default.
e O
9.0.1 ALLOCATE CHANNEL FOR
DELETE
Not available
U s
9.0.1 ALLOCATE CHANNEL ...
A I
CONFIGURE CHANNEL ... DEVICE
TYPE
O
TYPE
9.0.1 ALLOCATE CHANNEL ...

l & CONFIGURE CHANNEL ...
KBYTES
n a MAXPIECESIZE
9.0.1
te r
ALLOCATE CHANNEL ... CONFIGURE CHANNEL ... RATE
n
READRATE
I
9.0.1 ...
cl eARCHIVELOG ...
LOGSEQ ...
ARCHIVELOG ... SEQUENCE
r a
9.0.1
O 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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
__________
Appendix B
Practices
__________
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Lesson 2 Practices
1. Put your database in archivelog mode. Make sure 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, etc. Make the datafile 20meg in size and place it in
$HOME/ORADATA/u04. Create a Recovery Manager user called RMAN and set the user’s
default tablespace to RCVCAT. Let the RMAN user have unlimited quota on this tablespace.
Set the temporary tablespace to TEMP. Grant role of 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 backup the control file
• Make DISK the default device type
• Set the level of parallelization for the DISK device to 2
• Configure 2 disk channels and specify the file format to be
$HOME/ORADATA/u06/C#_%U
• Create a 7 day recovery window
• Name the snap controlfile $HOME/ORADATA/u06/cfcp/snapcf_SID.f
Verify your configuration
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager Appendix B-2
Lesson 3 Practices
1. Using operating system commands make a complete cold backup into the directory
DONTTOUCH. This is done to provide a point of disaster recovery, should 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 in order to advise the repository of the backup 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. Into the directory BACKUP, make a full or incremental 0 backup of the database. Put all files
into one set, but restrict the size of each piece to 20 megabytes. Confirm the backup by
examining the appropriate tables in the repository.
5. Perform a database backup using automatic channel allocation. Make sure the backup
command behaves as specified in your persistent configuration.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Lesson 4 Practices
Complete recovery from a total failure
1. Delete all the datafiles and controlfiles 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 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. Use this time (less five 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. The script needs two
arguments; the absolute filename and block number respectively and should be run like the
example below:
$ corrupt.sh /u01/user01/ORADATA/u02/sample_01_U01.dbf 417
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
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 2. Using REPORT:

• Identify files that have less than 4 redundant backups.
• Identify files whose recovery needs more than 7 days of archived logs.
• Identify backups that are obsolete according to the new retention policy
• Use REPORT to view your database schema.
3. Delete obsolete backups as identified by the redundancy value 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.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Lesson 6 Practices
1. Configure the channel SBT_TAPE to use Oracle’s SBT dummy disk API. Use the
SBT_LIBRARY parameter to tell RMAN the proper library to load. Configure the
SBT_TAPE channel to be the default channel. Test the SBT configuration by performing a
backup. Troubleshoot the configuration if unsuccessful.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Lesson 7 Practices
1. Use RMAN to set a backup in progress. While the backup is running log onto the target
database using another telnet session and examine the view V$SESSION_LONGOPS. Using
this view it is possible to determine if the backup is progressing, or hanging. If all is well,
time_remaining should be decreasing.
2. Using RMAN perform another backup using the DEBUG option. On completion of the
backup script, examine the trace file produced by DEBUG.
3. Run the shell script les07_03.sh. After doing this, perform a database backup 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 re-run the backup to verify the repair.
persistent configuration. Investigate the alert log and trace files for any clues. If this proves
fruitless, use debug to gather more information. Correct the condition and run the backup.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
__________
Appendix C
Solutions
__________
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Lesson 2 Practices
1. Put your database in archivelog mode. Make sure the archived logs are written to
$HOME/ORADATA/ARCHIVE1.
To switch a database’s 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 equal 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;
n l y
e O
2. On your database Unn create a tablespace called RCVCAT that will contain the schema for
the repository tables, views, etc. Make the datafile 20meg in size and place it in
U s
$HOME/ORADATA/u04. Create a Recovery Manager user called RMAN and set the user’s
default tablespace to RCVCAT. Let the RMAN user have unlimited quota on this tablespace.
A
user. Create the catalog and register the target database.
I
Set the temporary tablespace to TEMP. Grant role of RECOVERY_CATALOG_OWNER to this
O
$HOME/ORADATA/u04.
l &
Use the create tablespace command. Name the file rcvcat.dbf and place it in
SQL> create tablespace rcvcat

n a
3 size 20m;
te r
2 datafile '$HOME/ORADATA/u04/rcvcat.dbf'
Tablespace created.
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager Appendix C-2
Create the RMAN user. Make RCVCAT the default tablespace and TEMP the temporary
tablespace. Give RMAN unlimited quota in RCVCAT.
Note: In order to connect to your target database it is required that the target user be
identified as a sysdba
SQL> create user rman identified by rman
2 DEFAULT TABLESPACE rcvcat QUOTA UNLIMITED ON rcvcat
3 temporary tablespace temp;
User created.
Grant RECOVERY_CATALOG_OWNER and any other privileges needed to the RMAN

user:
SQL> grant RECOVERY_CATALOG_OWNER, connect, resource, sysdba TO rman;
Grant succeeded.
Start RMAN and connect to the target database and the catalog. Create the catalog and
register the database.
SQL> exit
$ rman target / catalog rman/rman
connected to target database: U221 (DBID=4278320558)
recovery catalog is not installed
RMAN> CREATE CATALOG
recovery catalog created n l y
RMAN> register database;
database registered in recovery catalog
e O
Starting full resync of recovery catalog
full resync complete
U s
A I
3. Create a persistent configuration for the recovery catalog. Use the following specifications as
a guide:
• Automatically backup the control file O
• Make DISK the default device type
l &
•
•
n a
Set the level of parallelization for the DISK device to 2
Configure 2 disk channels and specify the file format to be
•
$HOME/ORADATA/u06/C#_%U
te r
Create a 7 day recovery window
•
I n
Name the snap controlfile $HOME/ORADATA/u06/snapcf_SID.f
Verify your configuration
c l e
r a
O
From the RMAN prompt, issue the show all command.
RMAN> show all;
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 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';
n l y
again and comparing the output with the practice requirements.
e O
Confirm that the necessary changes have been made by issuing the show all command
RMAN> show all;

U s
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default A I
O
'$HOME/ORADATA/u05/%F';
l &
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
n a
te r
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C1_%U';
I n
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT
'$HOME/ORADATA/u06/C2_%U';
l e
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$HOME/ORADATA/u06/snapcf_U01.f';
c
r a
O
Lesson 3 Practices
1. Using operating system commands make a complete cold backup into the directory
DONTTOUCH. This is done to provide a point of disaster recovery, should 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 under the ORADATA directory to
the DONTTOUCH directory. The datafiles are on different disks (simulated) so the find
command is useful for copying files from multiple locations and collapsing 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 cp {} $HOME/DONTTOUCH \;
$ ls –l $HOME/DONTTOUCH
total 821824
-rw-r----- 1 user01 dba 954368 Apr 14 17:16 control01.ctl
-rw-r----- 1 user01 dba 26214912 Apr 14 17:17 example01.dbf
-rw-r----- 1 user01 dba 26214912 Apr 14 17:17 indx01.dbf.rdo
...
-rw-r----- 1 user01 dba 15732736 Apr 14 17:17 users01.dbf
n l y
O
Query the CDF table in the RMAN schema. The backups listed include ALL blocks and
e
all.
U s
is most like an operating system backup. In this case, there is no history of the backup at
SQL> column fname format a50

SQL> select file#, fname, completion_time from rman.cdf; A I
no rows selected
O
l &
2. Use the CATALOG command in order to advise the repository of the backup taken previously.
a
Then confirm by examining the appropriate tables.
n
te r
Run each catalog individually from the RMAN prompt or include them in a run block.
copies.
I n
Use the output from the list command performed earlier to get the names of the datafile
SQL> exit
c l e
r a
$ rman target / catalog
RMAN> run {
rman/rman
O
2> catalog datafilecopy
'$HOME/DONTTOUCH/indx01.dbf';
'$HOME/DONTTOUCH/rcvcat.dbf';
'$HOME/DONTTOUCH/example01.dbf';
5> catalog datafilecopy '$HOME/DONTTOUCH/system01.dbf';

6> catalog datafilecopy '$HOME/DONTTOUCH/undotbs01.dbf';
7> catalog datafilecopy '$HOME/DONTTOUCH/users01.dbf';
}
To confirm RMAN’s knowledge 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 needed to do the RMAN
datafile backup.
n l y
SQL> column name format a45;
SQL> select file#, name from v$datafile;
e O
FILE #
------
1
NAME
--------------------------------------------
/home1/user01/ORADATA/u01/system01.dbf
U s
2
3
/home1/user01/ORADATA/u02/undotbs01.dbf
/home1/user01/ORADATA/u03/users01.dbf
A I
4
5
/home1/user01/ORADATA/u03/indx01.dbf
/home1/user01/ORADATA/u02/example01.dbf O
6
&
/home1/user01/ORADATA/u04/rcvcat.dbf
l
n a
Using the information from V$DATAFILE execute RMAN, connecting to the catalog
r
and the target database and perform the backup.
te
I n
RMAN> run {
l e
2> copy datafile 1 to '$HOME/BACKUP/RMAN/system01.dbf';
c
3> copy datafile 2 to '$HOME/BACKUP/RMAN/undotbs01.dbf';
r a
4> copy datafile 3 to '$HOME/BACKUP/RMAN/users01.dbf';
5> copy datafile 4 to '$HOME/BACKUP/RMAN/indx01.dbf';
O
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 n l y
Note that the control file has been backed up automatically.
e O
U s
Query the CDF table in the RMAN schema and compare the results with the query
I
performed earlier. You should see a second datafile backup.
A
RMAN> exit
O
$ sqlplus rman/rman
SQL> column completion_time format a15
l &
n a
SQL> select file#, fname, completion_time from cdf;
FILE# FNAME
te r COMPLETION_TIME
I n
---------- --------------------------------------------- ---------------
1 /home1/user01/DONTTOUCH/system01.dbf 14-APR-02
c l e
4 /home1/user01/DONTTOUCH/indx01.dbf
6 /home1/user01/DONTTOUCH/rcvcat.dbf
14-APR-02
14-APR-02
r a5 /home1/user01/DONTTOUCH/example01.dbf
2 /home1/user01/DONTTOUCH/undotbs01.dbf
14-APR-02
14-APR-02
O 3 /home1/user01/DONTTOUCH/users01.dbf
1 /home1/user01/BACKUP/RMAN/system01.dbf
2 /home1/user01/BACKUP/RMAN/undotbs01.dbf
14-APR-02
14-APR-02
14-APR-02
3 /home1/user01/BACKUP/RMAN/users01.dbf 14-APR-02
4 /home1/user01/BACKUP/RMAN/indx01.dbf 14-APR-02
5 /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. Into the directory BACKUP, make a full or incremental 0 backup of the database. Put all files
into one set, but restrict the size of each piece to 20 megabytes. Confirm the backup 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
... n l y
input datafile fno=00003 name=/home1/user01/ORADATA/u03/users01.dbf
channel c1: starting piece 1 at 14-APR-02
e O
channel c1: finished piece 1 at 14-APR-02
piece handle=/home1/user01/BACKUP/back_1U01.3 comment=NONE
U s
...
channel c1: starting piece 7 at 14-APR-02

A I
channel c1: finished piece 7 at 14-APR-02
O
piece handle=/home1/user01/BACKUP/back_7U01.3 comment=NONE
l &
channel c1: backup set complete, elapsed time: 00:00:33
Finished backup at 14-APR-02
n a
te r
comment=NONE
I n
Finished Control File Autobackup at 14-APR-02
c l e
a
Again, note the autobackup of the control file.
r
O
5. Perform a database backup using automatic channel allocation. Make sure the backup
command behaves as specified in your persistent configuration.

Start RMAN connecting to the catalog and the target database. Issue the backup database
command. If the persistent configuration has been setup properly, the RMAN output
should be similar to the example below. Please note the two disk channels that are
allocated and the backuppiece creation.

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
n l y
e O
Take notice of the channel allocation. Does the number of channels allocated match the degree of
parallelization specified for the DISK device in the persistent configuration? Note the files
U s
created by channels 1 and 2. Does the format and file location match that specified by the
persistent configuration create earlier? In the output above, the channels are automatically
I
allocated as desired and the backup pieces are written in the correct format and location.
A
O
l &
n a
te r
I n
c l e
r a
O
Lesson 4 Practices
Complete recovery from a total failure
1. Delete all the datafiles and controlfiles 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 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, backup 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
n l y
e O
Query V$DATAFILE and V$CONTROLFILE to find the location of the control file and
s
datafiles and delete them. DO NOT delete your backups. Be careful!
U
SQL> select name from v$datafile;
NAME
A I
---------------------------------------------
/home1/user01/ORADATA/u01/system01.dbf O
l &
n a
te r
/home1/user01/ORADATA/u02/example01.dbf
6 rows selected.
I n
SQL> select name from v$controlfile;
NAME
c l e
-------------------------------------------
r a
/home1/user01/ORADATA/u01/ctrl01.ctl
O Shutdown the database and remove the control file and datafiles.

SQL> exit
$ cd $HOME/ORADATA
$ rm u01/*.dbf
$ rm u01/*.ctl
$ rm u02/*.dbf
$ rm u03/*.dbf
$ rm u04/*.dbf
Start RMAN and connect to the target database only as 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 14 20:59 c-0574317449-20020414-00
-rw-r----- 1 ora9i dba 963072 Apr 14 21:14 c-0574317449-20020414-01
-rw-r----- 1 ora9i dba 963072 Apr 14 21:46 c-0574317449-20020414-02
-rw-r-----
-rw-r-----
-rw-r-----
1 ora9i dba
1 ora9i dba
1 ora9i dba
963072 Apr
963072 Apr
963072 Apr
14
14
15
21:51
23:51
12:41
c-0574317449-20020414-03
c-0574317449-20020414-05
c-0574317449-20020415-00n l y
-rw-r----- 1 ora9i dba
host command complete
963072 Apr 15 14:17
O
c-0574317449-20020415-01
e
Starting restore at 15-APR-02
U s
RMAN> restore controlfile from '$HOME/ORADATA/u05/c-0574317449-20020415-01';

channel ORA_DISK_1: restoring controlfile
A I
channel ORA_DISK_1: restore complete
RMAN>
O
l &
Using RMAN restore the datafiles and recover the database. At the end of the recovery
a
you will need to reset the database and make a complete backup since the database will
n
r
need to be opened using the resetlogs option.
te
I n
RMAN> alter database mount;
RMAN> restore database;
c l e
r a
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
O
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 n l y
RMAN> alter database open resetlogs;
e O
database opened
RMAN> exit
U s
RMAN> reset database;
A I
RMAN> exit
O
l &
a
Incomplete recovery to some time in the past
n
te r
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 *
I n
from HR.DEPARTMENTS and perform some inserts, noting the time before committing the
l e
inserts. Use this time (less five minutes) to recover the database to a point in time before the
new data was introduced.
c
r a
As user system/manager create the table HR.DEPARTMENTS2 as select * from
O 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# STATUS
---------- ----------------
3 INACTIVE
4 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# STATUS
n l y
----------
5
----------------
CURRENT
e O
4 ACTIVE
U s
I
SQL> insert into hr.departments2 values (280, 'DUMMY1','','');
A
SQL> commit
SQL> select count(*) from hr.departments2; O
COUNT(*)
l &
----------
30
n a
te r
I n
Shutdown the database, and restart it in mount mode.
l e
c
SQL> startup mount;
r a
ORACLE instance started.
O
SQL> exit

Using RMAN perform an incomplete recovery until the date and time recorded in the
previous step, less five 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
n l y
archive log filename=/home1/user01/ORADATA/ARCHIVE1/1_3.dbf thread=1
sequence=3
e O
Finished recover at 16-APR-02
RMAN> exit
U s
A I
Open the database with the resetlogs option and get a row count for the
O
DEPARTMENTS2 table. If it returns the same count as step 1, then the recovery was
l &
successful. Always perform a reset and a backup after opening the database with the
resetlogs option. Finally, bounce the database.
n a
te r
SQL> alter database open resetlogs;
SQL> select count(*) from hr.departments2;
COUNT(*)
I n
----------
27
SQL> exit
c l e
r a
RMAN> reset database;
O
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 respectively 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.
Make sure 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
n l y
5 /home1/user01/ORADATA/u02/example01.dbf
6 /home1/user01/ORADATA/u04/rcvcat.dbf
e O
SQL> exit
$ ls –l $HOME/ORADATA/u02/example01.dbf
U s
-rw-rw---- 1 ora9i dba 31461376 May
I
9 22:45 example01.dbf
A
O
Corrupt the block identified in the query above (in this case 417 in example01.dbf)
&
using the corrupt.sh shell script. Bounce the database to clear the buffer cache.
l
SQL> !
n a
0+1 records in
0+1 records out
te r
$ corrupt.sh /home1/user01/ORADATA/u02/example01.dbf 417
$ exit I n
c l e
r a
SQL> startup
O 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 that the corruption is repaired.
$ exit
n l y
SQL> select * from hr.departments;
e O
DEPARTMENT_ID DEPARTMENT_NAME
s
MANAGER_ID LOCATION_ID
U
------------- ------------------------------ ---------- -----------
10 Administration
20 Marketing
A I
200
201
1700
1800
...
250 Retail Sales O 1700
260 Recruiting
270 Payroll
l & 1700
1700
n a
27 rows selected.
te r
I n
c l e
r a
O
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

===================

------- ---- -- ---------- ----------- ------------ ---------------
19 Full 928K DISK 00:00:00 17-APR-02
Piece Name: /home1/user01/ORADATA/u05/c-0574317449-20020417-00
Controlfile Included: Ckp SCN: 163384 Ckp time: 17-APR-02

------- ---- -- ---------- ----------- ------------ ---------------
23 Full 45M DISK 00:00:24 17-APR-02
Piece Name: /u03/ora9ir2/dbs/03dm4rji_1_1
---- -- ---- ---------- --------- ----
2 Full 163636 17-APR-02 /home1/user01/ORADATA/u02/undotbs01.dbf
n l y
5
6
Full 163636
Full 163636
e O
17-APR-02 /home1/user01/ORADATA/u02/example01.dbf
17-APR-02 /home1/user01/ORADATA/u04/rcvcat.dbf

U
------- ---- -- ---------- ----------- ------------ ---------------
s
24 Full 90M
BP Key: 26
DISK
Status: AVAILABLE
00:00:24
Tag: I
17-APR-02
A
Piece Name: /u03/ora9ir2/dbs/04dm4rjj_1_1
List of Datafiles in backup set 24 O
---- -- ---- ---------- --------- ----
l &
1 Full 163637
a
17-APR-02 /home1/user01/ORADATA/u01/system01.dbf
n
3
4
...
Full 163637
Full 163637
te r
17-APR-02 /home1/user01/ORADATA/u03/users01.dbf
17-APR-02 /home1/user01/ORADATA/u03/indx01.dbf
BS Key Type LV Size

I n Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
50 Full
c l
BP Key: 51e
928K DISK
Status: AVAILABLE
00:00:00
Tag:
17-APR-02
r a
O
------- ---- -- ---------- ----------- ------------ ---------------
66 Full 928K DISK 00:00:00 17-APR-02

RMAN> list backup by file;
List of Datafile Backups

========================
File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Tag

---- ------- - -- - ---------- --------- ------- ------- ---
1 473 B F A 74588 28-MAY-02 1 1 TAG20020528T145408
415 B F A 74176 28-MAY-02 1 1 WKLY_BKUP
381 B F A 70420 28-MAY-02 1 1 TAG20020528T115053
274 B F A 69997 28-MAY-02 1 1 TAG20020528T113959
259 B F A 69942 28-MAY-02 1 1 TAG20020528T113852
...
5 473 B F A 74588 28-MAY-02 1 1 TAG20020528T145408
382 B F A 70421 28-MAY-02 1 1 TAG20020528T115053
274 B F A 69997 28-MAY-02 1 1 TAG20020528T113959
259 B F A 69942 28-MAY-02 1 1 TAG20020528T113852
6 473 B F A 74588 28-MAY-02 1 1 TAG20020528T145408
382 B F A 70421 28-MAY-02 1 1 TAG20020528T115053
274 B F A 69997 28-MAY-02 1 1 TAG20020528T113959
259 B F A 69942 28-MAY-02 1 1 TAG20020528T113852
List of Archived Log Backups

============================
Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Tag n l y
----
1
-------
1
----------
70236
---------
28-MAY-02
-------
441
-
A
-------
1
-------
1
e O
---
TAG20020528T144920
1
1
2
3
74241
74293
28-MAY-02
28-MAY-02
440
454
A
A
1
1
1
1
U s TAG20020528T144920
TAG20020528T144927
RMAN> list incarnation;

List of Database Incarnations
A I
DB Key Inc Key DB Name DB ID
------- ------- -------- ------------
CUR
--- O Reset SCN
----------
Reset Time
----------
1
1
2
73
U02
U02
775813490
775813490
l & NO
YES
1
440227
06-MAR-02
27-MAR-02
n a
te r
I n
2. Use CONFIGURE to change the REDUNDANCY to 2. Using REPORT:
• Identify files that have less than 4 redundant backups.
c l e
• Identify files whose recovery needs more than 7 days of archived logs.
• Identify backups that are obsolete according to the new retention policy
a
• Use REPORT to view your database schema.
r
O
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY = 2;
old RMAN configuration parameters:

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 /home1/user01/ORADATA/u02/undotbs01.dbf
3 3 /home1/user01/ORADATA/u03/users01.dbf
4 3 /home1/user01/ORADATA/u03/indx01.dbf
5 3 /home1/user01/ORADATA/u02/example01.dbf
6 3 /home1/user01/ORADATA/u04/rcvcat.dbf
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 n l y

RMAN retention policy is set to redundancy 2
Report of obsolete backups and copies
e O
Type Key Completion Time Filename/Handle
U s
-------------------- ------ ------------------ --------------------
Backup Set
Backup Piece
19
20
0574317449-20020417-00
17-APR-02
17-APR-02
A I
/home1/user01/ORADATA/u05/c-
...
O
l&
Backup Set 50 17-APR-02
Backup Piece 51 17-APR-02 /home1/user01/ORADATA/u05/c-
0574317449-20020417-02
n a
RMAN> report schema;
t e r
In
Report of database schema
File K-bytes Tablespace RB segs Datafile Name
1
2
c l e
---- ---------- --------------
102400 SYSTEM
56320 UNDOTBS
-------
YES
YES
-------------------
/home1/user01/ORADATA/u01/system01.dbf
3
4
r a 15360 USERS
46080 INDX
NO
NO
5
6 O 71680 SAMPLE
20480 RCVCAT
NO
NO
/home1/user01/ORADATA/u02/example01.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
l y
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.
n
Create and store the script.
e O
RMAN> create script whole_bkup
U s
2> {
A I
3> ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/%U';
4> backup database;
5> }
O
l &
Test the script to be sure it works properly.
n
RMAN> run {execute script whole_bkup;} a
allocated channel: d1
te
channel d1: sid=14 devtype=DISK r
...
I n
l e
c
piece handle=/home1/user01/ORADATA/u05/c0574317449-20020417-06
r a
comment=NONE
O
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;
}
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Lesson 6 Practices
Configure the channel SBT_TAPE to use Oracle’s SBT dummy disk API. Use the
SBT_LIBRARY parameter to tell RMAN the proper library to load. 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';
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/home1/user01/ORADATA/u06/C1_%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/home1/user01/ORADATA/u06/C2_%U';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home1/user01/ORADATA/u06/snapcf_U01.f';
n l y
Issue the configure channel command to configure the SBT_TAPE channel. Set the
channel.
e O
SBT_LIBRARY parameter to oracle.disksbt. Configure SBT_TAPE as the default
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'

U s
...
A I
PARMS="SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/home1/user01/ORADATA/u06)";
O
...
l &
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
a
n
te r
Backup the database to test the configuration.
I
n
l e
c
r a
O
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, troubleshoot the configuration. Below are some common
configuration errors.
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
n l y
errno = 0, Oracle Test Disk API: BACKUP_DIR environment variable is not set
e O
ORA-19511: Error received from media manager layer, error text:SBT error = 4110,
U s
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.
A I
O
RMAN-00571: ===========================================================
l &
RMAN-00571: ===========================================================
09:58:44
n a
RMAN-03009: failure of backup command on ORA_SBT_TAPE_1 channel at 04/18/2002
te r
ORA-19506: failed to create sequential file, name="0ndm75aj_1_1", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
I n
sbtpvt_catalog_open: file $HOME/ORADATA/u06/Oracle_Disk_SBT_Catalog, open
error, errno = 2
c l e
r a
O
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
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Lesson 7 Practices
1. Use RMAN to set a backup in progress. While the backup is running log onto the target
database using another telnet session and examine the view V$SESSION_LONGOPS. Using
this view it is possible to determine if the backup is progressing, or hanging. If all is well,
time_remaining should be decreasing.
Start RMAN and backup 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
About 5 seconds later:

0
n l y
v$session_longops;
e O
SID
----------
START_TIM ELAPSED_SECONDS TIME_REMAINING
--------- --------------- --------------
U s
10
15
15
19-APR-02
19-APR-02
19-APR-02
0
8
8
15
A I
About 5 seconds later: O
l &
v$session_longops;
n a
SID
----------
10
r
START_TIM ELAPSED_SECONDS TIME_REMAINING
te
--------- --------------- --------------
19-APR-02 0
15
15
I
19-APR-02
19-APR-02 n 11
11
10
c l e
r a
v$session_longops;
O SID START_TIM ELAPSED_SECONDS TIME_REMAINING

---------- --------- --------------- --------------
10 19-APR-02
15 19-APR-02
0
14 5
15 19-APR-02 14

v$session_longops;

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

v$session_longops;

---------- --------- --------------- --------------
10 19-APR-02 25 0
15 19-APR-02 20 0
15 19-APR-02 20 0
13 19-APR-02 0 0
Backup has finished:

v$session_longops;

---------- --------- --------------- --------------
10 19-APR-02 31 0
15
15
13
19-APR-02
19-APR-02
19-APR-02
20
20
0
0
0
0
n l y
10 19-APR-02 0 0
e O
U s
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
A I
the initial process started when the backup is initiated, you can see the process 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.
O
l &
2. Using RMAN perform another backup using the DEBUG option. On completion of the
backup script, examine the trace file produced by DEBUG.
n a
RMAN> run {
te r
$ rman target / catalog rman/rman trace $HOME/rman.out
2> debug on;

3> backup database;
4> debug off; I n
5> }
c l e
r a
Debugging set to level=9, types=ALL
O
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:
DBGSQL:
DBGSQL:
sqlcode=0
:b1 = "08.00.04"
:b3 = 80004
n l y
...
O
DBGSQL: EXEC SQL AT TARGET declare vsn varchar2 ( 20 ) ; begin vsn :=
dbms_rcvman . getPackageVersion ; :pkg_vsn:pkg_vsn_i := vsn ;
e
U
substr ( vsn , 4 , 2 ) || substr ( vsn , 7 , 2 ) ) ; en s
if vsn is not null then :pkg_vsnub4 := to_number ( substr ( vsn , 1 , 2 ) ||
d if ; end ;
DBGSQL:
DBGSQL:
sqlcode=0
:b1 = "09.02.00"
A I
DBGSQL:
...
:b3 = 90200
O
DBGSQL: sqlcode=0
l &
DBGSQL: EXEC SQL AT RCVCAT select user into :b1 from dual
DBGSQL: :b1 = "RMAN"

# Encoding the backup request
n a
RMAN> 2> 3> 4> 5>
te r
DBGMISC: Node # 1
DBGMISC: run
DBGMISC: I
1 JCL n
DBGMISC:
DBGMISC:
c l e 1 DEBUG
1 ON
DBGMISC:
r
DBGMISC:a 2 backup
1 BSLIST
O
DBGMISC:
DBGMISC:
DBGMISC:
DBGMISC:
3 DEBUG
1 OFF
1 BSPEC
1 DBASE
...
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 (krmice)
DBGMISC: command after this command is: NONE (krmice)
Debugging turned off
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 re-run the backup to verify the repair.
From the operating system prompt run the les07_03.sh script. Start RMAN and backup
the database, observing any errors.
$ les07_03.sh
starting full resync of recovery catalog
RMAN-00571: ===========================================================
n l y
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on t1 channel at 05/07/2002
e O
13:42:26
U s
ORA-27211: Failed to load Media Management Library
A I
O
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 file in
l
a
USER_DUMP_DEST gives a clue to the problem:
n
te r
*** SESSION ID:(15.22) 2002-05-07 13:55:44.577
Failed to load SBT library phony.disksbt
I n
This is not correct. The SBT library that needs to be loaded is defined by the SBT_LIBRARY
l e
parameter of the configure channel… command. Use the show command to see how
c
it is currently defined:
r a
O
RMAN> show channel;
"SBT_LIBRARY=phony.disksbt,ENV=(BACKUP_DIR=$HOME/ORADATA/u06)";
...

CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C2_%U';
Use the configure command to change the SBT_LIBRARY parameter to

oracle.disksbt and re-run the backup to confirm the correction. If you have difficulty,
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
n
4. Run the shell script les07_04.sh. After doing this, perform a database backup using the l y
persistent configuration. Investigate the alert log and trace files for any clues. If this proves
O
fruitless, use debug to gather more information. Correct the condition and run the backup.
e
observer the error: U s
After running the les07_04.sh shell script, use RMAN to perform a backup and

A I
Starting backup at 30-MAY-02 O
...
l &
RMAN-00571: ===========================================================
a
n
te r
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"
I n
ORA-27040: skgfrcre: create error, unable to create file
SVR4 Error: 13: Permission denied
c l e
The error SVR4 Error: 13: Permission denied is an operating system error.
r a
Running the backup again with the debug option may provide some useful information.
O
$ 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"
...
The SVR4 (Unix System V Kernel Release 4) exception is definitely raised by the OS.
This looks suspiciously like a permissions issue. Using cd, navigate ORADATA and
inspect the u06 directory.
$ pwd
/home1/user01
$ cd ORADATA
n l y
$ ls -la
total 21316
drwxrwxr-x 10 user01 dba 512 May 7 17:32 .
e O
drwxrwxrwx 10
drwxrwsr-x 2
user01
user121
dba
class7
512
96
May
May
7
29
17:23
17:52
..
U s
ARCHIVE1
-rw-rw----
drwxrwsr-x
drwxrwsr-x
1
2
2
user121
user121
user121
class7
class7
class7
4096
96
96
May
May
May
29
28
30
I
14:26
A
16:33
06:23
ARCHIVE15_193_0_60083.bkd
ARCHIVE2
u01
drwxrwsr-x
drwxrwsr-x
2
2
user121
user121
class7
class7
8192
8192 O
May
May
30
30
06:23
06:23
u02
u03
drwxrwsr-x
drwxrwsr-x
2
2
user121
user121
class7
class7
l & 96
8192
May
May
30
29
06:23
17:59
u04
u05
dr-xr-s--- 2 user121 class7
n a 8192 May 29 17:58 u06
te r
Notice that there are no write privileges on u06 where the backup pieces are to be written.
n
Use chmod to give write privileges to the user and group and retest the backup.
I
l
$ chmod 770 u06
c
$ ls -ld u06 e
r a
drwxrws--- 2 user01 dba
512 May 7 16:18 u06
O
Starting backup at 07-MAY-02
...
Finished backup at 07-MAY-02

Oracle 9i - Database Supporting Recovery Manager - RMAN - Student Guide

Uploaded by

Document Information

Original Description:

Original Title

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

Oracle 9i - Database Supporting Recovery Manager - RMAN - Student Guide

Uploaded by

Copyright:

Available Formats

Oracle9i Database: Supporting

1 Overview of Recovery Manager

Backups with RMAN n l y

O Advanced Algorithm 3-21

Using RMAN with a Media Manager

• Thorough knowledge of Oracle database administration and backup and

• Working experience with Recovery Manager

• Oracle9i Database Administration Fundamentals I and II or similar.

How This Course Is Organized

Oracle9i Release 2 Database: Supporting Recovery Manager is an instructor-led

Title Part Number

Oracle8i Online Generic Documentation CD-ROM A87860

Oracle9i Online Generic Documentation CD-ROM

• System release bulletins

• Installation and user’s guides

• Selected WebIV Notes

Convention Element Example

Caps and Buttons, Click the Executable button.

Courier new, Code output, Code output: debug.set (‘I”, 300);

Initial cap Graphics labels

Copyright Oracle Corporation, 2002. All rights reserved.

Commas Key sequences Press and release keys one at a time:

Typographic Conventions in Code

Convention Element Example

Passwords DROP USER scott

Lowercase Syntax variables CREATE ROLE role

This simplified path translates to the following: O

Copyright Oracle Corporation, 2002. All rights reserved.

Typographical Conventions in Help System Paths

The following help navigation path, for example—

(Help) General Ledger > Journals > Enter Journals

—represents the following sequence of actions:

2. Under the General Ledger entry, expand Journals.

3. Under Journals, select Enter Journals.

Copyright Oracle Corporation, 2002. All rights reserved.

Searching for Help

A list of titles, ranked by relevance and linked to the documents in question, is

After completing this lesson, you should be able to do

• Recovery Manager (RMAN) is an Oracle utility that

The features of RMAN include:

• Corrupt block detection

Oracle9i Database: Supporting Recovery Manager 1-6

A typical RMAN environment utilizes the following

• Four separate items must be compatible with one

Oracle9i Database: Supporting Recovery Manager 1-8

The RMAN tool consists of the following components:

Oracle9i Database: Supporting Recovery Manager 1-9

Media Manager Interface

The RMAN executable is responsible for:

• RMAN cannot function without the recover.bsq

Oracle9i Database: Supporting Recovery Manager 1-12

• The Recovery Catalog consists of the following

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

The SYS.DBMS_RCVMAN functions read data from the

• It is a fixed package, linked into the kernel so that

• Each DBMS_BACKUP_RESTORE call is:

• A channel represents one stream of data to a

• Type them into the RMAN command line interface

• Crash recovery versus media recovery

may even be done in parallel.

Oracle9i Database: Supporting Recovery Manager 1-20

• The redo after image is used to repeat a data