Professional Documents
Culture Documents
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
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
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
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
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:
Prerequisites
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
Additional Publications
• 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
Copyright Oracle Corporation, 2002. All rights reserved.
Preface-2
Typographic Conventions
Typographic Conventions in Text
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].
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
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
This course uses a “navigation path” convention to represent actions you perform
to find pertinent information in the Oracle Applications Help System.
1. In the navigation frame of the help system window, expand the General
Ledger entry.
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.
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.
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-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
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
Oracle9i Database: Supporting Recovery Manager 1-2
Recovery Manager
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-3
RMAN Features
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-4
RMAN Features
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-5
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
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-7
RMAN Version Compatibility
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
• Target Database
• Control file fixed tables and views
• Channel (Server Sessions)
• Media management interface module
• Media Manager Server
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
c l e
Media Manager Server
r a
A non-Oracle product that communicates with the interface module to manage tertiary storage.
O
Oracle9i Database: Supporting Recovery Manager 1-10
Recovery Manager
Utility Executable
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-11
Recovery Manager Executable:
The recover.bsq File
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
The recover.bsq File
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 >>>
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-13
Target Database:
Controlfile Tables and Views
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-14
Target Database:
SYS.DBMS_RCVMAN
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
r a
O
Oracle9i Database: Supporting Recovery Manager 1-15
Target Database:
DBMS_BACKUP_RESTORE
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-16
Target Database:
DBMS_BACKUP_RESTORE
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 l e
r a
O
Oracle9i Database: Supporting Recovery Manager 1-17
Channels and Media Manager Server
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-18
Running RMAN Commands
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-19
Simple Backup and Recovery Concepts
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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.
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
Oracle9i Database: Supporting Recovery Manager 1-21
Database Inconsistency
• Constraint inconsistency
• Logical inconsistency
• Structural inconsistency
• Physical inconsistency
– At the block level
– At the inter-block level
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-22
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
Oracle9i Database: Supporting Recovery Manager 1-23
Comparing Redo and Undo
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 1-25
Recovery Concepts
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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 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
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 1-28
Stuck Recovery
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Stuck Recovery
U s
Stuck recovery should cause a trace or a dump, typically ORA-600[3020]. To progress past a
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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
Oracle9i Database: Supporting Recovery Manager 1-31
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
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
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
Oracle9i Database: Supporting Recovery Manager 2-2
RMAN Configuration Decisions
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-4
Using RMAN Without a Recovery Catalog
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-5
Steps to Create the Recovery Catalog
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 2-6
Creating an RMAN User
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-7
Creating the Repository
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Creating the Repository
U s
The recovery catalog is created by issuing the RMAN command and connecting to the RMAN
n
connected to recovery catalog database
a
RMAN>
te r
recovery catalog is not installed
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 2-8
Recovery Catalog Strategy
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-9
RMAN Backup Strategy Guidelines
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-10
Ways to Start RMAN
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-11
Oracle Real Application Clusters
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-12
Connecting to an Auxiliary Database
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-13
RMAN and Pipes
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-14
Registering a Database
in a Recovery Catalog
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-15
Catalog Maintenance Commands
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-16
RESYNC CATALOG Command
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-18
Recovery Catalog Resync Types
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-19
When to Run a RESYNC CATALOG
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-20
Resync and Snapshot Control Files
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-21
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
Oracle9i Database: Supporting Recovery Manager 2-22
Persistent RMAN
Configuration Parameters
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-26
The CONFIGURE CHANNEL Command
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
CONFIGURE SNAPSHOT CONTROLFILE
U s
These command name changes are consistent with the rule that CONFIGURE sets persistent
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-31
CATALOG Command
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-33
Recovery Catalog Compatibility
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-35
Upgrading Recovery Catalog
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-36
Dropping the Recovery Catalog
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 2-37
Summary
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
r a
O
Oracle9i Database: Supporting Recovery Manager 2-38
Practice Overview:
Configuring RMAN
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
Oracle9i Database: Supporting Recovery Manager 2-39
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
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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 3-2
RMAN Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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;
}
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-8
Backup Set
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-11
Parallelization of Backup Sets
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
Level 0 2 2 1 2 2 2 0
Day Sun Mon Tue Wed Thu Fri Sat Sun
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-15
Cumulative Incremental Backups
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
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-16
SCN and Incremental Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-17
Basic Backup Algorithm
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-18
Algorithm Rules
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 3-20
Advanced Algorithm
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-22
Algorithm Behavior for Standard
Backup Sets
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-24
Algorithm Behavior for File Copies
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
O
l &
n a
te r
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 3-25
Backup Optimization
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-26
Backup Optimization Algorithm
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-29
Duplexed Backups
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
Oracle9i Database: Supporting Recovery Manager 3-30
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;
e
Device Type Elapsed Time Completion Time Tag
----------- ------------ --------------- ---
DISK 00:00:01 08-MAR-02 TAG20020208T152314
U s
List of Backup Pieces for backup set 1 Copy #2
BP Key Pc# Status Piece Name
A I
------- --- ----------- ----------
O
Backup Set Copy #3 of backup set 1
l &
2 1 AVAILABLE /oracle/oradata/01dg9tb2_1_2
n a
Device Type Elapsed Time Completion Time Tag
te r
----------- ------------ --------------- ---
I n
DISK 00:00:01 08-MAR-02 TAG20020208T152314
List of Backup Pieces for backup set 1 Copy #3
l e
BP Key Pc# Status Piece Name
c
------- --- ----------- ----------
r a
3 1 AVAILABLE /oracle/01dg9tb2_1_3
O
Oracle9i Database: Supporting Recovery Manager 3-31
Mirrored Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 3-32
Proxy Copy
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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,
n a
The BACKUP BACKUPSET command is a useful way to spread backups among multiple
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
• 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
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n a
te r
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 3-36
Long Term Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 3-39
Restarting a Backup
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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
Oracle9i Database: Supporting Recovery Manager 3-41
Summary
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 3-42
Practice Overview:
Backups With 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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 3-43
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
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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 4-2
The RESTORE Command
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-3
Steps in the RESTORE Process
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-4
File Selection When Restoring
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
Oracle9i Database: Supporting Recovery Manager 4-5
Restore Optimization
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-6
Restore Concepts
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 4-7
Restoring Data Files and Tablespaces
• Restore a tablespace:
RMAN> RESTORE TABLESPACE tools;
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Restoring Data Files and Tablespaces
U s
RMAN automates the procedure for restoring files. It is not necessary to copy files manually
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";
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
}
• 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
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 4-11
Parallelization of RESTORE
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-12
Restoring the Database to a New Host
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Restoring the Database to a New Host
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-14
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
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
Oracle9i Database: Supporting Recovery Manager 4-15
Create Standby Database with DUPLICATE
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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;
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 4-18
Restore Autolocation
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
I n
• Different PARMS settings
• Different connect strings
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 4-19
Restore When All Is Lost
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Restoring When All Is Lost
U s
What happens if the recovery catalog and target database are both lost or the target
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
Oracle9i Database: Supporting Recovery Manager 4-20
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
Oracle9i Database: Supporting Recovery Manager 4-21
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
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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
Oracle9i Database: Supporting Recovery Manager 4-22
Recovery Concepts
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-23
Basic RMAN Media Recovery
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
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
Oracle9i Database: Supporting Recovery Manager 4-24
RMAN Recovery Phases
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 4-26
Parallelization of Recovery
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
Oracle9i Database: Supporting Recovery Manager 4-27
Incomplete Database Recovery
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
Tape
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 4-32
RMAN BMR Interface
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-35
Recover Database Example
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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
RMAN> BACKUP DATABASE;
c
RMAN> ALTER DATABASE OPEN;
r a
O
Oracle9i Database: Supporting Recovery Manager 4-37
Recover a NOARCHIVELOG
Database Example
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 4-39
BLOCKRECOVER Examples
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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';
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 4-41
Summary
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
Oracle9i Database: Supporting Recovery Manager 4-42
Practice Overview:
Restore and Recovery with RMAN
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
Oracle9i Database: Supporting Recovery Manager 4-43
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
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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 5-2
Oracle9i Command Unification
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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.
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
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 5-8
Report Objects Needing Backup
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 5-9
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
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
Oracle9i Database: Supporting Recovery Manager 5-10
Report Unrecoverable Backups
and Copies
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 5-11
Report Obsolete Backups and Copies
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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 5-13
Report Database Schema
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Show RMAN Configuration Settings
U s
The SHOW ALL command displays both the CONFIGURE commands that you have issued
O
To show all RMAN configuration settings, connect to the target database and run the
SHOW ALL command:
RMAN> SHOW ALL;
l &
n
RMAN configuration parameters are:
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;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 5-16
CHANGE…UNCATALOG Command
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 5-17
Deleting Specified Backups and Copies
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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’;
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 5-19
Deleting Expired or Obsolete Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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;
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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;
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 5-23
Practice Overview:
RMAN Maintenance
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 5-24
Using RMAN with a Media 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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 6-2
Backups to Tape
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-3
Media Manager
Media
Oracle Media
Recovery Management
Manager Server Manager
Server
Session Library
Software
Recovery
Catalog
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-4
Media Manager Prerequisites
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-6
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
Oracle9i Database: Supporting Recovery Manager 6-7
Linking a Media Manager on NT
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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
Additional information: 25
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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;
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 6-12
Default SBT Interface
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-13
Events in a Media Manager Backup
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Events in a Media Manager Backup
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Events in a Media Manager Restore
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
Oracle9i Database: Supporting Recovery Manager 6-16
Events in a Media Manager Restore
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-17
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
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-18
Troubleshooting: Media Manager or RMAN
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Troubleshooting: Media Manager or RMAN
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)’;
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
ORA-19506: failed to create sequential file,
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
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
Oracle9i Database: Supporting Recovery Manager 6-21
Troubleshooting: Media Manager or RMAN
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Troubleshooting: Media Manager or RMAN (continued)
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Troubleshooting: Media Manager or RMAN (continued)
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
A I
O
l &
n a
te r
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 6-24
Troubleshooting: Media Manager or RMAN
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Troubleshooting: Media Manager or RMAN (continued)
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
Oracle9i Database: Supporting Recovery Manager 6-25
Troubleshooting Media Manager
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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:
ORA-19511: Error received from media manager layer, error
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
ORA-19511: Error received from media manager layer, error
text:
sbtbackup: Failed to open for backup.
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 6-27
SBTINIT and SBTINIT2 Function Errors
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Additional information: 4110
ORA-19511: SBT error = 4110, errno = 0, BACKUP_DIR
environment variable is not set
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 6-29
SBTOPEN or SBTBACKUP Failures
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 6-32
SBT API Return Codes
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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
Oracle9i Database: Supporting Recovery Manager 6-35
Practice Overview:
Using RMAN with a Media 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
Oracle9i Database: Supporting Recovery Manager 6-36
Debugging RMAN
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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 7-2
RMAN Message Output
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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> backup database;
RMAN> host "ls –l sample.log";
O
-rw-r--r-- 1 user02
host command complete
dba 576270 Apr 6 10:38 sample.log
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
RMAN Code Layer Error Numbers
U s
In the RMAN message stack, you will find errors prefixed with RMAN-nnn, ORA-nnn,
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Additional information: 7005
text:
r n
ORA-19511: Error received from media manager layer, error
I n te
SBT error = 7005, errno = 2, sbtopen: system error
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 7-6
Interpreting RMAN Error Stacks
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-8
Interpreting Server Errors
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-9
The sbttest Utility
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-11
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
Oracle9i Database: Supporting Recovery Manager 7-12
Monitoring the Media Manager
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-13
Monitoring Recovery Manager Sessions
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
r
9 8642 id=sess2,rman channel=c1
te
I n
c l e
r a
O
Oracle9i Database: Supporting Recovery Manager 7-15
Determining Which Data Files
Require Recovery
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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);
r
NAME
a
---------------------------------- ---------------
NAME
O/oracle/oradata/trgt/drsys01.dbf
/oracle/oradata/trgt/example01.dbf EXAMPLE
DRSYS
/oracle/oradata/trgt/users01.dbf USERS
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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 7-18
UNIX Tape Backup Failure
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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;
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 7-20
NT Tape Backup Failure
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-24
Snapshot Control File Creation Failure
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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,
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 7-26
RMAN Cannot Locate an Archived Log
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 7-29
Summary
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
Oracle9i Database: Supporting Recovery Manager 7-30
Practice Overview:
Debugging RMAN
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
Oracle9i Database: Supporting Recovery Manager 7-31
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
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
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 l e
ra
O
Oracle9i Database: Supporting Recovery Manager 8-2
Tuning RMAN
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-4
Disk Buffer Allocation Example
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
Copyright © Oracle Corporation, 2002. All rights reserved.
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
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
Oracle9i Database: Supporting Recovery Manager 8-5
Tape Buffer Allocation
Channel
Tape Buffers
256 kb 256 kb
256 kb 256 kb
DIGITAL DATA STORAGE
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
Server 0100100
Process 0100100
DIGITAL DATA STORAGE
Tape
4. Server process 3. Tape process
writes data to
Buffers signals finish
new buffer
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
e O
Synchronous Versus Asynchronous I/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.
Server 0100100
Process 0100100 0100100
DIGITAL DATA STORAGE
Tape
Buffers
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-10
Asynchronous I/O Bottlenecks
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-11
Synchronous I/O Bottlenecks
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-12
Tape Backup Speed
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-14
Empty Files and Incremental Backups
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
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 8-16
Control Tape Buffer Size with BLKSIZE
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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.
n l y
Copyright © Oracle Corporation, 2002. All rights reserved.
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
Oracle9i Database: Supporting Recovery Manager 8-19
Summary
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
Oracle9i Database: Supporting Recovery Manager 8-20
__________
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
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
I n
RC_DATABASE_INCARNATI V$DATABASE_INCARNATI Database incarnations registered in
ON
r a
RC_DATAFILE V$DATAFILE Datafiles registered in the recovery
catalog
O
RC_DATAFILE_COPY V$DATAFILE_COPY Datafile copies on disk
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
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
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
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
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 A-5
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
Oracle9i Database: Supporting Recovery Manager Appendix B-3
Lesson 4 Practices
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.
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.
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
Oracle9i Database: Supporting Recovery Manager Appendix B-4
Lesson 5 Practices
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
Oracle9i Database: Supporting Recovery Manager Appendix B-5
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
Oracle9i Database: Supporting Recovery Manager Appendix B-6
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.
4. Run the shell script les07_04.sh. After doing this, perform a database backup using the
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
Oracle9i Database: Supporting Recovery Manager Appendix B-7
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.
Start the instance and mount, but do not open, the database.
$sqlplus /nolog
SQL> connect / as sysdba
SQL> startup mount pfile=$HOME/oracle/dbs/initUnn.ora
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
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.
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)
connected to recovery catalog database
recovery catalog is not installed
RMAN> CREATE CATALOG
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
Oracle9i Database: Supporting Recovery Manager Appendix C-3
From the RMAN prompt, issue the show all command.
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u03/ora9ir2/dbs/snapcf_U01.f';# default
Run the appropriate configure commands to create the persistant configuration. Note
that DISK is already the default device type. Remember that the show all command
output was designed to allow easy cut and past operations to modify parameters.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'$HOME/ORADATA/u05/%F'
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$HOME/ORADATA/u06/snapcf_U01.f';
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C1_%U';
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C2_%U';
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
n a
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
te r
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '$HOME/ORADATA/u06/C1_%U';
I n
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
'$HOME/ORADATA/u06/C2_%U';
l e
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$HOME/ORADATA/u06/snapcf_U01.f';
c
r a
O
Oracle9i Database: Supporting Recovery Manager Appendix C-4
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> connect / as sysdba
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
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
3> catalog datafilecopy
4> catalog datafilecopy
'$HOME/DONTTOUCH/indx01.dbf';
'$HOME/DONTTOUCH/rcvcat.dbf';
'$HOME/DONTTOUCH/example01.dbf';
5> catalog datafilecopy '$HOME/DONTTOUCH/system01.dbf';
To confirm RMAN’s knowledge of the cataloged datafile copies, query the CDF table as
done previously.
$ sqlplus rman/rman
SQL> column fname format a50
SQL> select file#, fname, completion_time from cdf;
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 target / catalog rman/rman
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
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
Oracle9i Database: Supporting Recovery Manager Appendix C-7
5 /home1/user01/BACKUP/RMAN/example01.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.
l &
channel c1: backup set complete, elapsed time: 00:00:33
Finished backup at 14-APR-02
n a
te r
Starting Control File Autobackup at 14-APR-02
piece handle=/home1/user01/ORADATA/u05/c-0574317449-20020414-02
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.
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
Oracle9i Database: Supporting Recovery Manager Appendix C-9
Lesson 4 Practices
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.
U
SQL> select name from v$datafile;
NAME
A I
---------------------------------------------
/home1/user01/ORADATA/u01/system01.dbf O
/home1/user01/ORADATA/u02/undotbs01.dbf
/home1/user01/ORADATA/u03/users01.dbf
l &
/home1/user01/ORADATA/u03/indx01.dbf
n a
te r
/home1/user01/ORADATA/u02/example01.dbf
/home1/user01/ORADATA/u04/rcvcat.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.
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';
te
I n
RMAN> alter database mount;
RMAN> restore database;
c l e
Starting restore at 15-APR-02
using channel ORA_DISK_1
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
channel ORA_DISK_1: restored backup piece 1
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.
COUNT(*)
----------
27
SQL> !date
Tue Apr 16 17:05:50 EDT 2002
SEQUENCE# STATUS
---------- ----------------
3 INACTIVE
4 CURRENT
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.
SEQUENCE# STATUS
n l y
----------
5
----------------
CURRENT
e O
4 ACTIVE
U s
I
SQL> insert into hr.departments2 values (280, 'DUMMY1','','');
SQL> insert into hr.departments2 values (290, 'DUMMY2','','');
A
SQL> insert into hr.departments2 values (300, 'DUMMY3','','');
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
SQL> shutdown immediate;
c
SQL> startup mount;
r a
ORACLE instance started.
O
SQL> exit
$ rman target /
connected to target database: U01 (DBID=574317449)
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
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 target / catalog rman/rman
RMAN> reset database;
O
RMAN> backup database;
RMAN> shutdown immediate;
RMAN> startup;
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.
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
SQL> shutdown immediate;
r a
SQL> startup
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'
RMAN> exit
$ 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
Oracle9i Database: Supporting Recovery Manager Appendix C-16
Lesson 5 Practices
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
c l
BP Key: 51e
928K DISK
Status: AVAILABLE
00:00:00
Tag:
17-APR-02
r a
Piece Name: /home1/user01/ORADATA/u05/c-0574317449-20020417-02
Controlfile Included: Ckp SCN: 167802 Ckp time: 17-APR-02
O
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
66 Full 928K DISK 00:00:00 17-APR-02
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
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
Oracle9i Database: Supporting Recovery Manager Appendix C-18
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY = 2;
Report of files whose recovery needs more than 7 days of archived logs
File Days Name
---- ----- -----------------------------------------------------
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
/home1/user01/ORADATA/u02/undotbs01.dbf
3
4
r a 15360 USERS
46080 INDX
NO
NO
/home1/user01/ORADATA/u03/users01.dbf
/home1/user01/ORADATA/u03/indx01.dbf
5
6 O 71680 SAMPLE
20480 RCVCAT
NO
NO
/home1/user01/ORADATA/u02/example01.dbf
/home1/user01/ORADATA/u04/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
Finished backup at 17-APR-02
l e
Starting Control File Autobackup at 17-APR-02
c
piece handle=/home1/user01/ORADATA/u05/c0574317449-20020417-06
r a
comment=NONE
Finished Control File Autobackup at 17-APR-02
O
released channel: d1
RMAN>
Issue the RMAN print script command to view the stored script lines.
Oracle9i Database: Supporting Recovery Manager Appendix C-20
RMAN> print script whole_bkup;
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
Oracle9i Database: Supporting Recovery Manager Appendix C-21
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.
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
O
...
l &
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
a
new RMAN configuration parameters are successfully stored
n
te r
Backup the database to test the configuration.
I
RMAN> backup database;
n
l e
Starting backup at 18-APR-02
c
allocated channel: ORA_SBT_TAPE_1
r a
channel ORA_SBT_TAPE_1: sid=16 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
O
channel ORA_SBT_TAPE_1: starting full datafile backupset
channel ORA_SBT_TAPE_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home1/user01/ORADATA/u01/system01.dbf
input datafile fno=00005 name=/home1/user01/ORADATA/u02/example01.dbf
Oracle9i Database: Supporting Recovery Manager Appendix C-22
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
Finished backup at 18-APR-02
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: ===========================================================
RMAN-03002: failure of backup command at 04/18/2002 10:42:43
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27000: skgfqsbi: failed to initialize storage subsystem (SBT) layer
Additional information: 4110
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-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
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
Oracle9i Database: Supporting Recovery Manager Appendix C-23
An improperly configured default device will produce an error stack like this:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 04/18/2002 09:55:36
ORA-19569: no device is allocated to this session
RMAN-00600: internal error, arguments [6027] [1] [] [] []
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 C-24
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.
n l y
SQL> select sid, start_time, elapsed_seconds, time_remaining from
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 &
SQL> select sid, start_time, elapsed_seconds, time_remaining from
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
About 5 seconds later:
r a
SQL> select sid, start_time, elapsed_seconds, time_remaining from
v$session_longops;
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
c l e
r a
Debugging set to level=9, types=ALL
Starting backup at 19-APR-02
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
input datafile fno=00001 name=/home1/user01/ORADATA/u01/system01.dbf
...
Oracle9i Database: Supporting Recovery Manager Appendix C-26
Debugging turned off
RMAN> exit
$ vi rman.out
Recovery Manager: Release 9.2.0.0.0 - Beta
ORACLE_HOME = /u03/ora9ir2
System name: SunOS
Node name: stc-sun02
Release: 5.8
Version: Generic_108528-05
Machine: sun4u
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
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
...
Oracle9i Database: Supporting Recovery Manager Appendix C-27
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]
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.
From the operating system prompt run the les07_03.sh script. Start RMAN and backup
the database, observing any errors.
$ les07_03.sh
$ rman target / catalog rman/rman
RMAN> backup database;
starting full resync of recovery catalog
full resync complete
RMAN-00571: ===========================================================
n l y
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on t1 channel at 05/07/2002
e O
13:42:26
U s
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25
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;
RMAN configuration parameters are:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
"SBT_LIBRARY=phony.disksbt,ENV=(BACKUP_DIR=$HOME/ORADATA/u06)";
...
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
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
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> backup database;
RMAN> exit
$ vi rman.out
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
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
$ rman target / catalog rman/rman
512 May 7 16:18 u06
O
RMAN> backup database;
Starting backup at 07-MAY-02
...
Finished backup at 07-MAY-02