EMC NetWorker Module for Oracle Release 5.0 Administration Guide

EMC ® NetWorker ® 

Module for Oracle 

Release 5.0 

Administration Guide 

P/N 300-006-990 

REV A02 

EMC Corporation 

Corporate Headquarters: 

Hopkinton, MA 01748-9103 

1-508-435-1000 

www.EMC.com

2 

Copyright © 2003 - 2009 EMC Corporation. All rights reserved. 

Published June, 2009 

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change 

without notice. 

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO 

REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, 

AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 

PURPOSE. 

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. 

For the most up-to-date regulatory document for your product line, go to the Technical Documentation and Advisories section 

on EMC Powerlink. 

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. 

All other trademarks used herein are the property of their respective owners. 

EMC NetWorker Module for Oracle Release 5.0 Administration Guide

Preface 

Chapter 1 Introduction 

Contents 

Naming conventions used in this guide............................................................... 20 

Importance of backups............................................................................................ 20 

Product features ....................................................................................................... 20 

Scheduled compared to manual backups ..................................................... 21 

Deduplication backups and restores ............................................................. 21 

Probe-based backups ....................................................................................... 23 

Proxy backups and restores ............................................................................ 24 

VMware support............................................................................................... 25 

Archived redo log backups ............................................................................. 25 

Control file autobackup ................................................................................... 25 

Automatic channel allocation ......................................................................... 26 

Backup and restore optimization ................................................................... 26 

Backup copies.................................................................................................... 27 

Backup of backup sets...................................................................................... 29 

Cluster and RAC backups and restores......................................................... 29 

Configuration wizards..................................................................................... 30 

Internationalization (I18N) and localization (L10N)................................... 33 

Oracle Data Guard support............................................................................. 36 

Parallelism ......................................................................................................... 36 

Policy uniformity.............................................................................................. 37 

Restartable backups.......................................................................................... 37 

Retention policies ............................................................................................. 38 

Save set bundling.............................................................................................. 39 

Other Oracle features ....................................................................................... 44 

Software used in the NMO environment ............................................................. 47 

NetWorker software ......................................................................................... 47 

NMO software................................................................................................... 48 

NetWorker PowerSnap Module software..................................................... 48 

Oracle backup and recovery system.............................................................. 49 

NMO components ................................................................................................... 51 

NMO backup and restore processes ..................................................................... 52 

Regular scheduled backup processes ............................................................ 53 

Regular manual backup processes................................................................. 54 

Deduplication backup processes.................................................................... 55 

Regular restore processes ................................................................................ 57 

Deduplication restore processes..................................................................... 58 

EMC NetWorker Module for Oracle Release 5.0 Administration Guide 3

Contents 

4 

Chapter 2 Software Configuration 

Configuration roadmap.......................................................................................... 62 

Verify the Oracle Server configuration................................................................. 63 

Verify the NetWorker resources ............................................................................ 63 

NetWorker Server resource.............................................................................. 63 

NetWorker user group privileges ................................................................... 64 

NetWorker Schedule resource......................................................................... 66 

NetWorker Device resources ........................................................................... 66 

NetWorker volume pools................................................................................. 66 

Firewall support ................................................................................................ 67 

Configuring I18N support ..................................................................................... 67 

Requirements for I18N support ...................................................................... 68 

Configure I18N support................................................................................... 68 

Configure L10N support ........................................................................................ 69 

Migrating a legacy configuration with the nsrnmoadmin command ..............69 

Requirements for using the nsrnmoadmin command for migration........ 70 

Migration command syntax and options ...................................................... 71 

Configuring a backup with the NMC wizard......................................................72 

About the backup configuration wizard ....................................................... 72 

Requirements for using the backup configuration wizard......................... 73 

Configure a backup with the wizard ............................................................. 73 

Configuring a backup with the NMC legacy method ........................................75 

About backup configuration with the legacy method................................. 75 

Create RMAN scripts for backups.................................................................. 75 

Customize the nsrnmo script .......................................................................... 79 

Configure a Group resource with NMC ........................................................ 86 

Configure a Schedule resource with NMC.................................................... 87 

Configure a Client resource with NMC......................................................... 87 

Configure save set bundling............................................................................ 91 

Configure policy uniformity ........................................................................... 92 

Configuring a deduplication backup ................................................................... 93 

Requirements for a deduplication backup .................................................... 94 

Best practices for a deduplication backup..................................................... 94 

Configure a deduplication backup................................................................. 95 

Configuring a probe-based backup ...................................................................... 97 

Requirements for a probe-based backup....................................................... 97 

Configure a probe-based backup.................................................................... 97 

Chapter 3 Backup Procedures 

Manual backup procedures ..................................................................................104 

Requirements for a manual backup ............................................................. 104 

Manual backup through the RMAN command line interface ................. 105 

Manual backup through Oracle Enterprise Manager Backup Management 

Tools .................................................................................................................. 105 

NetWorker server bootstrap backup ............................................................ 106 

Cancel a manual backup ................................................................................ 107 

Monitor a manual backup.............................................................................. 108 

Scheduled backup procedures .............................................................................110 

Test a scheduled backup ................................................................................ 110 

Cancel a scheduled backup ........................................................................... 111 

Monitor a scheduled backup......................................................................... 112 

Automation of NSR_SERVER and NSR_GROUP parameter settings .... 113 

Regular backup information in NetWorker indexes.........................................114 

Deduplication backup information in NetWorker indexes..............................115 


Chapter 4 Data Restore and Recovery 

Contents 

About restore and recovery.................................................................................. 118 

NetWorker indexes and policies used for restores .................................... 118 

Recovery configuration wizard .................................................................... 118 

RMAN scripts for restore and recovery ............................................................. 121 

Performing an Oracle data restore and recovery .............................................. 123 

Requirements for an Oracle data restore..................................................... 123 

Restore through the RMAN command line interface ............................... 125 

Restore with Oracle Enterprise Manager Backup Management Tools ... 126 

Perform an Oracle data recovery ................................................................. 127 

Chapter 5 Disaster Recovery 

About disaster recovery........................................................................................ 130 

Preparing an Oracle database for disaster recovery......................................... 130 

Create the DBID text file................................................................................ 131 

Set up a postcommand script for backup of Oracle-related files............. 131 

Set up RMAN backups of the database and related files ......................... 132 

Set up RMAN backups of Recovery Catalog.............................................. 132 

Performing a disaster recovery............................................................................ 133 

NetWorker server recovery ........................................................................... 133 

Oracle disaster recovery to a new host........................................................ 133 

Sample postcommand script................................................................................ 134 

Chapter 6 Cluster and RAC Systems 

Considerations for cluster and RAC systems.................................................... 138 

Parameters in the RMAN script or session................................................. 138 

NetWorker software configuration .............................................................. 139 

Backup failover ............................................................................................... 139 

Cluster systems ...................................................................................................... 139 

Roadmap for backup/restore configuration in a cluster system............. 140 

Backup failover ............................................................................................... 140 

RAC systems........................................................................................................... 140 

RAC terminology............................................................................................ 140 

RAC backups and restores ............................................................................ 141 

Roadmap for backup/restore configuration in a RAC system................ 141 

Setting up RAC nodes to back up to a local storage node........................ 142 

Connect-time failover..................................................................................... 144 

Creating RMAN backup scripts ................................................................... 146 

Creating RMAN restore scripts .................................................................... 146 

Archived redo logs ......................................................................................... 147 

Chapter 7 Proxy Backups and Restores 

Overview of proxy backups and restores........................................................... 150 

Types of proxy backups ................................................................................. 150 

Types of proxy restores .................................................................................. 151 

Proxy backup and restore system........................................................................ 151 

Proxy backup processes ........................................................................................ 153 

Scheduled proxy backup ............................................................................... 154 

Proxy restore processes ......................................................................................... 159 

Instant restore or rollback.............................................................................. 160 

Restore from secondary storage ................................................................... 161 

Software configuration roadmap........................................................................ 163 


Contents 

6 

Basic configurations........................................................................................ 163 

Additional configurations for proxy operations ........................................ 163 

Proxy backup requirements..................................................................................171 

Checking configuration consistency ............................................................ 171 

Performing proxy backups ............................................................................ 172 

Proxy backup information in the NetWorker indexes......................................174 

Entries in the client file index........................................................................ 175 

Entries in the media database ....................................................................... 175 

NWORA resource file backup in the NetWorker indexes......................... 176 

Proxy restore requirements.................................................................................. 177 

Creating RMAN scripts for proxy restores.................................................. 177 

Performing proxy restores ............................................................................. 178 

Relocating files during proxy restores ......................................................... 179 

Restoring to a different host .......................................................................... 180 

Point-in-time recoveries without a Recovery Catalog............................... 181 

Catalog synchronization for proxy backups ......................................................181 

Extra entries in the catalogs........................................................................... 181 

Control file versus recovery catalog............................................................. 183 

The NWORA resource file ............................................................................. 183 

Automatic catalog synchronization with the nsroraclecat program ....... 191 

Proxy backups and restores on cluster systems.................................................194 

Proxy backup failover .................................................................................... 194 

Proxy backups from a virtual cluster client ................................................ 195 

Proxy backups from a physical cluster client.............................................. 196 

Restores from proxy backups on a cluster system ..................................... 197 

Appendix A Parameters in an RMAN Session 

Setting the NSR* parameters ............................................................................... 200 

NSR* parameter definitions................................................................................. 201 

Appendix B RMAN Commands 

The delete expired backup command ................................................................ 210 

The change...crosscheck and crosscheck commands ....................................... 210 

The pool option of the backup command.......................................................... 210 

The send command............................................................................................... 211 

Syntax rules...................................................................................................... 211 

Two ways to run the send command........................................................... 213 

Precedence rules.............................................................................................. 215 

The set duplex command..................................................................................... 215 

The trace option of the backup command......................................................... 217 


Appendix C Troubleshooting and Error Messages 

Glossary 

Index 

Contents 

Troubleshooting tips............................................................................................. 220 

RMAN error messages......................................................................................... 221 

NMO error messages............................................................................................ 222 

Error messages from the libnwora library.................................................. 223 

Error messages from the nsrnmoadmin program ..................................... 231 

Error messages from the nsrnmoinfo program.......................................... 233 

Error messages from the nsrnmoprobe program ...................................... 235 

Error messages from the nsrnmostart program......................................... 236 


Contents 

8 


Figures 

Title Page 

1 Regular Oracle backup and recovery system.................................................................... 50 

2 Regular scheduled NMO backup ....................................................................................... 54 

3 Regular manual NMO backup ............................................................................................ 55 

4 Deduplication NMO backup ............................................................................................... 57 

5 Regular NMO restore ........................................................................................................... 58 

6 UNIX Client resource for scheduled backups................................................................... 90 

7 Windows Client resource for scheduled backups............................................................ 91 

8 Oracle backup messages in Sessions tab of Monitoring window ................................ 108 

9 Oracle backup messages in Devices tab of Monitoring window................................. 109 

10 Oracle backup messages in Log tab of Monitoring window ........................................ 109 

11 Group details for regular scheduled backups................................................................. 113 

12 Proxy backup and restore system..................................................................................... 153 

13 Scheduled instant backup .................................................................................................. 156 

14 Scheduled immediate live backup.................................................................................... 158 

15 Deferred live backup .......................................................................................................... 159 

16 Instant restore or rollback .................................................................................................. 161 

17 Restore from secondary storage........................................................................................ 162 


Figures 

10 


Tables 

Title Page 

1 NMO components................................................................................................................. 51 

2 NetWorker Server resource attributes ............................................................................... 63 

3 User group privileges required for NMO operations...................................................... 65 

4 Options of the nsrnmoadmin command for migration................................................... 72 

5 NetWorker Client resource attributes................................................................................ 88 

6 NetWorker Probe resource attributes ................................................................................ 98 

7 PowerSnap parameters ...................................................................................................... 167 

8 NWORA parameter resources .......................................................................................... 184 

9 NWORA SID resource components ................................................................................. 186 

10 Parameters in the RMAN command or script ................................................................ 201 

11 Option values in the send command ............................................................................... 213 

12 Set duplex command values.............................................................................................. 216 

13 Trace option values and conditions traced...................................................................... 217 

14 Error messages from the libnwora library....................................................................... 223 

15 Error messages from the nsrnmoadmin program.......................................................... 231 

16 Error messages from the nsrnmoinfo program .............................................................. 234 

17 Error messages from the nsrnmoprobe program ........................................................... 235 

18 Error messages from the nsrnmostart program ............................................................. 236 


Tables 

12 


Examples 

Title Page 

1 Using the configure channel command with parms option for automatic channels .. 26 

2 Specifying parameter values per automatic channel ....................................................... 26 

3 Using the set backup copies command in the RMAN script .......................................... 28 

4 Using automatic channels for backup copies .................................................................... 28 

5 Expiring a backup ................................................................................................................. 38 

6 Save set bundling for a one-week scheduled backup cycle of a tablespace ................. 42 

7 Save set bundle join .............................................................................................................. 43 

8 Splitting a save set bundle across volumes ....................................................................... 43 

9 Using save set consolidation to re-unite a save set bundle ............................................. 44 

10 RMAN script for a manual backup .................................................................................... 75 

11 RMAN script for AES encryption during an Oracle backup .......................................... 76 

12 RMAN script for a scheduled backup ................................................................................ 77 

13 RMAN script for a manual deduplication backup ........................................................... 96 

14 Possible Command Options settings for the nsrnmoprobe program ........................... 99 

15 Multiple probes for a probe-based backup ..................................................................... 100 

16 RMAN script to restore a tablespace ................................................................................ 121 

17 RMAN script to restore an AES encrypted backup ....................................................... 122 

18 RMAN script to restore from a specified pool ................................................................ 122 

19 Sample nsrnmoinfo commands for Oracle restores ....................................................... 125 

20 Volume information displayed by the nsrnmoinfo command ..................................... 125 

21 Sample postcommand script on UNIX ............................................................................ 134 

22 Sample postcommand script on Windows ...................................................................... 135 

23 Setting up RAC nodes as storage nodes .......................................................................... 142 

24 RMAN script for a manual Oracle backup on a RAC system ...................................... 146 

25 RMAN script for an Oracle restore on a RAC system ................................................... 146 

26 RMAN scripts with multiple channels ............................................................................ 165 

27 PowerSnap parameter settings .......................................................................................... 168 

28 PowerSnap parameter settings for a Celerra NAS device ............................................ 168 

29 Proxy backup failure ........................................................................................................... 172 

30 Proxy backup entries in the client file index ................................................................... 175 

31 Proxy backup entries in the media database ................................................................... 176 

32 Resource file backup entry in the client file index ......................................................... 176 

33 Resource file backup entry in the media database ......................................................... 176 

34 RESTORE_TYPE_ORDER parameter settings ................................................................ 177 

35 Symbolic link specified in the set newname command ................................................. 180 

36 Relocation of a raw volume ............................................................................................... 180 

37 Default NWORA parameter resources ............................................................................ 186 

38 NWORA SID resource ........................................................................................................ 187 

39 Connection file contents ..................................................................................................... 188 

40 Proxy backup entries in the index of a physical cluster client ...................................... 196 


Examples 

14 

Title Page 

41 Proxy backup entries in the index of a virtual cluster client ......................................... 197 

42 A send command sets the parameters for a specified channel ..................................... 212 

43 An rman send command sets a parameter for all channels .......................................... 214 

44 Order of parameters set according to the precedence rules .......................................... 215 


Preface 

As part of an effort to improve and enhance the performance and capabilities of its product 

lines, EMC periodically releases revisions of its hardware and software. Therefore, some 

functions described in this document may not be supported by all versions of the software or 

hardware currently in use. For the most up-to-date information on product features, refer to 

your product release notes. 

If a product does not function properly or does not function as described in this document, 

please contact your EMC representative. 

Audience This document is part of the EMC NetWorker Module for Oracle (NMO) 

documentation set, and is intended for use by system administrators and Oracle 

database administrators (DBAs) who are responsible for installing software and 

maintaining the Oracle Server backup and recovery systems. Operators who monitor 

Oracle database backups may also find this document useful. 

Readers of this document are expected to be familiar with the following topics: 

Related 

documentation 

◆ Oracle terminology and concepts, especially those related to Oracle database 

backup and recovery. 

◆ Backup and recovery procedures on an Oracle Server. 

◆ Disaster recovery procedures on an Oracle Server. 

Documentation related to the use of this product can be found at the EMC website, 

http://Powerlink.EMC.com, including: 

◆ The NetWorker Module for Oracle release 5.0 documentation set: 

Administration guide 

Installation guide 

Release notes 

Command reference guide 

◆ The NetWorker documentation set: 

Administration guide 

Installation guide 

Release notes 

Command reference guide 

Disaster recovery guide 

◆ Other EMC documentation: 

NetWorker PowerSnap Module documentation 

Software compatibility guide 

UNIX man pages 


Preface 

16 

Conventions used in 

this document 

! 

! 

The following additional documentation may be useful: 

◆ Oracle Server documentation 

◆ Oracle database backup and recovery documentation 

EMC uses the following conventions for special notices. 

Note: A note presents information that is important, but not hazard-related. 

CAUTION 

A caution contains information essential to avoid data loss or damage to the system 

or equipment. 

IMPORTANT 

An important notice contains information essential to software or hardware 

operation. 

Typographical conventions 

EMC uses the following type style conventions in this document: 

Normal Used in running (nonprocedural) text for: 

Names of interface elements (such as names of windows, dialog boxes, buttons, 

fields, and menus) 

Names of resources, attributes, pools, Boolean expressions, buttons, DQL 

statements, keywords, clauses, environment variables, functions, utilities 

URLs, pathnames, filenames, directory names, computer names, links, groups, 

service keys, file systems, notifications 

Bold Used in running (nonprocedural) text for: 

Names of commands, daemons, options, programs, processes, services, 

applications, utilities, kernels, notifications, system calls, man pages 

Used in procedures for: 

Names of interface elements (such as names of windows, dialog boxes, buttons, 

fields, and menus) 

What the user specifically selects, clicks, presses, or types 

Italic Used in all text (including procedures) for: 

Full titles of publications referenced in text 

Emphasis (for example, a new term) 

Variables 

Courier Used for: 

System output, such as an error message or script 

URLs, complete paths, filenames, prompts, and syntax when shown outside of 

running text 

Courier bold Used for: 

Specific user input (such as commands) 

Courier italic Used in procedures for: 

Variables on the command line 

User input variables 

< > Angle brackets enclose parameter or variable values supplied by the user 

[ ] Square brackets enclose optional values 


| Vertical bar indicates alternate selections - the bar means “or” 

{ } Braces indicate content that you must specify (that is, x or y or z) 

... Ellipses indicate nonessential information omitted from the example 

Where to get help EMC support, product, and licensing information can be obtained as follows. 

Product information — For documentation, release notes, software updates, or for 

information about EMC products, licensing, and service, go to the EMC Powerlink 

website (registration required) at: 

Preface 

http://Powerlink.EMC.com 

Technical support — For technical support, go to EMC Customer Service on 

Powerlink. To open a service request through Powerlink, you must have a valid 

support agreement. Please contact your EMC sales representative for details about 

obtaining a valid support agreement or to answer any questions about your account. 

Your comments Your suggestions will help us continue to improve the accuracy, organization, and 

overall quality of the user publications. Please send your opinion of this document to: 

SSGdocumentation@EMC.com 

If you have issues, comments, or questions about specific information or procedures, 

please include the title and, if available, the part number, the revision (for example, 

A01), the page numbers, and any other details that will help us locate the subject you 

are addressing. 


Preface 

18 


This chapter includes the following major sections: 

1 

Introduction 

◆ Naming conventions used in this guide .................................................................... 20 

◆ Importance of backups ................................................................................................. 20 

◆ Product features............................................................................................................. 20 

◆ Software used in the NMO environment .................................................................. 47 

◆ NMO components......................................................................................................... 51 

◆ NMO backup and restore processes........................................................................... 52 

Introduction 19

Introduction 

20 

Naming conventions used in this guide 

Importance of backups 

Product features 

Consider the naming conventions used throughout this guide: 

◆ “Administrator Microsoft user” and “a member of the Microsoft Windows 

Administrators group” are used interchangeably. 

◆ “Oracle Server host” refers to the host where both the Oracle Server and EMC ® 

NetWorker ® Module for Oracle (NMO) software are installed. 

◆ “Proxy backup or restore” refers to an Oracle RMAN proxy copy backup or 

restore that is implemented by using snapshot technologies through the 

PowerSnap Module software. 

◆ Unlike the NetWorker software, which uses the term recover for all data retrieval 

activities, Oracle distinguishes between restoring and recovering a database: 

“Restore” refers to retrieving individual datafiles from backup and storing the 

files on disk. 

“Recover” refers to applying the redo logs to make the database consistent. 

This guide follows the Oracle terminology. 

◆ “Regular backup or restore” refers to an NMO backup or restore of Oracle data 

that does not use snapshot technologies through the PowerSnap Module 

software. 

◆ "UNIX" refers to both UNIX and Linux operating systems, unless specified 

otherwise. 

◆ "Windows" refers to all the supported Microsoft Windows operating systems, 

unless specified otherwise. 

The reliability of computer equipment has improved greatly in recent years, but 

system and hardware failures still occur, sometimes with catastrophic results. 

In a client/server environment, data can be lost due to hardware failures and user 

errors. Software bugs, procedural flaws, and simple user errors are common 

problems that necessitate database restores from backup storage media. A viable 

backup strategy can help in the recovery from disastrous situations. 

Database administrators must recognize the importance of performing regular 

backups of database files and frequent backups of archived redo logs. If all archived 

redo logs are lost, a database can be recovered only to the time of the last consistent 

backup. Without backups and archived redo logs, the database cannot be recovered 

at all. 

The following sections describe major features of the NMO, Oracle Recovery 

Manager (RMAN), and Oracle Server software. 

Certain sections refer to the send command, which is used to set parameters in the 

RMAN script for an NMO backup, as described in “The send command” on 

page 211. 

The Oracle backup and recovery documentation provides more details on RMAN 

backups and restores and Oracle product features. 


Scheduled compared to manual backups 

Deduplication backups and restores 

An NMO backup can be either a scheduled or manual (unscheduled) backup: 

Introduction 

◆ A scheduled NMO backup includes the following features: 

The backup is initiated by the NetWorker server. 

The backup start time depends on the settings in the NetWorker resources. 

A regular scheduled backup starts at a time specified in the NetWorker Group 

resource. 

A probe-based backup (or event-based backup) is a type of scheduled backup 

that starts when specified conditions are met, as described in “Probe-based 

backups” on page 23. 

A proxy backup is only supported by using a scheduled backup, as described in 

“Proxy backups and restores” on page 24. 

◆ A manual NMO backup includes the following features: 

The backup is initiated by a user on the NMO host through an Oracle backup 

utility, which can be RMAN or Oracle Enterprise Manager. 

The backup is performed by running the Oracle utility from the operating 

system command line. For example, a user starts a manual NMO backup by 

running an RMAN backup script from the command line. 

Chapter 2, “Software Configuration,” provides details on the configuration of both 

scheduled and manual backups. 

Chapter 3, “Backup Procedures,” provides details on scheduled and manual backup 

procedures. 

NMO 5.0 software provides new support for deduplication backups and restores. 

The NetWorker Module for Oracle release notes provides details on the NetWorker 

requirements for the support of deduplication operations. 

Main features of deduplication operations 

An EMC Avamar ® server (on Linux) interacts with the NetWorker server and NMO 

software during deduplication backups and restores. The Avamar server is 

configured as a NetWorker deduplication node, and deduplicates the data from 

various clients, including the NMO clients. (The Avamar server must also be 

available when a deduplication client resource is created.) 

The initial backup to a deduplication node (Avamar server) will be a full backup. 

During subsequent deduplication backups, the Avamar server identifies redundant 

data blocks on the NMO client host and backs up only the unique blocks (not entire 

files) that contain changes. Only a single instance of any unique (atomic in Avamar 

terminology) data block is maintained on the Avamar server. 

Since data deduplication is performed on the client host, deduplication backups 

typically require less time, network bandwidth, and storage space than regular NMO 

backups. 

Product features 21

Introduction 

22 

The Avamar client-side binary, nsravtar, is installed on the NMO client with the 

NetWorker client software. During a deduplication backup, the nsravtar process 

sends the deduplicated client data to the Avamar server. A deduplication NMO 

backup uses a hash cache on the client side. The Avamar and NetWorker 

documentation provides more details about caches in deduplication backups. 

The following sections describe the processes involved in deduplication backups and 

restores: 

◆ “Deduplication backup processes” on page 55 

◆ “Deduplication restore processes” on page 58 

A deduplication backup can be a manual or scheduled backup, including a 

probe-based backup. 

The application of browse and retention policies and the selection of media pools is 

the same for a deduplication backup as for a regular NMO backup. 

Since only the backup metadata (hash ID) is stored on the NetWorker backup device 

(generating a very small save set), the device should be configured as an advanced 

file type device (AFTD). The NetWorker administration guide provides more 

information. 

You must configure a scheduled or manual deduplication backup according to 

“Configuring a deduplication backup” on page 93. 

“Deduplication backup information in NetWorker indexes” on page 115 describes 

the backup information stored in the NetWorker indexes, and how to delete the 

backups. 

Features not supported with deduplication operations 

Deduplication operations do not support the following: 

◆ Oracle proxy backups or restores. 

◆ Cluster or RAC backups or restores. 

◆ Internet Protocol version 6 (IPv6). 

◆ AES encryption of deduplicated data through the NSR_AES_ENCRYPTION 

parameter. 

◆ Checksumming of deduplicated data through the NSR_CHECKSUM parameter. 

◆ Compression of deduplicated data through the NSR_COMPRESSION parameter. 

If NSR_AES_ENCRYPTION, NSR_CHECKSUM, or NSR_COMPRESSION is set 

for a deduplication backup, NMO applies the AES encryption, checksumming, or 

compression, respectively, to only the metadata that is stored on the NetWorker 

storage node. 

◆ Cloning or staging of deduplicated data on the Avamar server. 

Only the metadata stored on the NetWorker storage node can be cloned or 

staged. However, deduplicated save sets on the Avamar server can be replicated to 

another Avamar server that has been configured as a replication node by EMC 

Professional Services. Avamar documentation and the NetWorker administration 

guide provide details on replication of deduplication backups. 


Probe-based backups 

Introduction 

NMO 5.0 software provides new support for probe-based backups (also known as 

event-based backups). A probe-based backup is a type of scheduled backup: 

◆ The NetWorker server starts a regular scheduled backup based on a time interval. 

◆ The NetWorker server starts a probe-based backup when specified conditions are 

met. 


requirements for the support of probe-based backups. 

Probe-based backups are not supported for proxy backups or cluster/RAC 

environments. 

Workflow of probe-based backups 

A probe-based NMO backup starts when both of the following are true: 

◆ (Condition 1) The current time is within a specified window of time (the backup 

window, defined by the probe start time and probe end time in the probe-enabled 

backup group resource). 

◆ One of the following conditions is met: 

(Condition 2) A specified amount of time has elapsed since the previous 


(Condition 3) One or all of the probes associated with the backup are 

successful, depending on the probe success criteria specified in the backup 

configuration. 

The probe success criteria can be set in the NetWorker Group resource to the 

value Any or All. 

At specified probe intervals, the NetWorker server performs the following: 

1. The server checks for condition 1, to determine if the current time is within the 

backup window. 

2. If condition 1 is met, then the server checks for condition 2, to determine if a 

specified amount of time has elapsed since the last probe-based backup: 

If condition 2 is met, then the server starts the probe-based backup. 

If condition 2 is not met, then the server checks for condition 3, to determine if 

one or all of the probes are successful: 

– If the probe success criteria is set to Any, and any one of the probes is 

successful, then the server starts the probe-based backup. 

– If the probe success criteria is set to All, and all of the probes are successful, 

then the server starts the probe-based backup. 

Product features 23

Introduction 

24 

Types of probes 

Proxy backups and restores 

There are two different types of probes: 

◆ An NMO probe. 

The NMO probe is implemented through the NMO program nsrnmoprobe. The 

nsrnmoprobe program returns a successful result (signifying that the condition 

being checked has been met) when it detects either of the following: 

The number of Oracle redo logs generated since the previous probe-based 

backup exceeds a number known as the change threshold. 

A new database incarnation (reset log) has occurred since the previous 


◆ User-defined probes. 

A user-defined probe checks if any other user-defined condition (other than the 

number of generated Oracle redo logs) has been met since the previous 

probe-based backup. (This option requires more advanced configuration.) To 

implement a user-defined probe, you must create a new script or program that 

checks for the condition, as described in “Configuring a probe-based backup” on 

page 97. 

You must configure the required parameters and NetWorker resources to specify the 

probe interval, backup window, and any other settings for a probe-based backup. 

“Configuring a probe-based backup” on page 97 provides details on how to 

configure a probe-based backup. 

Proxy backups and restores provide continuous snapshot-based protection and 

availability of Oracle data on specific types of primary storage. A proxy operation 

involves both the NMO software and a specific PowerSnap Module. The EMC 

Information Protection Software Compatibility Guide on the EMC Powerlink ® website 

provides a list of supported PowerSnap Modules. 

Proxy backups create point-in-time copies or snapshots of Oracle data, store the 

snapshots on primary storage devices supported by the PowerSnap Modules (for 

Symmetrix ® , CLARiiON ® , and so on), and optionally back up the data to secondary 

storage (such as tape) from the point-in-time copies. 

Proxy restores are used to restore the Oracle data that is backed up during the proxy 

backups. 

Chapter 7, “Proxy Backups and Restores,” provides more information on proxy 

backup and restore operations. 


VMware support 

Archived redo log backups 

Control file autobackup 

Introduction 

NMO 4.5 provided support for regular backups and restores of an Oracle database 

installed on a VMware Virtual Machine (VM) on an ESX server. 

NMO 5.0 extends this support with the support for the following advanced features 

of a VMware ESX server: 

◆ VMotion — The VMotion feature enables migration of virtual machines from one 

ESX server to another while the servers are on. The migration is seamless to the 

applications running on the virtual machines, and a user does not experience any 

disconnection. If a migration occurs during an NMO backup or restore, the 

backup or restore is not interrupted. VMware documentation provides details on 

the VM requirements for VMotion. 

◆ Distributed Resource Scheduler (DRS) — The DRS feature enables dynamic 

balancing and allocation of resources across multiple ESX servers. Depending on 

the DRS policies set by the user, the DRS can migrate or recommend that users 

migrate a virtual machine to a different ESX server by using VMotion. DRS can 

also start (at boot-up time) a virtual machine on a different ESX server. Since this 

feature uses VMotion, if a migration occurs during an NMO backup or restore, 

the backup or restore is not interrupted. 


requirements for the support of VMware features. 

Archived redo log backups enable recovery of the database to its predisaster state. 

Without archived redo log backups, the database can be recovered only to the time of 

the last consistent Oracle backup. In this case, transactions that occurred between the 

time of the last consistent backup and the time of the database corruption will be lost. 

Archived redo logs can be backed up by using the appropriate option of the RMAN 

backup command. Ensure that the NMO backups of archived redo logs are enabled. 

“Backing up all archived logs from each node” on page 147 provides a sample script 

to back up the archived redo log files in a RAC system. 

The appropriate Oracle backup and recovery documentation provides more 

information on setting up and running archived redo log backups. 

RMAN performs a control file autobackup after each RMAN backup command if the 

control file autobackup has been enabled with the configure controlfile autobackup 

on command. Use this feature to restore the backup entries contained in the control 

file when the control file is lost and the Recovery Catalog is not available. 

Specify persistent settings for the control file autobackups with the configure 

controlfile autobackup command. For example, enable control file autobackup and 

specify the persistent setting for the format of the control file autobackup name with 

the following commands: 

configure controlfile autobackup on 

configure controlfile autobackup format for device type ’sbt_tape’ to 

’/NMO_%f/’ 

Product features 25

Introduction 

26 

Automatic channel allocation 

! 

If the control file autobackup is set to on and the RMAN backup is performed with 

NMO, the control file autobackup will also be performed with NMO. As a result, one 

or more channels of device type sbt_tape must be allocated for the restore. 

Note: Oracle also supports autobackup of the current server parameter file together with 

control file autobackup. 

RMAN supports automatic channel allocation. This feature enables the configuration 

of persistent settings for automatic channels, for use in all RMAN sessions. 

IMPORTANT 

Manual and automatic channels are mutually exclusive and cannot be mixed in an 

RMAN session. The format of an automatic channel name of the device type for 

NMO backups and restores is ORA_SBT_n or ORA_SBT_TAPE_n, where n is the 

channel number. Do not use this name format for manual channel allocation for 

NMO. Otherwise, RMAN reports an error. 

With automatic channel allocation, specification of the send command before the 

backup or restore command causes the following error: 

RMAN-06422: no channels found for SEND command 

You must use the configure channel...parms... command to set the NSR* parameters 

for automatic channels for an NMO backup. Do not use the send command or option 

to set the NSR* parameters for automatic channels if you plan to use scheduled 

backups. 

Table 10 on page 201 lists all the NSR* parameters and their requirements. 

Example 1 Using the configure channel command with parms option for automatic channels 

Automatic channels are configured for NMO backups with the NetWorker server 

server1.emc.com by typing the following configure channel...parms... command: 

configure channel device type ’sbt_tape’ parms 

’ENV=(NSR_SERVER=server1.emc.com)’ 

This command sets the default parameters for all the automatic channels. 

Example 2 Specifying parameter values per automatic channel 

Backup and restore optimization 

Specific NSR* parameter values can be set for different channels (for example, a 

separate setting of parameter NSR_GROUP for each channel) by typing the configure 

channel n device type...parms... command, where n represents a channel number. 

An NMO debug file is specified for the second automatic channel by typing the 

following configure channel command: 

configure channel 2 device type ’sbt_tape’ parms 

’ENV=(NSR_DEBUG_FILE=/db/logs/backup.log)’ 

If backup optimization is enabled with the configure backup optimization on 

command, RMAN skips selected files during a backup, based on several criteria. The 

Oracle backup and recovery documentation provides more details on these criteria. 


! 

Backup copies 

! 

Introduction 

Note: 

- To force a backup that would otherwise be skipped due to backup optimization, use the force 

option in the backup command. 

- When RMAN skips a backup due to backup optimization, it does not produce an error 

message. However, RMAN does issue a warning message similar to the following: 

skipping archive log file... 

IMPORTANT 

When using Oracle backup optimization with NMO backups and restores, run the 

crosscheck command regularly to synchronize the Recovery Catalog and 

NetWorker indexes. This ensures that backups expired by the NetWorker server 

are also marked as expired in the Recovery Catalog and RMAN does not skip a 

backup when a referenced backup has already expired in NetWorker. 

The restore optimization function prevents RMAN from restoring a file if the original 

file is already in the correct location and contains the expected information. 

Note: To force a restore that would otherwise be skipped due to restore optimization, use the 

force option in the restore command. 

IMPORTANT 

If more than one RMAN channel is used for backup copies of an NMO backup, 

parameter values set with the send command or option are passed by RMAN to the 

first backup channel only. Due to this send command limitation, NMO does not 

support the use of RMAN backup copies commands during scheduled backups. 

NMO supports backup copies with manual backups only. 

Use the RMAN commands for backup copies only during manual backups when the 

parameters NSR_SERVER, NSR_DATA_VOLUME_POOL, 

NSR_DATA_VOLUME_POOL1, NSR_DATA_VOLUME_POOL2, and 

NSR_DATA_VOLUME_POOL3 are set with the parms option, not with the send 

command or option. 

The set duplex command is deprecated (no longer supported by Oracle, but still 

functional in some Oracle releases). The Oracle documentation provides more details. 

Despite the fact that RMAN provides different commands for duplexing backups, the 

rules for duplexing through NMO remain the same as with the set duplex command. 

Separate NetWorker pools must still be defined for each copy. “The set duplex 

command” on page 215 provides more information on the set duplex command and 

setting up NetWorker pools for each copy. 

Product features 27

Introduction 

28 

Manual backups can be duplexed (up to four copies) by using one of the following 

commands: 

◆ The configure...backup copies for device type sbt_tape to... command specifies 

persistent settings for duplexing backups through NMO. 

For example, specify persistent settings for duplex copies of datafiles and 

archived redo logs (respectively) in NMO backups with the following types of 

configure commands: 

configure datafile backup copies for device type ’sbt_tape’ to 2 

configure archivelog backup copies for device type ’sbt_tape’ to 2 

◆ The backup command with the copies option applies to objects within the 

backup command. The backup...copies setting takes precedence over the 

persistent settings in the configure...backup copies command. 

◆ The set backup copies command applies to all backup objects in the same run 

job. 

In the following examples, the parms option is used to configure the channel and set 

the required parameters. These sample scripts must be invoked manually with 

RMAN, for example, by using the following command: 

rman cmdfile script_name 

Example 3 Using the set backup copies command in the RMAN script 

The following RMAN script uses the set backup copies command to generate the 

backup copies. The parameters are set with the parms option, as required. The 

RMAN script must be invoked for a manual backup, not a scheduled backup: 

run { 

set backup copies 4; 

allocate channel ch1 parms ’ENV=(NSR_SERVER=server_name, 

NSR_DATA_VOLUME_POOL=nmo1, NSR_DATA_VOLUME_POOL1=nmo2, 

NSR_DATA_VOLUME_POOL2=nmo3, NSR_DATA_VOLUME_POOL3=nmo4)’; 

backup format '%d_%U' 

tag tag_name 

(tablespace 'SYSTEM' ); 

release channel ch1; 

} 

Example 4 Using automatic channels for backup copies 

The following configure commands are used to configure RMAN automatic 

channels. (The configure commands could also be included in the RMAN script.) The 

configure...backup copies command generates the backup copies. The parameters 

are set with the parms option, as required. The RMAN script must be invoked for a 

manual backup, not a scheduled backup: 

configure default device type to ’sbt_tape’; 

configure datafile backup copies for device type ’sbt_tape’ to 4; 


’ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmo1, 

NSR_DATA_VOLUME_POOL1=nmo2, NSR_DATA_VOLUME_POOL2=nmo3, 

NSR_DATA_VOLUME_POOL3=nmo4)’; 


Backup of backup sets 

Cluster and RAC backups and restores 

The RMAN script invoked for the manual backup is as follows: 

connect target sys/oracle@test; 

run { 

backup format '%d_%U' 

tag tag_name 

(tablespace 'SYSTEM'); 

} 

Introduction 

RMAN supports the backup of backup sets. If Oracle data has been backed up with 

device type disk, NMO can be used to back up these backup sets from disk to 

NetWorker volumes. 

For example, to back up all backup sets from disk to NetWorker volumes in a tape 

device, use the following command: 

backup device type sbt backupset all 

The backup set on disk can also be deleted with the delete input option in the backup 

device type sbt backupset... command. For example, to back up the backup sets that 

were created on disk more than a week ago and then remove the backup sets from 

disk, use the following command: 

backup device type sbt backupset completed before sysdate-7 delete 

input 

The NMO software supports backups and restores of cluster and Real Application 

Cluster (RAC) systems for high availability and parallelism. 

A cluster system typically includes multiple nodes connected by a shared SCSI bus to 

which common storage is attached. Cluster services such as disk services can be 

defined and assigned their own IP addresses and names (virtual hosts). The services 

and their associated storage can migrate for failover between the physical nodes in 

the cluster. 

After a cluster service is configured as a NetWorker client, NMO can be used with 

NetWorker server software to back up and restore an Oracle database associated with 

the service, independent of the actual node that provides the service. 

A RAC system enables multiple Oracle instances across multiples nodes to access the 

same Oracle database at the same time. Oracle RAC is based on a cluster software 

infrastructure that provides concurrent access to the same storage and the same set of 

datafiles from all nodes in the cluster. All the database files reside on cluster-aware 

shared disks. 

After RAC and the associated cluster system are properly configured, NMO enables 

Oracle backups on either a single node or several nodes of the RAC system. A parallel 

Oracle backup uses Oracle instances running in parallel on multiple nodes of the 

cluster. 

NMO software supports restores of the Oracle data to any physical node in the 

cluster, regardless of which physical node originally performed the backup. 

Chapter 6, “Cluster and RAC Systems,” provides more information on cluster and 

RAC systems and how to configure the systems for Oracle backup and restore 

operations that use the NMO software. 

Product features 29

Introduction 

30 

Configuration wizards 

NMO 5.0 software supports new backup and recovery configuration wizards that are 

integrated with the NetWorker Management Console (NMC). The configuration 

wizards used in NMO release 4.5 or earlier are replaced by the NMC-based wizards 

in NMO release 5.0. 

Configuration wizard plug-in components are installed with the NMO software on 

the NMO client host. NMC loads the NMO wizard plug-in at run time. You can run 

the NMO wizards from the NetWorker Console Administration window, which you 

can start on any supported host by using a web browser session and specifying the 

Console server URL. 


requirements for the support of the NMC-based configuration wizards. 

Main features of the wizards 

The configuration wizards can be used to configure the following for an NMO client: 

◆ Scheduled Oracle backups (either typical or customized). 

“Configuring a backup with the NMC wizard” on page 72 provides details on 

using the backup configuration wizard. 

◆ RMAN scripts for Oracle data restores to the original host. 

◆ RMAN scripts for Oracle database duplication to either a local or remote host. 

“Recovery configuration wizard” on page 118 provides details on the recovery 

configuration wizard. 

The configuration wizards support NetWorker servers and clients in a stand-alone or 

cluster environment. 

The new wizards provide improved security and ease of management for backup 

and recovery configurations, compared to the wizards from NMO release 4.5 or 

earlier. 

Features of the backup configuration wizard 

The backup configuration wizard can perform the following: 

◆ Configure a new NetWorker Client resource for an NMO backup. 

◆ Configure a new or use an existing NetWorker Group resource for the backup 

Client resource. 

◆ Configure new or use existing browse and retention policies for the backup Client 

resource. 

◆ Optionally save a copy of the configuration settings from the Client resource to a 

nsrnmo script or RMAN script. 

◆ Modify a backup configuration that was created with the NMC-based NMO 


◆ Modify a backup configuration that was created either with the wizard from 

NMO release 4.5 or earlier, or with the legacy method, but only after the 

configuration has been migrated according to “Migration of configurations for 

the wizard” on page 32. 


Introduction 

Note: NMO 5.0 still supports the legacy method of backup configuration whereby you 

manually create a nsrnmo script and RMAN script, set any required parameters in the 

NWORA resource file, and configure the NetWorker resources with NMC (without the 

wizard). “Configuring a backup with the NMC legacy method” on page 75 describes the 

legacy configuration method. 

“Configuring a backup with the NMC wizard” on page 72 provides information on 

using the wizard to create or modify a backup configuration. 

Features of the recovery configuration wizard 

“Features of the recovery configuration wizard” on page 119 provides information on 

the features of the recovery configuration wizard. 

Backup configuration storage with the wizard 

The backup configuration wizard stores the configuration information in a new 

hidden attribute named Backup Config in the NetWorker Client resource. Do not 

modify the new attribute manually. If you use the wizard to create a backup 

configuration, you must use the wizard to modify the configuration. 

In a backup configuration created with the wizard, the Client resource stores the 

parameters and RMAN commands (except for sensitive data, such as passwords) that 

would have been stored in the nsrnmo and RMAN scripts and NWORA resource file 

in NMO release 4.5 or earlier. 

Note: The backup configuration wizard stores sensitive data securely by using NetWorker 

lockbox services. 

The wizard does not automatically generate a nsrnmo script and RMAN script, but 

provides an option to save configuration settings to a nsrnmo script or RMAN script 

on disk. These scripts are meant for reference use only. 

When you run a backup that was configured through the wizard, the backup does not 

access any nsrnmo or RMAN script file that the wizard saved to disk. Instead, the 

backup accesses the configuration information that the wizard stored in the Client 

resource. 

The wizards do not store any database connection passwords in any RMAN scripts 

that are saved to disk. 

The backup configuration wizard also sets the following values in the Client 

resource: 

◆ Backup Command attribute is set to: 

nsrnmostart -C [-c virtual_client] 

◆ Save Set attribute is set to: 

RMAN:/_level[/] 

where: 

database_Net_service_name is the the name of the Oracle database to be 

backed up. 

level is the Oracle backup level (full, incr_differential, or incr_cumulative). 

name_of_first_tablespace_or_datafile is the name of the first tablespace or datafile 

in the backup list. This name is included in Save Set attribute only if a partial 

database (subset of the entire database) is selected for backup. 

Product features 31

Introduction 

Features not supported with the wizards 

The configuration wizards cannot perform the following: 

32 

◆ Configure backups or restores in a RAC environment. 

◆ Configure proxy backups or restores that require a PowerSnap Module. 

Proxy backups and restores must be configured without the wizard, as described 

in Chapter 7, “Proxy Backups and Restores.” 

◆ Configure two different database backups in the same Client resource. 

A separate Client resource must be created for each database to be backed up on 

the same client host. 

◆ Modify a backup configuration that was created either with the wizard from 

NMO 4.5 or earlier, or with the legacy method, unless the configuration has been 

migrated according to “Migration of configurations for the wizard” on page 32. 

Migration of configurations for the wizard 

The backup configuration wizard stores the scheduled backup configuration in the 

Client resource by using a configuration storage framework that is incompatible with 

the configurations created either through the wizard from NMO release 4.5 or earlier, 

or through a legacy method (without a wizard). 

The backup configuration wizard can modify only the following types of backup 

configurations: 

◆ Configurations created with the new wizard. 

◆ Configurations migrated to the configuration storage framework that is 

supported by the new wizard. 

If you have a backup configuration that was created with the wizard from NMO 

release 4.5 or earlier, or with a legacy configuration method, you must migrate the 

configuration before you can use the new wizard to modify it. The recommended 

migration method is to use the nsrnmoadmin command, as described in “Migrating 

a legacy configuration with the nsrnmoadmin command” on page 69. 

Note: Migration of a proxy backup configuration is not supported. “Requirements for using the 

nsrnmoadmin command for migration” on page 70 describes the requirements and limitations 

of migration with the nsrnmoadmin command. 

Migration converts legacy configuration files and resources (the nsrnmo script, 

RMAN script, NWORA resource file, and Client resource) to the configuration 

storage framework used by the new wizard. Migration with the nsrnmoadmin 

command does not create a new Client resource; the migration modifies an existing 

Client resource, such that you can then use the wizard to modify it. 

The migration process stores the following in a hidden attribute in the Client 

resource: 

◆ Environment variable settings extracted from the nsrnmo script. (Any scripting 

commands in the nsrnmo script are ignored.) 

◆ RMAN commands and options extracted from the RMAN script. 

◆ NSR_BUNDLING, NSR_INCR_EXPIRATION, and NSR_ORACLE_NLS_LANG 

settings extracted from the NWORA resource file. 


The migration process also sets the following values in the Client resource: 

◆ Backup Command attribute is set to: 

nsrnmostart -C [-c virtual_client] 

◆ Save Set attribute is set to: 

RMAN:database_Net_service_name 

Internationalization (I18N) and localization (L10N) 

I18N features 

Introduction 

The following sections describe internationalization (I18N) and localization (L10N) 

features that NMO release 5.0 supports in a non-English locale. 

NMO I18N is the capability of the NMO software to operate in a non-English 

environment or locale without itself generating non-ASCII data. After you set up 

NMO I18N as described in “Configuring I18N support” on page 67, NMO can 

process and display non-ASCII data that is passed to it by the operating system, 

NetWorker software, and Oracle software. The non-ASCII data can include text 

messages, dates, times, numbers, and so on. 

The EMC Information Protection Software Compatibility Guide on the Powerlink website 

provides details on the different languages supported and the operating system, 

Oracle Server, and NetWorker software requirements for NMO I18N. 

NMO I18N is supported for the following: 

◆ Regular (nonproxy) backups and restores 

◆ Proxy backups and restores with a supported PowerSnap Module release, as 

described in the NetWorker Module for Oracle release notes 

As a separate NMO feature, NMO localization (L10N) is the capability of NMO to 

itself generate non-ASCII data and print the data to the user interface. “L10N 

features” on page 35 provides more information on NMO L10N support. 

The term internalization is used differently in the NetWorker documentation (as 

opposed to this NMO documentation). NetWorker server and client documents refer 

to internationalization as the capability of the NetWorker software to both process 

non-ASCII data as input and generate non-ASCII data as output in a non-English 

locale. 

The extent of the NMO I18N support is dependent on the following: 

◆ I18N support that is provided by the operating system on the NMO client host. 

◆ I18N support that is provided by the NetWorker client and server software. 

◆ National Language Support (NLS) or globalization support that is provided by 

the Oracle software. 

For example, if NetWorker software does not support non-ASCII data in a specific 

NetWorker resource attribute (such as the group name in the Group resource), NMO 

cannot support non-ASCII data in that resource attribute. The EMC Information 

Protection Software Compatibility Guide and the NetWorker documentation include 

more information on the I18N support provided by NetWorker. 

Product features 33

Introduction 

34 

When NMO I18N support is set up as described in “Configuring I18N support” on 

page 67, NMO supports non-ASCII data in the following: 

◆ Pathnames of nsrnmo scripts 

◆ Pathnames of preprocessing and postprocessing scripts 

◆ Pathnames of RMAN scripts 

◆ Strings passed as command line options to the nsrnmo(.bat), 

nsrnmoadmin(.exe), nsrnmoinfo(.exe), and nsroraclecat(.exe) commands 

◆ Tablespace names and datafile paths 

◆ The format string of the RMAN backup command (unless the nsrnmoadmin -M 

or nsrnmoadmin -P command is used for migration of a legacy backup 

configuration on Windows) 

◆ The tag string of the RMAN backup command 

◆ Usernames in the connection strings to the target database and recovery catalog 

Note: Oracle does not recommend the use of non-ASCII text in the Oracle database 

usernames. Due to Oracle limitations, ASCII text must be used for the password of the 

target database. 

◆ Values of the following parameters: 

NSR_DEBUG_FILE 

NSR_ORACLECAT_LOG_FILE 

NSR_RMAN_ARGUMENTS 

NSR_SB_DEBUG_FILE 

Note: Support of non-ASCII values for ORACLE_SID and TNS_ADMIN is dependent on 

the Oracle software. Support of non-ASCII values for LD_LIBRARY_PATH, LIBPATH, 

and SHLIB_PATH is dependent on the operating system. 

◆ Additional values input in the NMO wizard, including the following: 

New or existing names of NetWorker Group resources 

Time data based on the time zone of the user 

◆ Information displayed on the following screens of the NMO wizard: 

Review and Edit the RMAN Script screen 

Review and Accept the Client Configuration screen 

◆ Content of output files created by the NMO wizard, such as nsrnmo scripts (for 

example, nsrnmo.bat or nsrnmo.sh file) and RMAN scripts 

Due to Oracle limitations, ASCII text must be input in the wizard for the following: 

◆ ORACLE_HOME path 

◆ Net service name of the Oracle target database, recovery catalog, or duplicate 

database 

The deduplication backup process, nsravtar, on the NMO client generates messages 

in English only. 


L10N features 

Introduction 

When NMO I18N support is set up, NMO generates debug messages in English only. 

NMO generates error messages in the nmo.messages.raw file in a 

language-independent binary form, readable by the nsr_render_log program only. 

The nmo.messages.raw file replaces the nmo.messages file used in previous NMO 

releases. (The log file does not contain Oracle Server or RMAN errors.) 

The NetWorker administration guide provides information on how to use the 

nsr_render_log program to read any language-independent binary file, such as 

nmo.messages.raw. 

The PowerSnap Module documentation provides details on the PowerSnap options 

that support non-ASCII values. 

“Configuring I18N support” on page 67 describes how to set up NMO I18N support. 

NMO L10N is the capability of the NMO software to generate non-ASCII character 

and numeric data based on the locale of the user, and output the data to the user 

interface. This capability requires the installation of the appropriate NMO language 

packs in non-English locales. The non-ASCII data generated by NMO is printed to the 

command line or to specific log files or wizard screens. 

◆ When NMO I18N is set up, NMO can process and display non-ASCII data that is 

passed to it by the operating system, NetWorker software, and Oracle software. 

◆ When NMO L10N is set up by also installing the required NMO language packs, 

NMO can also generate non-ASCII data, localized according to the user locale. The 

non-ASCII data can include text messages, dates, times, and numeric values 

displayed in the locale-dependent format. 


provides details on the different languages supported and the operating system, 

Oracle Server, and NetWorker software requirements for NMO L10N. 

NMO L10N is supported for the following: 

◆ Regular backups and restores 

◆ Proxy backups and restores with a supported PowerSnap Module release, as 

described in the NetWorker Module for Oracle release notes 

The extent of the NMO L10N support is limited by the following: 

◆ L10N support that is provided by the operating system on the NMO client host. 

◆ L10N support that is provided by the NetWorker client and server software. 

◆ National Language Support (NLS) or globalization support that is provided by 

the Oracle software. 

When NMO L10N support is set up as described in “Configure L10N support” on 

page 69, NMO generates messages in localized form and displays localized text in the 

wizard, except for the following: 

◆ Comments (lines starting with the symbol #) in the nwora.res file and RMAN 

scripts 

◆ All debug messages, including the messages in the configuration wizard debug 

log files and in the log files specified by NSR_DEBUG_FILE and 


◆ Output to the Oracle trace file 

“Configure L10N support” on page 69 describes how to set up NMO L10N support. 

Product features 35

Introduction 

36 

Oracle Data Guard support 

Parallelism 

NMO software supports Oracle Data Guard, an Oracle data availability and 

protection solution that involves the primary database and one or more standby 

databases over an IP network. As transactions occur in the primary database and 

redo data is written to the local redo logs, Data Guard automatically transfers this 

redo data to the standby sites and applies it to the standby databases, synchronizing 

them with the primary database. 

RMAN backups of datafiles, archived redo logs, and possibly other files can be 

offloaded to a physical standby database, and the backups used to recover the 

primary database or a standby database. RMAN and Data Guard documentation 

provides information on how to configure and back up a physical standby database, 

and use the backups to recover the primary or standby database. 

To configure NMO backups and restores in a Data Guard environment: 

1. Follow the instructions in Oracle documentation on how to set up the required 

RMAN configurations, for example, to use a Recovery Catalog and the 

DB_UNIQUE_NAME parameter. 

2. Install and configure the NMO and NetWorker client software on the primary 

database host, and on each physical standby database host involved in the 

backups and restores. 

3. Configure a Client resource on the NetWorker server for the primary database 

host and each physical standby database host involved in the backups and 

restores. In the Client resource of the primary database host, specify the hostname 

of the physical standby host in the Remote Access attribute if you set 

NSR_CLIENT to the primary database hostname in the following step. 

4. Create an RMAN script for the primary database and the standby database, 

setting the same NSR_CLIENT parameter value in both. The NSR_CLIENT value 

used for a backup should be the same as the NSR_CLIENT value used for the 

restore of that backup. Setting NSR_CLIENT to the primary hostname might be 

preferable. 

Parallelism is a feature that enables NMO backup or restore streams of Oracle data 

from several clients, or many Oracle data streams from one client, at the same time. 

Different types of configuration settings enable different types of parallelism during 

NMO operations: 

◆ The Parallelism attribute in the NetWorker Server resource specifies the 

maximum number of backup save streams that the NetWorker software allows to 

arrive in parallel at the server. 

◆ The Parallelism attribute (a hidden attribute) in the NetWorker Client resource 

specifies the maximum number of data streams that the Oracle Server sends in 

parallel to the NetWorker server or storage node during an NMO backup. 


Policy uniformity 

Restartable backups 

Introduction 

◆ For proxy operations, the PowerSnap parameter settings specify the maximum 

number of parallel save streams on the proxy client host. 

Note: The degree of proxy backup or restore parallelism is not controlled by the allocation 

of multiple channels in the RMAN script. Oracle uses only one of the allocated channels for 

the proxy backup or restore, unless specific backup options are used. 

◆ Configurations on a RAC system enable parallel Oracle backups and restores 

with the NMO software on multiple nodes of a cluster. Chapter 6, “Cluster and 

RAC Systems,” provides more details. 

If policy uniformity is enabled, NMO automatically enforces the uniformity of the 

browse and retention policies between all the dependent save sets in a scheduled 

backup cycle (whether or not save set bundling is enabled). When save set bundling 

is also enabled, all the save sets in a bundle receive the same browse and retention 

policies. 

After NMO performs an incremental scheduled backup, if the browse and retention 

policies of the save sets in the backup are longer than the policies of preceding 

dependent save sets in the same backup cycle, the NMO program nsrnmostart 

changes the policies of all save sets in the cycle to match the longest policy of the new 

incremental save sets. NMO modifies the policies recorded in the NetWorker media 

database. As a result, backups cannot expire and become recyclable before other 

dependent backups from the same backup cycle. 

The NMO software does not enforce policy uniformity for a manual backup, except 

when a subsequent scheduled backup is dependent on the manual backup, and then 

the policies of the manual backup are modified accordingly. 

Policy uniformity does not depend on whether save sets are stored on separate 

volumes. For example, if parts of a save set bundle are split onto separate volumes, all 

the save sets in the bundle still receive the same browse and retention policies. 

“Configure policy uniformity” on page 92 provides information on how to configure 

policy uniformity for NMO backups. 

RMAN can back up files that have not been backed up since a specified time. For 

example, to continue the backup of a database that was canceled 2 days ago, use the 

following command: 

backup device type sbt database not backed up since time ’sysdate-2’ 

RMAN compares the given time in this command with the completion time of the 

most recent backup of a datafile to determine if the datafile requires backup. The 

appropriate Oracle backup and recovery documentation provides more information. 

The following sections provide more information on how to cancel NMO backups: 

◆ “Cancel a manual backup” on page 107 

◆ “Cancel a scheduled backup” on page 111 

Product features 37

Introduction 

38 

Retention policies 

RMAN provides an Oracle retention policy for backups. An Oracle retention policy is 

based on the recovery window or redundancy; it is not based on a defined time 

period, such as a year. Oracle considers a backup obsolete when it is no longer 

required according to the Oracle retention policy setting. Oracle checks the retention 

policy of a backup when the report obsolete... or delete obsolete... command is run. 

NMO supports the Oracle retention policy with some restrictions, since the 

NetWorker server has its own browse and retention policies to specify how long data 

is available for recovery. NetWorker browse and retention policies are based on a 

user-defined time period. Since the Oracle retention policy is independent from that 

of the NetWorker server, and there is no mechanism to synchronize these policies, the 

NetWorker and Oracle policies could conflict. 

Example 5 Expiring a backup 

! 

A NetWorker server might expire an NMO backup that is not yet obsolete in RMAN, 

depending on the NetWorker browse and retention policies. Use of NMO cannot 

guarantee that the NetWorker server will not expire a backup volume until all the 

RMAN backups on that volume have been removed from the RMAN catalog. 

To avoid conflicts, perform either of the following: 

◆ Disable the Oracle retention policy (and then use only the NetWorker server 

policy) with the following command: 

configure retention policy to none 

If the Recovery Catalog is used, exempt a backup from the retention policy with 

one of the following commands: 

change backupset...keep until/forever... 

backup...keep until/forever... 

◆ (If you want to use the Oracle retention policy) Set the NetWorker browse and 

retention policies to be long enough that backups are kept on the backup volumes 

until the Oracle retention policy makes them obsolete. 

Set the NetWorker policies in the NetWorker Client resource for scheduled 

backups or through the NSR_SAVESET_BROWSE and 

NSR_SAVESET_RETENTION parameters. “Configure a Client resource with 

NMC” on page 87 provides more information on how to set NetWorker policies 

for NMO backups. 

IMPORTANT 

Run the crosscheck command on the NMO backups before running report 

obsolete or delete obsolete backups of the device type sbt_tape. This ensures that 

backups expired by the NetWorker server are flagged as expired in the RMAN 

catalog. As a result, RMAN can correctly identify which backups are not needed 

according to the Oracle retention policy. 

For example: 

1. Run the following command to synchronize the RMAN Catalog and 

NetWorker indexes: 

crosscheck backup; 

2. Run the following command to delete all obsolete backups defined by the 

current Oracle retention policy: 

delete obsolete; 


Save set bundling 

Introduction 

If NMO save set bundling is configured, NMO automatically creates a save set 

bundle for each scheduled backup cycle of an Oracle database object, by grouping all 

the dependent save sets from the same backup cycle into the save set bundle. 

A “backup cycle” includes a full backup of the database object and all subsequent 

incremental backups that are dependent on the full backup. 

Note: NMO does not support save set bundling for proxy backups. NMO performs save set 

bundling for regular Oracle backups only. 

During staging operations with NetWorker server release 7.4 and later, if the staging 

criteria determine that a particular NMO save set should be staged (migrated) and 

the save set is part of a save set bundle, the NetWorker server stages the entire save 

set bundle. If the nsrstage command is used to manually stage one or more save sets 

from a save set bundle, all the save sets in the bundle are staged. 

Note: After a staging operation during which all the save sets in a bundle are staged, the 

resulting available space on the staging device might exceed the lower-water mark specified in 

the staging policy. 

The NetWorker administration guide provides details on how to work with staging 

policies and perform automatic and manual staging operations through the 

NetWorker server. 

“NMO scheduled backups and save set bundling” on page 39 describes NMO save 

set bundling during regular scheduled backups, and how to configure save set 

bundling. 

If policy uniformity is configured, NMO automatically enforces the uniformity of 

browse and retention policies for all the dependent save sets of the same scheduled 

backup cycle or same save set bundle, which ensures that incremental backups do not 

persist after the backups they depend on have expired. 

“Other Oracle features” on page 44 provides more information on how policy 

uniformity relates to save set bundling. Save set bundling and policy uniformity can 

be enabled and disabled independently. 

NMO scheduled backups and save set bundling 

Use the information in the following sections to plan a save set bundling strategy and 

enable save set bundling for NMO scheduled backups. Both are performed to 

prepare for staging operations with NetWorker server 7.4 and later. 

“Configure save set bundling” on page 91 provides information on how to configure 

save set bundling for NMO scheduled backups. 

RMAN backup levels and dependencies 

An RMAN backup can be either full or incremental: 

◆ A full (or stand-alone full) backup includes every used block of the database 

objects listed in the RMAN backup script (unused blocks might be skipped). This 

type of backup is created when you do not specify a backup level with the RMAN 

backup command. A full backup cannot be the parent of a subsequent 

incremental backup. (Incremental backups cannot be dependent on a stand-alone 

full backup.) 

Product features 39

Introduction 

40 

◆ An incremental backup is either level 0 or level 1. Incremental backups are created 

when you specify either incremental level=0 or incremental level=1 with the 

RMAN backup command. Incremental backups are dependent on preceding 

incremental backups in the same scheduled backup cycle: 

A level 0 incremental is physically identical to a full backup, but is recorded as 

incremental in the RMAN repository. (A level 0 backup may also be referred 

to as "full" in other sections of this guide.) 

A level 1 incremental can be either of the following: 

– A differential backup, which contains only the data blocks changed since the 

most recent incremental backup, whether level 0 or 1. The differential 

backup is dependent on the preceding level 0 or 1 backup. Incremental 

backups are differential by default. 

– A cumulative backup, which contains only the data blocks changed since 

the most recent level 0 incremental backup. The cumulative backup is 

dependent on the preceding level 0 backup. 

RMAN backup sets and NMO save sets 

NMO save set bundling is performed at the backup set level. 

An NMO backup (either full or incremental) generates one or more NetWorker save 

sets. The backup is also composed of one or more RMAN backup sets, with each 

backup set containing one or more backup pieces. A backup piece contains data 

blocks from one or more Oracle database files. Each NMO save set corresponds to 

one backup piece. 

Note: Backup set and backup piece are Oracle terms. Save set is a NetWorker term. 

◆ A control file, parameter file (or spfile), archived log, or datafile cannot span more 

than one backup set. 

◆ A control file or parameter file backup cannot span more than one backup piece. 

◆ An archived log or datafile backup can span more than one backup piece in a 

backup set. 

It is possible to determine which backup set contains a specific datafile (by querying 

the v$ views in the Oracle database), but not which backup pieces within the backup 

set contain the datafile. 

An Oracle backup set contains either of the following: 

◆ The backup of a control file, parameter file, or archived log, which is always 

performed as a full backup. 

Note: The backup of a control file, parameter file, or archived log is always placed in its 

own save set bundle. 

◆ Full or incremental backups of one or more Oracle datafiles. 

A backup set can include both full and incremental backups. For example, a 

backup set might contain incremental backups of datafiles 1 and 2 and a full 

backup of datafile 3. 

Creating NMO save set bundles 

If save set bundling is enabled, all dependent save sets from the same backup cycle are 

included in the same save set bundle. Save sets are dependent when two or more 

save sets are required to restore a database object. (All the NMO save sets from a 

backup set are placed into the same save set bundle.) 


Introduction 

At the end of a full or level 0 scheduled backup, the NMO software creates a new save 

set bundle for the backup set from the backup. If subsequent incremental backups are 

performed that are dependent on the level 0 backup, NMO adds their save sets to the 

save set bundle from the level 0 backup. 

A separate save set bundle is created for each scheduled backup cycle of a particular 

Oracle database object, where a backup cycle consists of a full or level 0 backup of the 

object and all the subsequent incremental backups that are dependent on the level 0 

backup. 

A save set bundle contains one of the following: 

◆ The save sets from a stand-alone full backup, with no other dependent save sets. 

For example, the save sets from the backup of a control file, parameter file, or 

archived log (always performed as a full backup) are placed in their own save set 

bundle. 

◆ The save sets from a level 0 backup of an Oracle object and all subsequent 

incremental backups in the same backup cycle of the object. 

When an incremental backup occurs and NMO cannot find a preceding dependent 

backup in any existing bundles, NMO creates a new save set bundle for the 

incremental backup. 

Save sets from a manual backup are placed into a save set bundle only if a subsequent 

scheduled backup is dependent on them. The manual backup save sets are placed in 

the save set bundle at the same time as the dependent save sets from the scheduled 

backup. 

For save set bundling purposes, you can simultaneously run multiple backup cycles 

that back up different objects from the same database, as long as different files are 

backed up by the different cycles. For example, one cycle can back up datafiles 1 and 

2, while another cycle backs up datafiles 3, 4, and 5 from the same database. The 

cycles can also be of different lengths. For example, one cycle can last a week, while 

another concurrent cycle lasts several weeks. 

Note: The backup copies feature and save set bundling of backup copies are not supported 

with NMO scheduled backups. Backup copies created during a manual backup are 

independent of each other, and each copy goes to a different NetWorker volume. 

If an error occurs during save set bundling, the bundling operation fails but the 

scheduled backup can finish successfully. Information about the bundling failure is 

printed to the savegrp output and to the debug file specified by NSR_DEBUG_FILE. 

How the nsrnmostart program performs save set bundling 

The NMO program nsrnmostart automatically places save sets into a save set bundle 

at the end of a scheduled backup, before the nwora.res file is backed up. “Configure 

save set bundling” on page 91 provides information on the nwora.res file. 

To perform save set bundling, the nsrnmostart program connects to the Oracle 

database by attempting to use the login and password from the RMAN script. If a 

login and password are not available from the script, the program uses the 

ORACLE_SID value from the nsrnmo script to search the nwora.res file for the 

NSR_ORACLE_CONNECT_FILE parameter, and uses the connection strings from 

the specified connection file. “Configure save set bundling” on page 91 provides 

more details on the requirements of save set bundling. 

Product features 41

Introduction 

42 

After connecting to the Oracle database, the nsrnmostart program obtains all the 

required information about the backups from the Oracle control file (by querying the 

v$backup_set, v$backup_piece, and v$backup_datafile tables). The control file can 

store only a limited number of backup entries. When the maximum number of entries 

is exceeded, old entries in the control file are overwritten by new ones. Save set 

bundling is successful only if information in the control file about backed-up save 

sets has not been overwritten. The Oracle documentation provides information about 

proper maintenance of the control file and how much backup information the control 

file can store. 

The nsrnmostart program creates a save set bundle for each full or incremental level 

0 backup. The program adds the save sets from subsequent incremental backups to 

the bundles of the full or level 0 backups they are dependent on. 

The name that the nsrnmostart program assigns to a save set bundle is a number 

corresponding to the save time of the oldest save set in the bundle. NMO provides the 

NetWorker server with the list of save sets contained in each save set bundle. 

After a scheduled backup, the NetWorker server stores the save set bundle name and 

the list of save sets it contains in the media database. You can view the bundle 

information by using the mminfo command, as described in “Save set bundling 

information in the media database” on page 43. 

Example 6 Save set bundling for a one-week scheduled backup cycle of a tablespace 

A one-week scheduled backup cycle of a tablespace includes a level 0 backup of the 

tablespace on Sunday and a level 1 backup every other day of the week. The save set 

bundle for the cycle is created during the Sunday backup, and save sets from each 

level 1 backup are added into the same bundle. The complete bundle contains the 

save sets from the seven daily backups of the tablespace. A new bundle is created for 

the next backup cycle during the following week. 

NetWorker staging restrictions 

When planning the strategy for NMO save set bundling, consider the following 

NetWorker staging restrictions: 

◆ NetWorker cannot simultaneously stage all the save sets from a save set bundle if 

some of the save sets were backed up to separate volumes. NetWorker 

simultaneously stages save sets only if they are located on the same staging 

volume. Example 8 on page 43 provides more information. 

To ensure the proper staging of all the save sets from a save set bundle, do not 

split the backup between different staging volumes. If required, split the backup 

into different backup cycles, with each cycle going to a separate volume. 

◆ NetWorker staging policies must not cause the save sets of an NMO backup cycle 

to be staged before the cycle is complete. For example, if a one-week NMO cycle 

starts on Sunday, the staging policy must not cause the partially complete save set 

bundle to be staged before the final backup of the cycle occurs on Saturday. 

To prevent a staging operation from splitting an NMO backup cycle, adjust the 

NetWorker staging policy accordingly. For example, adjust the policy so that 

older save sets are staged before new ones, or adjust the high-water and 

low-water marks. 

The NetWorker administration guide provides details on how to work with staging 

policies and perform automatic and manual staging operations through the 



Introduction 

Save set bundling information in the media database 

The NMO software stores information about each save set bundle in the NetWorker 

media database. “NetWorker software” on page 47 provides more information about 

the media database. 

Query the media database by using the NetWorker command, mminfo, with the 

appropriate options: 

◆ The mminfo -r command can display the name of the bundle associated with a 

save set. For example, the following command displays a list of all save sets and 

their bundles: 

mminfo -a -r "ssid,ssbundle" 

◆ The mminfo -q command can display all the save sets in a specific bundle. For 

example, the following command displays all the save sets in the bundle named 

12983479182: 

mminfo -a -q "ssbundle=12983479182" 

The NetWorker command reference guide and the UNIX man pages provide more 

information on the mminfo command and its available options. 

Examples of save set bundles and staging 

The following examples illustrate different aspects of save set bundling, and how 

splitting the save set bundles across volumes can affect staging operations. 

Example 7 Save set bundle join 

Two save set bundles are created by separate level 0 backups of files A and B. Then a 

new backup set is created by a level 1 backup of both files A and B. Since the new 

backup set is dependent on both of the preceding level 0 backups, NMO combines all 

three backups into the same save set bundle. 

If the original file A backup has the oldest backup time, NMO places the new backup 

set (from the level 1 backup) into the save set bundle of the (level 0) file A backup. 

NMO then moves the original (level 0) file B backup into the save set bundle with the 

other two backups. This method of combining existing bundles into a new save set 

bundle is known as a “save set bundle join.” 

Example 8 Splitting a save set bundle across volumes 

In both of the following cases, a save set bundle is split across multiple volumes. The 

parts of the save set bundle on different volumes must be staged separately by the 

NetWorker server: 

◆ A backup uses multiple channels so the backup set spans multiple volumes. All 

the save sets belong to the same backup set and save set bundle, but parts of the 

bundle are stored on different volumes. During staging, only the save sets on the 

same volume can be staged together. 

◆ A level 0 backup of file A is performed to volume A. An incremental backup of 

file A is then performed to volume B. Although both backups are recorded as 

belonging to the same save set bundle, the save set bundle is split across volumes. 

During staging, only the save sets on the same volume can be staged together. 

Product features 43

Introduction 

44 

Other Oracle features 

Example 9 Using save set consolidation to re-unite a save set bundle 

A level 0 backup of file A is performed to volume A. A level 1 backup of file A is then 

performed to volume B. Save set consolidation is used to merge the save sets from 

these two backups onto the same volume. Bundle names are preserved when save sets 

are moved from volume to volume by save set consolidation. The consolidated 

backup is staged as a single save set bundle. 

This section describes supported features of the Oracle Server software. The NMO 

software supports the Oracle releases on specific platforms, as outlined in the EMC 

Information Protection Software Compatibility Guide on the Powerlink website. 

The NetWorker Module for Oracle release notes describes known NMO limitations 

related to specific Oracle releases. 

Examples of the Oracle RMAN features that NMO supports are as follows: 

◆ Fast incremental backups that use change tracking files. 

◆ Proxy backups and restores of archived redo logs. 

Note: Oracle does not support proxy backups of datafiles or archived redo logs that reside 

on Oracle Automated Storage. Oracle Automated Storage is also known by the term Oracle 

Automated Storage Management (ASM). 

◆ Channel backup failover and backup piece restore failover. 

◆ Management of backup duration and throttling. 

◆ Backups and restores of data residing on Oracle Automated Storage. 

◆ Flash recovery area and flashback database. 

The Oracle Recovery Manager documentation provides a complete list of the RMAN 

features. 

When using Oracle RMAN features with NMO, consider the following: 

◆ A flash recovery area stores and manages files related to the recovery of a 

particular database. 

To back up RMAN disk backups, control file autobackups, and archived redo 

logs from the flash recovery area to NetWorker volumes: 

a. Allocate or configure one or more channels with the sbt_tape device type. 

b. Back up the files with one of the following RMAN commands: 

backup recovery area 

backup recovery files 

Note: Whether or not a flash recovery area is enabled, the backup recovery files 

command can be used to perform the backup. 


For example, the following sequence of RMAN commands can be used to 

configure an automatic channel for NMO and back up the files from the flash 

recovery area: 

configure default device type to ’sbt_tape’; 

configure channel device type ’sbt_tape’ send 

’NSR_ENV=(NSR_SERVER=server1)’; 

backup recovery files; 

Introduction 

◆ If multiple channels are used for an RMAN backup command and one of the 

channels fails, Oracle fails over to another channel to continue the backup job. 

For example, if two channels are configured with different NetWorker volume 

pools and one of the channels fails over to the other channel during a backup, the 

entire backup goes to the volumes in the pool of that remaining channel. 

◆ Before using the backup command with the duration...minimize load option, 

consider: 

The minimize load option might impact the tape streaming since the transfer 

rate of data sent by RMAN might be slow with this option, depending on the 

duration value. 

Note: This is not a concern if you use the NetWorker backup to disk feature. 

The minimize load option might cause an NMO scheduled backup to be 

timed out if RMAN does not send data to the NetWorker Module within the 

time frame specified in the Inactivity Timeout field of the corresponding 

NetWorker Group resource. 

◆ Starting with release 10.1, RMAN does not print database connection strings 

(user/password@Netservicename) to the session output. As a result, the parameter 

NSR_RMAN_OUTPUT is not required (to suppress the connection strings in the 

log files) for an RMAN scheduled backup. 

Oracle11g specific features 

NMO 5.0 supports the following major Oracle11g features: 

◆ Data Recovery Advisor 

◆ Improved integration with Data Guard 

◆ Archival backup through the RMAN backup...keep command 

◆ Improved archived redo log management through the configure archivelog 

deletion policy command 

◆ Recovery catalog enhancements, such as virtual private catalogs and the import 

and merging of recovery catalogs 

◆ Multisection or intrafile backup and validation, with the backup of a single large 

datafile over multiple channels 

◆ Improved block media recovery, with the blockrecover command being replaced 

by the recover...block command 

◆ Configurable backup compression through the configure compression algorithm 

to command 

◆ Block change tracking support in Data Guard 

Product features 45

Introduction 

46 

◆ Backup of read-only transportable tablespaces 

◆ Oracle Enterprise Manager enhancements, with new interfaces for the Data 

Recovery Advisor 

◆ Oracle Globalization Support enhancements 

To enable NMO support of two of the Oracle11g features, Data Recovery Advisor 

and archival backup, you must perform the additional configuration procedures 

described in “Data Recovery Advisor” on page 46 and “Archival backup feature” on 

page 46. 

The appropriate Oracle documentation provides more information on the Oracle11g 

features. 

Data Recovery Advisor 

The Oracle Data Recovery Advisor is a new tool in Oracle11g. Integrated with RMAN 

and Oracle Enterprise Manager (OEM), the tool enables a DBA to diagnose and repair 

database failures. 

Before you can use the Data Recovery Advisor to invoke an RMAN restore script that 

involves NMO to repair a database failure, automatic channels must be configured to 

specify at least the mandatory parameters NSR_SERVER and NSR_CLIENT. 

Note: The NSR_SERVER and NSR_CLIENT parameters are the minimum parameters required 

to perform a restore. Other NMO parameters may also be specified for the automatic channel 

configuration. 

To enable the use of Data Recovery Advisor with Oracle11g and NMO: 

◆ If automatic channels have not been configured for NMO backups, use the 

following commands to ensure the basic automatic channel configuration: 


’ENV=(NSR_SERVER=NetWorker_server_name, 

NSR_CLIENT=NMO_client_name)’; 

configure channel device type 'sbt_tape' parallelism 

number_of_restore_channels; 

◆ If automatic channels are already configured for NMO backups, no additional 

configuration steps are required. 

Archival backup feature 

With Oracle11g, the RMAN backup...keep forever command enables the creation of 

an archival backup that is exempt from Oracle backup retention policies (but not 

automatically exempt from NetWorker retention policies). The archival backup is 

all-inclusive because every file required to restore a database is backed up to a single 

disk or tape location. 

To enable the use of the RMAN backup...keep forever command with NMO: 

1. Configure an Archive type Pool resource through the NetWorker server. 

2. Specify that the backup data must go to the Archive pool by performing one of 

the following: 

Set the pool selection criteria accordingly on the NetWorker server. 

Set the NSR_DATA_VOLUME_POOL parameter in the RMAN backup script. 


Introduction 

3. Set the parameter value NSR_SAVESET_RETENTION=forever through the send 

command in the RMAN backup script. 

Note: Ensure that the NSR_RETENTION_DISABLED option is not set in the RMAN 

backup script used with NMO. 

The NetWorker administration guide provides more information on how to 

configure resources and specify pool selection criteria through the NetWorker server. 

Software used in the NMO environment 

NetWorker software 

The following sections describe the different software components involved in the 

NMO environment. 

The NetWorker software comprises a high-capacity, easy-to-use data storage 

management solution that protects and helps manage data across an entire network. 

The NetWorker software simplifies the storage management process and reduces the 

administrative burden by automating and centralizing data storage operations. 

The NetWorker software enables a user to: 

◆ Perform automated backups during nonpeak hours 

◆ Administer, configure, monitor, and control NetWorker functions from any 

computer on a network 

◆ Centralize and automate data management operations 

◆ Increase backup performance by simultaneously sending more than one save 

stream to a single device 

◆ Optimize performance by using parallel save streams to multiple backup devices 

or storage nodes 

NetWorker client/server technology uses the network remote procedure call (RPC) 

protocol to back up data. The NetWorker client software consists of client-side 

services and user interface programs. 

The NetWorker server software consists of several server-side services and programs 

that: 

◆ Oversee backup and restore processes 

◆ Maintain client configuration files 

◆ Maintain an online client file index and online media database, which together 

comprise the online indexes on the NetWorker server 

During a backup, the NetWorker server makes an entry in the online client file index 

and records the location of the data in the online media database. These entries 

provide recovery information required for all backed-up data. 

Software used in the NMO environment 47

Introduction 

48 

NMO software 

After a scheduled backup, the NetWorker server sends a record of the bootstrap file to 

the default printer. This is a printed record of the dates, locations, and save set ID 

numbers for the server’s online indexes that are required for restoring data. Keep the 

bootstrap printout on file as a quick reference in the event of a disaster, such as a disk 

crash or server failure: 

◆ The NetWorker installation guide provides information on how to install 

NetWorker software. 

◆ The NetWorker administration guide provides information on how to configure 

and use NetWorker software. 

NetWorker Module for Oracle (NMO) software is an add-on module for the 

NetWorker server that enables you to perform the following tasks: 

◆ Manual Oracle backups 

◆ Scheduled Oracle backups 

◆ Restores of Oracle backup data 

NetWorker PowerSnap Module software 

◆ Automated media management 

NMO software provides the following features: 

◆ Capability to integrate database and file system backups, to relieve the burden of 

backup from the database administrator while allowing the administrator to 

retain control of the restore process. 

◆ Automatic database storage management through automated scheduling, 

autochanger support, electronic tape labeling, and tracking. 

◆ Support for backup to a centralized backup server. 

◆ High performance through support for multiple, concurrent high-speed devices 

such as digital linear tape (DLT) drives. 

Together with the NetWorker server, NMO augments the backup and recovery 

system provided by the Oracle Server and provides a storage management solution 

that addresses the need for cross-platform support of enterprise applications. 

Proxy backups and restores of Oracle database files residing on specific types of 

primary storage devices are supported. These proxy operations are performed by 

NMO, with the NetWorker server and the appropriate NetWorker PowerSnap 

Module software. 

The NetWorker Module for Oracle installation guide provides information on how to 

install the NMO software. 

The NetWorker PowerSnap Module software works with the NetWorker server and 

NMO software to perform RMAN proxy backups and restores of Oracle data that 

resides on specific types of primary storage. 

Each type of primary storage requires a different type of PowerSnap Module. A 

proxy backup performed with the PowerSnap Module involves taking a snapshot of 

the Oracle data. The snapshot resides on the primary storage to ensure high 

availability of the database and eliminate downtime latency on the Oracle Server 

host. 


Oracle backup and recovery system 

Introduction 

During a proxy backup, the Oracle data can optionally be copied from the snapshot to 

a NetWorker storage device. The data is copied to the secondary storage by either the 

Oracle Server host or a proxy client host that is separate from the Oracle Server host. 

The following sources provide information on how to configure and run proxy 

backups and restores with the NMO and PowerSnap Module software: 

◆ Chapter 7, “Proxy Backups and Restores” 

◆ NetWorker PowerSnap Module documentation 


provides a complete list of supported PowerSnap Modules. 

This section describes the system used for regular Oracle backup and recovery. 

The NMO and NetWorker server and client software function with the standard 

Oracle backup and recovery system to produce an efficient Oracle data storage 

management system. The implementation of an Oracle backup and recovery strategy 

requires a knowledge of how the NetWorker software works together with the Oracle 

components. 

The regular Oracle backup and recovery system consists of the following: 

◆ Oracle Server 

◆ Oracle Recovery Manager (RMAN) 

◆ Recovery Catalog (optional) 

◆ Backup Management Tools for Oracle Enterprise Manager (optional) 

The NetWorker software consists of the following components: 

◆ NetWorker server 

◆ NetWorker client 

◆ NetWorker Module for Oracle 

Figure 1 on page 50 illustrates the architecture of the regular Oracle backup and 

recovery system, and shows the functional relationship between the NetWorker and 

Oracle software components. The NetWorker Module for Oracle media management 

library (MML) is integrated with the Oracle Server during the NMO installation on 

the Oracle Server host. The NetWorker Management Console program (used to 

configure the NetWorker resources) and the Oracle Enterprise Manager (OEM) 

Backup Manager can be optionally located on a separate platform, referred to as the 

GUI console. 

Software used in the NMO environment 49

Introduction 

50 

Figure 1 Regular Oracle backup and recovery system 

Oracle Recovery Manager 

During the Oracle backup and restore operations, NMO acts as an intermediary 

between the NetWorker server and Oracle Recovery Manager (RMAN). 

RMAN is the main Oracle utility for backing up, restoring, and recovering Oracle 

datafiles, control files, and archived redo log files. It stores information about its 

operations in the control file of the backed-up database (target database) and, 

optionally, in the Recovery Catalog on the Oracle Server host. 

RMAN provides the following features: 

◆ Online and offline Oracle database backups 

◆ High performance through parallel backups and restores 

◆ An intelligent interface to Oracle databases 

◆ Well-defined backup strategies 

◆ Checks for corrupt blocks during backups and restores 

◆ Block-level incremental backups and restores 

The Oracle Recovery Manager documentation provides more information on RMAN. 

EMC NetWorker Module for Oracle Release 5.0 Administration Guide 

GUI console Oracle Server system 

NetWorker 

server 

OEM 

Backup 

Manager 


Management Console 

RMAN 

Recovery 

Catalog 


client 

Oracle 

database files 


Server 


Module 

for Oracle 

MML 

Storage 

medium 


server 

GEN-000170

Introduction 

Oracle Recovery Catalog 

The Recovery Catalog is a collection of Oracle database tables that contain structural 

information about Oracle database backups and restores. The collection includes 

information about the following types of objects: 

NMO components 

◆ Backup sets and backup pieces 

◆ Image copies 

◆ Proxy copies 

◆ Archived redo logs 

◆ Target database schema 

◆ Stored scripts (user-created sequences of RMAN commands) 

The Recovery Catalog is maintained by the RMAN utility. This utility uses the 

catalog information or the database control file to determine how to perform 

requested backup and restore operations. Store the Recovery Catalog in the dedicated 

Recovery Catalog database. 

The Oracle Recovery Manager documentation provides more information on the 

Recovery Catalog, including the implications of not using it for backups and restores. 

Table 1 on page 51 lists the components that are installed on the NMO client host 

during the NMO software installation. Unless specified otherwise, the files are 

located in the same directory as the NetWorker client software. 

Table 1 NMO components (page 1 of 2) 

Name on UNIX Name on Windows Description 

fdiff.jar 

nwora.jar 

nwora_res.jar 

fdiff.jar 

nwora.jar 

nwora_res.jar 

Plug-in jar files for the NMO backup and recovery configuration wizards. 

libcommonssl.7.5.build#.so In a subdirectory under /usr/lib/nsr/nmo or /opt/networker/lib/nmo on UNIX only. An NMO 

library that is required for communication with NetWorker. 

libnwora.xx In /usr/lib on UNIX only. The main NMO library (known as Media Management Library in 

Oracle documentation) that is loaded by the Oracle backup or restore process. 

nsrnmo nsrnmo.bat The nsrnmo script that contains parameter settings for a particular scheduled backup. The 

script is only used for a scheduled backup that has been configured through NMC (the legacy 

configuration method without the wizard). 

nsrnmo.sh In /etc on UNIX only. A sample template for the nsrnmo script. You should copy and customize 

this template, and save the original file in /etc. 

nsrnmoadmin nsrnmoadmin.exe The program that is used either to create resource settings in the NWORA resource file, or to 

migrate legacy backup configurations to the new format supported by the configuration wizard. 

nsrnmodrpostcmd nsrnmodrpostcmd.exe A sample postcommand script that can be customized to back up specific files at the end of a 

scheduled backup, in preparation for disaster recovery. 

nsrnmoinfo nsrnmoinfo.exe The program that determines the NetWorker volumes required to restore specified Oracle 

backup pieces from NMO backups. 

nsrnmoprobe nsrnmoprobe.exe The program that probes for the number of generated Oracle logs as a condition that triggers 

probe-based backups. 

NMO components 51

Introduction 

52 

Table 1 NMO components (page 2 of 2) 

Name on UNIX Name on Windows Description 

nsrnmostart nsrnmostart.exe The program that invokes a scheduled backup on the Oracle Server, launching RMAN by 

passing arguments to the Oracle utility. The program optionally runs precommand and 

postcommand scripts. 

nsroraclecat nsroraclecat.exe Not available on Linux Itanium, Solaris AMD64/EM64T, or Windows Itanium (platforms that do 

not support proxy backups). The program that is used to remove RMAN catalog entries during 

automatic catalog synchronization for proxy backups. 

nsrorara nsrorara.exe The program that performs operations on behalf of the NMO configuration wizard on the local 

or remote NMO host. 

nsrsbtcn.exe 

orasbt.dll 

NMO backup and restore processes 

This section describes the processes involved in regular backups and restores. 

To provide storage management services for Oracle Server data, NMO implements 

the media management interface, also known as the Oracle System Backup to Tape 

(SBT). This interface comprises a media management library (MML) that is integrated 

with the Oracle Server during the NMO installation on the Oracle Server host. 

Oracle loads the NMO MML at run time, and the Oracle Server backup sessions call 

the NMO MML software routines to back up and restore Oracle data to and from the 

media controlled by the NetWorker server. 

A regular Oracle backup can be performed in either of two ways: 

◆ By issuing the appropriate commands through the RMAN command line 

interface. 

◆ By using the Oracle Enterprise Manager Backup Management Tools, which 

include an optional graphical user interface to the RMAN utility. 

RMAN establishes connections with the target database. Each RMAN channel starts 

an Oracle Server backup session that performs the backup. During the backup, the 

following occurs: 

1. The Oracle Server backup sessions read the datafile, control file, or archived redo 

log being backed up, and then write it to the NetWorker server through the MML. 

2. The NetWorker server stores the Oracle data to the appropriate backup storage 

device. 

At the end of the Oracle backup, the NetWorker server updates the online client and 

media indexes with information about the backup media used and the Oracle data it 

contains. 


On Windows only. The orasbt.dll file is the main NMO library (known as Media Management 

Library in Oracle documentation) that is loaded by the Oracle backup or restore thread, and it 

uses nsrsbtcn.exe to perform any corresponding NetWorker operations.

Regular scheduled backup processes 

Note: “Deduplication backup processes” on page 55 provides information specifically for a 

deduplication backup. 

Introduction 

A scheduled NMO backup is a backup of Oracle data initiated by the NetWorker 

server. 

A regular scheduled backup includes the following interactions: 

1. At the scheduled backup start time, the main NetWorker service, nsrd, starts the 

configured group’s backup by invoking the savegrp program. 

2. The savegrp program requests that the NetWorker client-side service, nsrexecd, 

run the savefs program (mainly used for file system backups; it has no usage for 

Oracle backups). 

3. The savefs program sends back information to the savegrp program. 

4. The savegrp program contacts the nsrexecd service to start the backup. 

5. For each client in the backup group and each of the client’s save sets, the 

following sequence of events occurs: 

a. The nsrexecd service starts a specific process, depending on how the backup 

was configured: 

– If the backup was configured through the legacy method (without the 

wizard), nsexecd starts the nsrnmo script, which then sets the required 

parameters and invokes the NMO program, nsrnmostart. 

– If the backup was configured through the new configuration wizard, 

nsexecd starts the nsrnmostart program directly. 

b. The nsrnmostart program starts the RMAN utility to run the required RMAN 

backup script. 

c. From this point on, the scheduled Oracle backup sessions follow the same 

steps as described in “Regular manual backup processes” on page 54. 

Note: At the end of a scheduled Oracle backup, the savegrp program also automatically backs 

up the NetWorker server bootstrap and the Oracle client file indexes. The bootstrap and client 

indexes are not automatically backed up at the end of a manual NMO backup. 

Figure 2 on page 54 shows how the Oracle Server, NetWorker server, and NMO 

processes interact during a regular scheduled NMO backup that was configured 

through the legacy method (without the wizard). 

NMO backup and restore processes 53

Introduction 

54 

In a scheduled backup configured through the wizard, the nsrnmo process is 

removed from the picture, and the nsrexecd and nsrnmostart processes interact 

directly with each other. 

savefs 

Oracle Server 

(NetWorker client) 

Figure 2 Regular scheduled NMO backup 

Regular manual backup processes 

Note: “Deduplication backup processes” on page 55 provides information specifically for a 


A manual NMO backup is a user-initiated backup through an Oracle backup utility, 

RMAN or Oracle Enterprise Manager. NMO considers a backup scheduled through 

Oracle Enterprise Manager to be a manual backup. 

When the RMAN utility is invoked for a backup, Oracle Server backup sessions call 

the NMO media management library (MML) software routines to initiate the backup. 

A manual NMO backup includes the following interactions: 

1. The Oracle Server backup session that loads the NMO MML (one such backup 

session for each allocated channel) contacts the nsrexecd service to obtain the 

NetWorker client information. 

2. The Oracle Server backup sessions contact the main NetWorker service, nsrd, to 

obtain the required authorization and the identifier of the nsrmmd process that 

manages the requested backup device. 


NetWorker server Storage 

medium 

Backup pieces Client file index Media database 


process 

(channel) 




MML 

rman 

nsrnmostart 

nsrexecd 

tracking 

information 

nsrindexd nsrmmdbd 

NetWorker Module 

elements 

data 

interprocess 

communication 

nsrmmd 

nsrnmo savegrp nsrd 

GEN-001110

Introduction 

3. The Oracle Server backup sessions send the backup data to the NetWorker media 

service, nsrmmd, to store on the appropriate backup volumes. 

4. Tracking information is stored in the NetWorker online indexes: 

The nsrmmd service records tracking information in the NetWorker media 

database by using the nsrmmdbd service. 

The Oracle backup sessions send tracking information to the NetWorker client 

file index by using the nsrindexd service. 


processes interact during a regular manual NMO backup. 



Figure 3 Regular manual NMO backup 

Deduplication backup processes 

NetWorker server Storage medium 


RMAN 

tracking 



process 

nsrindexd nsrmmdbd 

(channel) data 

nsrmmd 




MML 

nsrexecd 



element 

interprocess 

communication 

GEN-000171 

“Deduplication backups and restores” on page 21 describes the features of a 

deduplication NMO backup. 

For scheduled deduplication backups, the steps from “Regular scheduled backup 

processes” on page 53 still apply. 

A deduplication NMO backup includes the following interactions: 

1. The Oracle Server backup session that loads the NMO MML (one such backup 

session for each allocated channel) contacts the nsrexecd service to obtain the 

NetWorker client information. 

2. Each Oracle Server backup session runs one nsravtar process at any given time. 

nsrd 


Introduction 

56 

3. The Oracle Server backup session contacts the main NetWorker service, nsrd, to 

obtain the required authorization and the identifier of the nsrmmd process that 

manages the requested backup device on the NetWorker server or storage node. 

4. The Oracle Server backup session sends the backup data in the NetWorker save 

set format to the nsravtar process. 

5. The nsravtar process applies deduplication logic to the backup data by using 

information in a local cache or by contacting the Avamar server, and sends the 

unique data blocks to the Avamar server (NetWorker deduplication node). 

6. The nsravtar process sends a hash ID (one hash ID per save set) to the Oracle 

Server backup session. 

7. The Oracle Server backup session sends the hash ID in save set format to the 

NetWorker media service, nsrmmd, to store on the NetWorker backup device. 

8. Tracking information is stored in the NetWorker online indexes: 

The nsrmmd service records tracking information in the NetWorker media 

database by using the nsrmmdbd service. The media database entry contains 

extended attributes that identify the backup as a deduplication backup, as 

described in “Deduplication backup information in NetWorker indexes” on 

page 115. 

The Oracle backup session sends tracking information to the NetWorker client 

file index by using the nsrindexd service. 

Figure 4 on page 57 shows how the Avamar server, NetWorker, and NMO processes 

interact during a deduplication NMO backup. In the figure, the thickness of the data 

arrows indicates the amount of data passed between processes: 

◆ All the data being backed up is passed between the Oracle Server backup session 

and nsravtar process. 

◆ Hash IDs and new data blocks (never backed up before by the Avamar server) are 

passed between the nsravtar process and Avamar server. 

◆ A single hash ID for the entire NMO save set is passed between the Oracle Server 

backup session and NetWorker storage node. 


Regular restore processes 

Oracle acle 

data / 

hash ID 


server 

NMO client 


backup session 

with NMO MML 

nsravtar 

Figure 4 Deduplication NMO backup 

Hash ID 

Deduplicated 

data / hash ID 


storage node 


deduplication node 

(Avamar server) 

NetWorker client / 

utility node 

GSAN 

Node 1 

Node 2 

An NMO restore can be performed in either of two ways: 

GEN-001111 


interface. 

Or 

Introduction 



The RMAN utility starts Oracle Server sessions on the target database. These Oracle 

Server sessions initiate the restore by calling NMO media management library 

(MML) software routines. 

Note: “Deduplication restore processes” on page 58 provides information specifically for a 

deduplication restore. 

A regular NMO restore includes the following interactions: 

1. The NMO MML translates the object names requested by RMAN into a format 

that the NetWorker server understands, and forwards the names to the 

NetWorker service, nsrindexd. 

2. The nsrindexd service verifies that the backup pieces exist in the client file index. 

3. When the NetWorker server receives a restore request from the client, the main 

NetWorker service, nsrd, contacts the media service, nsrmmd. 


Introduction 

58 

4. The nsrmmd service calls the media database service, nsrmmdbd, to determine 

which media contains the requested save set and issue a mount request. 

5. The nsrmmd service reads the appropriate backup volumes and passes the data 

to the Oracle sessions through the NMO MML. 

6. The Oracle Server sessions write the data to the disk. 


processes interact during a regular NMO restore. 

Figure 5 Regular NMO restore 

Deduplication restore processes 



RMAN 

Once RMAN has restored the required files from the backup volumes, a database 

administrator can complete the standard Oracle database recovery. 

A deduplication NMO restore includes the following interactions: 

1. The NMO MML translates the object names requested by RMAN into a format 

that the NetWorker server understands, and forwards the names to the 


2. The NetWorker server verifies that the backup pieces exist in the NetWorker 

client file index and media database. 

3. When the Oracle Server restore session determines from the media database 

information that the data exists in a deduplication backup, the Oracle session 

starts a nsravtar process on the NMO client. 

4. When the NetWorker server receives a restore request from the client, the main 

NetWorker service, nsrd, contacts the media service, nsrmmd. 


NetWorker server Storage 

medium 



process 

(channel) 




MML 

nsrexecd 

nsrindexd 

NetWorker Module 

element 

data 

interprocess 

communication 

tracking 


nsrmmdbd 

nsrmmd 

nsrd 

GEN-000173

Introduction 

5. The nsrmmd service on the NetWorker server calls the media database service, 

nsrmmdbd, to determine which media contains the requested save set and issue a 

mount request. 

6. The nsrmmd service reads the appropriate backup volumes and passes the data 

(hash ID) to the Oracle Server session. 

7. The Oracle Server session passes the hash ID to the nsravtar process. 

8. The nsravtar process retrieves the data corresponding to the hash ID from either 

the primary Avamar server or the replication Avamar server, and sends the data 

to the Oracle Server session. 

9. The Oracle Server session writes the data to the disk. 


Introduction 

60 



2 

Software 

Configuration 

◆ Configuration roadmap................................................................................................ 62 

◆ Verify the Oracle Server configuration....................................................................... 63 

◆ Verify the NetWorker resources .................................................................................. 63 

◆ Configuring I18N support ........................................................................................... 67 

◆ Configure L10N support .............................................................................................. 69 

◆ Migrating a legacy configuration with the nsrnmoadmin command ................... 69 

◆ Configuring a backup with the NMC wizard........................................................... 72 

◆ Configuring a backup with the NMC legacy method ............................................. 75 

◆ Configuring a deduplication backup ......................................................................... 93 

◆ Configuring a probe-based backup ............................................................................ 97 

Software Configuration 61

Software Configuration 

62 

Configuration roadmap 

The Oracle Server and NetWorker server must be properly configured before the 

NetWorker Module for Oracle (NMO) software can be used for backup and restore 

operations. 

Before configuring the Oracle Server and NetWorker server, ensure that the NMO 

software is installed on the Oracle Server host according to the instructions in the 

NetWorker Module for Oracle installation guide. 

To perform specific configuration procedures, you can use either of the following 

through NetWorker Management Console (NMC): 

◆ Client backup configuration wizard for Oracle 

◆ Legacy configuration method (without the wizard) that uses 

application-independent screens in NMC 

To configure a regular scheduled backup, follow the instructions in the following 

sections that apply to your particular environment: 

1. Verify the Oracle Server configuration according to “Verify the Oracle Server 

configuration” on page 63. 

2. Verify the NetWorker resources according to “Verify the NetWorker resources” 

on page 63. 

3. If required, configure internationalization (I18N) support according to 

“Configuring I18N support” on page 67. 

4. If required, configure localization (L10N) support according to “Configure L10N 

support” on page 69. 

5. To use the new backup configuration wizard to modify a legacy configuration 

that was not created with that wizard, migrate the configuration first according to 

“Migrating a legacy configuration with the nsrnmoadmin command” on page 69. 

6. Complete the backup configuration by using either the wizard or NMC: 

“Configuring a backup with the NMC wizard” on page 72 

“Configuring a backup with the NMC legacy method” on page 75 (This 

section includes details on creation of nsrnmo and RMAN scripts and manual 

configuration of save set bundling and policy uniformity.) 

Refer to the following for additional information on configuring a deduplication 

backup or probe-based backup: 

◆ “Configuring a deduplication backup” on page 93 

◆ “Configuring a probe-based backup” on page 97 

Chapter 6, “Cluster and RAC Systems,” provides information on configuring any 

required cluster or Real Application Cluster (RAC) systems. 


Verify the Oracle Server configuration 

Verify the NetWorker resources 

NetWorker Server resource 


The Oracle Server system must be properly installed and configured before the 

NetWorker server and NMO software is configured. 

To set up the Oracle Server system: 

1. Install and configure the Oracle Server software components, including RMAN. 

The appropriate Oracle installation guide provides more information. 

2. Set up and configure the target database and Oracle Recovery Catalog. The 

Oracle Recovery Manager documentation provides more information on the 

Recovery Catalog. 

3. Set up and configure the Oracle networking software, Oracle Net. 

4. Register the target database with the Recovery Catalog. The Oracle backup and 

recovery documentation provides more information. 

Note: Detailed information on these steps is available from Oracle user documentation and 

Oracle support services. Oracle support contact information is available at the Oracle website. 

Verify that the required NetWorker resources are configured on the NetWorker 

server, according to the information in the following sections. 

After the NetWorker server software is installed, the NetWorker configuration 

includes a preconfigured Server resource with attribute settings that influence the 

performance and security of backups. 

Table 2 on page 63 describes the main NetWorker Server resource attributes. Verify 

that the attribute settings in the Server resource are valid for the NMO backup 

environment. Modify the settings as required. 

Table 2 NetWorker Server resource attributes 

Attribute Description 

Name Specifies the hostname of the NetWorker server. 

Parallelism Specifies the maximum number of backup save streams that the NetWorker software allows 

to arrive concurrently at the server. The NetWorker server edition determines the maximum 

parallelism value. When multiple data streams are backed up simultaneously, the efficiency of 

the storage devices is increased. 

Administrator Specifies users with NetWorker Administrator privileges. The initial default setting of the 

attribute is root@hostname on UNIX and Administrators@hostname on Windows, where 

hostname is the NetWorker server hostname. “Specify the required NetWorker privileges” on 

page 64 provides more information. 

Datazone pass 

phrase 

Specifies the key or pass phrase to use for AES encryption of Oracle data during an NMO 

backup. The pass phrase is required to restore the Oracle data from the backup. 

“NSR_AES_ENCRYPTION” on page 201 provides more information. 

Verify the Oracle Server configuration 63


64 

The NetWorker server online help and the NetWorker administration guide provide 

more information on how to configure a NetWorker Server resource and its 

attributes. 

Specify the required NetWorker privileges 

Certain NMO operations require specific NetWorker privileges. The NetWorker 

privileges are specified through the User Group resource. “NetWorker user group 

privileges” on page 64 provides more information. 

One NMO operation that requires special privileges is deletion. NMO attempts to 

remove an entry from the NetWorker index in the following cases: 

NetWorker user group privileges 

◆ If the RMAN delete command is used. 

◆ If a running Oracle backup is canceled according to the instructions in one of the 

following sections: 

“Cancel a manual backup” on page 107 

“Cancel a scheduled backup” on page 111 

Note: If the Oracle user is not granted the required NetWorker privileges in these cases, NMO 

fails to remove the backup save set entries from the NetWorker index. However, RMAN might 

remove the corresponding entries from the RMAN catalog, which would leave the NetWorker 

index and RMAN catalog unsynchronized. To resynchronize the index and catalog, issue the 

appropriate NetWorker media management command to manually remove the inconsistent 

save set entries from the NetWorker index. 

To enable NMO to remove an entry from the NetWorker index, ensure that the 

Oracle user has the required NetWorker privileges. Verify that the required user 

group privileges exist according to “NetWorker user group privileges” on page 64. 

The NetWorker server includes an access control feature. This feature allows 

NetWorker administrators to assign users to NetWorker user groups. Each user 

group has a specific set of privileges associated with it, as defined in the Privileges 

attribute of the User Group resource. 

The NetWorker server is installed with two preconfigured user groups: 

◆ Administrators — Members of this group have privileges to perform all 

NetWorker operations. The root user on UNIX, and members of the Microsoft 

Windows Administrators group, are always members of this group and cannot 

be removed from the group. 

◆ Users — By default, members of this group have privileges to back up and 

recover local data and monitor NetWorker operations. They cannot view or edit 

configurations. 

Note: The privileges associated with the Users group can be customized to fit the requirements 

of the NetWorker users in the group. The privileges associated with the Administrators group 

cannot be changed. 

By default, the NetWorker server assigns the following privileges to all users: 

◆ Monitor NetWorker 

◆ Recover Local Data 

◆ Backup Local Data 



The default user group configurations are sufficient for RMAN backup, restore, and 

crosscheck operations that use NMO. If the default user group configurations are 

changed, ensure that the required privileges are assigned for the operations. 

Verify that the required user group privileges exist for the NMO operations, as 

described in Table 3 on page 65. The NetWorker administration guide provides 

information on how to modify existing privileges. 

Note: Proxy backups and restores require the same privileges as regular Oracle backups and 

restores, plus the privileges required by the PowerSnap Module. The NetWorker PowerSnap 

Module documentation provides more information on the required privileges. 

Table 3 User group privileges required for NMO operations 

Operation Operating system user that performs operation Required user group privileges 

Migration of a legacy backup configuration with 

the nsrnmoadmin command 

! 

The Oracle user is defined as the following: 

◆ On UNIX: 

If Net service is used, it is the operating system user that starts the Net service. 

If Net service is not used, it is the operating system user that runs RMAN. 

In the case of a scheduled backup, the operating system user is root on UNIX 

and system on Microsoft Windows. 

◆ On Windows, the operating system user that runs the Oracle service 

(OracleServiceoracle_sid). 

IMPORTANT 

Root user, or a member of the Microsoft Windows 

Administrators group, on the Oracle Server 

Configure NetWorker 

Regular manual Oracle backup Oracle user on the Oracle Server Recover Local Data, Backup Local Data 

(These privileges are set by default) 

Regular scheduled Oracle backup Oracle user on the Oracle Server Recover Local Data, Backup Local Data 




Monitor NetWorker, Backup Local Data 


Regular Oracle restore Oracle user on the Oracle Server Recover Local Data 

(This privilege is set by default) 

RMAN crosscheck Oracle user on the Oracle Server Recover Local Data 


RMAN backup deletion Oracle user on the Oracle Server Operate NetWorker, and all its prerequisite 

privileges 

Restore of NWORA resource file backup to the 




Save set bundling Root user, or a member of the Microsoft Windows 


Recover Local Data 


Operate NetWorker, and all its prerequisite 

privileges 

If the correct user group privileges are not assigned, an Oracle backup or restore 

fails with an error message that indicates the required user group privileges. The 

NetWorker administration guide provides more information on NetWorker user 

groups and setting user group privileges. 

Verify the NetWorker resources 65


66 

NetWorker Schedule resource 

! 

NetWorker Device resources 

NetWorker volume pools 

You can set the backup schedule to one of the existing schedules (provided by the 

NetWorker Schedule resources on the server) for the NMO client by using either 

backup configuration wizard or the legacy configuration method. 

A NetWorker Schedule resource specifies the attributes of the backup schedule. The 

NetWorker administration guide provides more information on the features of a 

Schedule resource. 

The NMO software does not honor the NetWorker backup levels (except skip) that are 

specified in the NetWorker Schedule resource. 

IMPORTANT 

For scheduled NMO backups, the NetWorker backup levels that appear in the 

Schedule resource do not determine the NMO backup levels. The level of the 

NMO backup must be specified as either full or incremental in the RMAN backup 

script. The backup level is determined by the level in the RMAN script only. 

You must configure a Schedule resource through the legacy method with NMC, as 

described in “Configure a Schedule resource with NMC” on page 87. 

The NetWorker server uses a supported tape or disk storage device to write data 

during an Oracle backup and to read data during an Oracle restore. The NetWorker 

server configuration must include a Device resource for each storage device to be 

used for backups and restores. In addition, each storage device must contain a 

labeled and mounted volume. 

Configure the required NetWorker Device resources with the NMC program. The 

NetWorker administration guide provides more information on storage devices, the 

NMC program, and how to configure Device resources. 

The EMC NetWorker Hardware Compatibility Guide on the Powerlink website provides 

a complete list of the storage devices that the NetWorker server supports. 

The NetWorker administration guide also provides information on how to label and 

mount backup volumes in the storage devices, and how to configure any required 

storage nodes (with attached devices), autochangers, and silos. 

NetWorker software directs backups to groups of media or backup volumes called 

pools. A pool is a specific collection of backup volumes that the NetWorker server 

uses to store, sort, and organize backup data. For example, backups of Oracle data 

such as tablespaces and archived redo logs can be directed to volumes in specific 

devices. 

Each NetWorker volume pool is defined by its Pool resource in the NetWorker 

server. The attribute settings in the Pool resource act as a filter that the server uses to 

determine the type of data to write to volumes in the pool. Each volume pool has a 

Pool Type attribute. 

Note: With NMO, the only valid pool types are backup and backup clone. 



Each NetWorker volume belongs to either a preconfigured pool or a user-created 

pool. Each pool has a specific label template associated with it, providing an 

automated method to identify the media assigned to a pool. NetWorker software 

uses pools of volumes and label templates to track the data is on each volume. 

Note: If a customized volume pool is not specified for Oracle backup volumes, the NetWorker 

server routes data for an Oracle backup to the appropriate volume pool. 

Configure any required NetWorker Pool resources and corresponding Label 

Template resources with the NMC program. The NetWorker administration guide 

and NMC online help provide more information. 

Setting the NSR_DATA_VOLUME_POOL parameter 

To send data from a manual or scheduled backup to a specific pool, you can set the 

NSR_DATA_VOLUME_POOL parameter in the RMAN backup session. Chapter 3, 

“Backup Procedures,” provides more information on the two types of backups. 

Firewall support 

Configuring I18N support 

Note: In the case of proxy backups, the parameter is used to specify the volume pool for live 

backups only (backups to secondary storage only). The parameter cannot specify the snapshot 

pool for instant backups. The only way to specify the snapshot pool is by configuring the 

NetWorker resources, as described in “Configuring the NetWorker Pool resources” on 

page 169. 

NSR_DATA_VOLUME_POOL is mandatory if backup copies are generated during a 

manual backup only. Separate NetWorker pools must be defined for each backup 

copy. “Backup copies” on page 27 provides more information on how to generate 

backup copies during a manual backup. 

Appendix A, “Parameters in an RMAN Session,” provides more information on the 

NSR_DATA_VOLUME_POOL parameters. 

The NMO software provides firewall support. The ports that the NMO software uses 

for the firewall depend on the corresponding ports configured for the NetWorker 

server. 

To configure the firewall that the NMO software uses, follow the firewall 

configuration instructions in the NetWorker administration guide for the particular 

NetWorker server platform. 

“Internationalization (I18N) and localization (L10N)” on page 33 describes the 

features of NMO internationalization (I18N) support. 

To configure I18N support: 

1. Ensure that you meet the “Requirements for I18N support” on page 68. 

2. Follow the configuration steps in “Configure I18N support” on page 68. 

Configuring I18N support 67


68 

Requirements for I18N support 

Configure I18N support 

Ensure that all of the following I18N requirements are met: 

◆ The NMO client host includes a supported internationalized version of the 

operating system, properly configured to operate in the non-English locale. 

◆ The Oracle software provides the required National Language Support (NLS) or 

Globalization support, and the Oracle database is configured with the required 

non-ASCII character set. The Oracle Globalization Support documentation 

provides details. 

◆ A supported NetWorker release 7.4 or later is installed: 

Internationalized NetWorker server software is installed, either on the NMO 

client or on a remote host. 

If the NetWorker server is located on a remote host, internationalized 

NetWorker client or storage node software is installed on the NMO client. 

The NetWorker installation guide provides details on installation of the 

NetWorker software. 

◆ For I18N support during proxy operations, a supported release of the PowerSnap 

Module is installed and configured, as described in the NetWorker Module for 

Oracle release notes. 

The NetWorker documentation provides details on any other I18N requirements. 

Note: Configuration of proxy backups or restores with the NMO wizard is not supported. 

Wizard references in the following steps do not apply to the configuration of proxy operations. 

The PowerSnap Module documentation provides details on the PowerSnap options that 

support non-ASCII values. 

To configure I18N support on the NMO client host: 

1. On UNIX only, log in as the root user, then shut down the NetWorker services, set 

the environment variable LC_ALL to the appropriate locale, and restart the 

NetWorker services. 

For example, in a Japanese locale on UNIX, set LC_ALL as follows: 

# nsr_shutdown 

# export LC_ALL=JA_jp.eucJP 

# /etc/init.d/networker start 

2. Set the environment variable NLS_LANG to the character set supported by the 

operating system and Oracle database, and then restart the Oracle Server. 

The Oracle Globalization Support documentation provides details on the 

NLS_LANG variable. 

For example, to ensure that Oracle properly returns Japanese text in a Japanese 

locale, set NLS_LANG as follows: 

export NLS_LANG=JAPANESE_JAPAN.JA16EUC 

% lsnrctl stop 

% lsnrctl start 

% sqlplus /nolog 

SQL*Plus: Release 10.1.0.2.0 - Production on Thu Apr 26 15:12:03 

Copyright (c) 1982, 2004, Oracle. All rights reserved. 

SQL> connect sys/oracle as sysdba; 


Configure L10N support 

SQL> shutdown; 

SQL> startup; 

SQL> quit; 


3. If you do not configure a scheduled backup with the configuration wizard, set the 

NLS_LANG parameter in the nsrnmo script to the same value as the environment 

variable NLS_LANG. 

For example, in a Japanese locale, set NLS_LANG in the nsrnmo script as follows: 

NLS_LANG=JAPANESE_JAPAN.JA16EUC 

Note: If you configure the scheduled backup with the configuration wizard, you can set 

NLS_LANG on a wizard screen. The wizard autopopulates the NLS_LANG field if 

NLS_LANG is set in the NWORA resource file. 

4. To enable proxy catalog synchronization, set the NSR_ORACLE_NLS_LANG 

parameter to the same value as the environment variable NLS_LANG by using 

the nsrnmoadmin command. 

For example, in a Japanese locale, set the parameter by typing the following 

command: 

nsrnmoadmin -r add NSR_ORACLE_NLS_LANG JAPANESE_JAPAN.JA16EUC 

“Configuring the NWORA resource file with the nsrnmoadmin program” on 

page 188 provides details on the nsrnmoadmin command. The command sets the 

parameter value in the NWORA resource file, which is described in “The 

NWORA resource file” on page 183. 

“L10N features” on page 35 describes the features of NMO localization (L10N) 

support. 

Note: L10N support for proxy operations requires PowerSnap Module 2.4 SP2 or later. 

To configure NMO L10N support, enable the locale by installing the appropriate 

NMO language pack for the user locale on the NMO client host. Each supported 

language has its own language pack. 

The NetWorker Module for Oracle installation guide provides details on how to 

install a supported NMO language pack on a UNIX or Windows system. 

Migrating a legacy configuration with the nsrnmoadmin command 

You can use the nsrnmoadmin command to migrate a scheduled backup 

configuration that was created with a legacy method (without the configuration 

wizard in NMO 5.0) to the configuration storage framework that is supported by the 

new NMO wizard. After the migration, you can use the new wizard to modify the 

backup configuration. 

As an alternative to using the nsrnmoadmin command for the migration, you can use 

the Specify the RMAN Script Template (Optional) screen of the NMO wizard to 

retrieve an existing configuration from an RMAN script. 

Configure L10N support 69


70 

To migrate a legacy configuration with the nsrnmoadmin command: 

1. Ensure that you meet the “Requirements for using the nsrnmoadmin command 

for migration” on page 70. 

2. Use the proper nsrnmoadmin command and options, according to the 

“Migration command syntax and options” on page 71. 

Requirements for using the nsrnmoadmin command for migration 

Before using the nsrnmoadmin command to migrate a backup configuration, ensure 

that the appropriate requirements are met: 

◆ “Windows 2008 and Windows Vista requirements for the nsrnmoadmin 

command” on page 189 are met on Windows 2008 or Windows Vista. 

◆ The required NetWorker releases are installed, as described in the NetWorker 

Module for Oracle release notes. 

◆ The nsrnmo script contains the mandatory ORACLE_HOME setting. 

◆ The RMAN script contains a single valid value for each of the following: 

Target database username 

Password of the target database user 

Net service (instance) name 

◆ The RMAN script contains correct syntax for the following commands: 

allocate channel 

backup 

connect 

release channel 

send 

◆ The RMAN script does not contain any of the following commands: 

@ 

allocate channel for maintenance 

configure 

proxy 

Note: Migration of a proxy backup configuration is not supported. 

◆ The RMAN script on Microsoft Windows does not include non-ASCII characters. 

◆ You have all of the NetWorker privileges needed to query and update the Client 

resources on a NetWorker server, as described in Table 3 on page 65. The 

NetWorker documentation provides information on the required user group 

privileges. 

◆ If you use the nsrnmoadmin command in interactive mode (without the -Y 

option), you can provide the names of all the users that will use the wizard to 

modify the configuration (after it has been migrated): 

When you use nsrnmoadmin in interactive mode (without the -Y option), you 

are prompted by default for the names of all such users in ACL format 

(user@hostname). If you do not provide the usernames when prompted, you 

must add the usernames at a later time to the NetWorker Lockbock resource 


! 

Migration command syntax and options 


for the client by using NMC to edit the resource. The NetWorker 

administration guide provides details on editing the Lockbox resource in the 

section on lockbox password management. 

When you use nsrnmoadmin in noninteractive mode (with the -Y option), the 

migration does not prompt for any input. After the migration, you must add 

the usernames to the NetWorker Lockbox resource for all the users that will 

use the wizard to modify the configuration. 

IMPORTANT 

If you migrate the backup configuration of a cluster virtual client, you must do one 

of the following to enable scheduled backups of the client: 

- During the migration, when nsrnmoadmin prompts for names of wizard users to 

add to the Lockbox resource, specify the name system@physical_hostname 

(Windows) or root@physical_hostname (UNIX). 

- After the migration, use NMC to edit the Lockbox resource for the cluster virtual 

client, and add the name system@physical_hostname (Windows) or 

root@physical_hostname (UNIX) to the resource. 

You must type the nsrnmoadmin command for migration on the operating system 

command line, as one of the following users: 

◆ Root user on UNIX 

◆ A member of the Microsoft Windows Administrators group 

The command user must meet the migration requirements listed in Table 3 on 

page 65. 

“Windows 2008 and Windows Vista requirements for the nsrnmoadmin command” 

on page 189 provides details for Windows 2008 and Windows Vista systems. 

The nsrnmoadmin command syntax and options are as follows: 

nsrnmoadmin -M -s server_name [-c client_name] [-g group_name] 

[-N save_set_name] [-Y] 

nsrnmoadmin -P -s server_name [-c client_name] [-g group_name] 

[-N save_set_name] 

The -M and -P options are mutually exclusive. 

Command options and settings in brackets ([ ]) are optional. Do not include the 

brackets when typing the command. 

Migrating a legacy configuration with the nsrnmoadmin command 71


72 

Option Description 

Table 4 on page 72 describes the nsrnmoadmin command options. 

Table 4 Options of the nsrnmoadmin command for migration 

-M Specifies the migrate option. The nsrnmoadmin program performs the following: 

1. Queries the NetWorker server resource database to locate all of the Client resources that match the values specified by the 

-c, -g, -N, and -s options. 

2. Migrates each legacy configuration (the nsrnmo script, RMAN script, NWORA resource file, Client resource) to the 

configuration format that is supported by the new NMO wizard. 

Note: The nsrnmoadmin program can only migrate a configuration that physically resides on the host where the nsrnmoadmin 

command is typed. To migrate the Client resources for different physical hosts, you must run the nsrnmoadmin program on 

each physical host, or write a script to automate the process. 

-P Specifies the probe option. The nsrnmoadmin program performs a probe to query the NetWorker server resource database and 

locate all of the Client resources that match the values specified by the -c, -g, -N, and -s options, and prints the results to 

standard output. The program does not actually migrate any legacy configurations. 

Note: The nsrnmoadmin program can only probe configurations that physically reside on the host where the nsrnmoadmin 

command is typed. To probe the Client resources created for different physical hosts, you must run the nsrnmoadmin program 

on each physical host. 

-c client_name Optional. Specifies the hostname of the NetWorker client to be configured. Typically, this option specifies a virtual client in a 

cluster. The default value is the hostname of the local physical client. 

-g group_name Optional. Specifies the name of the NetWorker group for the query operation. If this option is not specified, then a group name is 

not included in the criteria for the query of the server resource database. 

-N save_set_name Optional. Specifies the value set in the Save Set attribute of the Client resource. If this option is not specified, then a save set 

name is not included in the criteria for the query of the server resource database. 

-s server_name Mandatory. Specifies the hostname of the NetWorker server that backs up the client being configured. 

-Y Optional. Specifies non-interactive mode, which causes the nsrnmoadmin program to proceed with a migration without 

prompting for confirmation. If this option is not specified, the nsrnmoadmin program displays all of the fields to be updated in the 

Client resource and requests confirmation to proceed with the migration. 

Configuring a backup with the NMC wizard 

About the backup configuration wizard 

To configure a backup with the wizard: 

1. Review the information in “About the backup configuration wizard” on page 72. 

2. Ensure that you meet the “Requirements for using the backup configuration 

wizard” on page 73. 

3. Follow the configuration steps in “Configure a backup with the wizard” on 

page 73. 

NMO release 5.0 includes a new NMC-based backup configuration wizard (also 

known as Client Backup Configuration in NMC) that is integrated with a supported 

NMC release 7.5 or later. 

“Configuration wizards” on page 30 describes the main features of the backup 

configuration wizard. The wizard can configure the Client, Group, and Policy 

(browse or retention) resources for a scheduled backup. Other NetWorker resources 



must be configured manually (without the wizard) through NMC, as described in 

“Configuring a backup with the NMC legacy method” on page 75. 

The wizard option for configuring a "typical" scheduled backup provides a more 

simplified workflow that generates predefined values (for the number of backup 

channels, backup name format, and so on). The wizard help provides details on the 

predefined settings used for a typical scheduled backup. 

To use the NMO wizard to modify an existing legacy configuration that was not 

created with the wizard, you must first migrate the configuration according to 

“Migrating a legacy configuration with the nsrnmoadmin command” on page 69. 

The following sources provide more information on the configuration wizard: 

◆ NetWorker Module for Oracle installation guide 

◆ NetWorker administration guide or release notes 

◆ Descriptive inline text in the wizard 

◆ Online help in the wizard 

Requirements for using the backup configuration wizard 

Before you use the backup configuration wizard, ensure that all of the following 

requirements are met: 

Configure a backup with the wizard 

◆ The NMC user that starts the wizard (the wizard user) has the Configure 

NetWorker privileges on the NetWorker server where the configuration is 

created. 

◆ Communication between the NMC server, NetWorker server, and NMO client 

uses nsrauth authentication. The NetWorker documentation provides any 

requirements for nsrauth authentication. 

◆ The required NetWorker releases are installed on the NMC server, NetWorker 

server, and NMO client hosts, as described in the NetWorker Module for Oracle 

release notes. 

To create or modify a backup configuration with the wizard: 

1. Start the NetWorker Management Console software. 

2. Open the Administration window: 

a. In the Console window, click Enterprise. 

b. In the left pane, select a NetWorker server in the Enterprise list. 

c. In the right pane, select the application. 

d. From the Enterprise menu, click Launch Application. 

The Administration window is launched as a separate application. 

3. In the Administration window, click Configuration. 

4. In the Configuration window, click Clients. 

Configuring a backup with the NMC wizard 73


74 

! 

5. Start the wizard by the appropriate method: 

If you are creating a new backup configuration, use one of the following 

methods: 

– Select Configuration > Client Backup Configuration > New. 

– In the left pane under the client name, right-click Clients and select Client 

Backup Configuration > New. 

– In the main Clients list, right-click the NMO client and select Client 

Backup Configuration > New. 

If you are modifying an existing backup configuration, right-click the NMO 

client in the right pane, and select Client Backup Configuration > Modify. 

6. On each wizard screen that appears, specify the required options and values for 

the backup configuration. 

If you use the wizard to configure a deduplication backup, ensure that the 

Filesperset field is set to 1 on the Specify the RMAN Options (Part 1 of 2) screen. 

Each wizard screen includes an online help button that you can click to access 

descriptions of all the fields and options on the screen: 

On all but the last screen, click Next to proceed. 

On the last screen, Review and Accept the Client Configuration, click Create 

or Modify to create or modify the configuration, respectively, and click Finish 

to exit the wizard. 

If you choose to save configuration settings to an RMAN script on disk, you can edit 

the script later and also use the script for a manual NMO backup. The resources 

required for a manual backup must be configured with the legacy method (without 

the wizard). 

IMPORTANT 

When you use the wizard to configure a cluster virtual client, the wizard attempts 

to perform all of the additional settings required for the cluster environment, 

including the following: 

- Creating the required Client resources. 

- Adding the required ACL entries to the Lockbox resource, for the physical hosts 

provided in the Remote Access field on the NetWorker Client Properties screen of 

the wizard. 

- Setting the NSR_CLIENT parameter. 

- Adding the -c virtual_clientname option to the Backup Command attribute in the 

Client resource of the virtual client. 

In the Client resource of the virtual client, ensure that the Remote Access attribute 

is set with user@physical_hostname for each of the physical hosts of the cluster; 

otherwise, the backup might fail. 


Configuring a backup with the NMC legacy method 


The following sections describe how to configure backups with the legacy method 

(without the configuration wizard). 

About backup configuration with the legacy method 

Create RMAN scripts for backups 

NMO release 5.0 still supports the legacy method of backup configuration, as used in 

previous NMO releases. To configure a scheduled backup, you can still manually 

create an RMAN script and nsrnmo script, set parameters in the NWORA resource 

file if needed, and configure the NetWorker resources with NMC. 

As an alternative, you can use the backup configuration wizard to configure a 

scheduled backup, as described in “Configuring a backup with the NMC wizard” on 

page 72. However, NetWorker resources other than the Client and Group resource 

must still be configured manually with NMC. 

For a manual backup, the NetWorker Client resource must be modified manually 

through the legacy method, as required. 

Create an appropriate RMAN script to perform the preferred type of manual or 

scheduled backup on the Oracle Server host. 

NSR* parameters in the script must be set with the methods described in “Setting the 

NSR* parameters” on page 200. The use of the send command is recommended 

where possible. “The send command” on page 211 provides more information. 

NSR* parameters cannot be set through other methods, for example, by using the 

setenv or set command on the operating system command line. Appendix A, 

“Parameters in an RMAN Session,” provides complete information on the NSR* 

parameters in the RMAN script or session. 

RMAN backup scripts can be stored as flat ASCII files. Alternatively, if a Recovery 

Catalog is used, backup scripts can be stored in the Recovery Catalog database. The 

appropriate Oracle backup and recovery documentation provides information on 

storing the backup scripts in the Recovery Catalog database. 

The following sections provide details on RMAN scripts for manual backups and 

scheduled backups. 

RMAN scripts for manual backups 

If automatic channel allocation and persistent settings are used, the backup 

command can be run as a stand-alone command. “Automatic channel allocation” on 


Example 10 RMAN script for a manual backup 

The following RMAN script is for a manual backup of an entire Oracle database to 

the volume pool MondayFulls of the (remote) NetWorker server mars.emc.com: 

run { 

allocate channel t1 type ’SBT_TAPE’; 


send ’NSR_ENV=(NSR_SERVER=mars.emc.com, 

NSR_DATA_VOLUME_POOL=MondayFulls)’; 

backup full filesperset 4 format ’FULL_%d_%U’ (database); 

Configuring a backup with the NMC legacy method 75


76 

! 

} 

release channel t1; 


To specify a Media Management (in this case, NMO) device, set the type option in the 

allocate channel command to SBT_TAPE. 

If a device is allocated by using the allocate channel t1 type disk command (with 

Oracle correctly configured and NMO uninstalled), backups can be directed to disk 

files through Oracle’s backup implementation. 

In the preceding RMAN backup script, the format string FULL_%d_%U specifies the 

name of each backup piece. This name can be anything, provided that each backup 

piece has a unique name on the NetWorker server. Substitution variables, such as %d 

and %U, can be used to guarantee unique names: 

◆ %d specifies the name of the database. 

◆ %U specifies a unique Oracle system-generated filename. 

A format string such as FULL or FULL_%d will not generate unique names. 

Similarly, the format string FULL_%U will not generate unique names for two 

databases that are being backed up to the same NetWorker server. 

IMPORTANT 

If a backup piece name is not unique, the Oracle backup fails. 

During a manual backup, the prefix RMAN: automatically precedes the backup piece 

name in the NetWorker media database. For example, if the backup piece name 

specified in the RMAN script is accounts_data_file, the manual backup records the 

save set name as RMAN:accounts_data_file in the media database. The mminfo 

command displays the save set name in this form. 

The following sources provide more information: 

◆ The appropriate Oracle backup and recovery documentation provides 

information on how to write RMAN scripts. 

◆ The Oracle Enterprise Manager documentation provides information on how to 

use the Oracle Enterprise Manager Backup Wizard to generate RMAN scripts. 

◆ Appendix B, “RMAN Commands,” provides important information on RMAN 

commands. 

◆ “Regular backup information in NetWorker indexes” on page 114 describes the 

information stored for a manual backup in the NetWorker indexes. 

Example 11 RMAN script for AES encryption during an Oracle backup 

The following RMAN script performs a nonproxy backup of the Oracle database to 

the NetWorker server mars.emc.com by using 256-bit AES encryption, as specified by 

the NSR_AES_ENCRYPTION parameter setting: 

run { 


send ’NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_AES_ENCRYPTION=TRUE)’; 

backup full filesperset 4 format ’FULL_%d_%U’ (database); 


} 

The AES encryption uses the key or pass phrase that is set in the Datazone pass 

phrase attribute of the NetWorker Server resource. “NSR_AES_ENCRYPTION” on 



! 

IMPORTANT 

RMAN scripts for scheduled backups 

! 


Keep a record of all pass phrases used for 256-bit AES encryption. Be careful when 

you change the pass phrase on the NetWorker server. If the pass phrase on the 

server is changed and you cannot remember the pass phrase used for an NMO 

backup, the encrypted data cannot be recovered. The NetWorker administration 

guide provides more information on pass phrases. 

Example 17 on page 122 shows a sample Oracle restore of an AES encrypted backup, 

with the NSR_ENCRYPTION_PHRASES parameter that specifies the original pass 

phrase that was used for the backup. 

IMPORTANT 

For scheduled backups (both regular and proxy backups), do not include send as 

part of the allocate channel command. The send command must be separate. 

For example, NMO does not support the following for scheduled backups: 

allocate channel t1 type ’SBT_TAPE’ send 

’NSR_ENV=(NSR_SERVER=mars.emc.com)’; 

The following is the correct form of the commands: 


send channel t1 ’NSR_ENV=(NSR_SERVER=mars.emc.com)’; 

With automatic channel allocation, specifying the send command before the backup 

or restore command causes the following error: 

RMAN-06422: no channels found for SEND command 

“Automatic channel allocation” on page 26 provides information on automatic 

channel allocation. 

Example 12 RMAN script for a scheduled backup 

The following RMAN script is for a scheduled backup of an entire Oracle database to 

the volume pool MondayFulls. The Recovery Catalog is used in this case: 

connect target target_user/target_passwd@target_Netservicename; 

connect rcvcat rcvcat_user/rcvcat_passwd@rcvcat_Netservicename; 

run { 

set command id to ’xxx’; 



send ’NSR_ENV=(NSR_DATA_VOLUME_POOL=MondayFulls)’; 

backup full filesperset 4 

format ’FULL_%d_%U’ 

(database); 



} 

If automatic channel allocation and persistent settings are used, a scheduled RMAN 

backup script must still be created and contain the following commands: 

◆ connect target 

◆ connect rcvcat (if using a Recovery Catalog) 

◆ backup 



78 

! 

The command connect target target_user/target_passwd@target_Netservicename is 

mandatory in each RMAN script for a scheduled backup. This command establishes 

the proper connection to the target database. 

Specify the correct values in the connect target command: 

◆ target_user is the user with SYSDBA privileges for the target database. 

◆ target_passwd is the password of the target_user (for connecting as SYSDBA), 

specified in the target database’s orapwd file. 

◆ target_Netservicename is the Net service name of the target database. This name is 

mandatory in the connect target command. 

A password file must be used for the target database. To use the password file, the 

orapwd utility might need to be used and the REMOTE_LOGIN_PASSWORDFILE 

parameter set to exclusive in the initoracle_sid.ora file. The appropriate Oracle 

documentation provides more information. 

Notes: 

◆ Since each scheduled backup RMAN script requires a connect target command, 

each Oracle instance requires a separate scheduled backup RMAN script. 

◆ In the connect target command, do not use the value internal for target_user or the 

value oracle for target_passwd. 

The command connect rcvcat rcvcat_user/rcvcat_passwd@rcvcat_Netservicename is 

mandatory if the Recovery Catalog is used for the scheduled Oracle backup. This 

command establishes the proper connection to the Recovery Catalog database. 

Specify the correct values in the connect rcvcat command: 

◆ rcvcat_user is the owner of the Recovery Catalog database. 

◆ rcvcat_passwd is the password of the rcvcat_user. 

◆ rcvcat_Netservicename is the Net service name of the Recovery Catalog database. 

To enable the scheduled backup to be canceled, the scheduled Oracle backup script 

must include set command id to ‘xxx’ (where xxx can be any string of characters 

enclosed in single quotes). “Cancel a scheduled backup” on page 111 provides more 

information on how to cancel a scheduled backup. 

The remainder of the scheduled backup script in Example 12 on page 77, starting 

with the first allocate channel command, is similar to the manual backup script in 

Example 10 on page 75 except that the NSR_SERVER parameter setting is not 

included. 

IMPORTANT 

Do not set the parameters NSR_SERVER or NSR_GROUP in a scheduled RMAN 

backup script. NMO sets these two parameters to the values specified in the Client 

resource for the scheduled Oracle backup, and these values cannot be overridden. 

To have the scheduled backup automatically use a volume pool, the backup group 

can be specified in the Pool resource. The scheduled backup uses that pool unless the 

parameter NSR_DATA_VOLUME_POOL is set in the RMAN script. Then that 

parameter’s setting takes precedence over any pool associated with the scheduled 

backup group. 

If NSR_DATA_VOLUME_POOL is set in the RMAN script to a pool different from 

the one associated with the backup group, the scheduled backup uses the 



NSR_DATA_VOLUME_POOL pool. It is the user’s responsibility to set that 

parameter correctly in the RMAN script for a scheduled backup. 

Each scheduled backup RMAN script must be stored as a text file. The database 

administrator should give minimal permissions to the scheduled backup RMAN 

script file. This way, unauthorized users cannot see the sensitive user IDs and 

passwords of the target and Recovery Catalog databases. 

If a single Oracle instance has multiple RMAN scripts associated with it (for example, 

to perform tablespace-level or file-level, full or incremental backups, and so on), the 

database administrator might choose to place the two common connect commands in 

a single file and invoke those two connect commands in all RMAN scripts by using 

the @ command. 

Test RMAN scripts for scheduled backups 

When you create an RMAN script, test the script before using it for scheduled 

backups. 

To test the RMAN script, type one of the following commands: 

rman cmdfile ’script_name’ send 

’”NSR_ENV=(NSR_SERVER=NetWorker_server_name, NSR_GROUP=group_name)”’ 

rman nocatalog cmdfile ’script_name’ send 

’”NSR_ENV=(NSR_SERVER=NetWorker_server_name, NSR_GROUP=group_name)”’ 

where: 

Customize the nsrnmo script 

◆ script_name is the RMAN script file pathname. 

◆ NetWorker_server_name is the name of the server that starts the backup. 

◆ group_name is the name of the scheduled backup group as specified in the Client 

resource. 

Customize the nsrnmo script on the Oracle Server host by modifying the parameters 

in the script. 

The NMO installation on the Oracle Server host stores the following files: 

◆ A sample nsrnmo script in the same directory as the NetWorker executables. The 

sample script filenames are: 

nsrnmo on UNIX 

nsrnmo.bat on Windows 

◆ A template of the script in the /etc/nsrnmo.sh file on UNIX. Do not modify this 

file. 

Note: On Windows, save a copy of the original nsrnmo.bat file before modifying it. 

“Editing the nsrnmo.bat file on Windows 2008 or Windows Vista” on page 80 provides 

specific requirements for Windows 2008 and Windows Vista systems. 

Multiple versions of the nsrnmo script can be created (for example, one for each 

Oracle instance) on the same Oracle Server host. Each version of the script must have 

a unique name, starting with the letters nsr or save. On Windows, the name must also 

end in .bat or .cmd. 



80 

To create a new version of the nsrnmo script: 

1. Copy the sample script file (nsrnmo on UNIX or nsrnmo.bat on Windows) to a 

file with a different name. 

2. Customize the parameters in the new file. 

For example, you might create the new script file named nsrnmo_prodDB on UNIX 

or nsrnmo_prodDB.bat on Windows. 

All versions of the nsrnmo script must be located in the same directory as the 

NetWorker executables. Do not move the nsrnmo scripts to a different directory. 

Notes: 

◆ A nsrnmo script from a previous NMO release works with NMO release 5.0. 

However, the nsrnmo script installed with NMO release 5.0 might include new 

parameter settings not found in the script from the previous release. 

◆ To facilitate the correct reporting of scheduled backup save sets for a UNIX NMO 

client within the group details window of the NetWorker Management Console 

(NMC), specify the following shell within the nsrnmo script on UNIX: 

/bin/bash, if it exists on the UNIX client 

/bin/ksh, if /bin/bash does not exist on the UNIX client 

Editing the nsrnmo.bat file on Windows 2008 or Windows Vista 

Only a member of the Microsoft Windows Administrators group can edit the 

nsrnmo.bat file or any file located in the NetWorker_installation_dir\bin directory on 

Windows. 

On Windows 2008 or Windows Vista, you must follow these steps to edit the 

nsrnmo.bat file in the NetWorker_installation_dir\bin directory: 

1. Click Start. 

2. Right-click Notepad or any other text editor listed as a menu item. 

3. Select Run as administrator. 

4. Open the NetWorker_installation_dir\bin\nsrnmo.bat file in the text editor. 

5. Edit and save the nsrnmo.bat file. 

The nsrnmo script on Solaris zones 

On a Solaris system with Solaris zones, a sparse root zone can have shared directories 

that are mounted from the global zone. Such directories are read-only on the sparse 

root zone. If NMO is installed on a sparse root zone and /usr is one of the shared 

directories, the nsrnmo script in /usr/sbin is read-only on the sparse root zone. In 

this case, the nsrnmo script must be edited on the global zone. 

If multiple sparse root zones are configured on a physical computer, all of the virtual 

sparse root zones see the nsrnmo script in /usr/sbin. In this case, each sparse root 

zone should use a unique script filename, such as nsrnmo1, nsrnmo2, and so on. The 

Backup Command attribute in the Client resource for each sparse root zone must 

contain the unique nsrnmo filename for that zone. “Configure a Client resource with 

NMC” on page 87 provides more information on the Client resource. 

Parameters in the nsrnmo script 

The sample nsrnmo script installed with NMO contains parameters that must be 

customized for a particular scheduled Oracle backup. The parameters in the sample 

nsrnmo script are all undefined by default. 



The nsrnmo script contains only the parameters required on the particular system 

where the script is installed. The following parameters appear in the nsrnmo script 

on specific UNIX systems only: 

◆ LD_LIBRARY_PATH appears in the script on: 

HP-UX (64-bit Itanium) 

Linux 

Solaris 

◆ LIBPATH appears in the script on AIX. 

◆ SHLIB_PATH appears in the script on HP-UX (32-bit and 64-bit PA-RISC). 

Follow the instructions in the Oracle installation guide to determine which of the 

parameters (LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH) to set on a particular 

operating system and to what value. 

The ORACLE_HOME parameter is mandatory for each scheduled backup, and must 

be set in the nsrnmo script. The other parameters in the nsrnmo script are optional, 

and can be left undefined in the script, if preferred. 

Note: For other parameters to be in effect during a scheduled backup, lines must be added in 

the nsrnmo script to define and export the parameters. The use of either the UNIX setenv 

command or Windows set command to set the parameters has no effect. 

The following sections describe the parameters that can be set in the nsrnmo script 

for scheduled backups. The comments in the nsrnmo script file provide details on the 

parameters: 

◆ “ORACLE_HOME” on page 81 

◆ “LD_LIBRARY_PATH” on page 82 

◆ “LIBPATH” on page 82 

◆ “SHLIB_PATH” on page 82 

◆ “NSR_RMAN_ARGUMENTS” on page 82 

◆ “NSR_SB_DEBUG_FILE” on page 83 

◆ “ORACLE_SID” on page 83 

◆ “ORACLE_USER” on page 83 

◆ “PRECMD” on page 84 

◆ “POSTCMD” on page 85 

◆ “TNS_ADMIN” on page 86 

ORACLE_HOME 

This parameter is mandatory for each scheduled backup. Set ORACLE_HOME in the 

nsrnmo script file to the home directory of the Oracle Server installation. The RMAN 

executable, rman, must be located in the subdirectory bin of $ORACLE_HOME. 

For example, if the Oracle Server installation is located in the directory 

/disk3/oracle/app/oracle/product/10.0, ORACLE_HOME must be set in the 

nsrnmo script as follows: 

ORACLE_HOME=/disk3/oracle/app/oracle/product/10.0 



82 

LD_LIBRARY_PATH 

This parameter is optional for a scheduled backup. Set LD_LIBRARY_PATH in the 

nsrnmo script file to the pathname of the directory that contains the Oracle libraries, 

typically $ORACLE_HOME/lib or $ORACLE_HOME/lib64. 

For example, if the Oracle libraries are located in the directory 

/disk3/oracle/app/oracle/product/10.0/lib, set LD_LIBRARY_PATH in the 


LD_LIBRARY_PATH=/disk3/oracle/app/oracle/product/10.0/lib 

Uncomment the line “export LD_LIBRARY_PATH” (by removing the # symbol at the 

start of the line) under the “export_environment variables()” function heading in the 

nsrnmo script: 

export_environment_variables() 

{ 

export ORACLE_HOME 

export NSR_RMAN_ARGUMENTS 

: 

: 

export LD_LIBRARY_PATH 

} 

LIBPATH 

This parameter is optional for a scheduled backup. It appears in the nsrnmo script on 

AIX only. Set LIBPATH in the nsrnmo script file to the pathname of the directory that 

contains the Oracle libraries, typically $ORACLE_HOME/lib. 

To set LIBPATH in the nsrnmo script, follow the example shown in 

“LD_LIBRARY_PATH” on page 82. Replace LD_LIBRARY_PATH with LIBPATH. 

Uncomment the line “export LIBPATH” in the script. 

SHLIB_PATH 

This parameter is optional for a scheduled backup. It appears in the nsrnmo script on 

HP-UX only. Set SHLIB_PATH in the nsrnmo script file to the pathname of the 

directory that contains the Oracle libraries, typically $ORACLE_HOME/lib. 

To set SHLIB_PATH in the nsrnmo script, follow the example shown in 

“LD_LIBRARY_PATH” on page 82. Replace LD_LIBRARY_PATH with 

SHLIB_PATH. Uncomment the line “export SHLIB_PATH” in the script. 

NSR_RMAN_ARGUMENTS 

This parameter is optional for a scheduled backup. Set NSR_RMAN_ARGUMENTS to 

a double-quoted string that contains any valid combination of options for the RMAN 

executable, rman. The appropriate Oracle Recovery Manager documentation 

provides details on the valid options. 

For example, to append RMAN output to the message log file 

/nsr/applogs/msglog.log, set NSR_RMAN_ARGUMENTS in the nsrnmo script as 

follows: 

NSR_RMAN_ARGUMENTS="msglog ’/nsr/applogs/msglog.log’ append" 

To append RMAN output to the message log file /nsr/applogs/msglog.log if a 

Recovery Catalog is not used, set NSR_RMAN_ARGUMENTS in the nsrnmo script 

as follows: 

NSR_RMAN_ARGUMENTS="nocatalog msglog ’/nsr/applogs/msglog.log’ append" 




This parameter is optional for a scheduled backup. It is used only for debugging 

purposes. 

Enable debugging by setting NSR_SB_DEBUG_FILE to the complete pathname of a 

file to receive detailed debug information for the scheduled backup. This file will 

exclude MML-specific debug information, which is directed to NSR_DEBUG_FILE (if 

set in the RMAN script). 

Note: If NSR_SB_DEBUG_FILE is undefined (by default), no debug information is generated. 

If a file with the specified pathname cannot be created, debug information is either directed to 

the default location or not generated. 

For example, to send detailed debug information for the scheduled backup to the 

/usr/logs/schedbkup.log file, set the parameter NSR_SB_DEBUG_FILE in the 


NSR_SB_DEBUG_FILE=/usr/logs/schedbkup.log 

“NMO error messages” on page 222 provides more information on how the debug 

information is written if the parameter NSR_SB_DEBUG_FILE is set to an invalid 

pathname. 

ORACLE_SID 

This parameter is required for a scheduled backup in the following cases: 

◆ The connect target and connect rcvcat commands for the scheduled backup are 

stored in a separate file, and the connect commands are invoked in the RMAN 

script by using the @ command. 

◆ Save set bundling is enabled for the scheduled backup. 

◆ A proxy backup is performed with catalog synchronization enabled. Chapter 7, 

“Proxy Backups and Restores,” provides more information on proxy backups and 

catalog synchronization. 

Set ORACLE_SID in the nsrnmo script file to the system identifier (SID) value of the 

Oracle database to be backed up. For example, if catalog synchronization is enabled 

for proxy backups and the SID of the Oracle database to be backed up is orcl10, 

ORACLE_SID must be set as follows: 

ORACLE_SID=orcl10 

ORACLE_USER 

This parameter is optional for a scheduled backup configured through the legacy 

method (without the wizard) on UNIX only. 

Enable the scheduled backup for operating system authentication by setting 

ORACLE_USER to the username of the Oracle operating system user, which is set up 

to connect to the Oracle database through operating system authentication. 

Note: Using ORACLE_USER to perform an NMO backup through operating system 

authentication is not supported for the following: 

- A scheduled backup configured through the new configuration wizard. 

- A scheduled backup on Microsoft Windows. 

- A probe-based backup. 

- A scheduled proxy backup. 



84 

! 

For example, to perform a scheduled NMO backup on UNIX through operating 

system authentication (the backup must be configured through the legacy method), 

set ORACLE_USER to the required Oracle operating system username: 

ORACLE_USER=Oracle_OS_username 

PRECMD 

This parameter is optional. Set PRECMD to the complete pathname of a file containing 

a preprocessing script to be executed before the RMAN backup script. 

Note: The pathname value of PRECMD must not contain any spaces. For example, instead of 

setting PRECMD to C:\Program Files\Legato\nsr\precmd.bat, set the parameter to 

C:\Progra~1\Legato\nsr\precmd.bat. 

If the pre-command script fails (returns a nonzero value), the scheduled Oracle 

backup does not proceed (that is, the RMAN script is not executed). 

IMPORTANT 

The script file must have permissions that allow execution by the root user, as the 

scheduled Oracle backup is always launched by root. The script should return a 

zero value when it succeeds and a nonzero value when it fails. The return of a 

nonzero value will cause the scheduled backup to fail. 

A sample preprocessing script for UNIX is shown as follows. This script is stored in 

the file whose complete pathname is specified in the parameter PRECMD in the 

nsrnmo script. 

For example, if the script is stored in the /usr/scripts/orashutdown file, set the 

parameter PRECMD as follows: 

PRECMD=/usr/scripts/orashutdown 

This sample script shuts down the Oracle database, presumably for an offline 

database backup. The su command is required in the script since the nsrnmo script 

runs as root user: 

#!/bin/ksh 

# Define Site Specifics Here 

TARGET_DATABASE=proddb 

ERRFILE=/tmp/precmd.log 

ORACLE_USER=proddb 

# 

# Scheduled backup launches as "root" run PRECMD as oracle user 

su - $ORACLE_USER -c "{ 

# Shutdown target database and start in maintenace mode 

export ORACLE_SID=$TARGET_DATABASE 

svrmgrl

! 

status=0 

fi 

exit $status 


POSTCMD 

This parameter is optional. Set POSTCMD to the complete pathname of a file that 

contains a postprocessing script to be executed after the RMAN backup script. 

Note: The pathname value of POSTCMD must not contain any spaces. For example, instead of 

setting POSTCMD to C:\Program Files\Legato\nsr\postcmd.bat, set the parameter to 

C:\Progra~1\Legato\nsr\postcmd.bat. 

If the RMAN backup script fails, the failure is reported, and the postprocessing script 

is executed nevertheless. If the postprocessing script fails, an error message is 

reported. 

IMPORTANT 

The script file must have permissions allowing execution by the root user, as the 

scheduled Oracle backup is always launched by root. The script should return a 

zero value when it succeeds and a nonzero value when it fails. 

A sample postprocessing script for UNIX is shown as follows. This script is stored in 

the file whose complete pathname is specified in the parameter POSTCMD in the 


For example, if the script is stored in the /usr/scripts/orastartup file, set the 

parameter POSTCMD as follows: 

POSTCMD=/usr/scripts/orastartup 

This sample script starts up the Oracle database, presumably after an offline backup. 

The su command is required in the script since the nsrnmo script runs as root user: 

#!/bin/ksh 

# Define Site Specifics Here 

TARGET_DATABASE=proddb 

ERRFILE=/tmp/postcmd.log 

ORACLE_USER=proddb 

# 

# Scheduled backup launches as "root" run POSTCMD as user proddb 

su - $ORACLE_USER -c "{ 

# Mount target database as ready for use 

export ORACLE_SID=$TARGET_DATABASE 

svrmgrl


86 

Configure a Group resource with NMC 

! 

TNS_ADMIN 

This parameter is mandatory if the Oracle Net configuration files are located in a 

directory other than the default $ORACLE_HOME/network/admin directory. 

In this case, set the value of TNS_ADMIN to the pathname of the directory that 

contains the Oracle Net configuration files. To set TNS_ADMIN in the nsrnmo script, 

follow the example shown in “LD_LIBRARY_PATH” on page 82. Replace 

LD_LIBRARY_PATH with TNS_ADMIN. Uncomment the line “export 

TNS_ADMIN” in the script. 

Note: As an alternative, you can use the backup configuration wizard to configure the Group 

resource, as described in “Configuring a backup with the NMC wizard” on page 72. 

“Configuring a probe-based backup” on page 97 provides details on configuration 

requirements for a probe-based backup. 

For a scheduled NMO backup, a NetWorker Group resource must be configured that 

specifies the attributes of the backup group. The Group resource specifies a set of 

NetWorker Client resources that all start to back up data at a specified time, once the 

following occurs: 

◆ The Autostart attribute is enabled. 

◆ The backup start time is specified in the Group resource. 

By configuring one or more NetWorker backup groups for scheduled backups, the 

backups can be: 

◆ Distributed to alleviate network traffic. 

◆ Scheduled for a time of day when performance demands on the database and 

NetWorker server are lower. 

One or more Client resources configured for the Oracle Server host can be assigned to 

a NetWorker backup group. 

All NetWorker backup groups can be created and modified. All backup groups except 

the Default group can be deleted. 

To use the Default group for testing scheduled backups, change its Autostart 

attribute to Enabled. 

Note: To have a regular scheduled backup automatically use a volume pool associated with the 

backup group, specify the group name in the Pool resource for the volume pool. 

IMPORTANT 

For a regular scheduled Oracle backup, the Snapshot attribute in the Group 

resource must be set to False. 

You can create a NetWorker Group resource with the NMC interface. The NetWorker 

administration guide and NMC online help provide more information. 


Configure a Schedule resource with NMC 

Configure a Client resource with NMC 


Review the summary information in “NetWorker Schedule resource” on page 66. 

Configure the NetWorker Schedule resource with NMC, to specify the days of the 

week when a scheduled Oracle backup runs. 

The NetWorker server provides several preconfigured schedules. Both the 

preconfigured schedules and customized schedules can be created and modified. 

The NetWorker administration guide and NMC online help provide more 

information on how to use the NMC interface. 

Customize a NetWorker Schedule resource for an Oracle backup. In the Schedule 

resource, select a level for each day of the week: 

◆ Level full, incremental, or level 1 to 9 specifies that the NetWorker server runs the 

backup script on that day. 

◆ Level skip specifies that the NetWorker server does not run the backup script on 

that day. 

Specify the name of the NetWorker schedule in the Schedule attribute of the Client 

resource, as described in “Configure a Client resource with NMC” on page 87. 

Note: As an alternative, you can use the backup configuration wizard to configure the Client 

resource, as described in “Configuring a backup with the NMC wizard” on page 72. 

“Configuring a probe-based backup” on page 97 provides details on configuration 

requirements for a probe-based backup. 

A NetWorker Client resource is a set of attributes assigned to the NMO client host 

and stored on the NetWorker server. Before NMO software can be used for backups 

or restores, a Client resource must be configured for the NMO client host. 

If the NetWorker server software is installed on the NMO client host, a basic Client 

resource for the NMO client is created automatically during the NetWorker 

installation. The Client resource must be customized for an NMO backup. 

“NetWorker indexes and policies used for restores” on page 118 provides more 

information on how the NetWorker server uses the browse and retention policies to 

manage Oracle backup data and enable the data to be restored. 

“Configuring the NetWorker Client resource” on page 170 provides information on 

how to configure the Client resource for proxy backups. 

To configure the Client resource for a regular scheduled backup by using the NMC 

interface, specify the required values for each attribute, according to Table 5 on 

page 88. 

Leave the following attributes blank: 

◆ Directive 

◆ Archive Users 

◆ Remote User 

◆ Password 



88 


Note: On a Solaris system with Solaris zones, ensure that the security fields (such as Remote 

Access and Privileges) of NetWorker resources used during NMO backups and restores refer 

to the hostname of the zone in which NMO operates. 

Each Oracle installation requires a separate Client resource. The Backup Command 

attribute of the Client resource must contain only one nsrnmo script name, and 

ORACLE_HOME is a mandatory parameter in each nsrnmo script. 

If multiple RMAN scripts are specified for the Save Set attribute of the Client 

resource: 

◆ The RMAN scripts are executed in arbitrary order, possibly in parallel. 

◆ If the nsrnmo script also contains a well-defined setting for PRECMD or 

POSTCMD, the precommand and postcommand files will be: 

Common for all the RMAN scripts 

Executed once for each RMAN script 

The sequence of execution of “precommand–RMAN script–postcommand” triplets is 

arbitrary. To include preprocessing and postprocessing with the backups of the 

various Oracle database instances of an Oracle installation, define a separate 

NetWorker Client resource for each Oracle instance. 

Note: If a scheduled Oracle backup is retried, the specified precommand and postcommand 

will be executed again for that backup. 

Figure 6 on page 90 shows a sample Client resource for a UNIX NMO client. 

Figure 7 on page 91 shows a sample Client resource for a Windows NMO client. 

Table 5 NetWorker Client resource attributes (page 1 of 2) 

Name Specifies the hostname of the Oracle Server host. 

Backup Command For a scheduled backup configured through the legacy method with NMC (not through the wizard), specifies the name of a 

single customized nsrnmo script to use for the backup. 

For example, the nsrnmo script name might be nsrnmo or nsrnmo2 on UNIX, or nsrnmo.bat or nsrnmo2.bat on Windows. 

On a Solaris system with Solaris zones where NMO is installed on sparse root zones, the Backup Command attribute in the 

Client resource for each sparse root zone must contain the unique nsrnmo filename for that zone. 

Note: If you configure a scheduled backup through the configuration wizard, the wizard automatically adds the nsrnmostart 

program name to this attribute. In that case, do not modify this attribute. 

Browse Policy Specifies the length of time that the NetWorker server retains an entry for an Oracle backup in the online client file index. This 

attribute applies only to scheduled backups. 

Note: For a scheduled backup, if the parameter NSR_SAVESET_BROWSE is set as described in Appendix A, “Parameters 

in an RMAN Session,” its value overrides the Browse Policy attribute setting in the Client resource. 

To set a specific browse policy for a manual backup, use the parameter NSR_SAVESET_BROWSE. If the parameter is not 

set, the NetWorker server uses the most appropriate value for the browse policy. 

Group Specifies the NetWorker backup group to use for a scheduled backup. “Configure a Group resource with NMC” on page 86 

provides more information on NetWorker backup groups. 



Table 5 NetWorker Client resource attributes (page 2 of 2) 


Remote Access Specifies the fully qualified hostname of a remote system, to enable restores of the backups to that remote system. 

On a Solaris system with Solaris zones, the Remote Access attribute must contain the hostname of the zone in which NMO 

operates. 

Note: If backups from a cluster, or recovery to a host other than the one being backed up, are not required, do not modify the 

Remote Access attribute. 

Retention Policy Specifies the minimum length of time that the NetWorker server maintains information about Oracle backup data in the online 

media database. This attribute applies only to scheduled backups. 

Note: For a scheduled backup, if the parameter NSR_SAVESET_RETENTION is set as described in Appendix A, 

“Parameters in an RMAN Session,” its value overrides the Retention Policy attribute setting in the Client resource. 

To set a specific retention policy for a manual backup, use the parameter NSR_SAVESET_RETENTION. If the parameter is 

not set, the NetWorker server uses the most appropriate value for the retention policy. 

Save Set Specifies the complete pathname of each RMAN script to be used for a scheduled backup, preceded by RMAN:. Do not 

include any spaces between the prefix RMAN: and the script name. On Windows, the pathname can include forward slashes, 

for example, RMAN:F:/scripts/incr_1_bkup. 

For example, if two separate RMAN backup scripts are created in the files /disk/rman_scripts/archlogbkup and 

/disk/rman_scripts/fullbkup (to be run by the nsrnmo script in the Backup Command attribute), specify the complete file 

pathnames prepended by RMAN: in the Save Set attribute: 

RMAN:/disk/rman_scripts/archlogbkup 

RMAN:/disk/rman_scripts/fullbkup 

Note: If you configure a scheduled backup through the configuration wizard, the wizard automatically includes the prefix 

RMAN: in the Save Set attribute setting, as described in “Backup configuration storage with the wizard” on page 31. 

The save set information for the scheduled backup is stored in the NetWorker indexes as described in: 

“Regular backup information in NetWorker indexes” on page 114 

“Deduplication backup information in NetWorker indexes” on page 115 

Schedule Specifies the NetWorker backup schedule to use for a scheduled backup. “Configure a Schedule resource with NMC” on 

page 87 provides more information on NetWorker backup schedules. 



90 

Figure 6 UNIX Client resource for scheduled backups 


Figure 7 Windows Client resource for scheduled backups 


Configure an email notification 

To send an email notification of the scheduled backup results to the owner of a save 

set, edit the Owner Notification attribute in the Client resource for the Oracle Server 

(or Oracle instance). 

In the Owner Notification attribute, specify a notification command directed to the 

login ID of the owner, for example: 

Configure save set bundling 

/usr/bin/mail -s “server1-server2-server3 backup” jdoe 


information on how to edit the attributes of the NetWorker Client resource. 

This section describes how to manually configure save set bundling for NMO 


As an alternative, you can use the backup configuration wizard to configure the 

scheduled backup and set the NSR_BUNDLING parameter to enable save set 

bundling. “Configuring a backup with the NMC wizard” on page 72 provides more 


Save set bundling can be enabled and disabled independently of policy uniformity. If 

save set bundling is enabled, policy uniformity should also be enabled, as described 

in “Configure policy uniformity” on page 92. 



92 

Configure policy uniformity 

To enable save set bundling: 

◆ Set the NSR_BUNDLING parameter value to enabled by typing the following 

command: 

nsrnmoadmin -r add NSR_BUNDLING enabled 

By default, the NSR_BUNDLING parameter is disabled. 





◆ Ensure that NMO scheduled backups are configured properly according to the 

“Configuration roadmap” on page 62. 

◆ Ensure that the user group privileges for the root or administrative user on the 

NMO client include the Operate NetWorker privileges. The corresponding User 

Group resource is configured on the NetWorker server, as described in 

“NetWorker user group privileges” on page 64. 

◆ If the proper username and password are not located in the RMAN script (for 

example, the connection strings are included as a command file in the RMAN 

script, such as @connection_file), ensure the following: 

The ORACLE_SID parameter is set in the nsrnmo script, as described in 

“Customize the nsrnmo script” on page 79. 

An NWORA SID resource with the NSR_ORACLE_CONNECT_FILE 

parameter setting is created in the NWORA resource file (nwora.res) for the 

ORACLE_SID, as described in “NWORA SID resources” on page 186. 

NMO cannot retrieve the connection strings from the RMAN script when the 

connection strings are included as a command file in the script. In this case, NMO 

must retrieve the connection strings from the connection file specified by the 

parameter in the NWORA resource file. 

◆ Ensure that the NetWorker server is release 7.4 or later, to support staging of the 

NMO save set bundles. 

◆ In a RAC system, ensure that all channels are allocated on the same NMO client 

node where the backup is initiated. Save set bundling does not support load 

balancing across different RAC nodes. 

To disable save set bundling, set the NSR_BUNDLING parameter value to disabled by 

typing the following command: 

nsrnmoadmin -r update NSR_BUNDLING disabled 

This section describes how to manually configure policy uniformity for NMO 

backups. 

As an alternative, you can use the backup configuration wizard to set the 

NSR_INCR_EXPIRATION parameter to enable policy uniformity. “Configuring a 

backup with the NMC wizard” on page 72 provides more information. 

Policy uniformity can be enabled and disabled independently of save set bundling. If 

save set bundling is enabled, as described in “Configure save set bundling” on 

page 91, policy uniformity should also be enabled. 


To enable policy uniformity: 


◆ Set the NSR_INCR_EXPIRATION parameter value to enabled by typing the 

following command: 

nsrnmoadmin -r add NSR_INCR_EXPIRATION enabled 

By default, the NSR_INCR_EXPIRATION parameter is disabled. 





◆ Ensure that NMO scheduled backups are configured properly according to the 


◆ Ensure that the user group privileges for the root or administrative user on the 

NMO client include the Operate NetWorker privileges. The corresponding User 

Group resource is configured on the NetWorker server, as described in 

“NetWorker user group privileges” on page 64. 

◆ If the proper username and password are not located in the RMAN script (for 

example, the connection strings are included as a command file in the RMAN 

script, such as @connection_file), ensure the following: 

The ORACLE_SID parameter is set in the nsrnmo script, as described in 

“Customize the nsrnmo script” on page 79. 

An NWORA SID resource with the NSR_ORACLE_CONNECT_FILE 

parameter setting is created in the NWORA resource file (nwora.res) for the 

ORACLE_SID, as described in “NWORA SID resources” on page 186. 

NMO cannot retrieve the connection strings from the RMAN script when the 

connection strings are included as a command file in the script. In this case, NMO 

must retrieve the connection strings from the connection file specified by the 

parameter in the NWORA resource file. 

◆ In a RAC system, ensure that all channels are allocated on the same NMO client 

node where the backup is initiated. Policy uniformity does not support load 

balancing across different RAC nodes. 

To disable policy uniformity, set the NSR_INCR_EXPIRATION parameter value to 

disabled by typing the following command: 

Configuring a deduplication backup 

nsrnmoadmin -r update NSR_INCR_EXPIRATION disabled 

To configure a deduplication NMO backup: 

1. Review the following sections: 

“Deduplication backups and restores” on page 21 

“Requirements for a deduplication backup” on page 94 

“Best practices for a deduplication backup” on page 94 

2. Follow the configuration steps in “Configure a deduplication backup” on 

page 95. 

Configuring a deduplication backup 93


94 

Requirements for a deduplication backup 

Best practices for a deduplication backup 

Before you configure a deduplication backup, ensure that all of the following 


◆ The NMO client platform and operating system support deduplication. The EMC 

Information Protection Software Compatibility Guide on the Powerlink website 

provides details on the platforms and operating systems that support 

deduplication. 

◆ The NetWorker client and server releases support NMO deduplication. The 

NetWorker Module for Oracle release notes provides more details. 

◆ The Avamar server is installed and configured as a NetWorker deduplication 

node. The NetWorker documentation provides more details. 

◆ The NetWorker backup device (receives only the backup metadata or hash ID 

during the NMO deduplication backup) is configured as an advanced file type 

device (AFTD), as described in the NetWorker administration guide. 

This section provides recommendations on when to use NMO deduplication, and 

configuration tips to improve the performance of a deduplication backup. 

The benefits of deduplication are dependent on the environment. Deduplication may 

be beneficial in a data warehouse environment where the data does not change 

frequently. It may also be beneficial for databases where only a small percentage of 

data is updated repeatedly, or new data is added to a database but the old data does 

not change much. 

Deduplication is not recommended for RMAN incremental backups. During an 

incremental backup, Oracle transmits only the data blocks that have changed, which 

guarantees a very low rate of duplication. When the overhead of deduplicating data 

is added to the overhead of an Oracle incremental backup, the result is decreased 

performance and insignificant benefits for the amount of data stored. 

During planning and configuration of a deduplication backup, keep in mind these 

best practices that can improve the backup performance: 

◆ Do not create more than four backup channels for a deduplication backup. 

◆ Do not use RMAN multiplexing for a deduplication backup. To disable 

multiplexing, ensure that filesperset is set to 1. 

If you use the wizard to configure the deduplication backup, ensure that the 

Filesperset field is set to 1 on the Specify the RMAN Options (Part 1 of 2) screen. 

◆ Do not use RMAN binary compression (for example, ZLIB) with a deduplication 

backup. 

◆ Do not include a deduplication client in the same group as non-deduplication 

clients. 

◆ Once a deduplication node (Avamar server) is selected for an initial full backup 

of a client, continue to use the same deduplication node for all of the client's 

backups, to take advantage of the data already stored on the server. 


Configure a deduplication backup 


◆ Schedule a deduplication backup to avoid the Avamar server read-only periods. 

An Avamar server spends periods of time in maintenance mode, where it may be 

unavailable for backup or have limited bandwidth. 

Note: A deduplication NMO backup that runs during such a maintenance mode period 

may be suspended until the Avamar server resources become available. 

◆ Ensure that the same cache is used to back up the same data every time by not 

changing the values of the parameters NSR_DEDUP_CACHE_ENABLED and 

NSR_DEDUP_CACHE_TAG. The following sources provide more details: 

“NSR_DEDUP_CACHE_ENABLED” on page 203 

“NSR_DEDUP_CACHE_TAG” on page 204 

◆ Associate the backup of specific tablespaces with a specific channel to ensure that 

Oracle does not distribute the data to a different channel when the database 

structure or size changes. 

For example, the following RMAN backup script shows how to associate 

tablespaces with a channel: 

run { 

allocate channel c1 type 'SBT_TAPE'; 

send channel c1 'NSR_ENV=(NSR_DEDUP_CACHE_TAG=orcl102_c1)'; 


send channel c2 'NSR_ENV=(NSR_DEDUP_CACHE_TAG=orcl102_c2)'; 

send 'NSR_ENV=(NSR_DEDUP_BACKUP=TRUE, 

NSR_DEDUP_NODE=avamar.emc.com)'; 

backup filesperset=1 

(tablespace tbs1, tbs5 channel c1) 

(tablespace tbs2, tbs3, tbs4 channel c2); 

release channel c1; 


} 

◆ Group tablespaces that contain similar (duplicated) data and associate them with 

the same channel. This practice requires familiarity with the database data. A 

tablespace must also be added to the backup script when a new tablespace is 

created. 

Avamar and NetWorker documentation provides more information on Avamar 

server and NetWorker requirements for deduplication backups. 

To configure a scheduled deduplication backup, you can use either the configuration 

wizard or the legacy configuration method. 

Note: You must configure a manual deduplication backup with the legacy method only. 

However, you can generate the base RMAN script for a manual backup with the configuration 

wizard, described in “Configuring a backup with the NMC wizard” on page 72. 

◆ To use the configuration wizard (for a scheduled backup only), follow the 

instructions in “Configuring a backup with the NMC wizard” on page 72. 

On the Specify the De-duplication Options screen, apply these additional 

settings: 

Select to enable deduplication. 

Specify the hostname of the deduplication node (Avamar server) that will 

store the deduplicated backup data. 

Configuring a deduplication backup 95


96 

When you select to enable deduplication, the wizard automatically sets the 

parameter NSR_DEDUP_CACHE_TAG for each channel. 

Note: You cannot override the default NSR_DEDUP_CACHE_TAG setting. 

◆ To use the legacy configuration method (without the wizard), follow the 

instructions in “Configuring a backup with the NMC legacy method” on page 75. 

Note: For a manual deduplication backup, the Client resource needs to include only the 

two attribute settings in step a on page 96. 

Apply these additional settings for a deduplication backup: 

a. Set the following attributes in the Client resource for the NMO client by using 

NMC: 

– Select the De-duplication Backup attribute, to enable deduplication. 

– For the De-duplication Node attribute, specify the hostname of the 

deduplication node (Avamar server) that will store the deduplicated 

backup data. 

Note: For a manual deduplication backup, the De-duplication Node attribute must 

have the same value as the NSR_DEDUP_NODE setting in the RMAN script. 

b. Set the following parameters in the RMAN backup script, if required: 

– “NSR_DEDUP_BACKUP” on page 203 (for a manual backup only) 

– “NSR_DEDUP_CACHE_TAG” on page 204 

– “NSR_DEDUP_NODE” on page 204 (for a manual backup only) 

Example 13 on page 96 shows a sample RMAN script for a manual 


For a scheduled deduplication backup, if the Client resource contains the two 

attribute settings described in step a on page 96, the RMAN script must not 

include the parameters NSR_DEDUP_BACKUP and NSR_DEDUP_NODE. 

Example 13 RMAN script for a manual deduplication backup 

The following RMAN script shows the mandatory parameter settings for a manual 

deduplication backup. The NSR_DEDUP_CACHE_TAG parameter must be set to a 

different value for each allocated channel: 

run { 

allocate channel ch1 type 'SBT_TAPE'; 

allocate channel ch2 type 'SBT_TAPE’'; 

send 'NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_CLIENT=oracle.emc.com, 

NSR_DEDUP_BACKUP=TRUE, NSR_DEDUP_NODE=node3.emc.com)'; 

send channel ch1 'NSR_ENV=(NSR_DEDUP_CACHE_TAG=ora11_ch1)'; 

send channel ch2 'NSR_ENV=(NSR_DEDUP_CACHE_TAG=ora11_ch2)'; 

backup full filesperset 4 format 'FULL_%d_%U' (database); 



} 


Configuring a probe-based backup 

Requirements for a probe-based backup 

Configure a probe-based backup 

To configure a probe-based NMO backup: 

1. Review the following sections: 

“Probe-based backups” on page 23 


“Requirements for a probe-based backup” on page 97 

2. Follow the configuration steps in “Configure a probe-based backup” on page 97. 

Before you configure a probe-based backup, ensure that the following requirements 

are met: 

◆ The required NetWorker releases are installed, as described in the NetWorker 

Module for Oracle release notes. 

◆ If you want to use the nsrnmoprobe program provided with NMO to check for 

the number of Oracle logs generated since the last probe-based backup (as a 

condition that triggers a probe-based backup), ensure that you have reviewed the 

details on nsrnmoprobe in “Configure a probe-based backup” on page 97. 

◆ If you want to check for a user-defined condition (other than the number of 

generated Oracle logs) that triggers a probe-based backup, a script/program is 

created that meets the requirements of the Probe Command attribute of the Probe 

resource, as described in “Configure a probe-based backup” on page 97. 

For example, the user-defined condition that triggers a probe-based backup is 

that more than two tape drives are idle in a jukebox. To check for this condition, a 

script named nsrjukeboxprobe is created in the /usr/sbin directory on Solaris. 

When the script runs and checks the number of idle tape drives in the jukebox, it 

returns one of the following values: 

0 — Signifies that more than two tape drives are idle in the jukebox. 

1 — Signifies that two or fewer tape drives are idle in the jukebox. 

Other than 0 or 1 — Signifies that an error occurred during the probe. 

The NetWorker administration guide provides more information on user-defined 

probes in the section on creating a client probe. 

To configure a probe-based NMO backup: 

1. Create a separate NetWorker Probe resource for the nsrnmoprobe program and 

any other script/program that checks for a user-defined condition. Set the Probe 

resource attributes as described in Table 6 on page 98. 

Configuring a probe-based backup 97


98 


Table 6 NetWorker Probe resource attributes 

Name Name of the Probe resource for the probe script/program used to check for a probe-based backup condition. Each Probe 

resource must have a unique name, which does not have to be the same as the probe script/program name. 

Probe Command Name and path of the probe script/program that checks (“probes”) for the condition that triggers a probe-based backup. The 

script/program meets the following requirements: 

Name starts with nsr or save. 

Location is the same directory as used for the NetWorker client binaries. 

Permissions of the script/program file include the “execute” permission. 

Returns one of the following code values when it finishes running its probe: 

- 0 — Signifies that the backup condition has been met. 

- 1 — Signifies that the backup condition has not been met. 

- Other than 0 or 1 - Signifies that an error occurred during the probe. 

To use the probe program that is included with the NMO software, set this attribute to nsrnmoprobe. The nsrnmoprobe 

program checks for the number of Oracle logs generated since the last probe-based backup and triggers a new probe-based 

backup when the number exceeds the change threshold. 

Command Options Required for the nsrnmoprobe program only, a comma-separated list of the settings of one or more of the following 

parameters. Example 14 on page 99 outlines the parameter settings that nsrnmoprobe requires in each possible scenario. 

Parameter Description 

LOG_THRESHOLD Mandatory. Specifies the change threshold, which is the minimum number of redo logs 

(generated since the last probe-based backup) required to trigger a new probe-based 

backup. When the number of logs generated since the last probe-based backup equals 

or exceeds the change threshold, nsrnmoprobe triggers a probe-based backup. 

NSR_DEBUG_FILE Optional. Specifies the pathname of the log file that receives debug information from 

the probe-based backup triggered by nsrnmoprobe. 

NSR_ORACLE_CONNECT_FILE Set only if both of the following are true: 

The Client resource is not configured with the wizard; it is configured through the 

legacy method with NMC. 

The NWORA resource file is not set up with the Oracle home and database 

connection information. 

Specifies the pathname of the RMAN connection file, which contains the connection 

strings required to connect to the Oracle database that is to be probed. 

Example 14 on page 99 provides a sample setting of this parameter. 

ORACLE_HOME Set only if both of the following are true: 



The NWORA resource file is not set up with the Oracle home and database 


Specifies the home directory pathname for the Oracle database that is to be probed. 


ORACLE_SERVICE Set only if both of the following are true: 



The NWORA resource file is set up with the Oracle home and database connection 

information through the command nsrnmoadmin –r add sid=Net_service_name 

home=Oracle_home connect=connect_filepath. 

Specifies the Net service name for the Oracle database that is to be probed. In this 

case, the ORACLE_SERVICE setting must be the same as the NSR_ORACLE_SID 

setting in the NWORA resource file. 




Note: The State attribute of the Probe resource is visible only in diagnostic mode. At the 

end of each successful probe-based backup, the nsrnmoprobe program stores the current 

log sequence number and database instance number in the State attribute. The State 

attribute is not used with user-defined probes. 

2. Configure the NetWorker Group resource for a probe-enabled backup group. Set 

the probe-specific attributes in the Group resource, as described in the NetWorker 

administration guide (the section on creating and scheduling a probe group). The 

Group resource has been extended to include several new attributes that must be 

set for a probe-based backup group. 

When probing is enabled through the Group resource attributes, probing occurs 

continuously throughout the backup window, which is the time window defined 

by the Probe Start Time and Probe End Time attributes. 

Note: If a probe-enabled backup group is started manually, probing occurs immediately 

(only once, not repeatedly at intervals) and the backup starts only if the probe conditions 

are met. 

3. Configure the NetWorker Client resource for the NMO client according to the 

instructions in the appropriate section: 

“Configuring a backup with the NMC wizard” on page 72 

“Configure a Client resource with NMC” on page 87 

In the Client resource: 

For the Probe attribute, specify the name of the required Probe resource from 

step 1. This attribute associates the Client resource with the probe 

script/program specified in the Probe resource. 

Note: A Client resource can be associated with only one probe. 

The configuration wizard does not display the Probe field. If you configure a Client 

resource with the wizard, you must then use NMC manually to edit the Client resource 

and set the Probe attribute. 

For the Group attribute, specify the probe-enabled group from step 2. 

Note: A probe-based backup group must include at least one probe-enabled client. 

Example 15 on page 100 describes the configuration of a probe-based backup that 

is triggered by both nsrnmoprobe and a user-defined probe. 

Example 14 Possible Command Options settings for the nsrnmoprobe program 

To use the nsrnmoprobe program that is provided with the NMO software, the Probe 

resource must be set up properly, as described in “Configure a probe-based backup” 

on page 97. 



100 

The Command Options attribute in the Probe resource must include specific 

parameter settings, which depend on the particular scenario: 

◆ The LOG_THRESHOLD parameter is always mandatory. 

◆ The NSR_DEBUG_FILE parameter is optional. 

◆ Three possible scenarios dictate the required settings in the Command Options 

attribute: 

a. The Client resource has been configured through the legacy method with 

NMC (not with the wizard), and the NWORA resource file has not been set up 

with the Oracle home and database connection information. 

In this case, Command Options must include the parameters 

LOG_THRESHOLD, NSR_ORACLE_CONNECT_FILE, and 

ORACLE_HOME. (NSR_DEBUG_FILE is optional.) 

For example, Command Options is set as follows: 

LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log, 

NSR_ORACLE_CONNECT_FILE=/RMAN/rmanpw, 

ORACLE_HOME=/oracle/hp_11_31_ia/64bit/product/11.1.0.6.0 

b. The Client resource has been configured with the wizard, and the NWORA 

resource file has not been set up with the Oracle home and database 


In this case, Command Options must include the LOG_THRESHOLD 

parameter. (NSR_DEBUG_FILE is optional.) 


LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log 

c. The Client resource has been configured through the legacy method with 

NMC (without the wizard), and the NWORA resource file is set up to retrieve 

Oracle home and database connection information. 

In this case, the NWORA resource file must be set up through the command 

nsrnmoadmin –r add sid=Net_service_name home=Oracle_home 

connect=connect_filepath. Command Options must include the parameters 

LOG_THRESHOLD and ORACLE_SERVICE, where ORACLE_SERVICE is set 

to the same Net service name as NSR_ORACLE_SID in the NWORA file. 

(NSR_DEBUG_FILE is optional.) 


page 188 provides important details on the nsrnmoadmin command. 


LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log, 

ORACLE_SERVICE=proddb.world 

Example 15 Multiple probes for a probe-based backup 

A probe-based backup is triggered when both of the following are true: 

◆ At least 25 Oracle log files are generated on an NMO client named mars. 

◆ More than two tape drives are idle in a jukebox, attached to a NetWorker storage 

node named marmaris. (The jukebox is used to save the data for the probe-based 

backup.) 

Both the NMO client and storage node are Solaris machines. 



The nsrnmoprobe program is installed with the NMO software in /usr/sbin on the 

NMO client. The nsrnmoprobe program checks for the number of Oracle log files 

generated on the NMO client. 

A script named nsrjukeboxprobe is created with “execute” permissions and stored in 

the /usr/sbin directory on the storage node. The script checks for the number of idle 

tape drives in the jukebox, and returns either of two values: 

◆ 0 — Signifies that more than two tape drives are idle in the jukebox. 

◆ 1 — Signifies that two or fewer tape drives are idle in the jukebox. 

To configure the probe-based backup, the following steps are performed: 

1. A Probe resource is created for the nsrnmoprobe program with the following 

attribute settings: 

Name — NMO probe 

Probe Command — nsrnmoprobe 

Command Options — LOG_THRESHOLD=25, 

NSR_DEBUG_FILE=/tmp/probe.log 

2. A Probe resource is created for the user-defined probe with the following 

attribute settings: 

Name — Jukebox probe 

Probe Command — nsrjukeboxprobe 

3. A Group resource is created with the required attribute settings for the 

probe-enabled backup group, including the following: 

Name — probe_group 

Probe Based Backup — Enabled (this is a checkbox in NMC) 

Probe Success Criteria — All 

4. A Client resource is created for the NMO client through the configuration wizard. 

The Client resource includes the following attribute settings: 

Name — mars 

Backup Command — nsrnmostart -C 

Group — probe_group 

Probe — NMO probe 

Save Set — RMAN:/orcl102_FULL 

5. A Schedule resource is created with the following attribute settings: 

Name — SkipAll 

Period — Either Week or Month 

Calendar — Skip level is selected for every day in the period 

6. A “dummy” Client resource is created for the storage node through the legacy 

method (without the wizard). The Client resource includes the following attribute 

settings: 

Name — marmaris 

Backup Command — (blank) 

Group — probe_group 



102 

Probe — Jukebox probe 

Save Set — SKIP (a keyword is required in this attribute) 

Schedule — SkipAll 

Note: The Skip level in the SkipAll schedule causes the backup to be skipped on the 

storage node. The probe runs on the storage node as specified through the Group 

resource; the probe is not affected by the Schedule resource. 



3 

Backup Procedures 

◆ Manual backup procedures ....................................................................................... 104 

◆ Scheduled backup procedures ................................................................................... 110 

◆ Regular backup information in NetWorker indexes............................................... 114 

◆ Deduplication backup information in NetWorker indexes.................................... 115 

Backup Procedures 103


104 

Manual backup procedures 

! 

To perform a manual NMO backup of Oracle data: 

1. Review information in “Product features” on page 20 about the features that 

apply to your particular backup. 

2. Review “Requirements for a manual backup” on page 104. 

3. Review the information on how to cancel a manual backup in “Cancel a manual 

backup” on page 107. 

4. Perform the manual backup by either of the following methods: 

Use the RMAN command line interface, according to “Manual backup 

through the RMAN command line interface” on page 105. 

Use the Oracle Enterprise Manager Backup Management Tools, according to 

“Manual backup through Oracle Enterprise Manager Backup Management 

Tools” on page 105. 

IMPORTANT 

Requirements for a manual backup 

The NetWorker server bootstrap and client indexes are not automatically backed 

up at the end of a manual Oracle backup, as they are for a scheduled Oracle 

backup. After running a manual Oracle backup, perform a NetWorker server 

bootstrap backup according to “NetWorker server bootstrap backup” on page 106. 

Regular NetWorker server bootstrap backups help to ensure adequate preparation 

for disaster recovery. 

“Monitor a manual backup” on page 108 provides information on how to monitor the 

status of a manual NMO backup. 

“Scheduled backup procedures” on page 110 provides information on scheduled 

NMO backups. 

Before starting a manual backup, ensure that the required configurations and scripts 

are in place: 

◆ The Oracle system is properly configured, as described in Chapter 2, “Software 

Configuration.” 

The Oracle Server has the Net service configured. If a Recovery Catalog is to be 

used, the Recovery Catalog is set up and the target database registered. 

◆ The NetWorker server has the required resources configured, as described in 

Chapter 2, “Software Configuration”: 

Server 

Client 

Device 

Pool 

◆ If using an RMAN script for the manual backup, the script is created, as described 

in “Create RMAN scripts for backups” on page 75. 



◆ The required backup devices and volumes are set up: 

A volume is labeled (and mounted, as required) in each configured backup 

device. 

If auto media management is enabled for a tape device or autochanger, a tape 

is loaded in the tape device or autochanger for the NetWorker server to use 

automatically. 

Manual backup through the RMAN command line interface 

! 

A manual Oracle backup can be started by using the RMAN command line interface 

on the Oracle Server host. 

If the RMAN script for a manual backup from Example 10 on page 75 is stored in the 

file /disk1/scripts/full_backup.txt on a UNIX Oracle Server, and the Net service has 

been configured to connect to the databases payroll and rcvcatdb, then the manual 

Oracle backup can be started with the following command: 

rman target internal/oracle@payroll rcvcat rman/rman@rcvcatdb cmdfile 

\’/disk1/scripts/full_backup.txt\’ 

On Microsoft Windows, the command to run the RMAN script is rman.exe. The 

appropriate Oracle backup and recovery documentation provides more information 

on the rman or rman.exe command line options. 

IMPORTANT 

The NetWorker server bootstrap and client indexes are not automatically backed 

up at the end of a manual Oracle backup, as they are for a scheduled Oracle 

backup. After running a manual Oracle backup, perform a NetWorker server 

bootstrap backup according to “NetWorker server bootstrap backup” on page 106. 

Regular NetWorker server bootstrap backups help to ensure adequate preparation 

for disaster recovery. 

“Cancel a manual backup” on page 107 provides information on how to cancel a 

manual NMO backup. 

Manual backup through Oracle Enterprise Manager Backup Management Tools 

! 

The Oracle Enterprise Manager Backup Management Tools can be used instead of the 

RMAN command line interface to start an Oracle database backup. The Oracle 

Enterprise Manager Backup Management Tools include a graphical user interface to 

RMAN for generating the required RMAN commands and performing backup and 

restore operations. 

IMPORTANT 

After the completion of an NMO backup or restore, the Oracle Enterprise Manager 

job queue history displays the status of the job as “failed”, even if the backup or 

restore completed successfully. This is due to a known problem with Oracle 

Enterprise Manager. View the job output to confirm that the backup or restore 

completed successfully. 

The Oracle Enterprise Manager documentation included with the product kit 

provides more information on using the Oracle Enterprise Manager Backup 

Management Tools. 

Manual backup procedures 105


106 

NetWorker server bootstrap backup 

The bootstrap is a special save set that the NetWorker server software creates in 

preparation for disaster recovery. The bootstrap save set contains the information 

needed to restore the online NetWorker indexes and resource configuration files to 

the state just before the bootstrap was created. 

The NetWorker server automatically performs a backup of its bootstrap and the client 

index of the Oracle Server only at the end of a scheduled Oracle backup. This is done 

by the NetWorker savegrp program that performs the scheduled backup. 

Note: If only manual (unscheduled) Oracle backups are run, and the client index and bootstrap 

are not backed up manually, then no backups of the online client index and NetWorker server 

bootstrap will be available for use in the event of a disaster recovery on the NetWorker server. 

After finishing a manual Oracle backup, the bootstrap and client index must also be 

backed up. 

Back up the bootstrap and index 

To back up the NetWorker server bootstrap and index: 

1. Log in as follows: 

On a UNIX NetWorker server as the root user. 

On a Windows NetWorker server as the Windows system administrator. 

2. Type the following savegrp command: 

savegrp -O -l full -P printer_name -c Oracle_Server_name 

-c NetWorker_server_name 

where: 

printer_name is the name of the printer where the bootstrap information is 

printed at the end of the bootstrap backup. 

Oracle_Server_name is the hostname of the Oracle Server. 

NetWorker_server_name is the hostname of the NetWorker server. 

After successfully backing up the bootstrap and the client index by using the savegrp 

command: 

◆ Confirmation of the savegrp completion appears in the NetWorker Administrator 

program. 

◆ Information is sent to the printer_name printer about the saved bootstrap. 

Note: Store the bootstrap printout in a safe place. The printed bootstrap information includes 

dates, locations, and save set ID numbers for the bootstrap save sets backed up during the past 

month. With this information, determine which volumes are needed to recover the NetWorker 

indexes and resource configuration files during a disaster recovery. 

The following sources provide information on the savegrp command and options: 

◆ NetWorker administration guide for the particular NetWorker server platform 

◆ savegrp entry in the NetWorker command reference guide 

◆ savegrp man page on UNIX 

The NetWorker administration guide provides information on bootstrap backups. 


Cancel a manual backup 


The NetWorker disaster recovery guide provides information on how to use the 

bootstrap backup during a disaster recovery. 

To keep the NetWorker index and RMAN catalog synchronized, ensure that the 

Oracle user has the required NetWorker privileges for removing NetWorker index 

entries before you cancel a manual Oracle backup. “Specify the required NetWorker 


The following sections describe how to cancel a running or nonresponding manual 

backup. 

Cancel a running manual backup 

To cancel a running manual Oracle backup (not including a backup initiated by 

Oracle Enterprise Manager) during the RMAN script execution on any platform, 

press either Ctrl+C, or the equivalent “attention” key combination on the system. 

Note: If this method of canceling a manual Oracle backup is not successful, use the alter 

system kill command described in “Cancel a scheduled backup” on page 111. 

Cancel a nonresponding manual backup 

The following are the steps for canceling a nonresponding Oracle backup. However, 

if these steps do not work, contact Oracle for assistance. 

Note: When using these steps, NMO does not attempt to remove the backup save set entries 

from the NetWorker index. As a result, the NetWorker index and RMAN catalog might 

become unsynchronized. 

To cancel a nonresponding Oracle backup on UNIX: 

1. Include the set command id to ‘xxx’ command in the RMAN backup script that is 

used for the Oracle backup. Otherwise, the query in the next step will fail. 

Example 12 on page 77 provides a sample script with the command. 

2. Run the following query in the Oracle svrmgrl or sqlplus program to determine 

the Oracle process ID that corresponds to each RMAN channel: 

select spid, client_info from v$process p, v$session s where 

p.addr=s.paddr and client_info like ‘%id=%‘; 

3. Type the following kill command to cancel the Oracle backup process: 

kill -9 pid 

where pid is the appropriate Oracle process ID. 

To cancel a nonresponding Oracle backup on Windows, stop the nsrsbtcn.exe 

process in Task Manager. 



108 

Monitor a manual backup 

To monitor the status of Oracle backup and restore operations, use the NMC interface 

program. 

The NetWorker server program displays progress and completion messages that 

advise when a backup or restore is complete, and information on why a backup or 

restore cannot proceed. The NetWorker administration guide provides more 

information on viewing these types of messages with the NetWorker program. 

Appendix C, “Troubleshooting and Error Messages,” provides information on how 

to obtain RMAN-specific and NMO diagnostic and error messages. 

The following figures show the types of Oracle backup messages displayed in the 

Monitoring Window of the NMC interface: 

◆ Figure 8 on page 108 shows messages displayed in the Sessions tab. 

◆ Figure 9 on page 109 shows messages displayed in the Devices tab. 

◆ Figure 10 on page 109 show messages displayed in the Log tab. 



Figure 8 Oracle backup messages in Sessions tab of Monitoring window 


Figure 9 Oracle backup messages in Devices tab of Monitoring window 

Figure 10 Oracle backup messages in Log tab of Monitoring window 




110 

Scheduled backup procedures 

To prepare for a scheduled NMO backup of Oracle data: 

1. Review information in “Product features” on page 20 about the features that 

apply to your particular backup. 

2. Ensure that the required backup configurations are in place, as described in 


3. Run a test scheduled Oracle backup according to “Test a scheduled backup” on 

page 110. 

4. Review the steps for canceling a scheduled backup in “Cancel a scheduled 

backup” on page 111. 

At the end of a successful scheduled backup, NMO automatically backs up the 

NWORA resource file if it exists, as described in “NWORA resource file backup” on 

page 173. 

“Monitor a scheduled backup” on page 112 provides information on how to track the 

status of scheduled backups. 

The following sections describe the backup information stored in the NetWorker 

indexes: 

◆ “Regular backup information in NetWorker indexes” on page 114 

◆ “Deduplication backup information in NetWorker indexes” on page 115 

Test a scheduled backup 

After the NMO environment for scheduled backups on the Oracle Server is set up, 

test a scheduled backup manually by using the NMC program. 

Before starting the backup, check for the following: 

◆ All the required parameters have been set, either through the wizard or through 

the legacy method in the nsrnmo and RMAN scripts. 

◆ For a legacy configuration, any required preprocessing and postprocessing 

scripts (optional) are in place. 

◆ The NetWorker server and Oracle Server have been correctly configured. 

Test a scheduled backup as follows: 

1. Start the NMC program as the root user on UNIX, or as the administrator 

Microsoft user on Windows. 

2. Select the appropriate NetWorker server to perform the backup. 

3. Select the correct group name for the backup. 

4. Start the scheduled backup for the specified group. 

The NetWorker software immediately backs up the clients in the backup group. 

The NetWorker administration guide and NMC online help provide information on 

how to use the NMC interface to perform these steps. 

A savegroup completion report in email provides the scheduled backup results. 



Note: “Cancel a scheduled backup” on page 111 provides information on how to cancel the 

scheduled Oracle backup. 

Scheduled backup error messages 

If the scheduled backup fails, an error message is produced. The NetWorker 

administration guide provides information on how to obtain more details about the 

scheduled backup by using the NetWorker administration program. 

For additional debug information, set the NSR_SB_DEBUG_FILE parameter through 

one of the following methods: 

Cancel a scheduled backup 

◆ Use the configuration wizard to set the parameter in the Advanced Environment 

Options field on the Specify the Environment Options (Optional) screen. 

◆ Use the legacy configuration method to set the parameter in the nsrnmo script. 

“NSR_SB_DEBUG_FILE” on page 83 provides details on the parameter. 

If the scheduling portion of a scheduled NMO backup succeeds but the actual backup 

fails, error messages and debug information might be generated in the locations 

described in “RMAN error messages” on page 221. 

To keep the NetWorker index and RMAN catalog synchronized, ensure that the 

Oracle user has the required NetWorker privileges for removing NetWorker index 

entries before canceling a scheduled Oracle backup. “Specify the required NetWorker 


NMO currently supports use of the Stop button in the NetWorker Administrator 

program to cancel a running scheduled Oracle backup only if the NetWorker server 

and Oracle Server are both running on UNIX platforms. 

The level of Stop button support depends on the NetWorker server operating system 

(where the Oracle Server operating system is already assumed to be UNIX): 

◆ If the NetWorker server system is UNIX, then the Stop button is supported. 

◆ If the NetWorker server system is Windows, then the Stop button is not 

supported. 

Note: Although the progress message might indicate that the backup has exited 

prematurely (before finishing), the NMO processes might still be running on the Oracle 

Server host. 

To cancel a running scheduled Oracle backup when the Stop button does not work, 

the running rman process must be interrupted on the Oracle Server host: 

1. In the NetWorker Administrator program, click the Stop button to prevent NMO 

from retrying the backup. 

2. For each allocated channel, perform the following: 

a. View the RMAN message log file to determine the Oracle session ID for the 

channel. (The log filename is specified in the NSR_RMAN_ARGUMENTS 

parameter, set either through the Advanced Environment Options field in the 

wizard or through the nsrnmo script in a legacy configuration.) 

Scheduled backup procedures 111


112 

Monitor a scheduled backup 

For example, the following sample line from an RMAN message log shows 

that channel ch1 has the Oracle session ID 15: 

channel ch1: sid=15 devtype=SBT_TAPE 

b. Run the following select command in the Oracle svrmgrl or sqlplus program 

to determine the serial number: 

select serial# from v$session where sid=session_id; 

where session_id is the Oracle session ID from the RMAN message log in 

step a. 

c. Run the following alter system command in the Oracle svrmgrl or sqlplus 

program to terminate the channel: 

alter system kill session ‘session_id, serial#’; 

where: 

– session_id is the Oracle session ID from step a. 

– serial# is the serial number from step b. 

“Cancel a nonresponding manual backup” on page 107 describes how to also cancel a 

nonresponding scheduled backup. 

Scheduled Oracle backups can be monitored the same way as manual Oracle 

backups. “Monitor a manual backup” on page 108 provides more information. 

In addition, messages appear in the appropriate Group window in the NetWorker 

server program and a report is generated upon completion of a scheduled Oracle 

backup. 

Information about scheduled NMO backups is displayed on the Groups and Sessions 

tabs of the Monitoring window in the NMC interface program: 

◆ During the backup, the Sessions tab lists one save session for each channel used 

by NMO for the backup. The display shows the rate of data being backed up and 

total size of the backed-up data. 

◆ After the backup, the Groups tab enables you to select the backup group and 

display details about the group, including the “Completed successfully” box that 

contains one entry for each channel used by NMO for the backup. Figure 11 on 

page 113 shows the type of group details displayed, including the size of each 

save set. 

Note: For a deduplication backup, the NMC display shows the total size of the data prior to 

deduplication, not the size of the deduplicated data. The display also does not indicate that the 

data is for a deduplication backup that is stored on the Avamar server. 

The NetWorker administration guide provides details on viewing information about 

scheduled backups in the NMC program. 


Figure 11 Group details for regular scheduled backups 

Automation of NSR_SERVER and NSR_GROUP parameter settings 

! 


Note: The information in this section is applicable to a legacy configuration only, not to a 

configuration set up through the NMO 5.0 wizard. 

The parameters NSR_SERVER and NSR_GROUP must not be set in a scheduled 

backup RMAN script. NMO automatically passes server and group information 

(received from the NetWorker server that started the backup) to Oracle Server 

processes, created for each allocated channel. 

NMO also passes an internal parameter, NSR_SAVESET_NAME, to set the save set 

name. 

IMPORTANT 

Do not set the parameter NSR_SAVESET_NAME. 

To pass the information to the Oracle Server processes, NMO invokes the RMAN 

executable with send as a command line option. “The send command” on page 211 

provides more information. 

Scheduled backup procedures 113


114 

Regular backup information in NetWorker indexes 

The NetWorker server maintains information about each backup in its online 

indexes. Chapter 1, “Introduction,”provides more information about the online 

indexes. 

This section describes the information maintained in the NetWorker indexes for 

regular manual and scheduled backups. “Deduplication backup information in 

NetWorker indexes” on page 115 describes information about deduplication 

backups. 

The NetWorker client file index contains the filename backup_piece_name for the save 

set name for either a manual or scheduled NMO backup. 

The NetWorker media database contains the following information, depending on 

the type of backup and the NetWorker server version used to perform the backup: 

◆ For a manual backup, the name RMAN:backup_piece_name for the save set name. 

◆ For a scheduled backup with a NetWorker server release prior to 7.3.2, the value 

from the Save Set field of the Client resource for the save set name. 

◆ For a scheduled backup with NetWorker server release 7.3.2 or later, the name 

RMAN:backup_piece_name for the save set name. 

Query the online NetWorker indexes by using the NetWorker commands, nsrinfo 

and mminfo. 

◆ To query the client file index, use the nsrinfo command. For example: 

nsrinfo -n oracle -s NetWorker_server_hostname 

Oracle_Server_hostname 

◆ To query the media database, use the mminfo command. For example: 

mminfo -v -s NetWorker_server_hostname -c Oracle_Server_hostname 


information on these NetWorker commands. 

The following examples show the command output for a manual or scheduled NMO 

backup, where the backup piece is named 1hiu83f4_1_1 and the scheduled backup is 

performed with NetWorker server release 7.3.2 or later: 

◆ The client file index includes the backup piece name for the save set: 

nsrinfo -n oracle -s ca-oracle1 ca-oracle1 

1hiu83f4_1_1, date=1192133159 Thu Dec 11 16:05:59 2008 

◆ The media database includes the prefix RMAN: with the backup piece name for 

the save set: 

mminfo -v -s ca-oracle1 -c ca-oracle1 

volume client date time size 

NMO.001 ca-oracle1 12/11/08 16:05:59 145 MB 

ssid fl level name 

4212032038 cb full RMAN:1hiu83f4_1_1 

Note: The media database also includes information about the bootstrap, index, and NWORA 

resource file backups that occur as part of each scheduled backup. The preceding mminfo 

command sample does not show the bootstrap, index, and NWORA resource file information 

for the scheduled backup. 



Cross-check the client file index and media database by using the save time. For 

example: 

mminfo -c ca-oracle1 -t 1192133159 

nsrinfo -n oracle -t ’12/11/08 16:05:59’ ca-oracle1 

Deduplication backup information in NetWorker indexes 

The deduplication backup information maintained in the NetWorker indexes is for 

the NetWorker save set stored on the NetWorker storage node, which contains only a 

single file with the hash ID and NetWorker metadata for the backup. 

Note: The backup size recorded in the NetWorker indexes does not match the amount of data 

backed up during the deduplication backup. 

The following examples show the index query results from the nsrinfo and mminfo 

commands, where the backup piece is named 35ji3i75_1_1: 

◆ As for a regular backup, the client file index includes the backup piece name for 

the save set of the deduplication backup: 

nsrinfo -n oracle -vV molecule 

UNIX file '35ji3i75_1_1', size=212, off=0, app=oracle(25), 

date=1212610342 Wed Jun 04 16:12:22 2008, (unknown fid), file size=0 

In this case, the size of the backup piece is the size of the Avamar hash ID (20 

bytes) plus the size of the NetWorker metadata that contains the backup piece 

name. 

◆ To query the media database, use the mminfo command with the -q dedupe 

option (displays only save sets created through deduplication) and the -S option 

(lists the extended options for the deduplication backups): 

mminfo -S -q dedupe 

ssid=1330050855 savetime=06/04/08 16:12:22 (1212610342) 

RMAN:35ji3i75_1_1 level=full sflags=vF size=216 files=1 

insert=06/04/08 create=06/04/08 complete=06/04/08 browse=07/04/08 

23:59:59 retent=06/04/09 23:59:59 

clientid=08b98b33-00000004-4824ae51-4824ae45-000c0000-80de6f33 

*Client path: /NetWorker/server_name/client_name; 

*Data set size: 34000000; 

*De-Dup session id: 27; 

*De-Dup snapup time: 2008-06-04; 

*De-duplication: Yes; 

*De-duplication host: scip2d088.lss.emc.com; 

*Domain: /NetWorker/server_name; 

*New data on De-Dup Node: 6899656.00; 

*New files: 1; 

*Replication host: scip2d089.legato.com; 

*Size on De-Dup Node: 34603008.00; 

group: Default; 

Clone #1: cloneid=1212610343 time=06/04/08 16:12:23 

retent=06/04/09 flags=F frag@ 0 volid=1648811587 

file/rec=1330050855/0 rn=0 last=06/04/08 

The save file size reported by mminfo is the same as that reported by nsrinfo, 

except for an extra four bytes due to a NetWorker end-of-save-set marker. 

When a deduplication backup is deleted (for example, by a user or the NetWorker 

server), the backup information is deleted immediately from the NetWorker indexes, 

and a request is queued for deletion of the backup from the Avamar server. The 

Deduplication backup information in NetWorker indexes 115


116 

NetWorker documentation provides more information on deletion of deduplication 

backups. 

Once a deduplication save set passes its retention time and its data chunks are 

deleted from the Avamar server, the save set may no longer be recoverable with the 

scanner program. 


This chapter includes the following sections: 

4 

Data Restore and 

Recovery 

◆ About restore and recovery ........................................................................................ 118 

◆ RMAN scripts for restore and recovery................................................................... 121 

◆ Performing an Oracle data restore and recovery.................................................... 123 

Data Restore and Recovery 117

Data Restore and Recovery 

118 

About restore and recovery 

Only Oracle data that has been backed up according to the instructions in Chapter 3, 

“Backup Procedures,”can be restored. 

Note: The NetWorker server interface cannot be used to restore Oracle data that was backed up 

with NMO. 

Review the following sections in preparation for the Oracle data restore and recovery 

procedures: 

◆ “NetWorker indexes and policies used for restores” on page 118 

◆ “Recovery configuration wizard” on page 118 

◆ “RMAN scripts for restore and recovery” on page 121 

NetWorker indexes and policies used for restores 

Recovery configuration wizard 

During an Oracle backup, the NetWorker server adds an entry for each backup piece 

in the online client file index and records the location of the data in the media 

database. These entries provide information required to restore every Oracle data 

object backed up: 

◆ The client file index entry is maintained until the browse policy specified for the 

client’s save set expires. 

◆ The media database entry is maintained until the retention policy specified for the 

client’s save set expires. 

When the retention policies for all the save sets on a backup volume expire, the 

volume becomes recyclable and eligible for automatic relabeling by the NetWorker 

server. The save set entries, however, remain in the media database until the volume 

is actually relabeled. When the volume is relabeled, the data on it becomes 

inaccessible and can no longer be restored. 

NetWorker Module for Oracle (NMO) uses the client file index entries to restore 

Oracle backup pieces. Set the browse policy to a period long enough to retain the 

client index entries for restoring the Oracle backup pieces. 

Note: After a browse policy expires, the NetWorker scanner program can be used to rebuild 

the online indexes. However, index entries regenerated by using scanner might cause the 

NetWorker indexes to become unsynchronized with the RMAN catalog and lead to problems. 

To avoid problems, ensure that the backup pieces have unique names, as described in “RMAN 

scripts for manual backups” on page 75. 

The NetWorker administration guide provides more information on how the 

NetWorker server uses browse and retention policies to manage Oracle backup data 

and track the location and status of the data on backup volumes. 

NMO 5.0 software supports a new recovery configuration wizard that is integrated 

with the NetWorker Management Console (NMC). The recovery configuration 

wizard used in NMO release 4.5 or earlier is replaced by the NMC-based wizard in 

NMO release 5.0. 



You can run the recovery configuration wizard from the NetWorker Console 

Administration window, which you can start on any supported host by using a web 

browser session and specifying the Console server URL. 


requirements for the support of the NMC-based configuration wizards. 

To configure a restore with the wizard: 

1. Review the information in “Features of the recovery configuration wizard” on 

page 119. 

2. Ensure that you meet the “Requirements for using the recovery configuration 

wizard” on page 120. 

3. Follow the steps in “Configure a restore with the wizard” on page 120. 

Features of the recovery configuration wizard 

The recovery configuration wizard can create an RMAN script for the following types 

of restore and recovery: 

◆ Current time restore and recovery of a whole or partial Oracle database, where a 

partial database is a set of tablespaces or datafiles. 

The wizard can configure a tablespace restore as long as the control file contains 

information about the tablespace. 

◆ Point-in-time restore and recovery of a whole Oracle database. 

◆ Restore of individual archived redo logs. 

◆ Restore and recovery of Oracle data to a different database through the creation 

of a duplicate database on either the local host or a remote host, using backups of 

the original target database. 

The database duplication script created by the wizard uses the RMAN duplicate 

command to create a duplicate database while the original database is retained. 

The duplicate database can either be an identical copy of the original database or 

contain only a subset of the original tablespaces. For example, the duplicate 

database can be created to run independently on a remote host, for the purpose of 

practicing restore and recovery operations while the production database 

remains in operation on the local host: 

If the duplicate database is to be created on the same host as the original 

database, the RMAN script is also generated on the local host. In this case, the 

wizard requests names for the duplicate database, datafiles, and redo logs that 

differ from those of the original database. 

If the duplicate database is to be created on a remote host, the RMAN script is 

generated on either the local or remote host, as specified in the wizard. In this 

case, the wizard requests a name for the duplicate database that differs from 

that of the original database. (The datafile and redo log names can be the same 

as for the original database.) 

The recovery configuration wizard can only create a new RMAN script for restore 

and recovery. The wizard cannot modify an existing RMAN script. You must use a 

text editor to modify an RMAN script that was created by the wizard. 

“RMAN scripts for restore and recovery” on page 121 provides more information 

about RMAN scripts for restore and recovery. 

About restore and recovery 119


120 

The recovery configuration wizard does not support the following: 

◆ Cluster or Oracle RAC systems 

◆ Proxy backups 

◆ RMAN automatic channels 

The following sources provide more information on the configuration wizard: 


◆ Descriptive inline text in the wizard 

◆ Online help in the wizard 

Requirements for using the recovery configuration wizard 

Before you use the recovery configuration wizard, ensure that all of the following 


◆ The NMC user that starts the wizard (the wizard user) has the Remote Access 

NetWorker privileges on the NetWorker server where the NMO client 

configuration is stored. 

◆ Communication between the NMC server, NetWorker server, and NMO client 

uses nsrauth authentication. The NetWorker documentation provides any 

requirements for nsrauth authentication. 

◆ The required NetWorker releases are installed on the NMC server, NetWorker 

server, and NMO client hosts, as described in the NetWorker Module for Oracle 

release notes. 

◆ The NetWorker Client resource for the NMO client was created through one of 


Backup configuration wizard in NMO 5.0 

Migration of a legacy configuration with the nsrnmoadmin command 

Legacy configuration method (without the wizard), where the value of the 

Save Set attribute of the Client resource has the RMAN: prefix 

◆ Prior to creation of a database duplication script, the AUXILIARY instance exists 

on the local or remote host, and is accessible through Oracle Net. The Oracle 

Database Backup and Recovery Advanced User’s Guide provides details on how to 

create an AUXILIARY instance. 

Configure a restore with the wizard 

To create an RMAN restore script with the recovery configuration wizard: 

1. Start the NetWorker Management Console software. 

2. Open the Administration window: 

a. In the Console window, click Enterprise. 

b. In the left pane, select a NetWorker server in the Enterprise list. 

c. In the right pane, select the application. 

d. From the Enterprise menu, click Launch Application. 

The Administration window is launched as a separate application. 

3. In the Administration window, click Configuration. 

4. In the Configuration window, click Clients. 


! 


5. To start the wizard, right-click the NMO client in the right pane, and select 

Recover. 

6. On each wizard screen that appears, specify the required values for the RMAN 

script configuration. 

Each wizard screen includes an online help button that you can click to access 

descriptions of all the fields and options on the screen: 

On all but the last screen, click Next to proceed. 

On the last screen, Review and Accept the Script Creation, click Create to 

create the RMAN restore script. 

IMPORTANT 

When you create an RMAN restore script with the wizard and select the offline or 

online mode option for tablespaces, you might need to manually edit the script and 

insert an "alter database open;" command before the sql...tablespace... commands, 

if it will be required for your particular database (if the database will not be open 

at the point where the sql commands are to be run). 

RMAN scripts for restore and recovery 

An appropriate RMAN script is required to perform the preferred type of Oracle 

restore operation on the Oracle Server host. You can create the RMAN script either 

manually or by using the recovery configuration wizard. “Recovery configuration 

wizard” on page 118 provides details on the recovery configuration wizard. 

RMAN restore scripts can be stored as text files. Alternatively, if a Recovery Catalog 

is used, restore scripts can be stored in the Recovery Catalog database. The Oracle 

backup and recovery documentation provides more information on storing the 

restore scripts in the Recovery Catalog database. 

The NSR* parameters in the script must be set by the methods described in “Setting 

the NSR* parameters” on page 200. The use of the send command is recommended 

where possible. “The send command” on page 211 provides more information. 

Example 16 RMAN script to restore a tablespace 

The following RMAN script performs a restore of an Oracle tablespace by using the 

(remote) NetWorker server mars.emc.com. The Oracle data is restored to the 

NetWorker client server1.emc.com. This RMAN script also includes the recovery 

step, which is explained in “Perform an Oracle data recovery” on page 127: 

run { 




NSR_CLIENT=server1.emc.com)’; 

sql ’alter tablespace users offline immediate’; 

restore tablespace users; 

recover tablespace users; 

sql ’alter tablespace users online’; 



} 

“Create RMAN scripts for backups” on page 75 provides more information on setting 

NSR* parameters in an RMAN script. 

RMAN scripts for restore and recovery 121


122 

Example 17 RMAN script to restore an AES encrypted backup 

By default, if the NSR_ENCRYPTION_PHRASES parameter is not set, NMO obtains 

the encryption phrase from the NetWorker server for decrypting an AES encrypted 

backup during an Oracle restore. 

The NSR_ENCRYPTION_PHRASES parameter must be set if both of the following 

are true: 

◆ The Oracle data being restored was backed up with 256-bit AES encryption. 

Example 11 on page 76 shows a sample Oracle backup with AES encryption. 

◆ The encryption phrase on the NetWorker server has changed since the Oracle 

data was backed up. 

If both of these conditions are true, ensure that the NSR_ENCRYPTION_PHRASES 

parameter is set through the send command in the RMAN restore script. 

“NSR_ENCRYPTION_PHRASES” on page 205 provides more information. 

The following RMAN script performs a nonproxy Oracle restore of the database by 

using the encryption phrase, original_encryption_phrase, that was originally used to 

back up the database. The encryption phrase must be in double quotes: 

run { 


send ’NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_CLIENT=server1.emc.com, 

NSR_ENCRYPTION_PHRASES="original_encryption_phrase")’; 

restore database; 


} 

Example 18 RMAN script to restore from a specified pool 

By default, NMO and NetWorker use configuration settings and information in the 

media database to determine the backup volume to use for an NMO restore. 

As an alternative, you can use the NSR_RECOVER_POOL parameter in the RMAN 

restore script to restore data from a specified volume pool if there are multiple copies 

(clones) of the backup on different volume pools. “NSR_RECOVER_POOL” on 


The following RMAN script performs a nonproxy restore of the database from the 

specified volume pool named OracleClonePool2, where the pool contains a clone of 

the original backup volume. 

shutdown immediate; 

startup mount; 

run { 


send channel c1 ’NSR_ENV=(NSR_SERVER=backup01, 

NSR_RECOVER_POOL=OracleClonePool2)’; 



} 


Performing an Oracle data restore and recovery 

Requirements for an Oracle data restore 


To perform a restore and recovery of Oracle data: 

1. Review “Requirements for an Oracle data restore” on page 123. 

2. Perform the Oracle data restore by either of the following methods: 

Use the RMAN command line interface, according to “Restore through the 

RMAN command line interface” on page 125. 

Use the Oracle Enterprise Manager Backup Management Tools, according to 

“Restore with Oracle Enterprise Manager Backup Management Tools” on 

page 126. 

Note: Use of the Oracle Enterprise Manager Backup Management Tools is not 

supported with the recovery configuration wizard. 

3. Complete the Oracle data recovery, if required, according to “Perform an Oracle 

data recovery” on page 127. 

Before starting an Oracle data restore, ensure that the required configurations, 

volumes, and scripts are in place: 

◆ The Oracle system is properly configured, as described in Chapter 2, “Software 

Configuration.” 

◆ The NetWorker server has the required resources configured, as described in 

Chapter 2, “Software Configuration”: 

Server 

Client 

Device 

Pool 

◆ If using an RMAN restore script, the script is created, as described in “RMAN 

scripts for restore and recovery” on page 121. 

◆ The volume required for the restore operation is mounted in a configured backup 

device: 

If you use a stand-alone tape drive, the volume is mounted manually. 

If you use an autochanger, the NetWorker server mounts the volume 

automatically. 

To determine the volumes required for the restore, you can use the nsrnmoinfo 

command, as described in “Using the nsrnmoinfo command to determine the 

volumes for restore” on page 123. 

Using the nsrnmoinfo command to determine the volumes for restore 

To determine the NetWorker volumes that contain the Oracle backup pieces to be 

restored, you can use the nsrnmoinfo command. The nsrnmoinfo program is 

installed with the NMO software in the same directory as the NetWorker client 

software. 

Note: On Windows, the command name is nsrnmoinfo.exe. 

Performing an Oracle data restore and recovery 123


124 

The nsrnmoinfo command syntax and options are as follows: 

nsrnmoinfo[.exe] [-c NetWorker_client_name] [-s NetWorker_server_name] 

[-f filename] [backup_piece_name1 [backup_piece_name2 ...]] 

where: 

◆ NetWorker_client_name specifies the hostname of the NetWorker client whose 

index contains information on the Oracle backup pieces. By default, the client is 

the local host. 

◆ NetWorker_server_name specifies the hostname of the NetWorker server to query 

for the volumes. By default, the server is the local host. 

◆ filename specifies the name of a text file that contains a list of one or more backup 

piece names for restore: 

The file must contain each backup piece name on a separate line. 

The file cannot contain spaces or comments (for example, comment lines 

preceded with the # symbol). 

◆ backup_piece_name1 and backup_piece_name2 specify backup piece names for 

restore. 

Command options in brackets ([ ]) are optional. Do not include the brackets when 

typing the command. 

To use the nsrnmoinfo command, specify the names of the backup pieces by either or 

both of the following: 

◆ List the backup piece names as options of the nsrnmoinfo command. 

◆ List the backup piece names in a text file, and specify the name of the file with the 

-f option of the nsrnmoinfo command. 

The nsrnmoinfo command displays a list of one or more volumes required for the 

Oracle restore: 

◆ For each backup piece, the list includes the accessible volumes containing the 

backup piece, which the NetWorker server will use for the restore. 

◆ For each volume, the list includes the following: 

The name and location of the volume. 

The save time of the backup piece on the volume. 

The listed volumes are the most accessible ones, which the NetWorker server intends 

to use for the restore at the time that the command is typed: 

◆ The command lists clones of volumes if the original volumes are not accessible. 

◆ If any listed volumes are removed from the NetWorker devices or deleted after 

the nsrnmoinfo command is typed, the server can perform the restore by using 

different volumes that are accessible. For example, the server can use an 

accessible clone (already mounted in a drive or available for mounting in a 

jukebox) instead of a listed volume. 


Example 19 Sample nsrnmoinfo commands for Oracle restores 


Each of the following nsrnmoinfo commands displays a list of the volumes required 

to restore the specified backup pieces: 

◆ The following command searches in the NetWorker index of the client mars on 

the server server1 for information on the volumes that contain the backup pieces 

backupc_1 and backupc_2: 

nsrnmoinfo -c mars -s server1 backupc_1 backupc_2 

◆ The following command searches in the NetWorker index of the local host for 

information on the volumes that contain the backup pieces listed in the file 

backup2.txt: (Both the NetWorker client and server are assumed to be the local 

host.) 

nsrnmoinfo -f backup2.txt 

◆ The following command searches in the NetWorker index of the client mars for 

information on the volumes that contain both: 

The backup piece backupc_3. 

The backup pieces listed in the file backup3.txt. 

(The NetWorker server is assumed to be the local host.) 

nsrnmoinfo -c mars backupc_3 -f backup3.txt 

Example 20 Volume information displayed by the nsrnmoinfo command 

The following nsrnmoinfo command searches in the NetWorker index of the local 

host on the server mars for information on the volumes containing the backup pieces 

backup1 and backup2: 

nsrnmoinfo -s mars backup1 backup2 

The nsrnmoinfo command displays the following type of information: 

backup1: 

mars.003 at /space/nw_volume1 (save time 1098886937) 

mars.004 at /space/nw_volume2 (save time 1098883454) 

backup2: 

mars.005 at /dev/rmt/0cbn (save time 1098883452) 

According to this command display: 

◆ Volumes mars.003 and mars.004 are required to restore the backup piece 

backup1. 

◆ Volume mars.005 is required to restore the backup piece backup2. 

Restore through the RMAN command line interface 

An Oracle data restore can be started by using the RMAN command line interface on 

the Oracle Server host. 

To restore an Oracle database to a different system from the one backed up, follow 

the instructions in “Restore to a different host” on page 126. 

If the RMAN restore script on page 121 is stored in the file /disk1/scripts/restore.txt 

and the Net service has been configured to connect to the databases payroll and 

rcvcatdb, the Oracle restore can be started with the following command: 

rman target internal/oracle@payroll rcvcat rman/rman@rcvcatdb cmdfile 

\’/disk1/scripts/restore.txt\’ 



126 

On Microsoft Windows, the command to run the RMAN script is rman.exe. The 

appropriate Oracle backup and recovery documentation provides more information 

on the rman or rman.exe command options. 

Restore to a different host 

In some cases, an Oracle database must be restored to a different system from the one 

that was originally backed up. Some situations where this could occur include, but 

are not limited to, performing a disaster recovery or duplicating a database on a 

remote host. The appropriate Oracle documentation provides more information. 

To restore an Oracle database to different system: 

1. On the NetWorker server that contains the backup to be restored, specify the 

hostname of the different system for the Remote Access attribute in the Client 

resource of the original system. 

2. Install and configure NMO on the different system where the Oracle data is to be 

restored. 

3. Install and configure RMAN on the different system. 

4. Create an appropriate RMAN restore script. 

5. In the RMAN script, set the parameter NSR_SERVER to the name of the 

NetWorker server that contains the backup. 

6. In the RMAN script, set the parameter NSR_CLIENT to either the name of the 

NetWorker client (Oracle Server host) that was backed up or the value of 

NSR_CLIENT that was used during the backup. 

7. Use the appropriate RMAN command to run the script to restore the Oracle 

database files. 

Restore with Oracle Enterprise Manager Backup Management Tools 

! 

Note: Use of the Oracle Enterprise Manager Backup Management Tools is not supported with 

the recovery configuration wizard. 

The Oracle Enterprise Manager Backup Management Tools include a graphical user 

interface to RMAN. This interface can be used instead of the RMAN command line 

interface to do the following: 

◆ Generate the required RMAN commands. 

◆ Perform backup and restore operations. 

IMPORTANT 

After the completion of an NMO backup or restore, the Oracle Enterprise Manager 

job queue history displays the status of the job as “failed”, even if the backup or 

restore completed successfully. This is due to a known problem with Oracle 

Enterprise Manager. View the job output to confirm that the backup or restore 

completed successfully. 

The Oracle Enterprise Manager documentation included with the product kit 

provides more information on using the Oracle Enterprise Manager Backup 

Management Tools. 


Perform an Oracle data recovery 


After restoring the NMO backups of the Oracle data by using the RMAN utility, 

complete the data recovery, if required. 

To recover the Oracle data, use the appropriate Oracle commands to apply the 

archived redo logs and online redo logs. There are two ways to use the Oracle 

recovery commands: 

◆ Include the Oracle commands in the RMAN restore script. A sample RMAN 

script is provided on page 121. 

◆ After the RMAN restore script has completed successfully, type the commands at 

the operating system command line. 


information on Oracle data recovery procedures. 



128 



5 

Disaster Recovery 

◆ About disaster recovery ............................................................................................. 130 

◆ Preparing an Oracle database for disaster recovery .............................................. 130 

◆ Performing a disaster recovery ................................................................................. 133 

◆ Sample postcommand script ..................................................................................... 134 

Disaster Recovery 129


130 

About disaster recovery 

It is important to develop a plan for recovering from a disaster on the computer 

system. Back up important data on a daily basis. To prepare for a disk crash or loss of 

data, develop and test a plan for recovering data. 

You must determine the required frequency of backups. Consider that backup 

frequency is a trade-off between the time spent backing up data, and the time spent 

later recovering a database after a crash. 

The following sections describe how to prepare for disaster recovery on an Oracle 

Server or NetWorker server host, and how to perform an Oracle disaster recovery to a 

new host. 

This disaster recovery information pertains to single-instance databases only. The 

information does not pertain to disaster recovery for: 

◆ ASM environments (for example, requiring backups of ASM metadata) 

◆ PowerSnap Module environments 

◆ RAC environments 

Preparing an Oracle database for disaster recovery 

To prepare an Oracle database environment for disaster recovery, you must back up 

the following minimum list of files: 

◆ Oracle database (all the datafiles) 


◆ Control file 

◆ Initialization parameter files, including one or both of the following: 

PFILE (user-managed parameter file) 

SPFILE (server-managed parameter file) 

◆ Network files, including listener.ora, sqlnet.ora, tnsnames.ora 

◆ Text file containing the Oracle DBID 

◆ Password file, in the following location by default: 

On UNIX, $ORACLE_HOME/dbs/orapw$ORACLE_SID 

On Windows, %ORACLE_HOME%\database\PWD%ORACLE_SID%.ora 

◆ Registry files: 

On UNIX, oratab is typically in /var/opt/oracle or /etc 

On Windows, My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Oracle 

◆ Recovery Catalog, if applicable 

◆ RMAN scripts, if applicable 

The Oracle documentation provides an exhaustive list of the files (other than the 

Oracle database) that should be backed up. 

Follow these guidelines to facilitate disaster recovery: 

◆ Institute mirrored control files. 

◆ Refer to Oracle documentation for recommendations on whether to institute 

mirrored online redo logs. 


Create the DBID text file 

◆ Back up the archived redo logs frequently between database backups. 

◆ Back up the Recovery Catalog after every target database backup. 


◆ After manual Oracle backups, perform regular backups of the NetWorker server 

bootstrap and Oracle client file index by using the procedure described in 

“NetWorker server bootstrap backup” on page 106. 

To back up the required files in preparation for disaster recovery, perform the 

following: 

1. “Create the DBID text file” on page 131 

2. “Set up a postcommand script for backup of Oracle-related files” on page 131 

3. “Set up RMAN backups of the database and related files” on page 132 

4. “Set up RMAN backups of Recovery Catalog” on page 132 

The Oracle DBID is an internal Oracle ID that helps Oracle find the autobackup of the 

SPFILE, if the Recovery Catalog is not accessible. 

Before the Oracle DBID can be backed up, you must manually record the DBID in a 

text file. The simplest way to find the DBID of an Oracle database is to connect to the 

database through RMAN once the database has been mounted. 

Once you have recorded the DBID in a text file, you can store the text file containing 

the DBID in any directory where you have the proper operating system permissions. 

You can use a postcommand script to back up the DBID text file, as described in “Set 

up a postcommand script for backup of Oracle-related files” on page 131. 

In the sample postcommand script provided with the NMO software, the DBID text 

file is assumed to be dbid.txt, located in the $ORACLE_HOME directory. “Sample 

postcommand script” on page 134 provides details on the sample postcommand 

script. 

Set up a postcommand script for backup of Oracle-related files 

You can use a postcommand script to back up the files that Oracle RMAN does not 

back up, such as the following files: 

◆ Initialization parameter file PFILE (user-managed parameter file) 

◆ Network files, including listener.ora, sqlnet.ora, tnsnames.ora 

◆ Text file containing the Oracle DBID, as described in “Create the DBID text file” 

on page 131 

◆ Password file in the following location by default: 

On UNIX, $ORACLE_HOME/dbs/orapw$ORACLE_SID 

On Windows, %ORACLE_HOME%\database\PWD%ORACLE_SID%.ora 

◆ Registry files: 

On UNIX, oratab is typically in /var/opt/oracle or /etc 

On Windows, My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Oracle 

◆ RMAN scripts, if applicable 

You can either create a postcommand script from scratch, or modify the 

postcommand script that is provided with the NMO software. 

Preparing an Oracle database for disaster recovery 131


132 

On UNIX, you can use any name for the postcommand script. On Windows, the 

script name must end in .bat. 

Note: During a scheduled NMO backup, the nsrnmostart process passes the options 

-s server_name -g group_name to the postcommand script if the script name begins with 

nsrnmodr. 

In a scheduled RMAN backup, include the postcommand script by one of the 

following methods: 

◆ If you use the NMO wizard to configure the RMAN backup, specify the 

postcommand script in the wizard. 

◆ If you use the legacy method (without the wizard) to configure the RMAN 

backup, set the POSTCMD parameter in the nsrnmo script. 

“Sample postcommand script” on page 134 provides details on the postcommand 

script that is provided with the NMO software. 

Set up RMAN backups of the database and related files 

Set up an RMAN backup with NMO to back up the following files: 

◆ Oracle database (all the datafiles) 


◆ Control file 

◆ Initialization parameter file SPFILE (server-managed parameter file) 

Follow the instructions in the preceding chapters of this guide to properly configure 

and run the RMAN backup with NMO. 

For example, to include the control file and SPFILE in the backup, you can add the 

following commands to the RMAN backup script: 

◆ backup current control file 

Set up RMAN backups of Recovery Catalog 

◆ backup spfile 

The RMAN documentation provides details on RMAN commands and scripts. 

If you want to back up PFILE (user-managed parameter file) or other files that Oracle 

RMAN does not back up, you can use a postcommand script. “Set up a postcommand 

script for backup of Oracle-related files” on page 131 provides details on setting up 

the postcommand script. 

Set up an RMAN backup of the Recovery Catalog by using the same method as for 

the target database backup, as described in “Set up RMAN backups of the database 

and related files” on page 132. 

Oracle documentation provides more information on setting up and running 

Recovery Catalog backups. 


Performing a disaster recovery 

NetWorker server recovery 


The following sections provide guidelines for different types of disaster recovery 

operations: 

◆ “NetWorker server recovery” on page 133 

◆ “Oracle disaster recovery to a new host” on page 133 

NetWorker software can be used to recover from different types of disasters on the 

NetWorker server. The degree of data loss during a disaster can range from one or 

more files lost when a disk crashes, to an entire computer system. The degree of 

severity of the disaster determines the procedures that must be performed to recover 

data on the NetWorker server. 

With respect to NetWorker backups, recall that the bootstrap is a critical file, backed 

up only after scheduled Oracle backups. If only manual Oracle backups are performed, 

back up the bootstrap and client index manually. “NetWorker server bootstrap 

backup” on page 106 provides more information. 

Along with the bootstrap information, keep accurate records of the network and 

system configurations, and maintain all the original software in a safe location. For a 

comprehensive disaster recovery, the following items are required: 

◆ Original operating system media and patches 

◆ Original NetWorker media 

◆ Device drivers and media device names 

◆ File system configuration 

◆ IP addresses and hostnames 

Oracle disaster recovery to a new host 

◆ Bootstrap information 

The NetWorker disaster recovery guide provides information on how to recover the 

NetWorker server from various types of disasters. “Related documentation” on 

page 15 describes how to access the guide. 

To perform an Oracle disaster recovery to a new host: 

1. Install the Oracle software on the new host. 

2. Install NetWorker client and NMO software on the new host, and create a Client 

resource for the new host. 

3. Ensure that the user performing the recovery on the new host is listed in the 

Remote Access attribute in the Client resource of the original host. (This is 

required for “directed recovery” in NetWorker.) 

4. To recover Oracle files that were backed up through a postcommand script, use 

either the NetWorker User GUI or the recover command. 

For example, a typical recover command is as follows: 

recover –s NetWorker_server –c client_name_of_original_host 

–d /var/opt/oracle –a /var/opt/oracle/oratab 

Performing a disaster recovery 133


134 

Sample postcommand script 

Note: On Windows, you may need to reinsert the oracle.reg file into the registry after 

recovering it, for example, with the following command: 

regedit /S C:\temp\oracle.reg 

The Oracle documentation provides more details. 

5. To perform the remainder of the disaster recovery, follow the instructions in the 

Oracle Database Backup and Recovery User’s Guide. In the RMAN script, set the 

NSR_CLIENT parameter to the name of the original host. 

You can use a postcommand script to back up files that Oracle RMAN does not back 

up, as described in “Set up a postcommand script for backup of Oracle-related files” 

on page 131. The NMO software includes a sample postcommand script that you can 

modify for your environment. 

The NMO installation provides a sample postcommand script that is specific to UNIX 

or Windows, depending on the platform where NMO is installed. The sample script 

is installed in the bin subdirectory under the NetWorker software directory, for 

example, under /usr/sbin. 

You must customize the settings in the sample postcommand script for the specific 

environment. At a minimum, you must set the ORACLE_HOME and ORACLE_SID 

parameters in the script. If these two parameters are not set, the postcommand script 

fails at runtime. 

Note: During a scheduled NMO backup, the nsrnmostart process passes the options 

-s server_name -g group_name to the postcommand script if the script name begins with 

nsrnmodr. 

View the sample postcommand script provided with NMO as follows: 

◆ Example 21 on page 134 

◆ Example 22 on page 135 

Example 21 Sample postcommand script on UNIX 

The sample postcommand script named nsrnmodrpostcmd is installed with the 

NMO software on UNIX. 

To use this script for backups in your environment, you must customize the script. At 

a minimum, set the ORACLE_HOME and ORACLE_SID parameters in the script. 

The nsrnmodrpostcmd script provided on UNIX is as follows: 

##!/bin/ksh 

# 

ORACLE_HOME= 

ORACLE_SID= 

GRP=no 

SRV=no 

complete=0 

shift 

shift 


while [ "$#" -gt "0" ] 

do 

if [ "$1" = "-g" ]; then 

GRP=$2 

if [ "$SRV" != "no" ]; then 

complete=1 

fi 

elif [ "$1" = "-s" ]; then 

SRV=$2 

if [ "$GRP" != "no" ]; then 

complete=1 

fi 

fi 

shift 

done 

if [ $complete -eq 1 ]; then 

save -s $SRV -g $GRP $ORACLE_HOME/network/admin 

save -s $SRV -g $GRP $ORACLE_HOME/dbs/orapw$ORACLE_SID 

save -s $SRV -g $GRP /var/opt/oracle/oratab 

save -s $SRV -g $GRP $ORACLE_HOME/dbid.txt 

fi 

Example 22 Sample postcommand script on Windows 


The sample postcommand script named nsrnmodrpostcmd.bat is installed with the 

NMO software on Windows. 

To use this script for backups in your environment, you must customize the script. At 

a minimum, set the ORACLE_HOME and ORACLE_SID parameters in the script. 

The nsrnmodrpostcmd.bat script provided on Windows is as follows: 

echo off 

set SRV=no 

set GRP=no 

set ORACLE_HOME= 

shift 

set ORACLE_SID= 

shift 

:start 

if %1==-g goto assignG 

if %1==-s goto assignS 

if not exist %1 goto fail 

shift 

goto start 

:assignG 

set GRP=%2 

shift 

shift 

if %SRV%==no goto start 

goto end 

:assignS 

set SRV=%2 

shift 

shift 

if %GRP%==no goto start 

:end 

Sample postcommand script 135


136 

save -s %SRV% -g %GRP% %ORACLE_HOME%\network\admin 

save -s %SRV% -g %GRP% %ORACLE_HOME%\database\PWD%ORACLE_SID%.ora 

regedit -E C:\temp\oracle.reg HKEY_LOCAL_MACHINE\SOFTWARE\Oracle 

save -s %SRV% -g %GRP% C:\temp\oracle.reg 

save -s %SRV% -g %GRP% %ORACLE_HOME%\dbid.txt 

:fail 



6 

Cluster and RAC 

Systems 

◆ Considerations for cluster and RAC systems ......................................................... 138 

◆ Cluster systems............................................................................................................ 139 

◆ RAC systems ................................................................................................................ 140 

Cluster and RAC Systems 137

Cluster and RAC Systems 

138 

Considerations for cluster and RAC systems 

To prepare for successful NetWorker Module for Oracle (NMO) operations on cluster 

and RAC systems, consider the following: 

◆ “Parameters in the RMAN script or session” on page 138 

◆ “NetWorker software configuration” on page 139 

◆ “Backup failover” on page 139 

Parameters in the RMAN script or session 

NSR_CLIENT 

! 

The parameters NSR_CLIENT and NSR_SERVER must be correctly set in the RMAN 

script or session. Appendix A, “Parameters in an RMAN Session,” provides more 

information on how to set the required parameters. 

During an Oracle backup, the NetWorker server creates entries about the backed-up 

data in the online client file index. During an Oracle restore, the data is retrieved by 

first searching this client file index. 

The parameter NSR_CLIENT that is set in the RMAN script provides the following 

information to the NetWorker server: 

◆ During a backup, the name of the NetWorker client whose index file should be 

used to record the backup information. 

◆ During a restore, the name of the NetWorker client whose index file should be 

used to search for the save set to be restored. 

If NSR_CLIENT is not set, the NetWorker server uses the name of the local physical 

host. Set the parameter NSR_CLIENT to the same value for all channels allocated 

during the backup. 

The value of NSR_CLIENT (either the default value or an explicitly defined value) 

used for a backup should be the same as the value of NSR_CLIENT used for the 

restore of that backup. Setting NSR_CLIENT to the name of the virtual (as opposed to 

the physical) host might be preferable, so the backup and restore scripts run 

successfully unmodified, regardless of the physical host that executes the scripts. 

IMPORTANT 

If NSR_CLIENT is set to any value other than the default value during a backup or 

restore, the Remote Access attribute must be modified in that NetWorker Client 

resource. The NetWorker administration guide provides more information. 

For each Oracle backup and restore, set NSR_CLIENT by using either the rman send 

command on the operating system command line or the send command in the 

RMAN script. 

Note: Setting NSR_CLIENT in the system environment has no effect. 


NSR_SERVER 

NetWorker software configuration 

Backup failover 

Cluster systems 


Set the parameter NSR_SERVER for a manual Oracle backup or restore if the 

NetWorker server is a remote system for the node running the RMAN session. The 

parameter must be set to the server name for each channel. 

Note: The parameter NSR_SERVER does not need to be set for a scheduled Oracle backup. 

Ensure the correct NetWorker software configuration by performing the following 

tasks: 

1. Ensure that the system is set up properly: 

In the NetWorker Client resource of each host, the Save Set attribute is set to: 

RMAN:RMAN_script_pathname 

In the directory that contains the savefs program file, there is an empty file 

named pathownerignore. Create the pathownerignore file if it does not exist. 

The NetWorker installation guide provides more information on the default 

directory for the savefs program. 

2. Configure a Client resource on the NetWorker server for each RAC node that will 

be used to run backups and restores. In each Client resource, use the fully 

qualified IP name as the client name. 

“Configure a Client resource with NMC” on page 87 provides information on 

how to configure a Client resource for NMO backups. 

3. In the Remote Access attribute in the Client resource for a virtual host, specify the 

name of each physical host that can store and retrieve the backups. 

Neither RMAN nor NMO supports Transparent Application Failover (TAF). As a 

result, if a failure occurs during a backup, the backup is not automatically restarted 

from the point of failure on another node. Only connect-time failover is supported. 

“Connect-time failover” on page 144 provides more information. 

A cluster system typically includes multiple nodes connected by a shared SCSI bus to 

which common storage is attached. In a cluster system, cluster services such as disk 

services can be defined and assigned their own IP addresses and names (virtual 

hosts). The services and their associated storage can migrate for failover between the 

physical nodes in the cluster. 

Together, the NMO and NetWorker server software can back up and restore an 

Oracle database configured on cluster disk services. The NetWorker server treats 

each cluster service as an independent client and stores the associated backup entries 

in the online indexes under the name of the service. 

After properly configuring a cluster service as a NetWorker client, NMO can be used 

with the NetWorker server to back up and restore the database associated with the 

service, independent of the actual node that provides the service. 

Cluster systems 139


140 

To configure a cluster system for Oracle backup and restore operations that use 

NMO, follow the “Roadmap for backup/restore configuration in a cluster system” on 

page 140. 

Roadmap for backup/restore configuration in a cluster system 


RAC systems 

RAC terminology 

The Oracle Server and NetWorker server systems must be configured before NMO 

can be used with the NetWorker server for Oracle backup and restore operations in a 

cluster system. 

Before configuring Oracle backup and restore operations in a cluster system, ensure 


◆ The NMO software is properly installed according to the instructions in the 


◆ The Oracle Server and NetWorker server system configurations are completed 

according to the instructions in the “Configuration roadmap” on page 62. 

To properly configure Oracle backup and restore operations with NMO in a cluster 

system: 

1. Configure the storage for the database as a cluster disk service. 

The appropriate cluster administration guide from the particular cluster software 

vendor provides more information. 

2. Configure a Client resource on the NetWorker server for the virtual host and each 

physical host that will run backups and restores. 

3. Create an RMAN script that includes the appropriate NSR_CLIENT parameter 

settings. “NSR_CLIENT” on page 138 provides more information. 

When a node failure occurs during a manual (unscheduled) Oracle backup, a database 

administrator (DBA) must restart the backup after instance recovery. Since the Oracle 

Net services are configured with a cluster service name, the restarted backup is 

executed on the physical node that takes control of the cluster service. 

When a node failure occurs during a scheduled Oracle backup, the NetWorker server 

restarts the backup (from the beginning, not from the point of failure) if the Client 

Retries attribute in the NetWorker Group resource is set to a value greater than zero. 

The restarted backup is executed on the node that takes control of the cluster service. 

The NMO software supports backups and restores of RAC systems for parallelism 

and high availability. 

A node in a RAC system is a physical computer with a hostname such as 

node1.emc.com. An Oracle instance is a memory structure and a group of Oracle 

Server processes running on a node. 


RAC backups and restores 


An Oracle database (for example, named databs1) comprises a set of datafiles, which 

are used by the Oracle instances and can be shared between the nodes. All instances 

share the same datafiles and control file. Each node must have its own set of redo log 

files and its own archived redo logs. 

After proper configuration of RAC and the associated cluster system, NMO enables 

Oracle backups on either a single node or several nodes of the RAC system. 

A parallel Oracle backup uses Oracle instances running in parallel on multiple nodes 

of the cluster. In the RMAN backup script created for running a parallel Oracle 

backup, allocate multiple channels for the backup and specify that each channel run 

on a specific node. The parameter NSR_CLIENT must be set to the same value for each 

channel. “NSR_CLIENT” on page 138 provides more information on setting the 

parameter. 

NMO software enables restores of the Oracle data to any physical node in the cluster, 

regardless of which physical node originally performed the backup. 

To enable Oracle backup and restore operations, follow the configuration steps in 

“Roadmap for backup/restore configuration in a RAC system” on page 141. 

Roadmap for backup/restore configuration in a RAC system 

To properly configure Oracle backup and restore operations with NMO in a RAC 

system: 

1. Install the proper cluster management software on each cluster node. 

The appropriate cluster installation documentation from the particular cluster 

software vendor provides more information. 

2. Configure the cluster for use with RAC. 

The appropriate RAC documentation from Oracle Corporation provides more 


3. Install and configure the RAC software. 

The required patches from Oracle might need to be installed, to complete the 

RAC installation and linking procedures. Configure the Oracle Net services to 

allow connect-time (SQL Net) failover. “Connect-time failover” on page 144 

provides guidelines. The appropriate Oracle documentation provides more 


4. Install NMO on each node of the cluster to be used for backup and recover 

operations. 

The NetWorker Module for Oracle installation guide provides more information. 

5. Configure a Client resource on the NetWorker server for the virtual host and each 

physical host that will run backups and restores. 

6. Create the appropriate RMAN backup and restore scripts for the preferred types 

of Oracle backups and restores on the RAC system. The following sections 

provide more information: 

“Creating RMAN backup scripts” on page 146 

“Creating RMAN restore scripts” on page 146 

RAC systems 141


142 

7. Review the additional issues concerning Oracle recover operations in “Archived 

redo logs” on page 147. 

8. To set up a local storage node for each RAC node involved in a backup, follow the 

instructions in “Setting up RAC nodes to back up to a local storage node” on 

page 142. 

Setting up RAC nodes to back up to a local storage node 

To set up RAC nodes to back up to a local storage node: 

1. Ensure that the NetWorker storage node software is installed on each RAC node 

to be used for the NMO backup. 

2. On the NetWorker server, create a NetWorker Storage Node resource for each 

RAC node to be used for the NMO backup. The NetWorker administration guide 

provides details on storage node configuration. 

3. Create a NetWorker Device resource for the device on each RAC node to be used 

for the NMO backup. The NetWorker administration guide provides details on 

device resource configuration. 

4. Ensure that Groups and the selection criteria (such as Clients) of the media pool 

used for the devices match the settings in the NMO backup configuration. 

5. Label and mount a NetWorker volume on each storage node. 

6. Select one of the RAC nodes to store the NetWorker indexes for the NMO backup 

and to initiate the backup. 

7. For the RAC node that will initiate the NMO backup, create a NetWorker Client 

resource with the attribute settings required for the backup, as described in 

“NetWorker software configuration” on page 139: 

The Remote Access attribute must include the hostnames of all the other RAC 

nodes. 

The Storage Nodes attribute must contain curphyhost, followed by 

nsrserverhost. The Storage Nodes attribute must be set to the following: 

curphyhost 

nsrserverhost 

8. For each of the other RAC nodes that will not initiate the NMO backup, create a 

basic Client resource. (Settings in these other Client resources do not affect the 

NMO backup.) 

9. On the RAC node that will initiate the NMO backup, create the required nsrnmo 

script and RMAN backup script. The RMAN script must include the 

NSR_CLIENT setting, as described in “NSR_CLIENT” on page 138. 

Example 23 on page 142 shows how to set up three RAC nodes as storage nodes for 

NMO backups. 

Example 23 Setting up RAC nodes as storage nodes 

A RAC system contains three nodes named A, B, and C. Each node has a Linux 

operating system, and an attached tape drive to be used for NMO backups. 

NetWorker storage node software is installed on each node. 

In the NMC interface, a Storage Node resource is created for each node by 

right-clicking Storage Nodes in the Devices pane and selecting New. 



After the Storage Node resources are created, a Device resource is created for each 

tape drive. Each Device resource is created in NMC by right-clicking Devices in the 

Devices pane and selecting New. Since the tape devices are attached to storage 

nodes, the device names must have the format rd=host_name:device_name. For 

example: 

◆ Tape device /dev/rmt/tape0 is attached to node A. In the Device resource, the 

device name is rd=A:/dev/rmt/tape0. 

◆ Tape device /dev/rmt/tape3 is attached to node B. In the Device resource, the 

device name is rd=B:/dev/rmt/tape3. 

◆ Tape device /dev/rmt/tape1 is attached to node C. In the Device resource, the 

device name is rd=C:/dev/rmt/tape1. 

In the tape device on each node, a volume is labeled and mounted. All of the volumes 

are assigned to the Default pool in this example. 

Node A is selected to store the index entries for the NMO backups and initiate the 

backups. (The choice of node A was arbitrary; node B or node C could have been 

chosen instead.) In all the RMAN backup and restores scripts, NSR_CLIENT must be 

set to the hostname of node A. 

In the NetWorker Client resource for node A: 

◆ The Remote Access attribute is set to the hostnames of nodes B and C. 

◆ The Storage Nodes attribute is set to: 

curphyhost 

nsrserverhost 

◆ The remaining attributes are set, as required. For example: 

The Backup Command attribute is set to the nsrnmo script name. 

The Group attribute is set to the backup group name. 

The Save Set attribute is set to the RMAN script pathname. 

The following RMAN script uses all three nodes to perform the backup. Each node 

backs up data to its local tape drive: 

connect target sys/oracle@connect_identifier; 

run { 

allocate channel t1 type ’SBT_TAPE’ 

connect ’sys/oracle@Net_service_name_of_instance_A’; 


connect ’sys/oracle@Net_service_name_of_instance_B’; 


connect ’sys/oracle@Net_service_name_of_instance_C’; 

send channel t1 ’NSR_ENV=(NSR_CLIENT=A)’; 



backup database; 




} 

To enable restores, NSR_CLIENT must be set to the hostname of node A. For 

example, the following RMAN script restores the database. The script can be run on 

any host: 

connect target sys/oracle@connect_identifier; 

run { 




RAC systems 143


144 

Connect-time failover 

} 





If multiple listeners support a single service, a connect-time failover reroutes the 

connection request to another listener if the first listener is down or cannot make the 

connection. To enable the connect-time failover in RAC, there must be a listener on 

each node, and each instance must use the same Net service name. 

When using the local Net service naming method, the client’s tnsnames.ora file 

should include the following parameters: 

o92pA.emc.com = 

(DESCRIPTION = 

(ADDRESS_LIST = 

(FAILOVER = ON) 

(ADDRESS = (PROTOCOL = tcp) (HOST = nodeA) 

(PORT = 1521)) 

(ADDRESS = (PROTOCOL = tcp) (HOST = nodeB) 

(PORT = 1521)) 

) 

(CONNECT DATA = 

(SERVICE_NAME = proddb) 

) 

) 

◆ Set the FAILOVER parameter to ON. The default value is ON for an 

ADDRESS_LIST, and OFF when ADDRESS_LIST is not specified. 

Note: FAILOVER was introduced in Oracle8i. 

◆ Include the ADDRESS_LIST parameter: 

If multiple addresses are specified, but the ADDRESS_LIST parameter is 

omitted, the Oracle Net service reads the addresses sequentially and attempts 

to connect to the last one only. 

If the ADDRESS_LIST parameter is specified, the addresses are tried in the 

order they appear in the list. 

◆ In the CONNECT_DATA section, use SERVICE_NAME instead of the system 

identifer (SID). SERVICE_NAME should be different from SID. 

Note: SERVICE_NAME was introduced in Oracle8i. 

◆ GLOBAL_DBNAME should not appear in the SID_LIST_LISTENER parameter of 

the listener.ora file since it disables the failover. 

When a node or listener to which a client tries to connect is not available, the next 

listener on the list is contacted. When the instance is down but the listener is running, 

the failover occurs only if the instance is configured to dynamically register with the 

listener. 

Dynamic instance registration 

Dynamic instance registration was introduced in Oracle8i. During dynamic instance 

registration, the database registers itself with the Oracle listener on startup and 

unregisters itself on shutdown. 


To perform dynamic instance registration: 


◆ Set the INSTANCE_NAME and SERVICE_NAME parameters in the initialization 

file (initoracle_sid.ora). There can be several services for a single instance. 

◆ If the listener does not listen on the default port (1521), set the LOCAL_LISTENER 

parameter in the initialization file. 

◆ The SID_LIST_LISTENER parameter in listener.ora must not include SID_DESC 

for the RAC instances. 

◆ It is not necessary to have the listener.ora file when the listener listens on the 

default port. 

When the instance is down, the listener does not know how to connect to it. As a 

result, the listener tries the next connect option specified in the ADDRESS_LIST in the 

tnsnames.ora file. 

Note: Some applications such as Oracle Enterprise Manager still require static database 

registration with a listener. 

Static instance registration 

With static registration, the information about the instance is manually configured in 

the listener.ora file through SID_DES in the SID_LIST_LISTENER parameter. The 

listener contains continuous information about the instance, even if the instance is 

down. As a result, when the instance is down, the listener still tries to connect to it 

rather than try the next connect option specified in the tnsnames.ora file. 


When a manual backup is interrupted by an Oracle server-side failure, a DBA must 

restart the backup after instance recovery. During the restarted backup, the 

connection request to the failed instance is rerouted to another instance according to 

the connect-time failover setup in the tnsnames.ora file. 

For a scheduled backup, when the first backup attempt returns an error, the 

NetWorker server restarts the backup if the Client Retries attribute in the NetWorker 

Group resource is set to a value greater than zero. The connect-time failover reroutes 

the connection to an available instance, and the restarted backup starts from the 

beginning. For example, if the backup fails 5 hours into a 10-hour backup, it takes 15 

hours to complete the backup. In this case, the operator might elect to wait until the 

next scheduled backup. 

On a RAC system, traditional cluster failover is not available. If an instance or node 

fails in RAC, another node detects the failure and recovers the failed node’s data. As a 

result, the nodes in RAC carry on without the failed node. If a system failure occurs 

on the RAC node used to initiate an NMO backup, the backup fails. In this case, 

manual intervention is required to configure and restart the backup on a different 

RAC node that is available: 

1. On the available RAC node, ensure that the following software is installed: 

NetWorker client 

NetWorker storage node (optional) 

NMO 

2. Configure the Client resource for the available RAC node. 

3. Replace the original Client resource with the new Client resource from step 2 for 

the NMO backup. 

RAC systems 145


146 

Creating RMAN backup scripts 

A single RMAN backup script can be used to run a parallel Oracle backup with NMO 

on a RAC system. In the backup script, allocate multiple channels for the backup and 

specify that each channel run on a specific node. 

Example 24 RMAN script for a manual Oracle backup on a RAC system 

Creating RMAN restore scripts 

Suppose a RAC system consists of two nodes named node1.emc.com and 

node2.emc.com. The Oracle instances named instance1 and instance2 are running on 

node1.emc.com and node2.emc.com, respectively. The NetWorker server is located 

on a separate node, server1.emc.com. 

The following RMAN script for a manual backup is intended to run on 

node1.emc.com by using the NOCATALOG mode of RMAN. The script sets 

NSR_CLIENT to node1.emc.com and NSR_SERVER to server1.emc.com. As a result, 

the NetWorker server stores the backup information in the node1.emc.com client file 

index, as described in “NSR_CLIENT” on page 138. Two channels are allocated to 

each of the nodes, node1.emc.com and node2.emc.com: 

run { 




connect ’user_name/user_passwd@connect_string_of_node2’; 



send ’NSR_ENV=(NSR_CLIENT=node1.emc.com, 

NSR_SERVER=server1.emc.com); 

backup filesperset 1 

format ’instance1_%s_%p’ 

(database); 





} 

“Backing up all archived logs from each node” on page 147 provides a sample script 

to back up all the archive log files in a RAC system. 

A single RMAN restore script can be used to run a parallel Oracle restore with NMO 

on a RAC system. In the restore script, allocate multiple channels for the restore and 

specify that each channel run on a specific node. 

Note: NMO does not support multiple RMAN restores that are running at the same time. 

To run an Oracle restore on a RAC system, none of the nodes can be open. Only the 

node that is running the RMAN restore script needs to be mounted. 

Example 25 RMAN script for an Oracle restore on a RAC system 

Refer to Example 24 on page 146. A RAC system consists of two nodes named 

node1.emc.com and node2.emc.com. The Oracle instances named instance1 and 

instance2 are running on node1.emc.com and node2.emc.com, respectively. The 

NetWorker server is located on a separate node, server1.emc.com. 


Archived redo logs 


The following RMAN restore script is to be run on node2.emc.com. The script 

restores the backup that was created by the backup script in Example 24 on page 146. 

This restore script sets NSR_CLIENT to node1.emc.com and NSR_SERVER to the 

remote NetWorker server name. As a result, the NetWorker server will obtain the 

backup information from the node1.emc.com client file index. Two channels are 

allocated to each of the nodes, node1.emc.com and node2.emc.com: 

run { 







send ’NSR_ENV=(NSR_CLIENT=node1.emc.com, 

NSR_SERVER=server1.emc.com)’; 






} 

In this example, the parallel Oracle backup was performed with NSR_CLIENT set to 

node1.emc.com for each channel in the RMAN backup script. In order to restore the 

backup data to node2.emc.com, add node2.emc.com to the Remote Access attribute in 

the NetWorker Client resource for node1.emc.com. 

The NetWorker administration guide provides more information on how to modify 

the Client resource. 

“Restoring all archived logs from each node” on page 148 provides a sample script to 

restore all the archive log files in a RAC system. 

Each node in a RAC system maintains a separate set of redo logs. Redo logs that 

become full are archived on the local node. As a result, the archived redo logs are 

divided among the nodes of the system. 

To enable RMAN to back up and recover a RAC system, make all the archived redo 

log files accessible by all nodes participating in the backup or recovery. The 

appropriate Oracle RAC documentation provides information on how to share the 

archived redo logs. 

The following sections provide sample scripts to back up and restore all the archived 

redo log files in a RAC system: 

◆ “Backing up all archived logs from each node” on page 147 

◆ “Restoring all archived logs from each node” on page 148 

Backing up all archived logs from each node 

All the archived log files in a RAC system can be backed up from a single node (for 

example, a node named ops1.emc.com) by using the following type of RMAN script: 

run { 


connect ’user_name/user_passwd@connect_string_of_ops1’; 



send ’NSR_ENV=(NSR_CLIENT=ops1.emc.com)’; 

RAC systems 147


148 

} 

backup filesperset 10 

(archivelog all delete input format ’al_%s_%p’); 



Restoring all archived logs from each node 

All the archived log files in a RAC system can be restored from a single node (for 

example, a node named ops1.emc.com) by using the following type of RMAN script: 

run { 





send ’NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_CLIENT=ops1.emc.com)’; 

restore (archive log all); 

release t1; 

release t2; 

} 



7 

Proxy Backups and 

Restores 

◆ Overview of proxy backups and restores ................................................................ 150 

◆ Proxy backup and restore system ............................................................................. 151 

◆ Proxy backup processes ............................................................................................. 153 

◆ Proxy restore processes .............................................................................................. 159 

◆ Software configuration roadmap.............................................................................. 163 

◆ Proxy backup requirements....................................................................................... 171 

◆ Proxy backup information in the NetWorker indexes........................................... 174 

◆ Proxy restore requirements........................................................................................ 177 

◆ Catalog synchronization for proxy backups ........................................................... 181 

◆ Proxy backups and restores on cluster systems...................................................... 194 

Proxy Backups and Restores 149

Proxy Backups and Restores 

150 

Overview of proxy backups and restores 

Types of proxy backups 

Instant backups 

Live backups 

Proxy backups and restores provide continuous snapshot-based protection and 

availability of Oracle data on specific types of primary storage. The NetWorker 

Module for Oracle (NMO) software supports proxy backups and restores of Oracle 

data with the following requirements: 

◆ The proxy backups create snapshots of Oracle data that reside on primary storage 

devices supported by the PowerSnap Modules that work with the NMO. 

The EMC Information Protection Software Compatibility Guide on the Powerlink 

website provides a complete list of supported PowerSnap Modules. 

◆ The proxy operations use the particular PowerSnap Module software designed 

for the primary storage. 

The following sources provide details on the installation requirements for proxy 

operations: 



(Refer to the PowerSnap Module version for the primary storage system.) 

NMO supports the following types of proxy backups, in cooperation with the 

appropriate PowerSnap Module: 

◆ “Instant backups” on page 150 

◆ “Live backups” on page 150 

An instant backup creates a point-in-time copy (snapshot) of Oracle data and stores 

this copy on the primary storage system. Instant backups can be scheduled to occur 

many times in a single day, with little impact to the Oracle Server or network. 

The group of Oracle datafiles in the point-in-time copy is referred to as a snap set. A 

snapshot policy must be configured to control the lifecycle of the snap set. This policy 

specifies the frequency of instant backups and how long snapshots are retained 

before being recycled. “Software configuration roadmap” on page 163 provides more 


Note: NMO supports scheduled instant backups only. Manual (unscheduled) instant backups 

are not supported. 

NMO supports the following two types of live backup, which back up a snapshot to 

secondary (traditional) storage: 

◆ Deferred live backup — An existing point-in-time copy (snapshot), that is created 

during an instant backup, is backed up to secondary storage, such as tape. The 

snapshot is retained on the primary storage. 

◆ Immediate live backup — A point-in-time copy (snapshot) is created, and 

immediately backed up to secondary storage, such as tape. The snapshot is then 

automatically deleted from the primary storage. 


Types of proxy restores 

Instant restores 

Rollbacks 

! 

A snapshot policy must be configured to enable live backups. “Software 

configuration roadmap” on page 163 provides more information. 

IMPORTANT 


Instant backups protect against logical failures only. To protect against physical 

failures, the point-in-time copy must be backed up to secondary storage. 

A proxy client host that is separate from the Oracle Server host can be used to move 

the point-in-time copy to the traditional storage medium, such as tape. Using a proxy 

client as a secondary host reduces the impact on the Oracle Server. 

Note: The proxy client can be a NetWorker storage node. 

NMO supports the following types of proxy restores, in cooperation with the 

appropriate PowerSnap Module: 

◆ “Instant restores” on page 151 

◆ “Rollbacks” on page 151 

◆ “Restores from secondary storage” on page 151 

During an instant restore, the saved data is retrieved from a mounted point-in-time 

copy that was created with an instant backup. A minimal amount of time is required 

for this type of restore. 

A rollback restores a whole point-in-time copy to a source location by using the 

hardware’s particular capabilities. Rollbacks are destructive restores because they 

overwrite the entire contents of a snapshot unit, such as a volume or disk. Use the 

NetWorker PowerSnap Module documentation to determine if a rollback is 

supported on a specific type of hardware. 

Restores from secondary storage 

If the point-in-time copy was backed up to secondary storage through a live backup, 

the PowerSnap Module software uses the NetWorker recover program to retrieve the 

data. 

Proxy backup and restore system 

For proxy backups and restores, the NMO, NetWorker server and client, and 

appropriate PowerSnap Module software function with the components of the Oracle 

backup and restore system. The implementation of a proxy backup and restore 

strategy requires a knowledge of how the Oracle and EMC software components 

work together. 

Proxy backup and restore system 151


152 

The Oracle backup and restore system consists of the following: 

◆ Oracle Server 

◆ Recovery Manager (RMAN) 

◆ Recovery Catalog (optional) 

◆ Oracle Enterprise Manager Backup Management Tools (optional) 

The following sections provide more information on RMAN and the Recovery 

Catalog: 

◆ “Oracle Recovery Manager” on page 50 

◆ “Oracle Recovery Catalog” on page 51 

The EMC software components required for proxy backups are the following: 

◆ NetWorker server 

◆ NetWorker client (installed on the Oracle Server and proxy client host) 

◆ NMO (installed on the Oracle Server) 

◆ NetWorker PowerSnap Module (installed on the Oracle Server and proxy client 

host) 

Note: NetWorker storage node software can be optionally installed on the proxy client host. 

Figure 12 on page 153 illustrates the architecture of the proxy backup and restore 

system. It provides an overview of the functional relationship between the Oracle 

and NetWorker software components. The interactions of the components are 

described in the following sections: 

◆ “Proxy backup processes” on page 153 

◆ “Proxy restore processes” on page 159 


RMAN 

Recovery 

Catalog 

Figure 12 Proxy backup and restore system 

Proxy backup processes 

Oracle Server host PowerSnap proxy client 

(NetWorker storage node) 


client 


Server 




MML 

PowerSnap 



data files 


client 

PowerSnap 


Point-in-time copy 

of Oracle data files 

Primary storage 



server 


server 

Storage 

medium 

GEN-000174 

During a proxy backup of Oracle data, Oracle Server processes interact with the 

NetWorker server through the NMO and PowerSnap Module software. The NMO 

media management library (MML) is integrated with the Oracle Server kernel 

software. 

Note: Certain RMAN features, such as checking for corrupt blocks, are not applicable to proxy 

backups because the MML controls that process. 

When a proxy backup is initiated, the RMAN utility starts the Oracle Server 

processes that call the MML proxy-specific routines. The MML routines communicate 

with the PowerSnap Module service. 

On the Oracle Server host, the PowerSnap Module uses a storage platform-specific 

application programming interface (API) to take a snapshot of the Oracle data on the 

primary storage. 

Proxy backup processes 153


154 

Scheduled proxy backup 

If a live backup is performed, the PowerSnap Module moves the Oracle data from the 

point-in-time copy (snapshot) on the primary storage to the NetWorker server or 

storage node. The NetWorker server or storage node then stores the Oracle data on 

the secondary storage, such as a tape. 

At the end of the proxy backup, the NetWorker server updates the online client and 

media indexes with information about the backup. The NetWorker administration 

guide provides more information about NetWorker server and NetWorker client 

programs and services. 

Note: A proxy backup can be started only by automatic or manual invocation of the scheduled 

NetWorker backup group. A proxy backup cannot be scheduled through Oracle Enterprise 

Manager or started from RMAN. The NetWorker PowerSnap Module documentation provides 

information on how to manually invoke a scheduled backup. 

A scheduled backup is a backup of Oracle data that the NetWorker server initiates. 

The following sections describe the process steps in the three types of scheduled 

proxy backup: 

◆ “Scheduled instant backup” on page 154 

◆ “Scheduled immediate live backup” on page 156 

◆ “Deferred live backup” on page 158 

Note: To simplify the descriptions and illustrations in these sections, certain steps have been 

omitted, such as the step to obtain the proper NetWorker authorization. 

Scheduled instant backup 

A scheduled instant backup involves the following steps: 




on the Oracle Server host run the savefs program to verify the existence of the 

RMAN scripts to be used for the backup. 

3. If the savefs program succeeds, the savegrp program starts the PowerSnap 

program, nsrsnap, on the Oracle Server host. Otherwise, the backup fails. 

4. If an existing point-in-time copy needs to be removed (for example, it is expired 

according to the snapshot policy), the nsrsnap program invokes the nsrsnapck 

program to remove both the point-in-time copy from the storage system and the 

corresponding NetWorker index entries. 

Note: If the point-in-time copy was not copied to secondary storage, the nsrsnapck 

program invokes the nsroraclecat program to remove the corresponding RMAN catalog 

entries. “Automatic catalog synchronization with the nsroraclecat program” on page 191 


5. The nsrsnap program contacts the nsrexecd service, which starts the nsrnmo 

script for the scheduled backup. 

6. The nsrnmo script sets the required parameters and invokes the NMO program, 

nsrnmostart. 



7. The nsrnmostart program starts the RMAN utility to run the required RMAN 


8. RMAN starts an Oracle process that calls the MML, which contacts the 

PowerSnap master program, nsrpsd, to perform the instant backup: 

PowerSnap processes create the point-in-time copy that comprises the backup. 

The nsrmmd service performs the following: 

– Stores metadata (used only by the PowerSnap Module) about the 

point-in-time copy on the media belonging to the configured snapshot 

pool. 

– Records tracking information about the metadata in the NetWorker media 

database by using the nsrmmdbd service. 

The nsrindexd service records information about the point-in-time metadata 

in the NetWorker client file index. 

The nsrindexd service records tracking information about each backup piece 

name in the NetWorker client file index. The client index contains one entry 

per datafile. 

The Oracle Server records the backup entry in the RMAN catalog. 

9. After the RMAN script completes successfully, the nsrnmostart program backs 

up the NWORA resource file, described in “The NWORA resource file” on 

page 183. 

10. If the Snapshot Policy resource specifies that the point-in-time copy must be 

copied to secondary storage, the nsrsnap program performs the steps in 

“Deferred live backup” on page 158. 

Note: The point-in-time copy is not deleted from the primary storage. 

11. The savegrp program backs up the NetWorker server bootstrap and Oracle client 

file indexes. 

Figure 13 on page 156 shows how the Oracle Server and NetWorker processes 

interact during a scheduled instant backup. 



156 





process 




MML 

RMAN 

nsrnmostart 

nsrnmo 

nsrsnapck 

nsroraclecat 

(optional) 


data files 

nsrsnap 

Figure 13 Scheduled instant backup 

Scheduled immediate live backup 

A scheduled immediate live backup involves the following steps: 

data 

PowerSnap 

processes 

Note: The first seven steps are the same as those in “Scheduled instant backup” on page 154. 




on the Oracle Server host run the savefs program to verify the existence of the 

RMAN scripts to be used for the backup. 

3. If the savefs program succeeds, the savegrp program starts the PowerSnap 

program, nsrsnap, on the Oracle Server host. Otherwise, the backup fails. 


PowerSnap proxy client 




PowerSnap 

processes 

tracking 


nsrpsd nsrexecd nsrmmd 

PowerSnap 

elements 



elements 

nsrexecd 

savefs 

Snapshot 

pool media 

interprocess communication 


server 

Client file index 

nsrindexd 

Media database 

nsrmmdbd 

nsrd 

savegrp 

Start 

Here 

GEN-000175


4. If an existing point-in-time copy needs to be removed (for example, it is expired 

according to the snapshot policy), the nsrsnap program invokes the nsrsnapck 

program to remove both the point-in-time copy from the storage system and the 

corresponding NetWorker index entries. 

Note: If the point-in-time copy was not copied to secondary storage, the nsrsnapck 

program invokes the nsroraclecat program to remove the corresponding RMAN catalog 

entries. “Automatic catalog synchronization with the nsroraclecat program” on page 191 


5. The nsrsnap program contacts the nsrexecd service, which starts the nsrnmo 

script for the scheduled backup. 

6. The nsrnmo script sets the required parameters and invokes the NMO program, 

nsrnmostart. 

7. The nsrnmostart program starts the RMAN utility to run the required RMAN 


8. RMAN starts Oracle processes that call the MML, which contacts the PowerSnap 

master program, nsrpsd, to perform the immediate live backup: 

PowerSnap processes create the point-in-time copy, move the data to 

secondary storage, and then delete the point-in-time copy from the primary 

storage. 

The nsrmmd service records the tracking information about the secondary 

storage save sets in the NetWorker media database by using the nsrmmdbd 

service. 

The nsrindexd service records the tracking information for each backup piece 

name and for each stored operating system datafile in the NetWorker client 

file index. The client index contains two entries per datafile. 

The Oracle Server records the backup entry in the RMAN catalog. 

9. After the RMAN script completes successfully, the nsrnmostart program backs 

up the NWORA resource file, described in “The NWORA resource file” on 

page 183. 

10. The savegrp program backs up the NetWorker server bootstrap and Oracle client 

file indexes. 


interact during a scheduled immediate live backup. 



158 

Deferred live backup 





process 




MML 

RMAN 

nsrnmostart 

nsrnmo 

nsrsnapck 

nsroraclecat 

(optional) 


data files 

nsrsnap 

data 

PowerSnap 

processes 

Figure 14 Scheduled immediate live backup 

A deferred live backup runs automatically as part of a scheduled backup, as specified 

by the Backup Snapshots attribute of the Snapshot Policy resource. The NetWorker 

PowerSnap Module documentation provides more information. 

A deferred live backup involves the following steps: 

1. The nsrsnap or nsrsnapadmin program invokes the PowerSnap processes to 

copy the point-in-time copy to secondary storage. 

Note: The point-in-time copy is not deleted from the primary storage. 

2. The nsrmmd service records the tracking information about the deferred live 

backup in the NetWorker media database by using the nsrmmdbd service. 

3. The nsrindexd service records the tracking information for each stored operating 

system datafile in the NetWorker client file index. 






PowerSnap 

processes 

tracking 



PowerSnap 

elements 



elements 

nsrexecd 

savefs 

Secondary 

storage medium 



server 


nsrindexd 


nsrmmdbd 

nsrd 

savegrp 

Start 

Here 

GEN-000176



interact during a scheduled deferred live backup. 

Figure 15 Deferred live backup 

Proxy restore processes 




Start 

Here 


data files 

interprocess 

communication 

nsrsnap (at end 

of savegrp) or 

nsrsnapadmin 

PowerSnap 

elements 





PowerSnap 

processes 

tracking 


nsrexecd nsrmmd 

A proxy restore can be performed in either of two ways: 


interface. 

Or 


server 


nsrindexd 

GEN-000177 



The RMAN utility starts Oracle Server processes on the target database. These Oracle 

Server processes start the restore by calling MML routines. 

The following sections describe the process steps in the three types of proxy restore: 

◆ “Instant restore or rollback” on page 160 

◆ “Restore from secondary storage” on page 161 

data 

Secondary 

storage medium 


nsrmmdbd 

Proxy restore processes 159


160 

Instant restore or rollback 

An instant restore or rollback involves the following steps: 

1. The MML performs the following: 

a. Translates the instant backup object names requested by RMAN into a format 

that the NetWorker server understands. 

b. Verifies the existence of the instant backup objects through the nsrindexd 

service. 

c. Verifies that the restore destination directory exists and is accessible, and 

creates the .nworapc directory. 

2. The MML contacts the PowerSnap master program, nsrpsd, on the Oracle Server 

host. 

3. The nsrpsd program works with other PowerSnap and NetWorker programs to 

perform the restore operation: 

PowerSnap processes retrieve the point-in-time metadata stored on the device 

associated with the snapshot pool by using the nsrmmd and nsrmmdbd 

processes. 

PowerSnap processes perform one of the following: 

– During an instant restore, mount the point-in-time copy and copy the files 

into a destination requested by NMO. 

– During a rollback, execute a command (specific to the primary storage) to 

move the whole point-in-time copy (snapshot unit) into the source 

destination. 

4. If operating system files (not raw devices or volumes) are restored during an 

instant restore, NMO moves the restored files from the .nworapc directory to the 

parent directory. 

Once the required Oracle files are restored, a database administrator can complete the 

standard Oracle database recovery. 


interact during an instant restore or rollback. 


RMAN 




process 




MML 

Figure 16 Instant restore or rollback 

Restore from secondary storage 


data files 

nsrexecd 



element 


data 

(for details on 

data flow, see 

description) 

PowerSnap 

module 





PowerSnap 

module 

tracking 



PowerSnap 

elements 

Snapshot 

pool media 




server 


nsrindexd 


nsrmmdbd 

A restore of a proxy backup from secondary storage involves the following steps: 

1. The MML performs the following: 

a. Translates the instant backup object names requested by RMAN into a format 

that the NetWorker server understands. 

b. Verifies the existence of the instant backup objects through the nsrindexd 

service. 

c. Verifies that the restore destination directory exists, and creates the .nworapc 

directory. 

2. The MML contacts the PowerSnap master program, nsrpsd, on the Oracle Server 

host. 

nsrd 

GEN-000178 

Proxy restore processes 161


162 

3. The nsrpsd program works with other PowerSnap and NetWorker programs to 

retrieve the data from secondary storage, and perform the restore operation. 

PowerSnap processes restore the files (save sets) into a destination requested by 

NMO. The processes use the nsrmmd and nsrmmdbd processes to determine 

which media contain the requested save sets and to read the backup volumes. 

4. If operating system files (not raw devices or volumes) are restored, NMO moves 

the restored files from the .nworapc directory to the parent directory. 

Once the required Oracle files are restored from the backup volumes, a database 

administrator can complete the standard Oracle database recovery. 


interact during a restore from secondary storage. 

RMAN 


process 




MML 



nsrexecd 


data files 

PowerSnap 

module 

nsrpsd 


PowerSnap 

elements 



element 

data 

Figure 17 Restore from secondary storage 




tracking information 

nsrmmd 

Secondary 

storage 



server 


nsrindexd 


nsrmmdbd 

nsrd 

GEN-000179

Software configuration roadmap 

Basic configurations 


This section describes the configuration requirements for proxy backups and restores. 

Before performing the required configuration procedures, ensure that both the NMO 

and required PowerSnap Module software are installed according to the instructions 

in the following: 


Additional configurations for proxy operations 


(Refer to the PowerSnap Module version for the primary storage system.) 

Ensure that the following basic configurations are performed: 

◆ The basic Oracle Server and NetWorker configurations are performed according 

to the “Configuration roadmap” on page 62. The NetWorker Server, Client, 

Device, and other resources must be configured: 

For live Oracle backups, a Device resource must be configured for each 

secondary storage device, such as a tape drive, to be used for the backups. The 

devices must be mounted prior to the backups. 

For instant Oracle backups, a snapshot Pool resource must be configured, as 

described in “Additional configurations for proxy operations” on page 163. 

◆ The required scheduled backup configurations are performed according to 

“Configuring a backup with the NMC legacy method” on page 75. 

For proxy operations, you must configure the Oracle database layout to position the 

datafiles on primary storage that is supported by the specific PowerSnap Module. 

Ensure that the additional configuration procedures described in the following 

sections are performed: 

◆ “Configuring internationalization (I18N) support” on page 164 

◆ “Configuring the required Oracle settings” on page 164 

◆ “Configuring the NWORA resource file” on page 164 

◆ “Creating RMAN scripts for proxy backups” on page 165 

◆ “Configuring the NetWorker Pool resources” on page 169 

◆ “Configuring the NetWorker Snapshot Policy resource” on page 169 

◆ “Configuring the NetWorker Group resource” on page 169 

◆ “Configuring the NetWorker Client resource” on page 170 

◆ “Testing a scheduled proxy backup” on page 170 

Once all the configuration requirements are met, review the information in the 

following sections prior to performing proxy backups and restores: 

◆ “Proxy backup requirements” on page 171 

◆ “Proxy backup information in the NetWorker indexes” on page 174 

◆ “Proxy restore requirements” on page 177 

Software configuration roadmap 163


Configuring internationalization (I18N) support 

In a non-English environment, NMO supports internationalization (I18N) of proxy 

backups and restores with a supported release of the PowerSnap Module, as 

described in “Internationalization (I18N) and localization (L10N)” on page 33. 

To configure I18N support for proxy backups, follow the instructions in 

“Configuring I18N support” on page 67. 

Configuring the required Oracle settings 

Do not locate the database control files and online redo log files on the same volume 

(snapshot unit) as the datafiles that will be backed up through proxy backups. 

If the Oracle database is expected to have a lot of read or write activity, or an error, 

such as “skgfdisp: async read/write failed” appears, specify the following values in 

the Registry and Initialization Parameter file: 

164 

◆ In the Registry, specify the following parameters under 

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE: 

ORA_oracle_sid_WORKINGSETMAX 

ORA_oracle_sid_WORKINGSETMIN 

Possible values to set for these parameters are as follows: 

ORA_oracle_sid_WORKINGSETMAX = 1600 

ORA_oracle_sid_WORKINGSETMIN = 1200 

More information on these parameters and Oracle memory management on 

Windows is available in the Oracle document number 46001.1, “Oracle Database 

and the Windows NT Memory Architecture, Technical Bulletin.” 

◆ In the Initialization Parameter file (such as initoracle_sid.ora), increase the value of 

LARGE_POOL_SIZE to a large value that is appropriate for the particular system. 

Configuring the NWORA resource file 

To enable proxy backups, the NSR_ORACLECAT_MODE parameter resource must 

be set to either enabled or disabled in the NWORA resource file, as described in “The 

NWORA resource file” on page 183. If the resource value is left unset, proxy backups 

fail. 

To enable catalog synchronization, perform the configuration procedures in “Catalog 

synchronization for proxy backups” on page 181. 

Notes: 

◆ If catalog synchronization is enabled for instant backups, the NWORA resource 

file must contain an NWORA SID resource for each Oracle database to be backed 

up during instant backups. 

◆ Catalog synchronization must be configured before any proxy backups of a 

database are performed. 

◆ The parameter ORACLE_SID in the nsrnmo script (used for the proxy backup) 

must be set to the same value as the parameter NSR_ORACLE_SID in the 

NWORA SID resource. 



Creating RMAN scripts for proxy backups 

The basic information about RMAN backup scripts in “Create RMAN scripts for 

backups” on page 75 also applies to RMAN scripts for proxy backups: 

These added requirements apply to RMAN scripts for proxy backups: 

◆ The appropriate parameters must be set, as described in “Setting the parameters” 

on page 166. 

◆ The proxy or proxy only option must be specified with each RMAN backup 

command. 

Note: Certain options of the RMAN backup command, such as maxsetsize and diskratio, 

are not supported with the proxy option. Contact Oracle Corporation for more information 

on the RMAN options that are not supported. 

◆ As required by Oracle for proxy backups, the %p variable must be included in the 

format string, either explicitly or implicitly within %U. The appropriate Oracle 

backup and recovery documentation provides more information. 

◆ Allocate only one channel in the RMAN script. Do not allocate more than one 

channel in the RMAN script, in an attempt to distribute the proxy backup over 

more than one channel. 

Note: Proxy backup parallelism is defined by the PowerSnap parameter 

NSR_PS_SAVE_PARALLELISM. Table 7 on page 167 provides more information. 

The following sample RMAN script performs a proxy backup of an entire Oracle 

database that resides on one or more primary storage devices: 

run { 


send ’NSR_ENV=( 

NSR_PROXY_PFILE=/oracle/rman/proxy.cfg)’; 

backup full proxy only 


(database); 


} 

NSR_PROXY_PFILE is an optional NMO parameter used for proxy backups. “Setting 

the parameters” on page 166 provides details. 

Multiple channels in RMAN scripts 

The allocation of multiple channels in an RMAN script does not control the degree of 

backup or restore parallelism. Oracle uses only one of the allocated channels for the 

proxy backup or restore, unless specific backup options are used. 

Example 26 RMAN scripts with multiple channels 

The proxy backup performed with the following RMAN script is written to either the 

OracleVolume1 or OracleVolume2 volume pool (not to both volume pools) because 

Oracle uses only one of the allocated channels for the proxy backup: 

run { 

allocate channel c1 type ’SBT_TAPE’; 


send channel c1 ’NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume1)’; 




166 

} 

backup proxy only tablespace tbs1, tbs2, tbs3, tbs4; 



The following RMAN script uses specific backup options to enforce distribution of 

the proxy backup over two channels: 

run { 





backup proxy 

(tablespace tbs1, tbs2 channel c1) 

(tablespace tbs3, tbs4 channel c2); 



} 

Use the following RMAN script to replace both of the preceding two backup scripts: 

run { 



backup proxy tablespace tbs1, tbs2, tbs3, tbs4; 


} 

You might want to allocate more than one channel if you know that some of the data 

does not reside on supported primary storage devices. In this case, one channel is 

used for proxy backups and all the others are used for regular backups. 

Setting the parameters 

Two types of parameters can be set for the proxy backup and restore operations: 

◆ NMO parameters, as described in Appendix A, “Parameters in an RMAN 

Session.” 

The parameters must be set by using one of the methods in “Setting the NSR* 

parameters” on page 200. 

◆ PowerSnap Module parameters, as described in “PowerSnap parameter settings” 

on page 166. 

PowerSnap parameter settings 

The PowerSnap parameters must be set by using one of the following methods: 

◆ By setting the parameters in the send command in one of these ways: 

With the rman command on the operating system command line. 

In the RMAN backup or restore script. 

“The send command” on page 211 provides more information on how to use the 

send command. 

◆ By setting the parameters in a user-defined configuration file. The complete 

pathname of the file must be specified in the parameter NSR_PROXY_PFILE, as 

described in “NSR_PROXY_PFILE” on page 206. 



The configuration file consists of a separate line such as the following for each 

parameter setting: 

parameter_name=parameter_value 

where: 

parameter_name is the parameter name, such as RESTORE_TYPE_ORDER. 

parameter_value is the parameter value, such as pit. 

Use the following guidelines to set PowerSnap parameters: 

◆ A parameter setting in the configuration file takes precedence over a parameter 

setting in the send command. 

If the same PowerSnap parameter is set to different values in the configuration 

file and send command, the value in the configuration file is the one used for the 

proxy operation. 

◆ In the configuration file, the first valid occurrence of a PowerSnap parameter 

takes precedence over any other occurrences of the same parameter in the same 

file. 

◆ The following are not supported: 

The use of the parms option in the configure channel command to set 

PowerSnap parameters. 

The use of the setenv command on the operating system command line to set 

PowerSnap parameters. 

Example 27 on page 168 and Example 28 on page 168 provide examples of 

PowerSnap parameter settings. 

Table 7 on page 167 provides a basic list of supported PowerSnap parameters. The 

list is not exhaustive. The NetWorker PowerSnap Module documentation provides a 

complete list of PowerSnap parameters. 

For each parameter, the table includes: 

◆ A description of the parameter. 

◆ The default value of the parameter. 

◆ The valid values that can be assigned to the parameter. 

Table 7 PowerSnap parameters (page 1 of 2) 

Parameter Description Default and valid values 

NSR_DATA_MOVER Mandatory for a proxy backup that uses a proxy 

client host. Specifies the hostname of the proxy 

client host. 

NSR_PS_SAVE_PARALLELISM Optional. Specifies the number of concurrent save 

streams on the proxy client host. 

Local host (default). 

The valid hostname of the proxy client host. 

16 (default). 

An integer value less than or equal to the 

Parallelism attribute value in the NetWorker Client 

resource. 



168 

Table 7 PowerSnap parameters (page 2 of 2) 


NSR_MAX_STREAMS Optional. Specifies the maximum number of 

restore streams. 

RESTORE_TYPE_ORDER Optional. Specifies the type of proxy restore to be 

performed. 

Note: If multiple values are specified, each type of 

restore is attempted (n the order specified) until a 

restore operation is successful. 

Example 27 PowerSnap parameter settings 

To set the PowerSnap parameter RESTORE_TYPE_ORDER for a proxy restore, a 

configuration file named /oracle/rman/proxy.cfg can be created, consisting of the 

following line: 

RESTORE_TYPE_ORDER=rollback:pit:conventional 

In this case, the NMO parameter NSR_PROXY_PFILE must be set to 

/oracle/rman/proxy.cfg by using the send command. For example, the following 

command sets the parameter correctly: 

allocate channel t1 device type ’SBT_TAPE’; 

send ’NSR_ENV=(NSR_PROXY_PFILE=/oracle/rman/proxy.cfg)’; 

Example 28 PowerSnap parameter settings for a Celerra NAS device 

To enable proxy backup and restore operations with Celerra ® NAS devices, ensure 

that the following PowerSnap parameters are set in the user-defined configuration 

file that you specify with the NMO parameter NSR_PROXY_PFILE: 

◆ NSR_DATA_MOVER=name or IP of NetWorker data mover 

Identifies the NetWorker data mover to use for rollovers. 

◆ NSR_SNAP_NAS_CEL_CS_HOST=name or IP of Celerra control station 

Identifies the Celerra control station. 

◆ NAS_SNAP_SUBTYPE=CEL_SNAPSURE 

Identifies the NAS SCM subtype to use. 

◆ NSR_SNAP_TYPE=nas 

Specifies that this is a NAS save object. 

Note: The value of NSR_SNAP_TYPE must be lowercase nas. 

◆ NSR_SNAP_NAS_CLIENT=name or IP address of NAS filer with the NFS file system 

Identifies the NFS server for the specified mount point. 


16 (default). 

An integer value. 

pit:conventional (default). 

One or more of the following values, each value 

delimited from the others by a colon(:): 

pit — Specifies an instant restore. 

conventional — Specifies a proxy restore from 

secondary storage media. 

rollback — Specifies a rollback restore from a 

point-in-time proxy copy. 

“Proxy restore requirements” on page 177 provides 

more information.


The PowerSnap Module documentation provides more details on these PowerSnap 

parameters. 

For example, the following PowerSnap parameters are included in the 

/nsr/res/nas_backup.cfg file (specified with NSR_PROXY_PFILE) for a proxy 

backup with a Celerra NAS device: 

cat /nsr/res/nas_backup.cfg 

NSR_PS_DEBUG_LEVEL=9 

NSR_DEBUG_LEVEL=9 

NSR_DATA_MOVER=datamover.emc.com 

NSR_SNAP_NAS_CEL_CS_HOST=controlstn 

NAS_SNAP_SUBTYPE=CEL_SNAPSURE 

NSR_SNAP_TYPE=nas 

NSR_SNAP_NAS_CLIENT=11.222.333.44 

For example, the following PowerSnap parameters are included in the 

/nsr/res/nas_restore.cfg file (specified with NSR_PROXY_PFILE) for a proxy restore 

with a Celerra NAS device: 

cat /nsr/res/nas_restore.cfg 

NSR_PS_DEBUG_LEVEL=9 

NSR_DEBUG_LEVEL=9 

NSR_DATA_MOVER=datamover.emc.com 

NSR_SNAP_NAS_CEL_CS_HOST=controlstn 

NAS_SNAP_SUBTYPE=CEL_SNAPSURE 

NSR_SNAP_TYPE=nas 

NSR_SNAP_NAS_CLIENT=11.222.333.44 

RESTORE_TYPE_ORDER=conventional 

Configuring the NetWorker Pool resources 

A separate pool must be configured to support proxy backups. The PowerSnap 

Module stores the metadata from the point-in-time copy (snapshot) in this pool. The 

pool is configured by using the same method as for a regular NMO backup. 

However, the specified backup device should be a file or advanced file type. 

Note: Specify the pool name in the Snapshot Pool attribute of the NetWorker Group resource, 

as described in “Configuring the NetWorker Group resource” on page 169. 

The NetWorker PowerSnap Module documentation provides more information on 

configuring this extra pool. 

Configuring the NetWorker Snapshot Policy resource 

A special NetWorker snapshot policy is required to perform proxy backups. You can 

either specify a preconfigured policy or create a new snapshot policy. 

Configure a NetWorker Snapshot Policy resource by using the instructions in the 

NetWorker PowerSnap Module documentation. 

Configuring the NetWorker Group resource 

For proxy backups, configure a NetWorker Group resource by using the instructions 

in the NetWorker PowerSnap Module documentation. 



Configuring the NetWorker Client resource 

The basic NetWorker Client resource for the Oracle Server is configured according to 

“Configure a Client resource with NMC” on page 87. 

Notes: 

◆ Only members of a NetWorker user group with the Change Security Settings 

privilege can set the Remote Access attribute in the Client Resource. 

170 

Testing a scheduled proxy backup 

! 

◆ The Browse Policy attribute in the Client resource applies only to the NetWorker 

client file index entries for backups residing on secondary storage (live backups). 

◆ The Retention Policy attribute in the Client resource applies only to the 

NetWorker media database entries for live backups. 

◆ The lifecycle of a point-in-time copy (instant backup) is governed by the snapshot 

policy specified in the Group resource to which the given client belongs. 

How to configure the NetWorker Client resource 

To configure the NetWorker Client resource for the Oracle Server: 

1. For the Save Set attribute, specify the complete pathname of each RMAN script to 

be used for the backups. 

2. For the Group attribute, specify the name of the NetWorker Group resource 

created for the proxy backups. “Configuring the NetWorker Group resource” on 


3. For the Schedule attribute, specify a NetWorker backup schedule. 

4. For the Backup Command attribute, specify the name of the nsrnmo script to use 

for the proxy backups. 

5. For the Parallelism attribute (a hidden attribute), specify the number of data 

streams that the Oracle Server is allowed to send in parallel to the NetWorker 

server or storage node. 

6. For the Storage Nodes attribute, specify the name of each storage node to which 

the Oracle Server can back up data. 

The Oracle Server backs up to the first active, enabled storage node in the order 

listed in the attribute. The default storage node name, nsrserverhost, represents 

the NetWorker server. 

7. For the Remote Access attribute, specify the user ID or hostnames of other clients 

that are allowed to back up or restore this client’s files. 

For proxy backups that use a proxy client host, the Remote Access attribute must 

include the proxy client hostname. 

IMPORTANT 

A proxy backup can be started only by automatic or manual invocation of the 

scheduled NetWorker backup group. A proxy backup cannot be scheduled 

through Oracle Enterprise Manager, or started by invoking RMAN from the 

operating system command line. 

To verify the scheduled backup setup, follow the instructions for regular backups in 

“Test a scheduled backup” on page 110. 

Since manual (unscheduled) proxy backups are not supported, you cannot test a 

proxy RMAN script by using the information in “Test RMAN scripts for scheduled 


Proxy backup requirements 

Checking configuration consistency 


backups” on page 79. To determine if the script contains any errors, log the RMAN 

output into a file by setting the parameter NSR_RMAN_ARGUMENTS in the 

nsrnmo script used for the backup. 

Review the following information, specific to proxy backups: 

◆ “Checking configuration consistency” on page 171 

◆ “Performing proxy backups” on page 172 

“Proxy backups and restores on cluster systems” on page 194 provides information 

on proxy backups in a cluster environment. 

During a scheduled backup, NMO checks for consistency between the NetWorker 

Group resource configuration and the RMAN backup session. 

If NMO finds a discrepancy between the Group resource configuration and the 

RMAN session, warning messages are generated or the backup fails, as described in 

the following sections: 

◆ “With a group configured for proxy backups” on page 171 

◆ “With a group configured for regular backups” on page 172 

With a group configured for proxy backups 

If the Snapshot attribute in the NetWorker Group resource is set to True, the resource 

is configured for proxy backups. However, this configuration does not guarantee that 

a proxy backup is executed. RMAN might still perform only regular Oracle backups 

if either of the following exists: 

◆ None of the backup commands in the RMAN script include the proxy or proxy 

only option. 

◆ The backup commands in the RMAN script include the proxy or proxy only 

option, but none of the Oracle database objects (tablespaces or datafiles) specified 

in the backup commands reside on a primary storage device that the PowerSnap 

Module supports. 

If RMAN performs only regular Oracle backups due to one of these conditions, NMO 

generates the following warnings in the savegroup completion report: 

WARNING: Snapshot savegrp is completed but no Oracle proxy backup is 

detected. 

WARNING: Either fix your RMAN script or reconfigure the group resource 

without snapshot flag. 

While the resulting backups are valid regular (nonproxy) backups, correct the RMAN 

script or relocate the Oracle datafiles to a supported primary storage device, as 

required to enable proxy backups. 

The current EMC compatibility guides provide details on the primary storage devices 

supported for proxy backups with the PowerSnap Modules. 

If a backup command in the RMAN script includes the proxy only option and the 

Oracle data objects reside on volumes that do not support snapshots, the scheduled 

backup fails since RMAN cannot perform a regular backup of the objects. The Oracle 

Proxy backup requirements 171


172 

documentation provides a detailed description of the difference between the proxy 

and proxy only options. 

Note: If the PowerSnap Module software involved in a proxy backup cannot determine if a file 

is snapshotable, the proxy backup fails. 

With a group configured for regular backups 

If the Snapshot attribute in the NetWorker Group resource is set to False, the resource 

is configured for regular backups. In this case, the use of the proxy or proxy only 

option with a backup command in the RMAN script is not supported. Any proxy 

backup specified in the RMAN script will fail. If there are regular and proxy backups 

in the same RMAN script, RMAN might complete one or more regular backups 

before a proxy backup fails. 

Notes: 

◆ If RMAN terminates any of the proxy backups in an RMAN script, the savegroup 

completion report lists failure of the scheduled backup. 

◆ If any proxy backups in an RMAN script fail, RMAN still performs a regular 

backup of the corresponding archived redo logs. 

Example 29 Proxy backup failure 

Performing proxy backups 

! 

A scheduled backup includes the following RMAN script, with the database files 

residing on volumes that support snapshots. However, the Snapshot attribute in the 

Group resource is set to False. As a result, the proxy database backup fails: 

run { 

allocate channel ch1 type ’SBT_TAPE’; 

allocate channel ch2 type ’SBT_TAPE’; 

backup proxy database plus archivelog; 

} 

Despite the proxy backup failure, RMAN performs a regular backup of the archived 

redo logs. The savegroup completion report lists failure of the scheduled backup. 

A proxy backup can be started only by automatic or manual invocation of the 

scheduled NetWorker backup group. 

IMPORTANT 

A proxy backup cannot be scheduled through Oracle Enterprise Manager or started 

by invoking RMAN from the operating system command line. The NetWorker 

PowerSnap Module documentation provides information on how to manually 

invoke a scheduled backup. 

Specific types of Oracle files, such as control files, cannot be backed up through a 

proxy backup. This is an Oracle constraint. The Oracle documentation for the 

particular Oracle Server release provides more information on the Oracle file types 

that do not support proxy backups. 



Directory for temporary files 

NMO creates temporary files for processing purposes in the following directory: 

◆ On UNIX, the directory is /nsr/tmp. 

◆ On Microsoft Windows, the directory is NetWorker_install_path\tmp, where 

NetWorker_install_path is the root directory of the NetWorker installation path. 

Note: During RMAN operations, do not touch any files in this directory. 

Backup summary line in savegroup report 

The savegroup completion report for a proxy backup contains a summary line that 

includes the backup size and number of files. The summary line refers to backup data 

written to NetWorker devices only. 

The summary line for an instant backup includes the size of only the metadata stored 

for the backup, not the size of the files stored on the primary storage as a 

point-in-time copy. The number of files includes the number of entries generated for 

the metadata plus the number of entries generated for the backup pieces. 

Savegroup completion status 

When a deferred live backup is run as part of a scheduled group, the backup process 

involves two steps: 

1. An instant backup is performed. At the end of the instant backup, the backup 

entries for the point-in-time copy are recorded in the NetWorker indexes and 

RMAN catalog. 

2. The deferred live backup is performed. At the end of the deferred live backup, the 

backup entries for data stored on the secondary storage are recorded in the 

NetWorker indexes. 

“Proxy backup processes” on page 153 provides more details. 

If the instant backup succeeds but the deferred live backup fails, the entire scheduled 

backup is reported as failed. However, the point-in-time copy created during the 

instant backup is a valid backup and can be used for instant or rollback restore. 

Note: If RMAN performs only a regular Oracle backup during the instant backup step 

(“Checking configuration consistency” on page 171 provides details on when this can happen), 

the deferred live backup fails because there is no point-in-time copy to be moved to secondary 

storage. The entire backup is reported as failed, but the data is stored on tape and can be used 

for restore. 

NWORA resource file backup 

If a scheduled proxy backup completes successfully, NMO automatically backs up 

the NWORA resource file, as described in “The NWORA resource file” on page 183. 

The NWORA resource file backup is performed at the backup level specified in the 

Schedule resource (for example, incremental). Oracle backups are always performed 

at the full level. The NetWorker server selects the pool for the NWORA resource file 

backup based on existing resource configurations. The setting of the parameter 

NSR_DATA_VOLUME_POOL does not affect the pool selection. 

The savegroup completion report contains a summary line for the backup that 

includes the phrase "NWORA Resource Backup." The information is also written to 

the scheduled backup debug file, specified by the parameter NSR_SB_DEBUG_FILE 

in the nsrnmo script. 

Proxy backup requirements 173


174 

In the NetWorker indexes, the save set name for the NWORA resource file backup is 

the same as the file pathname. You can use the NetWorker mminfo command to 

display the save set name. “NWORA resource file backup in the NetWorker indexes” 

on page 176 provides information on how the backup is represented in the 


The NWORA resource file backup can be restored by using the NetWorker recover 

command or nwrecover GUI program. The NetWorker administration guide 


Note: The file is stored under the "backup" namespace, not the "oracle" namespace. 

The browse and retention policies applied to the NWORA resource file backup are 

the most conservative policies associated with the given NetWorker client, not the 

policies that are applied to the Oracle backups. As a result, you may see a difference 

between the policies assigned to the NWORA resource file backup and the Oracle 

backups. 

Canceling proxy backups 

Proxy backups can be canceled by using the same methods as for regular Oracle 

backups. The following sections provide more information: 

◆ “Cancel a manual backup” on page 107 

◆ “Cancel a scheduled backup” on page 111 

Proxy backup information in the NetWorker indexes 

The NetWorker server maintains information about each backup in its online 

indexes. “NetWorker software” on page 47 provides more information. 

The index entry for a proxy backup is stored in the NetWorker client file index for the 

Oracle Server host, under the "oracle" namespace (as is the case for a regular backup). 

The NetWorker client file index and media database each contain a different value for 

the name of the save set for a proxy backup (as is the case for a regular scheduled 

backup). 

Query the online NetWorker indexes by using the NetWorker commands, nsrinfo 

and mminfo: 

◆ Type the nsrinfo command to query the NetWorker client file index. For 

example: 

nsrinfo -n oracle -s NetWorker_server Oracle_Server_hostname 

◆ Type the mminfo command to query the NetWorker media database. For 

example: 

mminfo -v -s NetWorker_server -c Oracle_Server_hostname 




Entries in the client file index 


For a backup piece created through a proxy backup, the client file index contains 

three types of backup entries under the "oracle" namespace: 

◆ One entry is generated for the backup piece name assigned by RMAN, such as 

/PROXY_O901JB_811_1/ in Example 30 on page 175. 

◆ The second entry is generated for the point-in-time metadata, such as 

/brcmeta.1/ in Example 30 on page 175. This entry is created for an instant 

backup only. 

◆ The third entry is generated for the Oracle datafile that is backed up to secondary 

storage, for example, /JBOD13_NMO41_MVOL3/tbspc4_data1.dbf in 

Example 30 on page 175. This entry is created for a live backup only. 

Example 30 Proxy backup entries in the client file index 

Entries in the media database 

The nsrinfo command provides information on the proxy backup entries in the 

NetWorker client file index: 

nsrinfo -n oracle marmaris 

scanning client ’marmaris’ for all savetimes from the oracle namespace 

/PROXY_O901JB_811_1/, date=1178916449 Fri May 11 13:47:28 2007 

/brcmeta.1/, data=1178916446 Fri May 11 13:47:25 2007 

Physical files to rollover: 

/JBOD13_NMO41_MVOL3/tbspc4_data1.dbf 

/JBOD13_NMO41_MVOL3/tbspc4_data1.dbf, date=1178916453 Fri May 11 

13:47:31 2007 

For a backup piece created through a proxy backup, the media database contains two 

types of entries: 

◆ One entry is generated for the point-in-time metadata. This entry is created for an 

instant backup only. 

In the mminfo command output for this entry: 

The Size field contains the size of the metadata stored on the NetWorker 

device. 

The Flag field (fl) includes the letter P, representing the point-in-time copy. 

To list the entries for an instant backup only, type the following mminfo 

command: 

mminfo -v -c Oracle_Server_hostname -q ’snap’ 

The NetWorker PowerSnap Module documentation provides more information. 

◆ The other entry is generated for the Oracle datafile that is backed up to secondary 

storage. This entry is created for a live backup only. 

Both entries in the media database include the name of the RMAN backup script used 

for the proxy backup, such as /space1/home/oracle/bp1 in Example 31 on page 176. 

Proxy backup information in the NetWorker indexes 175


176 

Example 31 Proxy backup entries in the media database 

The mminfo command provides information on the proxy backup entries in the 

NetWorker media database: 

mminfo -v -c marmaris 


nmo.002 marmaris 05/10/07 13:18:39 102 MB 

snap.001 marmaris 05/10/07 13:18:41 2 KB 

ssid fl lvl name 

4064690015 cb full /space1/home/oracle/bp1 

4098244417 cbP full /space1/home/oracle/bp1 

NWORA resource file backup in the NetWorker indexes 

In the NetWorker indexes, the NWORA resource file backup is stored under the 

"backup" namespace. As a result, the NetWorker recover or nwrecover program can 

be used to restore the backup. The save set name for the backup is the same as the file 

pathname. 

Query the NetWorker indexes for information about the NWORA resource file 

backup by using the NetWorker commands nsrinfo and mminfo. 

Example 32 Resource file backup entry in the client file index 

The nsrinfo Oracle_Server_hostname command provides information on the NWORA 

resource file backup entry in the NetWorker client file index: 

nsrinfo marmaris 

scanning client ’marmaris’ for all savetimes from the backup namespace 

/nsr/res/nwora.res, date=1178808677 Thu May 10 13:18:39 2007 

/nsr/res/, date=1178808677 Thu May 10 13:18:39 2007 

/nsr/, date=1178808677 Thu May 10 13:18:39 2007 

/, date=1178808677 Thu May 10 13:18:39 2007 

Note: This entry is not displayed with the nsrinfo -n oracle command because it is stored 

under the "backup" namespace, not the "oracle" namespace. The "backup" namespace is the 

default namespace for the nsrinfo command. 

Example 33 Resource file backup entry in the media database 

The mminfo -v -c Oracle_Server_hostname command provides information on the 

NWORA resource file backup entry in the NetWorker media database: 

mminfo -v -c marmaris 


nmo.002 marmaris 05/10/07 13:18:39 4 KB 

ssid fl lvl name 

3863367791 cb full /nsr/res/nwora.res 




Proxy restore requirements 

Creating RMAN scripts for proxy restores 


Chapter 4, “Data Restore and Recovery,” provides basic information on how to 

configure and run Oracle data restore and recovery by using NMO. 

Review the following information, specific to proxy restores: 

◆ “Creating RMAN scripts for proxy restores” on page 177 

◆ “Performing proxy restores” on page 178 

◆ “Relocating files during proxy restores” on page 179 

◆ “Restoring to a different host” on page 180 

◆ “Point-in-time recoveries without a Recovery Catalog” on page 181 

“Proxy backups and restores on cluster systems” on page 194 provides information 

on proxy restores in a cluster environment. 

The same RMAN script used for a regular Oracle restore can also be used for a proxy 

restore. 

Note: The RMAN restore command does not include a proxy option. 

To create an RMAN script for a proxy restore, follow the instructions in Chapter 4, 

“Data Restore and Recovery.” 

To perform a proxy restore, the appropriate parameters must be set, as described in 

“Setting the parameters” on page 166. 

The RESTORE_TYPE_ORDER parameter 

The RESTORE_TYPE_ORDER parameter setting determines the type of proxy restore 

that is performed: 

1. RMAN determines which backup needs to be restored and passes the required 

backup piece name to NMO. 

2. The RESTORE_TYPE_ORDER parameter specifies whether the backup piece is to 

be restored by using one of the following: 

The point-in-time copy 

The copy stored on secondary storage 

Example 34 RESTORE_TYPE_ORDER parameter settings 

If the RESTORE_TYPE_ORDER parameter is set to the value rollback:pit, a rollback 

restore is attempted first. If it fails, an instant restore (indicated by pit) is attempted. If 

the parameter is not set, the default order pit:conventional is used, where 

conventional represents a restore from secondary storage. 

If the rollback option is not set explicitly, a rollback is not attempted. “Performing 

proxy restores” on page 178 provides more information on setting up a rollback 

operation. 

Proxy restore requirements 177


178 

! 

IMPORTANT 

For the RESTORE_TYPE_ORDER parameter, NMO does not support the 

force_rollback option, which is supported by PowerSnap Modules. If the option is 

specified, the restore fails, even if other valid restore options are also specified. 

The NSR_CLIENT parameter 

To restore Oracle data to a different host, the parameter NSR_CLIENT must be set to 

the required hostname. “Restoring to a different host” on page 180 provides more 


Performing proxy restores 

The following requirements apply to proxy restores: 

◆ The PowerSnap Module software must be installed, according to the instructions 

in the NetWorker PowerSnap Module documentation (refer to the PowerSnap 

Module version for the primary storage system). 

◆ Each element of the restore path must exist. Otherwise, the restore fails. For 

example, to restore a file backup to /space1/oradata/file.dbf, the path 

/space1/oradata must exist. 

◆ A proxy restore of a symbolic link restores the Oracle file to the location pointed 

to by the symbolic link. Both the symbolic link and the restore path must exist. 

Otherwise, the restore fails. 

◆ For a rollback restore, the psrollback.res file must be set up properly, as described 

in “Rollback restore” on page 179. 

◆ For user-specified relocation of files during a proxy restore, the relocation path 

must be specified as described in “Relocating files during proxy restores” on 

page 179. 

◆ After an Oracle restore is complete, a database administrator must recover the 

database by using the standard Oracle recover command. 

Concurrent restore streams 

During a proxy restore, the PowerSnap Module creates concurrent restore streams to 

optimize the restore. 

The maximum number of concurrent restore streams is defined by the PowerSnap 

parameter NSR_MAX_STREAMS. Table 7 on page 167 provides more information. 

Directory created for file system data restore 

During a proxy restore of regular file system data, a .nworapc subdirectory (with 

0700 permissions) is created under the restore directory for the temporary relocation 

of the files being restored. (This relocation is independent of user-specified 

relocation.) The empty .nworapc subdirectory persists after the restore and can be 

deleted manually, if required. 

If a proxy restore of file system data fails, the non-empty .nworapc subdirectory 

persists after the restore, and can be deleted manually, if required. Do not use any 

datafiles from this subdirectory for Oracle recovery, or database corruption might 

occur. If you restart the failed restore, NMO automatically cleans this subdirectory. 


Rollback restore 


For a rollback restore, the psrollback.res file must contain the directory name 

.nworapc. The file is located as follows: 

◆ On UNIX: /nsr/res/psrollback.res 

◆ On Microsoft Windows: NetWorker_install_path\res\psrollback.res, where 

NetWorker_install_path is the root directory of the NetWorker installation path 

Add the directory name to the file by using a text editor as either the root user on 

UNIX or a member of the Microsoft Windows Administrators group. 

The following sources provide more information on the psrollback.res file: 

◆ NetWorker PowerSnap Module documentation for the primary storage system. 

◆ Comments within the psrollback.res file itself. 

Note: The NetWorker PowerSnap Module documentation provides information on whether 

rollback is supported on a particular storage platform. 

Rollback restore on Celerra NAS devices 

NMO software supports the rollback safety check feature for rollback restores on 

Celerra NAS devices. The psrollback.res file lists all the files, directories, partitions, 

and volumes that are to be excluded from the rollback safety check. The items 

excluded from the safety check will be overwritten during a rollback operation. 

Note: For NMO systems, “.etc” must be added to the psrollback.res file. 

To enable remount of the NAS file system at the end of a rollback operation, place an 

entry for the target file system in the appropriate file: 

◆ /etc/vfstab on Solaris 

◆ /etc/fstab on HP-UX 

Relocating files during proxy restores 

! 

◆ /etc/filesystems on IBM AIX 

If this is not done, the remount at the end of the rollback fails. The data is recovered, 

but the file system must be remounted manually and the tablespace brought back 

online. 

This section describes the user-specified relocation of a proxy restore with NMO. 

IMPORTANT 

Relocation is not supported during a rollback restore. If the 

RESTORE_TYPE_ORDER parameter includes the rollback value and the RMAN 

restore script specifies relocation, the restore fails, even if the parameter includes 

other values. 

During a proxy restore, NMO supports and controls relocation, which is the restore 

of datafiles (regular files or raw volumes) to a new location. The new location can be 

specified by using the RMAN set newname command. 

Note: During a regular Oracle restore, relocation is also supported, but it is controlled by the 

Oracle Server. 

Proxy restore requirements 179


180 

To relocate a regular file or raw volume during a proxy restore, the set newname 

command must specify the name of the relocated file as one of the following: 

◆ The complete pathname of the relocated file. 

◆ The complete pathname of a symbolic link that points to the location where the 

file will be restored. 

Example 35 Symbolic link specified in the set newname command 

! 

If the symbolic link /tmp/file1 points to /dbapps/proddb/file2 and the symbolic 

link /tmp/file1 is specified in the set newname command, the backed-up file will be 

restored to /dbapps/proddb/file2. 

IMPORTANT 

The procedure to relocate a raw volume includes a restriction that does not apply 

when relocating a regular file. 

To relocate a raw volume, the base filename (the filename without the directory path) 

of the original backed-up raw volume must be identical to one of the following: 

◆ The base filename of the relocation path specified in the set newname command. 

◆ If the set newname command specifies a symbolic link, the base filename in the 

symbolic link. 

Example 36 Relocation of a raw volume 

Restoring to a different host 

If a backed-up raw volume is named /dev/volume_one/rvol1, the 

/dev/volume_two/rvol1 relocation path can be specified in the set newname 

command. This can occur because the original and relocation paths have the same 

base filename, rvol1. However, specifying the /dev/volume_one/rvol2 path in the 

set newname command would cause the proxy restore to fail, since the original and 

relocation paths have different base filenames. 

The following procedure is one way to relocate /dev/volume_one/rvol1 to 

/dev/volume_one/rvol2: 

1. Create a symbolic link named /tmp/rvol1 that points to 

/dev/volume_one/rvol2. 

2. Specify /tmp/rvol1 in the set newname command in the RMAN restore script. 

In this case, the relocation succeeds because both the original path and symbolic link 

name have the same base filename, rvol1. 

To restore proxy database backups to a different host, follow the guidelines in 

“Restore to a different host” on page 126. Task 2 of that section explains that NMO 

must be installed and configured on the system where the Oracle data is to be 

restored. For proxy restores to a different host, the required PowerSnap Module must 

also be installed and configured on that system. 


Point-in-time recoveries without a Recovery Catalog 


Note: If point-in-time recoveries are performed with an RMAN Recovery Catalog, the 

information in this section does not apply. 

During a proxy database backup, Oracle backs up the control file after the proxy 

backup of the datafiles is complete. In a large database production environment, 

there might be a delay between the end time of the datafile backup and the start time 

of the control file backup. 

During this time delay, if the physical structure of the database is changed (for 

example, a new datafile is added), the control file must be backed up in a separate 

RMAN session before the changes occur. This is due to the fact that the control file 

backup from the proxy database backup session will include information on the new 

database structure. 

Catalog synchronization for proxy backups 

Extra entries in the catalogs 

During Oracle backups, RMAN stores information about each backup piece in the 

RMAN repository, also known as the "RMAN catalog". Similarly, NMO stores 

information about each backup piece in the NetWorker indexes, or what Oracle 

documentation refers to as the "MML catalog." 

During Oracle restores, the following occurs: 

◆ The RMAN catalog determines the data to be restored. 

◆ The NetWorker indexes provide information that NMO requires to perform the 

restore. 

It is important to keep the RMAN catalog and NetWorker indexes synchronized, 

especially when performing instant backups. 

The catalogs are unsynchronized when one of the following exists: 

◆ The RMAN catalog contains backup piece entries that do not have corresponding 

NetWorker index entries. 

◆ The NetWorker indexes contain backup piece entries that do not have 

corresponding RMAN catalog entries. 

Note: If catalog synchronization is enabled for NMO, proxy backup entries in the catalogs are 

synchronized automatically. 

Extra entries in the NetWorker indexes do not cause problems as long as the extra 

entries contain unique backup piece names that RMAN does not attempt to reuse for 

backups. 

However, extra entries in the RMAN catalog can cause serious problems. These extra 

entries can occur when corresponding NetWorker index entries are removed through 

either expiration or NetWorker commands such as nsrmm. For example, instant 

backups are often configured to expire quickly (within hours), causing the 

NetWorker index entries to be removed. 

Catalog synchronization for proxy backups 181


Removing instant backup entries from the NetWorker indexes 

Instant backup entries in the NetWorker indexes are removed in one of the following 

ways: 

182 

◆ At the start of an instant backup, if the number of existing instant backups equals 

the value of the Retain Snapshots attribute in the NetWorker Snapshot Policy 

resource, the oldest instant backup is automatically expired and its NetWorker 

index entries are removed. 

Note: This automatic expiration and index entry removal does not apply to instant backups 

specified with the nsrnmo -c client_name command. 

The following sections provide more information on using this command: 

- “Proxy backups from a virtual cluster client” on page 195 

- “Proxy backups from a physical cluster client” on page 196 

◆ When the expiration policy for an instant backup expires, the NetWorker process 

nsrim prunes the backup entries from the NetWorker indexes. 

◆ The NetWorker process nsrexecd performs consistency checking that can remove 

backup entries from the NetWorker indexes. 

◆ The DBA uses a NetWorker command, such as nsrmm, to remove a save set that 

includes an instant backup. 

Problems with extra entries in the RMAN catalog 

When the RMAN catalog contains extra entries (without corresponding entries in the 

NetWorker indexes), the following types of problems can occur: 

! 

◆ When RMAN backup optimization is enabled, RMAN might skip backing up 

certain files. 

◆ The RMAN catalog might expire backups that are required for restores. 

◆ RMAN restores might fail when RMAN attempts to restore backup pieces that 

have no corresponding NetWorker index entries. 

The RMAN repository can be stored in either the control file of the target database or 

in an RMAN recovery catalog. An RMAN recovery catalog is an Oracle database. 

Note: For proxy instant backups, use an RMAN recovery catalog instead of a control file. 

“Control file versus recovery catalog” on page 183 provides more information. 

IMPORTANT 

To enable automatic catalog synchronization for proxy backups: 

- The parameter ORACLE_SID must be properly set in the nsrnmo scheduled 

backup script at the time of the proxy backup. “Customize the nsrnmo script” on 

page 79 provides details. 

- An NWORA resource file must include the required resources, as described in 

“The NWORA resource file” on page 183. 

The NMO program nsroraclecat uses the NWORA resources in the file to perform 

automatic synchronization of the RMAN catalog and NetWorker indexes. DBAs can 

also synchronize the catalogs manually by using RMAN commands. 


Control file versus recovery catalog 

The NWORA resource file 

! 


The following sections provide complete information on how to configure and 

perform catalog synchronization: 

◆ “The NWORA resource file” on page 183 

◆ “Automatic catalog synchronization with the nsroraclecat program” on page 191 

The control file of an Oracle database can store only a limited number of backup 

entries. When the maximum number of entries is exceeded, old entries in the control 

file are overwritten by new ones. You can determine the number of entries in a 

control file from the appropriate Oracle dynamic view. The Oracle documentation 


Instant backups use control file entries of type PROXY COPY. For instant backups, an 

RMAN recovery catalog (instead of a control file) can be used, since there is no limit 

on the number of entries a recovery catalog can contain. 

IMPORTANT 

If you use a control file as the RMAN catalog during an instant backup, ensure that 

the control file contains enough free entries for the backup. RMAN creates a new 

entry in the control file for each file backed up in an instant backup. The backup of 

a large database with many files can quickly use all the free entries in the control 

file and start overwriting old entries. When entries are overwritten, the 

corresponding backups cannot be restored. 

Proxy backups require the NWORA resource file to exist in the following location: 

◆ On UNIX: /nsr/res/nwora.res 

◆ On Microsoft Windows: NetWorker_install_path\res\nwora.res, where 


The NWORA resource file is created by the nsrnmoadmin program when it is run for 

the first time. 

To enable instant backups and catalog synchronization, specific NWORA resources 

must be added to the file with the nsrnmoadmin program. 

Note: The NWORA resource file must not be edited manually. All resources in the file must be 

added, modified, or deleted by using the nsrnmoadmin program only. The nsrnmoadmin 

program must be run by either the root user on UNIX or a member of the Microsoft Windows 

Administrators group. 


page 188 provides details on the nsrnmoadmin program. 

The NWORA resource file for instant backups must contain two types of resources, 

NWORA parameter resources and NWORA SID resources. The following sections 

provide more information: 

◆ “NWORA parameter resources” on page 184 

◆ “NWORA SID resources” on page 186 



NWORA parameter resources 

An NWORA parameter resource comprises one specific parameter setting, such as 

for the parameter NSR_ORACLECAT_MODE. For instant backups, the NWORA 

resource file must contain at least the following parameter resources: 

184 

◆ “NSR_NWPATH” on page 184 

◆ “NSR_ORACLECAT_DEBUG_FILE” on page 184 

◆ “NSR_ORACLECAT_LOG_FILE” on page 184 

◆ “NSR_ORACLECAT_MODE” on page 185 

◆ “NSR_REMOVE_ON_FAILURE” on page 185 

Note: The parameter resources listed in Table 8 on page 184 are the only ones supported. Do 

not attempt to add other parameter resources to the NWORA resource file. 

Table 8 NWORA parameter resources (page 1 of 2) 

Parameter resource Description Default and valid values 

NSR_NWPATH Specifies the directory location of the NetWorker binary 

nsrsnapck. 

Note: If you use NMO with Sun-branded NetWorker, you must 

set NSR_NWPATH by using the following nsrnmoadmin 

command: 

nsrnmoadmin -r update NSR_NWPATH=/usr/sbin/nsr 

NSR_ORACLECAT_DEBUG_FILE Specifies the debug file used by the nsroraclecat program. 

Set this parameter only for the purpose of debugging the 

nsroraclecat program. 

Note: The nsroraclecat debug file must be created in a 

secure location since it includes a copy of the strings from the 

RMAN connection file. 

NSR_ORACLECAT_LOG_FILE Specifies the operations log file used by the nsroraclecat 

program. The logged information includes the backup pieces 

successfully removed from the RMAN catalog, and those that 

failed to be removed during automatic catalog 

synchronization. 


Directory pathname for the location of 

nsrsnapck (default). 

Valid directory pathname for the location of 

the NetWorker binary nsrsnapck. 

Undefined (default). 

Valid pathname of the nsroraclecat debug 

file. 

Note: If undefined, debug information is not 

generated. 


Valid pathname of the nsroraclecat log file. 

Note: If undefined, logging information is written 

to the /nsr/applogs/nsroraclecat.log file by 

default.

Table 8 NWORA parameter resources (page 2 of 2) 

Parameter resource Description Default and valid values 

NSR_ORACLECAT_MODE Specifies whether automatic catalog synchronization is 

enabled or disabled during proxy backups. 

NSR_ORACLE_NLS_LANG Required to enable proxy catalog synchronization in a 

non-English environment only. Specifies the non-English 

locale value, as set in the NLS_LANG environment variable. 

“Configure I18N support” on page 68 provides more 


NSR_REMOVE_ON_FAILURE Specifies whether the corresponding NetWorker index entries 

are removed when the nsroraclecat program fails to remove 

one or more RMAN catalog entries during automatic catalog 

synchronization. “Automatic catalog synchronization with the 

nsroraclecat program” on page 191 provides more 


Undetermined (default). 

Enabled. 

Disabled. 


Note: Instant backups require the resource value 

to be set to either "enabled" or "disabled". If the 

value is unset, instant backups fail. 

Undetermined (default). 

Valid locale value, same as set in the 

NLS_LANG environment variable. 

Note: If the value is not set to the same value as 

the NLS_LANG variable in a non-English 

environment, proxy catalog synchronization fails. 

FALSE (default). 

TRUE. 

Using the nsrnmoadmin command to set parameter resources 

When the nsrnmoadmin command (with any options) is used for the first time after 

the NMO installation, the NWORA resource file is automatically populated with five 

parameter resources from Table 8 on page 184: NSR_NWPATH, 

NSR_ORACLECAT_DEBUG_FILE, NSR_ORACLECAT_LOG_FILE, 

NSR_ORACLECAT_MODE, NSR_REMOVE_ON_FAILURE. Depending on the 

nsrnmoadmin command options used, the parameter resources are set to either 

default or customized values. 

Note: Once an NWORA parameter resource is added to the resource file, it cannot be deleted. 

However, its value can be modified. 

To view the NWORA parameter resources in the resource file, use the nsrnmoadmin 

-r list command. 

To modify NWORA parameter resource settings, use the nsrnmoadmin -r update 

command. 


page 188 provides details on how to use the nsrnmoadmin command. 



186 

NWORA SID resources 

Example 37 Default NWORA parameter resources 

! 

After the NMO installation, if the first nsrnmoadmin command used is 

nsrnmoadmin -r list (to list the NWORA resource file contents), the command adds 

the following default settings for the NWORA parameter resources to the resource 

file: 

NSR_NWPATH=NetWorker_binary_path 

NSR_ORACLECAT_MODE=undetermined 

NSR_REMOVE_ON_FAILURE=FALSE 

NSR_ORACLE_LOG_FILE= 

NSR_ORACLECAT_DEBUG_FILE= 

NetWorker_binary_path is the pathname of the directory that contains the NetWorker 

binary nsrsnapck. 

To enable instant backups, NSR_ORACLECAT_MODE must be set to either enabled 

or disabled by using the nsrnmoadmin -r update command. 

This default NWORA resource file does not yet contain any NWORA SID resources, 

as described in “NWORA SID resources” on page 186. 

An NWORA SID resource comprises a specific group of parameters for a single 

Oracle database. If automatic catalog synchronization is enabled 

(NSR_ORACLECAT_MODE is set to enabled), the NWORA resource file must 

contain an NWORA SID resource for each Oracle database (ORACLE_SID). The 

NWORA SID resource can include only the parameters described in Table 9 on 

page 186. 

However, an unlimited number of NWORA SID resources can be added to the 

resource file. 

IMPORTANT 

If automatic catalog synchronization is enabled, but you do not create an NWORA 

SID resource for an Oracle database, the catalogs will not be synchronized during 

instant backups of that database. As a result, the catalogs can become 

unsynchronized unless you synchronize them manually by using RMAN 

commands. “Automatic catalog synchronization with the nsroraclecat program” on 


Note: Each NWORA SID resource must have a unique NSR_ORACLE_SID value. 

Table 9 NWORA SID resource components (page 1 of 2) 


NSR_ORACLE_CONNECT_FILE Mandatory. Specifies the location of the file containing the 

connection strings required to create an RMAN session. “The 

connection file” on page 188 provides more information. 

NSR_ORACLE_HOME Mandatory. Specifies the home directory of the Oracle 

installation. The RMAN executable must be located in 

subdirectory bin of this directory. 



Valid pathname of the RMAN connection file. 


Valid pathname of the Oracle home directory. 

Note: The value must be equal to the Oracle 

parameter $ORACLE_HOME value.

Table 9 NWORA SID resource components (page 2 of 2) 


NSR_ORACLE_LIB_PATH Optional. Specifies the pathname of the directory containing 

the Oracle shared libraries on UNIX, typically 

$ORACLE_HOME/lib. 

NSR_ORACLE_SID Mandatory. Specifies the SID value of the Oracle database 

whose RMAN catalog is to be synchronized. 

NSR_ORACLE_TNS_ADMIN Optional. Specifies the pathname of the directory containing 

the Oracle Net configuration files. 


Using the nsrnmoadmin command to set SID resources 

To add an NWORA SID resource to the resource file, use the nsrnmoadmin -r add 

command. 

To modify NWORA SID resource settings, use the nsrnmoadmin -r update 

command. 


page 188 provides details on how to use the nsrnmoadmin command. 

Example 38 NWORA SID resource 

Automatic catalog synchronization is enabled for instant backups when the 

NSR_ORACLECAT_MODE parameter resource is set to enabled. Prior to performing 

instant backups of an Oracle database with an ORACLE_SID value of proddb, add an 

NWORA SID resource to the resource file by using the nsrnmoadmin -r add 

command. The SID resource must include the following: 

◆ NSR_ORACLE_SID set to proddb. 


Valid pathname of the Oracle shared library 

directory on UNIX. 

Note: This parameter is not required on 

Windows. 


Valid SID value of the Oracle database. 

Note: The value must be equal to the 

ORACLE_SID value in the particular nsrnmo 

script used for the database backup. 

“ORACLE_SID” on page 83 provides more 



Valid pathname of Oracle network 

configuration directory. 

Note: The value must be equal to the Oracle 

parameter $TNS_ADMIN value. 

◆ NSR_ORACLE_CONNECT_FILE and NSR_ORACLE_HOME set to suitable 

values. 

◆ NSR_ORACLE_LIB_PATH and NSR_ORACLE_TNS_ADMIN (optional) set to 

suitable values. 

The following NWORA SID resource can be added for the Oracle database: 

NSR_ORACLE_CONNECT_FILE=/dbapps/proddb/connect.file 

NSR_ORACLE_HOME=/dbapps/proddb/app/oracle/product/10.2.0/Db_1 

NSR_ORACLE_LIB_PATH=/usr/lib 

NSR_ORACLE_SID=proddb 

NSR_ORACLE_TNS_ADMIN=/dbapps/proddb/tns 



188 

The connection file 

! 

In this sample, the RMAN connection file is /dbapps/proddb/connect.file and the 

Oracle home directory is /dbapps/proddb/app/oracle/product/10.2.0/Db_1. 

Catalog synchronization requires the connection file for an Oracle database. The 

nsroraclecat program uses the information in the connection file to delete RMAN 

catalog entries. 

In the NWORA SID resource for the target database, the parameter 

NSR_ORACLE_CONNECT_FILE must be set to the pathname of the connection file. 

“NWORA SID resources” on page 186 provides more information. 

IMPORTANT 

A DBA must create the connection file in a secure location. 

The connection file must include the following: 

◆ The connection string that is required to connect to the target database. 

◆ If an RMAN recovery catalog is used, the connection string that is required to 

connect to the RMAN recovery catalog. 

Note: The connection file must not include any lines starting with the # symbol. 

If the connection file does not contain a connection string for an RMAN recovery 

catalog, the nsroraclecat program assumes that a control file is used as the RMAN 

repository during instant backups. 

Example 39 Connection file contents 

If the following lines exist in the connection file, an RMAN recovery catalog is used as 

the RMAN repository: 

connect target sys/oracle@proddb; 

connect rcvcat rman/rman@oracat; 

Note: RMAN catalog deletions fail if the connection file for a backup piece does not exist or 

does not contain valid connection strings. 

Configuring the NWORA resource file with the nsrnmoadmin program 

All resources in the NWORA resource file must be added, modified, or deleted by 

using the nsrnmoadmin program only. 

To run the program, type the nsrnmoadmin command at the operating system 

command line, as the root user on UNIX or as a member of the Microsoft Windows 

Administrators group. 

“The nsrnmoadmin command syntax and options related to proxy backups” on 

page 189 provides details on the command syntax and options. 


Windows 2008 and Windows Vista requirements for the nsrnmoadmin 

command 


Note: Whenever you make changes to the NWORA resource file on Windows 2008 or 

Windows Vista, back up the file manually. 

On Windows 2008 and Windows Vista, you must run the nsrnmoadmin command in 

the Command Prompt window as an administrator: 

1. Click Start. 

2. Right-click Command Prompt. 

3. Select Run as administrator. 

4. Run the nsrnmoadmin command in the open Command Prompt window. 

The nsrnmoadmin command syntax and options related to proxy backups 

The nsrnmoadmin command syntax and options used to configure proxy backup 

settings are as follows: 

nsrnmoadmin [-D debug_level] -r list [ResourceName | SidName] 

nsrnmoadmin [-D debug_level] -r add ResourceName ResourceValue 

nsrnmoadmin [-D debug_level] -r add sid=SidName home=OracleHome 

connect=ConnectFilePath [lib=LibraryPath] [tns=TNSPath] 

nsrnmoadmin [-D debug_level] -r update ResourceName ResourceValue 

nsrnmoadmin [-D debug_level] -r update sid=SidName [home=OracleHome] 

[connect=ConnectFilePath] [lib=LibraryPath] [tns=TNSPath] 

nsrnmoadmin [-D debug_level] -r delete SidName 

where: 

◆ debug_level is the level of debug information generated. 

◆ ResourceName is the name of an NWORA parameter resource. 

◆ SidName is the value of the NSR_ORACLE_SID parameter of an NWORA SID 

resource. 

◆ ResourceValue is the value of the NWORA parameter resource. 

◆ OracleHome is the value of the NSR_ORACLE_HOME parameter of the NWORA 

SID resource. 

◆ ConnectFilePath is the value of the NSR_ORACLE_CONNECT_FILE parameter of 

the NWORA SID resource. 

◆ LibraryPath is the value of the NSR_ORACLE_LIB_PATH parameter of the 


◆ TNSPath is the value of the NSR_ORACLE_TNS_ADMIN parameter of the 


Only the -D and -r options are supported: 

◆ The -D option causes the nsrnmoadmin command to print debug information. 

◆ The -r option must be followed by the appropriate keywords, which determine 

the NWORA resource operation to be performed. 

Command options and settings in brackets ([ ]) are optional. Do not include the 

brackets when typing the command. 



190 

The following sections provide examples of how to use the nsrnmoadmin command 

to list, add, update, and delete NWORA resources: 

◆ “List the NWORA resources” on page 190 

◆ “Add the NWORA resources” on page 190 

◆ “Update the NWORA resources” on page 191 

◆ “Delete the NWORA SID resources” on page 191 

The following sources provide more information on the nsrnmoadmin command: 

◆ The nsrnmoadmin man page on a UNIX Oracle Server that contains the NMO 

software. 

◆ The nsrnmoadmin entry in the NetWorker Module for Oracle command 

reference guide on the Powerlink website. 

List the NWORA resources 

◆ To display the entire NWORA resource file contents, type the following: 

nsrnmoadmin -r list 

◆ To display the NSR_ORACLECAT_MODE parameter resource only, type the 

following: 

nsrnmoadmin -r list NSR_ORACLECAT_MODE 

◆ To display an NWORA SID resource with the NSR_ORACLE_SID value of 

proddb, type the following: 

nsrnmoadmin -r list proddb 

Add the NWORA resources 

◆ To add the NSR_ORACLECAT_MODE parameter resource with the value of 

enabled, type one of the following: 

nsrnmoadmin -r add NSR_ORACLECAT_MODE enabled 

nsrnmoadmin -r add NSR_ORACLECAT_MODE=enabled 

Note: If the NWORA parameter resource already exists in the resource file, use of the add 

keyword causes the resource value to be updated. 

◆ To add a new NWORA SID resource with the NSR_ORACLE_SID value of 

proddb and other values as specified in Example 38 on page 187, type the 

following: 

nsrnmoadmin -r add sid=proddb 

home=/dbapps/proddb/app/oracle/product/10.2.0/Db_1 

connect=/dbapps/proddb/connect.file lib=/usr/lib 

tns=/dbapps/proddb/tns 

Note: 

- When adding an NWORA SID resource, the keywords sid, home, and connect are 

mandatory; the keywords lib and tns are optional. 

- If an NWORA SID resource with the same NSR_ORACLE_SID value already exists, the 

command updates the values of the existing resource. 


Update the NWORA resources 


◆ To update the value of the NSR_ORACLECAT_MODE parameter resource to 

enabled, type one of the following: 

nsrnmoadmin -r update NSR_ORACLECAT_MODE enabled 

nsrnmoadmin -r update NSR_ORACLECAT_MODE=enabled 

◆ To update the values of the parameters NSR_ORACLE_HOME and 

NSR_ORACLE_CONNECT_FILE in an NWORA SID resource with the 

NSR_ORACLE_SID value of proddb, type the following: 

nsrnmoadmin -r update sid=proddb home=/dbapps/proddb/10.2.0/Db_1 

connect=/dbapps/oracle/connect/proddb.connect 

Note: When updating an NWORA SID resource, the keyword sid is mandatory. The 

keywords home, connect, lib, and tns are optional. 

Delete the NWORA SID resources 

To delete an NWORA SID resource with the NSR_ORACLE_SID value of proddb, 

type the following: 

nsrnmoadmin -r delete proddb 

Note: Only NWORA SID resources can be deleted from the resource file. NWORA parameter 

resources cannot be deleted. 

Automatic catalog synchronization with the nsroraclecat program 

Automatic catalog synchronization is managed jointly by NetWorker server and 

NMO programs. To remove instant Oracle backup entries from the NetWorker 

indexes, the NetWorker server invokes the nsrsnapck program. Prior to removing 

the index entries, nsrsnapck invokes the nsroraclecat program to remove the 

corresponding RMAN catalog entries. 

Note: To perform manual catalog synchronization, you can use specific RMAN commands, as 

described in “The change...crosscheck and crosscheck commands” on page 210. The 

appropriate Oracle documentation provides more information on RMAN commands. 

Review the following information on automatic catalog synchronization: 

◆ “RMAN catalog entry removals with nsroraclecat” on page 191 

◆ “Failure of the nsroraclecat program” on page 192 

◆ “NetWorker index entry removals with nsrsnapck” on page 193 

RMAN catalog entry removals with nsroraclecat 

The nsroraclecat program runs on the Oracle Server host that performed the instant 

backup: 

◆ Do not attempt to run the nsroraclecat program manually. 

◆ The nsroraclecat program is run automatically by the nsrsnapck program. 

◆ Only one nsroraclecat program can run at a time. If two nsroraclecat programs 

are started, the one started first completes its operation before the second one 

proceeds. 



192 

To remove the RMAN catalog entries, nsroraclecat obtains information from the 

NWORA resource file and generates temporary RMAN scripts that include an 

RMAN change...delete command for each backup piece to be removed. 

A separate script is created for all the backup pieces from the same database (or 

ORACLE_SID). 

The nsroraclecat program names each RMAN script as follows: 

◆ On UNIX: 

/nsr/tmp/.nworapc/nsroraclecat_date_pid 

◆ On Microsoft Windows: 

NetWorker_install_path\tmp\.nworapc\nsroraclecat_date_pid 

where: 


date is the current date. 

pid is the nsroraclecat process ID. 

The nsroraclecat program runs each script in an RMAN session. After the scripts 

have finished running, the program removes them. 

Note: The nsroraclecat program generates information about the backup piece entries 

removed from the RMAN catalog. The information is written to the nsroraclecat log and debug 

files. “NSR_ORACLECAT_LOG_FILE” and “NSR_ORACLECAT_DEBUG_FILE” on page 184 

provide more information on these files. 

The following sources provide more information on the nsroraclecat program: 

◆ The nsroraclecat man page on a UNIX Oracle Server that contains the NMO 

software. 

◆ The nsroraclecat entry in the NetWorker Module for Oracle command reference 

guide on the Powerlink website. 

Failure of the nsroraclecat program 

A fatal error that causes nsroraclecat to fail can be produced by the following: 

◆ The nsrsnapck program passes invalid information to nsroraclecat, for example, 

an invalid NetWorker client name or an invalid save time of a backup piece. 

◆ The nsroraclecat program cannot connect to the NetWorker server to query the 


◆ The nsroraclecat program cannot locate the required backup pieces in the 


To diagnose the cause of a nsroraclecat program failure, review the nsroraclecat log 

files specified by NSR_ORACLECAT_DEBUG_FILE and 

NSR_ORACLECAT_LOG_FILE. The operations log file is 

/nsr/applogs/nsroraclecat.log by default. 

If the nsroraclecat program fails, the nsrsnapck program removes the corresponding 

NetWorker index entries by using the procedures described in “NetWorker index 

entry removals with nsrsnapck” on page 193. 


! 

The following files (if they exist) need to be removed: 


◆ Files in one of these directories: 

On UNIX: /nsr/tmp/.nworapc 

On Microsoft Windows: NetWorker_install_path\tmp\.nworapc, where 


◆ Files in either the temporary directory /tmp on UNIX or the temporary directory 

specified by the TEMP system variable on Microsoft Windows, where the files 

have the name nwora_bp_sid_pid: 

sid is an ORACLE_SID value. 

pid is a nsroraclecat process ID. 

Note: If nsroraclecat fails continuously, disable catalog synchronization (by setting 

NSR_ORACLECAT_MODE to disabled) until the cause of the problem is determined. 

IMPORTANT 

After a nsroraclecat program failure occurs or while catalog synchronization is 

disabled, the DBA must synchronize the catalogs manually by using specific 

RMAN commands. The appropriate Oracle documentation provides more 


NetWorker index entry removals with nsrsnapck 

Once the nsroraclecat program has finished the RMAN catalog operations, the 

nsrsnapck program removes the NetWorker index entries for all the backups that 

were successfully removed from the RMAN catalog. 

If some of the backup entries failed to be removed from the RMAN catalog, the 

nsrsnapck program does the following: 

! 

◆ Removes the corresponding NetWorker index entries when 

NSR_REMOVE_ON_FAILURE is set to TRUE. 

◆ Does not remove the corresponding NetWorker index entries when 

NSR_REMOVE_ON_FAILURE is set to FALSE. 

Note: When NSR_REMOVE_ON_FAILURE is set to FALSE, nsrsnapck removes only 

those NetWorker index entries that correspond to removed RMAN catalog entries. 

IMPORTANT 

The NSR_REMOVE_ON_FAILURE setting controls the result of the nsroraclecat 

program failure to remove RMAN catalog entries. 

- In general, NSR_REMOVE_ON_FAILURE should be set to TRUE, to enable 

NetWorker index entries to be removed, even if the RMAN catalog entries are not 

removed. Otherwise, if entries are not removed from the NetWorker indexes, the 

snapshot resources are not freed and subsequent backups might fail. 

- If RMAN backup optimization is enabled, NSR_REMOVE_ON_FAILURE 

should be set to FALSE, to prevent the removal of NetWorker index entries. 

Otherwise, RMAN might skip backing up certain files. 



194 

When the nsroraclecat program fails to run properly, the nsrsnapck program’s 

actions depend on whether the instant backup on the primary storage is intact: 

◆ If the instant backup on the primary storage is destroyed or invalid, the 

nsrsnapck program removes the corresponding entry from the NetWorker 

indexes. 

◆ If the instant backup on the primary storage is intact, the nsrsnapck program 

does not remove any entries from the NetWorker indexes and generates an error 

message about the failure in the following file: 

On UNIX: /nsr/logs/daemon.raw 

On Microsoft Windows: NetWorker_install_path\logs\daemon.raw, where 


The NetWorker administration guide provides more information on the 

daemon.raw log file and how to view its contents. 

Proxy backups and restores on cluster systems 

Proxy backup failover 

! 

NMO can perform proxy backups and restores of an Oracle database configured on a 

cluster system. The software also enables cluster failover for proxy backups. 

IMPORTANT 

The parameter NSR_CLIENT is not supported for proxy backups on a cluster 

system. This parameter is used for restores and regular Oracle backups on a cluster 

system, as described in Chapter 6, “Cluster and RAC Systems.” 

Review the following information, specific to proxy operations on a cluster system: 

◆ “Proxy backup failover” on page 194 

◆ “Proxy backups from a virtual cluster client” on page 195 

◆ “Proxy backups from a physical cluster client” on page 196 

◆ “Restores from proxy backups on a cluster system” on page 197 

During a scheduled proxy backup where the Oracle software is configured to fail 

over (for example, by using Oracle Fail Save with MSCS on Microsoft Windows), the 

NetWorker server retries the backup on the failover node if the Client Retries 

attribute is set to a nonzero value in the Group resource. The retry occurs at the 

RMAN script level, whereby the RMAN script restarts from the beginning. 

Note: To avoid restarting the backups of all objects in the RMAN script during the NetWorker 

retry, you can use the Oracle restartable backups feature. This feature enables you to back up 

only the files that have not been backed up since a specified time, for example, by using the 

’sysdate -1’ option. “Restartable backups” on page 37 provides more information. 


Proxy backups from a virtual cluster client 


A proxy backup from a virtual cluster client (virtual host) protects Oracle data on 

shared cluster disks. 

To set up a proxy backup from a virtual cluster client: 

1. Install the NMO software on each physical node of the cluster, along with the 

NetWorker client and appropriate PowerSnap Module software. 

2. Create a NetWorker Client resource for the virtual host and each physical host, as 

described in “Configuring the NetWorker Client resource” on page 170: 

In the Remote Access attribute in the Client resource for a virtual cluster client, 

specify the Oracle user from each physical client that can store and retrieve 

backups. 

In the Save Set attribute, specify the complete pathname of the RMAN script 

to back up the Oracle data on the shared disk. 

3. Configure the other NetWorker resources required for proxy backups, as 

described in “Additional configurations for proxy operations” on page 163: 

To enable backup failover, specify a nonzero value in the Client Retries 

attribute in the NetWorker Group resource for the scheduled backup. This 

value causes the NetWorker server to restart the backup of uncompleted 

Oracle save sets on the failover node. 

Specify other recommended attribute settings in the Group resource, as 

described in the cluster support information of the NetWorker administration 

guide. 

4. Configure the NWORA resource file on each node of the cluster, as described in 

“Configuring the NWORA resource file” on page 164. 

5. If the Save Set attribute in the Client resource for a virtual client specifies an 

RMAN script that resides on a private disk, ensure that an empty 

pathownerignore file exists on the Oracle Server host as follows: 

On UNIX: NetWorker_install_path/bin/pathownerignore 

On Microsoft Windows: NetWorker_install_path\bin\pathownerignore 

Here, NetWorker_install_path is the root directory of the NetWorker installation 

path. 

Without the pathownerignore file on the Oracle Server, the scheduled backup 

fails due to the path-ownership rules used to distinguish between data associated 

with a physical host and data managed by a virtual client. 

6. To specify that the proxy backup entries be stored in a NetWorker client file index 

other than the virtual client index, for example, in a physical client index: 

Add -c client_name to the nsrnmo script name in the Backup Command 

attribute in the Client resource. 

Specify the Oracle user from the virtual host in the Remote Access attribute in 

the Client resource for client_name. 

The expiration of instant backups created with the nsrnmo -c client_name 

command differs from the expiration of instant backups created without the -c 

option. “Removing instant backup entries from the NetWorker indexes” on 

page 182 provides details on the expiration and removal of backups specified 

with nsrnmo -c client_name. 

Proxy backups and restores on cluster systems 195


196 

Notes: 

The host specified with -c client_name must have access to instant backups. 

NMO and the PowerSnap Module must be installed and configured on the 

host specified with -c client_name. 

When the backup is started from the virtual cluster client, the backup entries 

are stored in the NetWorker client file index of the virtual client by default. 

The entries for the NWORA resource file backup are always stored in the 

NetWorker index of the physical client. 

Example 40 Proxy backup entries in the index of a physical cluster client 

To specify that the backup entries be stored in the index of the physical cluster client 

mars.emc.com, where the script name is nsrnmo, specify the following in the Backup 

Command attribute: 

nsrnmo -c mars.emc.com 

Proxy backups from a physical cluster client 

A proxy backup from a physical cluster client protects Oracle data on private disks. 

This type of backup is similar to a regular scheduled Oracle backup on a non-cluster 

system. 

The following sources provide information on how to set up a proxy backup from a 

physical cluster client: 

◆ “Proxy backup requirements” on page 171 

◆ NetWorker administration guide (chapter on cluster support) 

When the backup is started from the physical client, the backup entries are stored in 

the NetWorker index of the physical client by default. 

Note: The entries for the NWORA resource file backup are always stored in the NetWorker 

index of the physical client. 

To specify that the proxy backup entries be stored in a NetWorker client file index 

other than the physical client index, for example, in a virtual client index: 

◆ Add -c client_name to the nsrnmo script name in the Backup Command attribute in 

the Client resource. 

◆ Specify the Oracle user from the physical host in the Remote Access attribute in 

the Client resource for client_name. 

The expiration of instant backups created with the nsrnmo -c client_name command 

differs from the expiration of instant backups created without the -c option. 

“Removing instant backup entries from the NetWorker indexes” on page 182 

provides details on the expiration and removal of backups specified with nsrnmo -c 

client_name. 

Notes: 

◆ The host specified with -c client_name must have access to instant backups. 

◆ NMO and the PowerSnap Module must be installed and configured on the host 

specified with -c client_name. 


Example 41 Proxy backup entries in the index of a virtual cluster client 


To specify that the backup entries be stored in the index of the virtual client 

monalisa.emc.com, where the script name is nsrnmo, specify the following in the 

Backup Command attribute: 

nsrnmo -c monalisa.emc.com 

Restores from proxy backups on a cluster system 

To set up a restore from a proxy backup on a cluster system, perform the following: 

1. Set the parameter NSR_CLIENT to the correct value by using one of the methods 

in “Setting the NSR* parameters” on page 200: 

To restore a backup from a virtual cluster client, set NSR_CLIENT to the name 

of the virtual cluster client. 

To restore a backup from a physical cluster client, set NSR_CLIENT to the 

name of the physical cluster client. 

2. In the Remote Access attribute of the Client resource, specify the hostname of the 

client on which the restore is to be started. 

Note: When a failover occurs during a restore, the restore must be restarted manually on the 

failover node. 

Proxy backups and restores on cluster systems 197


198 


This appendix includes the following sections: 

A 

Parameters in an RMAN 

Session 

◆ Setting the NSR* parameters ..................................................................................... 200 

◆ NSR* parameter definitions....................................................................................... 201 

Parameters in an RMAN Session 199

Parameters in an RMAN Session 

200 

Setting the NSR* parameters 

This appendix describes the NSR* parameters that can be set in the RMAN command 

or script for NetWorker Module for Oracle (NMO) backups and restores. 

Note: Unless noted otherwise, the parameters are supported for both regular and proxy 

backups and restores. “Setting the parameters” on page 166 provides information specific to 

proxy operations. 

The NSR* parameters described in Table 10 on page 201 are parameters specific to 

NetWorker that can be set for an RMAN session of: 

◆ A manual or scheduled Oracle backup. 

◆ An Oracle restore. 

To ensure that the required NSR* parameters are set during an NMO backup or 

restore, set them in one of the following ways unless specified otherwise in Table 10 

on page 201: 

◆ If using automatic channels, set the parameters with the parms option in the 

configure channel command. 

“Automatic channel allocation” on page 26 provides more information on 

automatic channels. 

◆ If not using automatic channels, set the parameters with the RMAN send 

command (recommended), as one of the following: 

The rman send command on the operating system command line. 

The send command in the RMAN session or script. 

Do not mix these different ways of setting the NSR* parameters in the same RMAN 

session. The use of a UNIX setenv command or Windows set command on the 

operating system command line to set the NSR* parameters has no effect. 

On Windows, when an NSR* parameter is set through the parms option, the value of 

that NSR* parameter remains in effect for all subsequent allocated channels, and for 

all subsequent RMAN sessions until one of the following occurs: 

◆ The Oracle database is shut down. 

◆ The NSR* parameter is unset for the channel by using the parms option, as in the 

following example: 

run { 


parms ’ENV=(NSR_SERVER=,NSR_DATA_VOLUME_POOL=)’; 

: 

: 


} 

Note: On Windows, this does not occur if the parameters are set through the send command in 

all RMAN sessions. 


NSR* parameter definitions 


Table 10 on page 201 lists all the NSR* parameters to set in the RMAN session. For 

each parameter, the table includes: 

◆ A description of the parameter. 

◆ The default value of the parameter. 

◆ The valid values that can be assigned to the parameter. 

Table 10 Parameters in the RMAN command or script (page 1 of 7) 


NSR_AES_ENCRYPTION Optional. Specifies whether the Oracle data is 

encrypted by NMO by using 256-bit AES encryption 

during the backup before being sent over the network. 

The AES encryption uses the key that is set in the 

Datazone pass phrase attribute of the NetWorker 

Server resource. Keep a record of this key or pass 

phrase because it is required for later restore of the 

backup. 

Note: NSR_AES_ENCRYPTION must be set through 

the send command only. 

Record all keys (pass phrases) used for 256-bit AES 

encryption. Be careful when you change the pass 

phrase on the NetWorker server. If the pass phrase on 

the server is changed and you cannot remember the 

pass phrase originally used for an NMO backup, the 

encrypted data cannot be recovered. The NetWorker 

administration guide provides more information on pass 

phrases. 

NSR_CHECKSUM Optional. Specifies whether or not the NetWorker 

software performs checksumming on the backup data. 

NSR_CLIENT Recommended for a backup of Oracle running on a 

cluster or RAC system. 

Recommended for all restores. 

Specifies the NetWorker Client resource to use for a 

backup or restore session. 

Might be needed for disaster recovery. 

NSR_COMPRESSION Optional. Specifies whether or not the NetWorker 

software performs compression on the backup data. 

FALSE (default) = The Oracle data is not encrypted 

through 256-bit AES encryption during the backup. 

TRUE = The Oracle data is encrypted through 

256-bit AES encryption during the backup. 

FALSE (default) = The NetWorker software 

performs no checksumming. 

TRUE = The NetWorker software performs 

checksumming. 

The physical host on which the session runs 

(default). 

A valid NetWorker client hostname. 

FALSE (default) = The NetWorker software 

performs no compression. 

TRUE = The NetWorker software performs 

compression. 

NSR* parameter definitions 201


202 



NSR_DATA_VOLUME_POOL Mandatory if using the set duplex command (with 

duplex set to 1, 2, 3, or 4) or other RMAN commands to 

generate backup copies during a manual backup. 

Specifies the name of the volume pool to use for the 

Oracle backup, including a duplexed Oracle backup. 

In the case of proxy backups, specifies the volume pool 

for live backups only (backups to secondary storage 

only). 

Note: For a scheduled backup, the 

NSR_DATA_VOLUME_POOL setting takes 

precedence over any pool associated with the 

scheduled backup group. For a manual backup that 

generates backup copies, 

NSR_DATA_VOLUME_POOL must be set through the 

parms option, not through the send command or 

option. 

NSR_DATA_VOLUME_POOL1 Mandatory if using the set duplex command (with 

duplex set to 2, 3, or 4) or other RMAN commands to 

generate two or more backup copies during a manual 

backup. 

Specifies the name of the volume pool to use for a 

duplexed Oracle backup. 

Note: For a manual backup that generates backup 

copies, NSR_DATA_VOLUME_POOL1 must be set 

through the parms option, not through the send 



duplex set to 3 or 4) or other RMAN commands to 

generate three or more backup copies during a manual 

backup. 








duplex set to 4) or other RMAN commands to generate 

four backup copies during a manual backup. 








The most appropriate pool, selected by the 

NetWorker server (default). 

A valid NetWorker pool name. 

The name must be different from the name used by 

the parameter NSR_DATA_VOLUME_POOL1, 

NSR_DATA_VOLUME_POOL2, or 

NSR_DATA_VOLUME_POOL3. 




the parameter NSR_DATA_VOLUME_POOL, 














NSR_DATA_VOLUME_POOL2.



NSR_DEBUG_FILE Optional. Enables debugging by specifying the 

complete pathname of the log file on the Oracle Server 

that receives debug information during a proxy or 

regular backup or restore. 

Only used for debugging of the NMO media 

management library (MML). 

Note: NSR_DEBUG_FILE must be set through the 

parms option. Do not set it through the send option or 

command. 

NSR_DEBUG_LEVEL Optional. Controls the amount of debug information that 

NMO writes to the debug log file, which is specified by 

NSR_DEBUG_FILE. 

Note: NSR_DEBUG_LEVEL must be set through the 

parms option. Do not set it through the send option or 

command. 

The debug level limits only the amount of debug 

information generated by the three functions sbtread(), 

sbtwrite(), and sbtpcstatus(), which are called most 

often during backups and restores. All the debug 

messages for other functions are always written to the 

log file, regardless of the debug level. 

NSR_DEDUP_BACKUP Mandatory for a manual deduplication backup. Do not 

set for a scheduled deduplication backup. Specifies 

whether or not deduplication is performed during a 

manual NMO backup. 

Note: For a scheduled deduplication backup, set the 

De-duplication Backup attribute in the NetWorker Client 

resource, instead of setting this parameter. 

NSR_DEDUP_CACHE_ENABLED Optional for a deduplication backup. Specifies whether 

a hash cache is used during a deduplication backup. 

The nsravtar process creates the cache in the 

/nsr/dedup/cache or Windows equivalent directory. Use 

of the cache increases both the deduplication backup 

performance and disk usage in the cache directory. 

Note: Setting of this parameter requires knowledge of 

the potential effects on Avamar server operations. 



The valid pathname of the debug file to use on the 

Oracle Server. 

Note: If undefined, no debug information is generated. 

If a file with the specified pathname cannot be created, 

debug information is either directed to the following 

location or not generated: 

- /nsr/applogs/nmosbt.log (UNIX) 

- NetWorker_install_path\applogs\nmosbt.log 

(Windows) 

0 (default) = Only operational messages are written 

for the sbtread(), sbtwrite(), and sbtpcstatus() 

functions. No entry or exit messages are written for 

the functions. 

1 = Only entry and exit messages are written for the 

sbtread(), sbtwrite(), and sbtpcstatus() functions. No 

operational messages are written for the functions. 

2 = All debug messages for all the functions are 

written to the log file. 

FALSE (default) = Deduplication is not performed 

during a manual NMO backup. Other NSR_DEDUP* 

parameters are ignored. 

TRUE = Deduplication is performed during a manual 

NMO backup. If NSR_DEDUP_NODE is not set, the 

backup fails. 

TRUE (default) = A hash cache is used to increase 

performance during a deduplication backup. This 

value is recommended in most cases. 

FALSE = A hash cache is not used during a 

deduplication backup. The parameter 

NSR_DEDUP_CACHE_TAG is ignored. 



204 



NSR_DEDUP_CACHE_TAG Mandatory for a deduplication backup if the parameter 

NSR_DEDUP_CACHE_ENABLED is set to TRUE. 

Specifies the tag for the nsravtar process to use to 

generate the hash cache name for a deduplication 

backup: 

Set to a different value for each channel; if the same 

tag value is used for more than one channel, the 

deduplication backup fails. 

Set with the send command (not the parms option) 

if multiple channels are used on Windows. 

Set with the parms option (not the send command) 

if automatic channel allocation is used (and multiple 

channels are not used on Windows). 

NSR_DEDUP_CHUNK_SIZE Optional for a deduplication backup. Specifies the size 

in bytes that the Avamar server uses for data chunks in 

a deduplication backup. 

If a nonzero value is specified, the Avamar server uses 

the fixed size for all of the data chunks saved in the 


Note: Setting of this parameter requires knowledge of 

the potential effects on Avamar server operations. 

NSR_DEDUP_NODE Mandatory for a manual deduplication backup. Do not 

set for a scheduled deduplication backup. Specifies the 

hostname of the Avamar server to perform a manual 

NMO backup and store the deduplicated client data. 

The hostname must be the same as the Avamar server 

hostname set in the De-duplication Node resource. 

Note: For a scheduled deduplication backup, set the 

De-duplication Node attribute in the NetWorker Client 

resource, instead of setting this parameter. 

NSR_DPRINTF Optional, for use with Tech Support only. Specifies 

whether NetWorker core debug messages are printed 

to the file specified by NSR_DEBUG_FILE. 

Note: NSR_DPRINTF must be set through the parms 

option, not through the send command or option. 

Recommended value for NSR_DEBUG_LEVEL is 9. 


/ (default; signifies the root directory). 

String value of the tag to use to generate a 

deduplication cache name. Do not include the client 

name in the value. 

Recommended value is: 

_ 

For example: ORCL102_t1 

Note: The nsravtar process uses the tag value to 

generate the cache name through hashing. The actual 

cache name does not contain this parameter value. 

0 (default; signifies that variable sizes are used for 

the data chunks, as determined by the Avamar 

server). This value is recommended in most cases. 

Size (greater than zero) in bytes to use for all of the 

data chunks in a deduplication backup; for example, 

1024, 2048, 5096, 8194, or a value recommended in 

the Avamar documentarion. 


Avamar server hostname set in the NetWorker 

De-duplication Node resource. 

FALSE (default) = NetWorker core debug messages 

are not printed to NSR_DEBUG_FILE. 

TRUE = NetWorker core debug messages are 

printed to NSR_DEBUG_FILE. 

- If NSR_DEBUG_FILE is not set, the messages are 

printed to the default location. 

- If NSR_DEBUG_LEVEL is set to 0, few debug 

messages are printed.



NSR_ENCRYPTION_PHRASES Optional. Specifies one or more encryption phrases to 

use for decrypting Oracle data during an NMO restore. 

If this parameter is not set, the NMO restore obtains the 

encryption phrase from the NetWorker server. 

If both of the following are true, set this parameter to the 

phrase used to originally back up the data: 

The Oracle data that is being restored was backed 

up with 256-bit AES encryption. 

The encryption phrase on the NetWorker server has 

changed since the Oracle data was backed up. 

Note: NSR_ENCRYPTION_PHRASES must be set 

through the RMAN send command only. 

NSR_GROUP Optional. Use for a manual backup only. Specifies the 

NetWorker group to use for a backup session. Used by 

the NetWorker server to select the volume pool for the 

manual backup. 

NSR_MMDB_RETRY_TIME Optional. Specifies the number of minutes that NMO 

should try to connect to the NetWorker media database 

before terminating the operation (backup, restore, or 

RMAN maintenance commands). When the media 

database is busy, NMO tries to reconnect after sleeping 

for five seconds between attempts. 

NSR_NO_BUSY_ERRORS Optional. Specifies whether a scheduled backup fails 

immediately when the NetWorker server is busy or 

waits for the NetWorker server to accept the 

connection. 

Note: For proxy backups, this parameter is always set 

to FALSE. 

NSR_NO_MULTIPLEX Optional. When set for a specific RMAN channel, 

specifies whether multiplexing is disabled during a 

backup on the NetWorker device that the RMAN 

channel is using. If multiplexing is disabled, no other 

save sets can be written to the device. 

To optimize restore operations, RMAN requires NMO 

backups to not be multiplexed. 

Setting the parameter to TRUE may affect the backup 

performance. For example, the device may sit idle 

during part of the backup. If the performance is 

adversely affected, reset the parameter to FALSE. 



One or more encryption phrases to use during an 

Oracle restore with NMO. Each phrase must be a 

string enclosed in quotes. Multiple phrases must be 

separated by commas, and the entire group of 

phrases surrounded by outer quotes that are 

different from the inner quotes. For example: 

NSR_ENCRYPTION_PHRASES="’key1’,’key2’" 

- NMO itself supports double ("), single (’), and 

backward (‘) quotes. 

- Certain shells might not support certain types of 

quotes, for example, when the parameter is set 

with the send command on the command line. 

- Oracle does not support the use of single quotes 

within an RMAN script. 

Note: If undefined, the NMO restore obtains the 

encryption phrase from the Datazone pass phrase 

attribute of the NetWorker Server resource, as 

described in “Datazone pass phrase” on page 63. 

The predefined NetWorker group named Default 

(default). 

A valid NetWorker backup group name. 

Note: A NetWorker Group resource must be configured 

for the specified backup group. 

0 (default). NMO does not try to reconnect to the 

media database if the first attempt fails. 

A valid number of minutes. 

FALSE (default) = The scheduled backup waits for 

the NetWorker server to accept the connection. 

TRUE = The scheduled backup fails immediately 

when the NetWorker server is busy. 

FALSE (default) = Multiplexing is enabled on the 

device that the RMAN channel is using. 

TRUE = Multiplexing is disabled on the device that 

the RMAN channel is using. 

Note: If a random access NetWorker device such as an 

advanced file device is used, do not set the parameter 

to TRUE. 



206 



NSR_NWPATH Mandatory when removing a backup from the 

NetWorker server if both of the following are true: 

The nsrsnapck binary is in a nondefault location. 

The NWORA resource file does not contain the 

correct location of the NetWorker client binaries. 

“The NWORA resource file” on page 183 provides 

details on the resource file. 

Mandatory for a manual deduplication backup or 

restore and for a proxy backup or restore when 

NetWorker software is installed in a nondefault location 

on a UNIX NMO client host. 

Specifies the complete pathname of the directory that 

contains nsrsnapck or NetWorker binaries. 

Note: If you use NMO with Sun-branded NetWorker, 

you must set NSR_NWPATH by using the following 

nsrnmoadmin command: 

nsrnmoadmin -r update 

NSR_NWPATH=/usr/sbin/nsr 


details on using the nsrnmoadmin command. 

NSR_PROXY_PFILE Supported only for a proxy backup or restore. 

Mandatory if setting PowerSnap parameters in a 

configuration file. 

Specifies the complete pathname of a configuration file 

that contains PowerSnap parameter settings for a proxy 

backup or restore. 

NSR_RECOVER_POOL Optional for restore only. Specifies the name of the 

NetWorker volume pool to use for an NMO restore. You 

can use this option to restore data from a specified 

volume pool if there are multiple copies (clones) of the 

backup on different volume pools. 

Note: This parameter cannot be used for proxy 

restores. 

NSR_RETENTION_DISABLED Optional. Specifies whether the NetWorker browse and 

retention policies are disabled. 

Set to TRUE to use Oracle policies only (not NetWorker 

policies) to manage the backup data lifecycle. Then the 

RMAN catalog and NetWorker indexes cannot become 

unsynchronized, for example, when a NetWorker index 

entry is expired but the corresponding RMAN catalog 

entry is not expired. 

NSR_SAVESET_BROWSE Mandatory if setting a nondefault browse policy for a 

manual Oracle backup. 

Specifies the date when the entry for the backup is to 

be removed from the NetWorker client index. 

Note: NSR_SAVESET_BROWSE must be set through 

the send command only. For a scheduled Oracle 

backup, this parameter overrides the Browse Policy 

attribute setting in the NetWorker Client resource. 


The platform-specific default location of the 

NetWorker client binaries (default). 

A valid pathname of the directory that contains the 

nsrsnapck binary, for example, /usr/local/bin. 


A valid pathname of the configuration file. 

Note: If undefined or an invalid pathname, parameter 

settings in the preferred configuration file are ignored. 


A valid name of a NetWorker volume pool that 

contains a cloned backup to use for a restore. 

FALSE (default) = NetWorker browse and retention 

policies are enabled, and used to manage the 

lifecycle of the NMO backup data. 

TRUE = NetWorker browse and retention policies 

are disabled. Only Oracle policies are used to 

manage the lifecycle of the NMO backup data. 

The most appropriate policy for the client, as 

selected by the NetWorker server (default). 

A valid date in nsr_getdate(3) format.



NSR_SAVESET_RETENTION Mandatory if setting a nondefault retention policy for a 

manual Oracle backup. 

Specifies the date when the save set becomes 

recyclable. 

Note: NSR_SAVESET_RETENTION must be set 

through the send command only. For a scheduled 

Oracle backup, this parameter overrides the Retention 

Policy attribute setting in the NetWorker Client 

resource. 

NSR_SERVER Mandatory for a manual backup if the NetWorker server 

host is different from the Oracle Server host. 

Recommended for a local manual backup. 

Specifies the hostname of the NetWorker server to 

perform the Oracle backup. 


copies, NSR_SERVER must be set through the parms 

option, not through the send command or option. 

NSR_SERVER_NIC Optional. Specifies the name of a network interface 

card (NIC) on a NetWorker server. 

When this parameter is set through the RMAN send 

command for an allocated channel, its value overrides 

the NSR_SERVER setting for that channel only. 

Note: This parameter must be explicitly set for each 

channel to which it applies. Setting this parameter is the 

only supported way to override the NSR_SERVER 

value for a scheduled backup. 


The most appropriate policy for the client, as 

selected by the NetWorker server (default). 

A valid date in nsr_getdate(3) format. 

The local physical host (default). 

A valid NetWorker server name. 


A valid name of a NetWorker server NIC. 



208 



B 

RMAN Commands 

◆ The delete expired backup command ...................................................................... 210 

◆ The change...crosscheck and crosscheck commands ............................................. 210 

◆ The pool option of the backup command................................................................ 210 

◆ The send command...................................................................................................... 211 

◆ The set duplex command........................................................................................... 215 

◆ The trace option of the backup command............................................................... 217 

RMAN Commands 209

RMAN Commands 

210 

The delete expired backup command 

For a particular user to be able to use the delete expired backup command with a 

NetWorker server, the user must have the required NetWorker privileges, as 

described in “Specify the required NetWorker privileges” on page 64. 

If the user does not have the required NetWorker privileges, or there is an 

authorization problem when the delete expired backup command runs, NetWorker 

Module for Oracle (NMO) fails to remove the required entries in the NetWorker client 

file index and media database. 

Despite this failure, the delete expired backup command removes the corresponding 

backup set or backup piece entries in the Oracle Recovery Catalog. In this case, the 

appropriate NetWorker media management command can be used to manually 

remove the required save set entries from the NetWorker indexes. 

The NetWorker command reference guide and UNIX man pages provide more 

information on the NetWorker media management commands. 

Note: If the NetWorker client binaries are located in a nondefault directory on the Oracle 

Server host and the NWORA resource file was not created during the NMO installation, the 

parameter NSR_NWPATH might need to be set in the NWORA resource file or in the RMAN 

script. “NSR_NWPATH” on page 206 provides more information. 

The change...crosscheck and crosscheck commands 

For all NetWorker client file index entries that are not browsable, the running of the 

change...crosscheck or crosscheck command causes the status of the corresponding 

backup pieces to change to expired in the RMAN catalog. 

In the RMAN catalog, an expired status for a backup piece indicates that the 

NetWorker browse policy specified for that backup piece has expired. 

The pool option of the backup command 

! 

IMPORTANT 

NMO does not support the pool option of the RMAN backup command, with the 

exception of pool=0. 

If any nonzero value is specified for the pool option of the RMAN backup command, 

the RMAN session terminates and NMO returns the following error message: 

sbtbackup: Oracle pools are not supported 

“NMO error messages” on page 222 provides more information on this error 

message. 

To specify the NetWorker volume pool to be used by NMO, set the parameter 

NSR_DATA_VOLUME_POOL in the RMAN script. Appendix A, “Parameters in an 

RMAN Session,” provides more information. 


The send command 

Syntax rules 

RMAN Commands 

The NMO implementation of the send command enables the NSR* parameters to be 

set, as described in Appendix A, “Parameters in an RMAN Session.” 

Set the NSR* parameter values by using the methods described in “Setting the NSR* 

parameters” on page 200. The use of the send command is recommended where 

possible. 

The following sections describe the send command syntax and precedence rules and 

how to use the send command to set the parameters. 

◆ “Syntax rules” on page 211 

◆ “Two ways to run the send command” on page 213 

◆ “Precedence rules” on page 215 

Note: In the following sections, brackets ([]) are used to denote the optional portions of a 

command, for example, command options and corresponding settings. When typing the 

command, do not include the brackets. 

The send command must have the following format: 

send [ device_type ’device_specifier’ | channel channel_id ] 

’NSR_ENV=(name1=value1 [, name2=value2, ...])’ 

These sections describe the syntax rules for the two main parts of the send command: 

◆ “The send command string” on page 211 

◆ “The send command options” on page 212 

The send command string 

The command string in the send command is the string inside the quotes, 

’NSR_ENV=(name1=value1...)’. 

Follow these syntax rules for the send command string: 

◆ The maximum length of the command string is restricted by Oracle to 512 bytes, 

including the terminating NULL. 

◆ The NSR_ENV keyword and the parameter names must be all uppercase. 

◆ Between the NSR_ENV keyword and left parenthesis, an equal sign and spaces 

are optional. For example, these commands are all correct: 

send ’NSR_ENV = (NSR_SERVER=server1)’ 

send ’NSR_ENV=(NSR_SERVER=server1)’ 

send ’NSR_ENV (NSR_SERVER=server1)’ 

send ’NSR_ENV(NSR_SERVER=server1)’ 

◆ The parentheses in the command string are mandatory. 

◆ Inside the parentheses, there must be one or more NMO parameter names and the 

corresponding parameter values. 

◆ Inside the parentheses, spaces are not allowed around the equal signs. A space 

before an equal sign becomes part of the parameter name. A space after an equal 

sign becomes part of the parameter’s value. 

◆ Commas separating the name=value entries are mandatory. 

The send command 211

RMAN Commands 

212 

◆ Comments are not allowed inside the quotes. In the following example, 

“# NSR_SERVER” is considered the first parameter’s name: 

run { 



# NSR_SERVER=server1, 

NSR_CLIENT=oracle)’; 

: 

◆ A send command in an RMAN script can span multiple lines. For example: 


NSR_SERVER=server1, 

NSR_CLIENT=oracle)’; 

The send command options 

Run the send command with only one of the following: 

! 

◆ send with no option (only the quoted command string) sets the parameters for all 

allocated channels. 

◆ send device_type ‘SBT_TAPE’ sets the parameters for all channels of the backup 

tape device. 

Note: The send command has no effect with device type disk. 

◆ send channel sets the parameters for the specified channels only. 

IMPORTANT 

The device_type or the channel option can be used in the send command in an 

RMAN script only. Neither option can be used in the send command on the 

operating system command line. “The send command on the operating system 

command line” on page 213 provides more information. 

Example 42 A send command sets the parameters for a specified channel 

In the following sample script, the parameters are set for channel t1 only, not for 

channel t2: 

run { 



send channel t1 ’NSR_ENV=(NSR_SERVER=server1, 


: 

} 

This sample RMAN script is referenced in Table 11 on page 213. 


Two ways to run the send command 

RMAN Commands 

Table 11 on page 213 lists the values for options used with the send command. The 

example referred to is Example 42 on page 212. 

Table 11 Option values in the send command 

Option value Describes 

device_specifier The device type as specified in an allocate channel command in the RMAN script. For a 

backup tape device, use SBT_TAPE. 

channel_id The channel identifier as specified in an allocate channel command in the RMAN script. In 

the example, the identifier is t1. 

name1 The first NMO parameter name. In the example, the first parameter name is 

NSR_SERVER. 

value1 The value assigned to the first parameter. In the example, the first value is server1. 

name2 The second NMO parameter name. In the example, the second parameter name is 

NSR_DATA_VOLUME_POOL. 

value2 The value assigned to the second parameter. In the example, the second value is 

MondayFulls. 

There are two different ways to run the send command: 

◆ As an option of the rman command on the operating system command line, as 

described in “The send command on the operating system command line” on 

page 213. 

◆ In the run job of the RMAN script, as described in “The send command in the 

RMAN script” on page 214. 

The send command on the operating system command line 

To run the send command as an option of the rman invocation on the operating 

system command line, type the command in the following format: 

rman send ”’NSR_ENV=(name1=value1[, name2=value2, ...])’” 

◆ If more than one send option appears in the rman command, only the last send 

command is executed. 

◆ Follow all the send command syntax rules listed in “The send command string” 

on page 211, except for the last rule, which applies only to a send command in an 

RMAN script. 

◆ Do not use either the device_type or channel option. “The send command 

options” on page 212 provides more information. 

◆ Use two sets of quotes around the command string, each set consisting of a single 

and double quote. The single quote can be either before or after the double quote, 

but the second set of quotes must be opposite to the first set. For example, this 

command is also correct: 

rman send ’”NSR_ENV=(name1=value1[, name2=value2, ...])”’ 

Two sets of quotes are required to prevent some operating system shells (for 

example, ksh) from treating spaces inside the quotes as meta (special) characters 

and attempting to tokenize the string. 

The send command 213

RMAN Commands 

214 

◆ The parameter values in the quoted string are applied to all channels allocated 

during the RMAN session. These values are applied before any parameter values 

specified in send commands within the RMAN script itself. “Precedence rules” 

on page 215 provides more information. 

Example 43 An rman send command sets a parameter for all channels 

In the following example, the NSR_SERVER parameter value (mars.emc.com) is 

applied to all three channels (t1, t2, t3) allocated in the RMAN script: 

rman send ”’NSR_ENV=(NSR_SERVER=mars.emc.com)’” 

(RMAN script:) 

run { 




: 

} 

The send command in the RMAN script 

To run the send command in the run job of the RMAN script, type the command in 

the following format, at the required point within the run command brackets: 

send [ device_type ’device_specifier’ | channel channel_id ] 

’NSR_ENV=(name1=value1 [, name2=value2, ...])’ 

◆ Follow all the send command syntax rules listed in “The send command string” 

on page 211. 

◆ Use either the device_type or channel option (if required) with the send 

command in an RMAN script, as described in “The send command options” on 

page 212. 

◆ Specify the correct option values in the send command, as described in “The send 

command options” on page 212. 

◆ RMAN commands are run in the order that they appear in the backup or restore 

script. For a parameter value to be in effect during a backup or restore, put the 

send command (setting the value) before the backup or restore command in the 

script, but after the allocate channel commands for those channels to which the 

parameter value applies. 

◆ If no channel is allocated when the send command runs, an RMAN error is 

produced. 

The following sample RMAN script performs an Oracle backup of the entire database 

to the volume pool MondayFulls of the (remote) NetWorker server mars.emc.com: 

run { 





backup full filesperset 4 


(database); 



} 

This script is the same as the sample script on page 75. The single send command sets 

the parameters for both channels. 


Precedence rules 

! 

RMAN Commands 

Parameters are set for channels allocated during the RMAN session in the following 

order: 

1. In the parms option in the allocate channel or configure channel command 

(configure channel is used only for automatic channel allocation). 

2. In the rman send command on the operating system command line. 

3. In the send command in the run job of the RMAN script. 

IMPORTANT 

If both the send command on the operating system command line and the send 

option in the configure channel command are used at the same time, only the send 

option in the configure channel command is executed by Oracle. 

To prevent confusion and simplify the task of setting parameters in a specific order, 

do not mix these different ways of setting parameters in the same RMAN session. 

Example 44 Order of parameters set according to the precedence rules 

The set duplex command 

In the following example, the parameters NSR_SERVER and NSR_CLIENT are set in 

this order: 

◆ NSR_SERVER is set to server1 (by rman send), changed to server2 (by the first 

send command), and finally changed to server3 (by send channel). 

◆ NSR_CLIENT is set to client1 (by rman send), changed to client2 (by the first 

send command), and finally changed to client3 (by send channel): 

rman send ”’NSR_ENV=(NSR_SERVER=server1, NSR_CLIENT=client1)’” 

(RMAN script:) 

run { 


send ’NSR_ENV=(NSR_SERVER=server2, NSR_CLIENT=client2)’; 

send channel t1 ’NSR_ENV=(NSR_SERVER=server3, 

NSR_CLIENT=client3)’; 

: 

} 

For a manual backup only, the set duplex command can be set in the RMAN backup 

script to generate up to four copies of an Oracle backup and then store those copies 

on separate media. Set duplex to the value 1, 2 (or instead of 2, set it to on), 3, or 4 to 

produce 1, 2, 3, or 4 copies, respectively, of every Oracle backup set generated by 

subsequent backup commands. 

Note: NMO supports the generation of backup copies for manual backups only, not for 


The set duplex command 215

RMAN Commands 

216 

Table 12 on page 216 describes the results of setting duplex to each of the valid 

values. 

Table 12 Set duplex command values 

Set duplex command Oracle backup results 

set duplex=1 The backup set is directed to NSR_DATA_VOLUME_POOL. 

set duplex=2 

or 

set duplex=on 

There are no default values for the parameters NSR_DATA_VOLUME_POOL, 

NSR_DATA_VOLUME_POOL1, NSR_DATA_VOLUME_POOL2, and 

NSR_DATA_VOLUME_POOL3. For a manual backup with backup copies, the 

values of these parameters must be defined with the parms option, not with the send 

command or option. Appendix A, “Parameters in an RMAN Session,” provides more 

information on how to set parameters. 

Each pool specified by one of these NSR_DATA_VOLUME_POOL* parameters must 

be properly configured, and each pool must be different from the other pools used. If 

a pool is not properly defined or configured, the Oracle backup will be suspended, 

waiting for the proper configuration of that pool. 

To enable use of the set duplex command, set the parameter 

BACKUP_TAPE_IO_SLAVES to TRUE in the initoracle_sid.ora file. The Oracle 

backup and recovery documentation provides more information. 

If the current control file is included in the backup, RMAN duplexes the backup 

pieces of the control file in the same backup set. If the control file autobackup is 

enabled, RMAN also duplexes the backup pieces that belong to the control file 

autobackup. 

Note: The set duplex command is deprecated by Oracle. “Backup copies” on page 27 provides 

information on additional Oracle commands to use for backup set duplexing during manual 

backups. 

During an Oracle restore, RMAN selects only one of the copies to use, and if it fails 

for some reason, the restore fails. If the first copy of a backup piece cannot be found in 

NMO, RMAN issues the following type of error message: 

RMAN-10035: exception raised in RPC: ORA-19507: failed to retrieve 

sequential file, handle="CH2_bkup3_1_1" 

To force RMAN to use the duplexed copy of this missing backup piece, run the 

change...crosscheck, crosscheck, or change backuppiece...unavailable command 

and retry the restore. These commands cause RMAN to mark the missing backup 

piece as expired (“Retention policies” on page 38 provides a definition of expired) and 

to use the duplexed copy for the restore operation. 


Two copies of the backup set are directed to the separate pools specified by 

NSR_DATA_VOLUME_POOL and NSR_DATA_VOLUME_POOL1. 

These two pools must be different. 

set duplex=3 Three copies of the backup set are directed to the separate pools specified by 

NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, and 


These three pools must be different. 

set duplex=4 Four copies of the backup set are directed to the separate pools specified by 

NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, 

NSR_DATA_VOLUME_POOL2, and NSR_DATA_VOLUME_POOL3. 

These four pools must be different.



The trace option of the backup command 

RMAN Commands 

Set the trace option of the RMAN backup command to the value 0, 1, or 2. The 

default value of trace is 0. 

The output of trace is written to the Oracle sbtio.log file. The output is also written to 

the following default log file on the Oracle Server host: 

◆ On UNIX: /nsr/applogs/nmo.messages.raw 

◆ On Windows: NetWorker_install_path\applogs\nmo.messages.raw, where 


These log files do not contain Oracle Server or RMAN errors. 




releases. 




Table 13 on page 217 outlines the conditions that are traced when the trace option is 

set to each of the three valid values. 

Table 13 Trace option values and conditions traced 

Trace value Conditions traced 

0 (default) All error conditions. 

1 All error conditions. 

Entry and exit for each System Backup to Tape (SBT) function (the NMO implementation of 

the Oracle SBT interface). 

2 All error conditions. 

Entry and exit for each SBT function (the NMO implementation of the Oracle SBT interface). 

Values of all function parameters. 

First 32 bytes of each read/write buffer. 

The trace option of the backup command 217

RMAN Commands 

218 



C 

Troubleshooting and 

Error Messages 

◆ Troubleshooting tips ................................................................................................... 220 

◆ RMAN error messages ............................................................................................... 221 

◆ NMO error messages .................................................................................................. 222 

Troubleshooting and Error Messages 219

Troubleshooting and Error Messages 

220 

Troubleshooting tips 

The following list of troubleshooting tips refers to sections of this administration 

guide and the NetWorker Module for Oracle installation guide. Use the following list 

to troubleshoot any problems in running Oracle backup and restore operations with 

NetWorker Module for Oracle (NMO). 

To set up an Oracle backup and restore system correctly: 

1. Verify that the combination of the operating system, Oracle Server, NetWorker 

server, and NetWorker client is supported. 

The NetWorker Module for Oracle installation guide provides information on 

installation requirements. 

2. Configure the Oracle Server and Net service (if used) according to the 

instructions in the Oracle documentation. “Verify the Oracle Server 

configuration” on page 63 provides more information. 

Without NMO installed on the Oracle Server host, it should be possible to 

perform a backup and restore by using the allocate channel t1 type disk 

command. 

3. Install and configure the NetWorker server and client software. 

The following sources provide more information: 

NetWorker installation guide 

NetWorker administration guide 

Chapter 2, “Software Configuration” 

4. Install and enable the NMO software according to the instructions in the 


To relink the library file on UNIX, use the linking commands listed in the 

installation guide. Use the correct libnwora.* library file. 

To verify the version of NMO installed, check the version of the nsrnmostart 

program file or libnwora.* library file: 

On UNIX, use one of the following commands, where filenm is either the 

nsrnmostart or libnwora.* filename: 

what filenm 

strings filenm | grep “@(#)” 

pkginfo -l LGTOnmo (Solaris only) 

On Windows: 

a. Find the nsrnmostart.exe or libwora.dll file. 

b. Right-click the file icon and select Properties. 

c. In the Properties window, click the Version tab and view the file version 


Compare the library file with the libnwora.* file in the NMO software package; 

the two files should be identical. Ensure that Oracle is not linked to another 

libnwora.*, libobk.* (NetWorker BusinesSuite Module for Oracle version of 

libnwora.*), or liblsm.* (from Legato Storage Manager or Legato Single Server 

Version) file. 


RMAN error messages 


5. Perform a manual Oracle backup by using NMO and the proper RMAN script. 

Set the required NSR* parameters in either the RMAN backup script or the rman 

send command on the operating system command line. Appendix A, 

“Parameters in an RMAN Session,” provides information on how to set the NSR* 

parameters. “RMAN scripts for manual backups” on page 75 provides a simple 

startup RMAN script. 

If the manual backup fails, check the debug files for NMO and the NetWorker 

server. For NMO debug information, set the parameters NSR_DEBUG_FILE and 

NSR_DEBUG_LEVEL. “NMO error messages” on page 222 provides more 


If the backup fails with the following error, ensure that both NMO and Oracle 

have the same bitness, and refer to the RMAN user guide for details on how to 

test that the media management library is integrated correctly: 

ORA-19554: error allocating device, device type: SBT_TAPE, device 

name: 

ORA-27211: Failed to load Media Management Library 

Additional information: 25 

6. Perform a scheduled Oracle backup by using NMO and the proper RMAN and 

nsrnmo scripts. 

In the working RMAN manual backup script, add the connect target and connect 

rcvcat commands, as described in “RMAN scripts for scheduled backups” on 

page 77. Customize the nsrnmo script, as described in “Customize the nsrnmo 

script” on page 79. 

If the manual backup succeeds but the scheduled backup fails, set the parameter 

NSR_SB_DEBUG_FILE to generate debug information for the scheduled backup. 

“RMAN error messages” on page 221 provides more information. 

RMAN stores information and RMAN-specific error messages in the log file specified 

by using the msglog option. Review the RMAN information in this log file after each 

backup. 

To specify the name of the RMAN log file: 

◆ For a manual Oracle backup, specify the msglog option in the rman command on 

the command line: 

rman target ... rcvcat ... msglog filename 

◆ For a scheduled Oracle backup, specify the msglog option in the parameter 

NSR_RMAN_ARGUMENTS in the nsrnmo script. 

“NSR_RMAN_ARGUMENTS” on page 82 provides more information. 

The appropriate Oracle error messages guide provides more information on specific 

RMAN error messages and recommended courses of action. 

Note: During a backup on AIX or Windows, if an NMO parameter is set to an invalid value, the 

resulting error message might be truncated in the RMAN output. This is due to an Oracle 

RMAN limitation. 

RMAN error messages 221


222 

NMO error messages 

During a backup or restore, the NMO software records the NMO error messages in 

both the Oracle sbtio.log file and the following default log file on the Oracle Server 

host: 

◆ On UNIX: /nsr/applogs/nmo.messages.raw 

◆ On Windows: NetWorker_install_path\applogs\nmo.messages.raw, where 


These log files do not contain Oracle Server or RMAN errors. 




releases. 




To obtain more debug information for a backup or restore, set the parameter 

NSR_DEBUG_FILE to the valid pathname of a log file to store the information. If the 

parameter is set to an invalid pathname or the specified file does not have write 

permissions, the debug information is written as follows: 

◆ On UNIX, in the /nsr/applogs/nmosbt.log file. 

Otherwise, the information is not written. 

◆ On Windows, in the NetWorker_install_path\applogs\nmosbt.log file, where 



“NSR_DEBUG_FILE” on page 203 provides more information. 

The parameter NSR_DEBUG_LEVEL controls the amount of debug information 

written to the log file specified by NSR_DEBUG_FILE. The debug level setting limits 

only the amount of debug information generated by the three functions sbtread(), 

sbtwrite(), and sbtpcstatus(), which are called most often during backups and 

restores. All the debug messages for other functions are always written to the log file, 

regardless of the debug level. “NSR_DEBUG_LEVEL” on page 203 provides more 


During a scheduled backup, the NMO software records additional information and 

error messages in the file specified by the parameter NSR_SB_DEBUG_FILE in the 

nsrnmo script. If the parameter is set to an invalid pathname or the specified file does 

not have write permissions, the debug information is written as follows: 

◆ On UNIX, in the /nsr/applogs/nsrnmostart.log file. 


◆ On Windows, in the NetWorker_install_path\applogs\nsrnmostart.log file, where 



If the parameter NSR_SB_DEBUG_FILE is not set in the nsrnmo script file, the debug 

information is not written. “NSR_SB_DEBUG_FILE” on page 83 provides more 



Error messages from the libnwora library 


The NetWorker server also writes diagnostic information from the manual or 

scheduled Oracle backup to specific log files on the NetWorker server. The 

NetWorker administration guide provides more information on these log files. 

NMO error messages can be grouped into categories, according to the program that 

generates the message and the message format: 

◆ “Error messages from the libnwora library” on page 223 

◆ “Error messages from the nsrnmoadmin program” on page 231 

◆ “Error messages from the nsrnmoinfo program” on page 233 

◆ “Error messages from the nsrnmoprobe program” on page 235 

◆ “Error messages from the nsrnmostart program” on page 236 

Table 14 on page 223 lists error messages generated by the libnwora library, in 

alphabetical order. 

Note: The library name libnwora applies to UNIX. On Windows, the corresponding library is 

named orasbt.dll. 

The error messages appear in the following format: 

function_name: error_message (error_type:error_code:error_number) 

where: 

◆ function_name is the name of the NMO function that produced the error. 

◆ error_message is the text of the error message, as shown in the table. 

◆ error_type, error_code, error_number are internal numbers that represent an error type 

or code. Their significance for the user is as follows: 

If error_code is 1, the system is out of memory. 

If error_code is 3, 13, or 17, a code-level error has occurred. Report the error 

message to Technical Support. 

Table 14 Error messages from the libnwora library (page 1 of 9) 

Error message Description Resolution 

A connection to NW server 'server' could not 

be established because 'reason'. 

Attempted to restore file 'filename' to raw 

device 'device_name'. 

Attempted to restore raw device 

'device_name' to file 'filename'. 

Cannot back up object object_name with 

proxy copy. 

Could not create the LNM index lock file 

'filename' (errno) 

NMO could not connect to the NetWorker client 

file index due to the given reason. The client 

might not be configured as a client on the server. 

A proxy restore of a regular file to a raw device 

was attempted. This type of restore is not 

supported. 

A proxy restore of a raw device file to a regular file 

was attempted. This type of restore is not 

supported. 

The RMAN backup command included the proxy 

only option, but the object object_name did not 

reside on a primary storage device that the 

PowerSnap Module supports. 

NMO failed to create the lock file required for an 

index deletion operation. 

Take the corrective action suggested by the error 

message. 

Do not attempt to restore a regular file to a raw 

device. 

Do not attempt to restore a raw device file to a 

regular file. 

When the backup command includes the proxy 

only option, ensure that the object object_name 

resides on a primary storage device that the 

PowerSnap Module supports. 

Report the error number (errno) to Technical 

Support. 

NMO error messages 223


224 

Could not decode the 'sf_check' value: xdrs = 

0xvalue 

Could not decode the 'sf_magic' value: xdrs = 

0x%value 

Could not decode the 'sf_more' flag: xdrs = 

0xvalue 

This is an internal XDR error caused by a network 

read or write operation. 





Could not find the nsrsnapck binary. During an index removal for a proxy backup, NMO 

could not locate the nsrsnapck binary, which is 

probably in a nondefault location. 

Could not locate the LNM save file 

'backup_piece_name' on server 'server'. 

Could not locate the LNM save time 

'save_time' on server 'server'. 

Could not lock 'filename' for index deletion. 

There were number attempts. (errno) 



NMO could not locate an index record for the 

backup piece. The index record is probably 

missing. 

NMO could not locate an index record for the save 

time in the client file index. The index record is 

probably missing. 

NMO was able to create the lock file required for 

an index deletion operation, but could not lock the 

file after the given number of attempts. 

Could not lstat - filename The lstat() system call failed. The file filename 

either did not exist or had invalid permissions. 

Could not lstat secondary link - filename The lstat() system call failed. The file filename 

was a symbolic link that pointed to a file that either 

did not exist or had invalid permissions. 

Could not obtain NSR_ORACLECAT_MODE 

from NWORA resource file. 

The error was caused by one of the following 

conditions: 

The NWORA resource file does not exist. 

The NWORA resource file has incorrect 

permissions. 

The NWORA resource file is corrupted. 

Could not read link - pathname A proxy backup failed due to the pathname that 

was an invalid symbolic link. 

Direct saves are not enabled. NMO attempted to connect to an old release of 

NetWorker server software that is no longer 

supported. 

Error creating staging directory 'directory'. During a proxy restore of a regular file, the 

permissions of the destination directory were 

possibly invalid. NMO was not able to create the 

required staging subdirectory, .nworapc. 

Error in mmdb lookup by time: reason A lookup in the media database failed for the 

given reason. 


Report the error to Technical Support. 



Ensure that the parameter NSR_NWPATH is set 

correctly. 

Use the mminfo and nsrinfo commands to verify 

the status of the index record. 



Report the error number (errno) to Technical 

Support. 

Ensure that the file is an existing file with valid 

permissions. 

Ensure that the symbolic link points to an existing 

file with valid permissions. 

Based on the condition, perform one of the 

following: 

If the NWORA resource file does not exist, 

create the file. 

Ensure that the NWORA resource file has 

correct permissions. 

If the NWORA resource file is corrupted, 

re-create the file. 


more information. 

Before a proxy backup, ensure that any symbolic 

link is a valid link. 

Update the NetWorker server software to a release 

supported by NMO 5.0. The EMC Information 

Protection Software Compatibility Guide on the 

Powerlink website provides details on the 

supported server releases. 

Ensure that the destination directory has valid 

permissions for a proxy restore. 

Use the mminfo command to verify the status of 

the media database record. Take the corrective 

action suggested by the error message.

Exceeded the number of retries. The 

NetWorker server may be down or 

unreachable. 

Exceeded the number of retries for nsr_init(). 

The NetWorker server may be down or 

unreachable. 

Exceeded the number of retries for nsr_start(). 

The NetWorker server may be down or 

unreachable. 

Invalid browse and retention policies. Values 

Ignored. 

Invalid browse policy browse_time. Value 

Ignored. 



NMO could not contact the NetWorker index 

service nsrindexd. This was probably caused by 

the NetWorker services being shutdown. 

After a maximum of five attempts, NMO failed to 

call the NetWorker core function, nsr_init(). This 

was probably caused by the NetWorker services 

being shut down. 

After a maximum of five attempts, NMO failed to 

call the NetWorker core function, nsr_start(). This 

was probably caused by the NetWorker services 

being shut down. 

The NSR_SAVESET_BROWSE and 

NSR_SAVESET_RETENTION parameters both 

had invalid time values. 

The NSR_SAVESET_BROWSE parameter had 

an invalid time value, browse_time. 

Invalid KEY word The syntax of the string in the RMAN send 

command was incorrect. 

Invalid retention policy: retention_time. Value 

Ignored. 

The NSR_SAVESET_RETENTION parameter 

had an invalid time value, retention_time. 

Invalid source path argument A proxy backup failed due to an invalid source 

pathname. 

NSR_DATA_VOLUME_POOLn is not set. Multiple copies of the backup data were 

requested, but the required 

NSR_DATA_VOLUME_POOL parameters were 

not set. In the message, n was replaced by a 

number corresponding to the missing pool 

parameter. 

nsrsnapck_binary_name process failed with 

error - reason 

ORA-19511: Error received from media 

manager layer, error text: 

Could not create the NWORA resource lock 

file (13) (103:105:13) 

During an index removal for a proxy backup, the 

nsrsnapck binary failed. The binary name is 

nsrsnapck on UNIX and nsrsnapck.exe on 

Windows. 

An NMO backup failed because a valid NWORA 

resource file does not exist or is not available. 

Oracle pools are not supported NMO does not support Oracle pools. NMO 

supports NetWorker pools only. 

Path pathname is too long. A proxy backup failed because the given 

pathname exceeded the limit of 1,024 bytes. 

pb_init() failed with (reason): invalid BRCAPI 

version 

The version number of the BRC API that was 

reported by the PowerSnap Module was 

corrupted. 


Restart the NetWorker services on the server, as 

required. 


required. 


required. 

Ensure that the parameters 

NSR_SAVESET_BROWSE and 

NSR_SAVESET_RETENTION in the RMAN script 

both have valid values in the NetWorker date 

format. 

Ensure that the parameter 

NSR_SAVESET_BROWSE in the RMAN script 

has a valid value in the NetWorker date format. 

“The send command” on page 211 provides the 

correct send command syntax. 

Ensure that the parameter 

NSR_SAVESET_RETENTION in the RMAN script 

has a valid value in the NetWorker date format. 

Perform a proxy backup with a valid source 

pathname only. 

When multiple copies of backup data are 

requested, set the required 

NSR_DATA_VOLUME_POOL parameters. 

“NSR_DATA_VOLUME_POOL” on page 202 



If you do not use the wizard to configure a 

scheduled backup with save set bundling, use the 

nsrnmoadmin command to create a valid 

NWORA resource file, according to instructions in 

Chapter 2 or 7 of this administration guide. 

Remove the pool option of the backup command 

in the RMAN script or set the pool option to zero. 

“The pool option of the backup command” on 


Ensure that any pathname involved in a proxy 

backup does not exceed 1,024 bytes. 




226 

Proxy copy is not supported. A proxy operation was attempted on a platform 

that NMO does not support for proxy operations. 

'string' should be in format: KEY=(xxxxx) The syntax of the string in the RMAN send 

command was incorrect. 

The ASDF body could not be unwrapped. The incoming recover stream of data could not be 

decoded due to a possible network error or data 

corruption. 

The backup file already exists: 

backup_piece_name 

The BRC API did not return an error string for 

the SBTPC object: object_name 

The BRC status of logical object 'filename' 

was failure: file_status 

The call to nsr_init() failed with the message: 

reason 

The call to nsr_start() failed with the message: 

reason 

The call to pb_environment() failed with error: 

reason 

The call to pb_open() failed with error: 

reason 

The call to pb_prepare() failed with error: 

reason 

The call to pb_status() failed for object 

'object_name' with the error: 

reason 

The call to pb_status() for object 

'object_name' failed with error: 

reason 

The canonical OS file name path is invalid: 

filename 



NMO could not complete the backup because the 

backup piece name already existed in the 

NetWorker client file index. 

An unknown error occurred during a BRC API 

function call by the PowerSnap Module. 

The PowerSnap Module reported a failure during 

a proxy backup of the file filename. 

A call of the NetWorker core function, nsr_init(), 

failed due to the given reason. 

A call of the NetWorker core function, nsr_rtart(), 


During a proxy operation, a pb_environment() 

function call failed due to the given reason. 

During a proxy operation, a pb_open() function 

call failed due to the given reason. 

During a proxy operation, a pb_prepare() function 


During a proxy operation, a pb_status() function 


During a proxy operation, a pb_status() function 


The operating system filename specified for a 

proxy operation was not a valid pathname. 

The current time could not be obtained (errno). NMO could not obtain the current time due to an 

operating system error. 

The data could not be XDR'd from the stream. The incoming recover stream of data could not be 

decoded due to a possible network error or data 

corruption. 


Do not attempt a proxy operation on an 

unsupported platform. The EMC Information 


Powerlink website provides details on supported 

platforms. 

“The send command” on page 211 provides the 

correct send command syntax. 


Change the format option string of the RMAN 

command to produce a unique backup piece 

name, or remove obsolete backup pieces. Then 

restart the backup operation. 




message. If required, report the error to Technical 

Support. 



Support. 



Support. 



Support. 



Support. 



Support. 



Support. 

Ensure that the file pathname specified for a proxy 

operation is a valid full pathname that is not a 

directory. 

Report the operating system error (errno) to the 

appropriate vendor. 

Report the error to Technical Support.

The data source is neither a file or a RAW 

volume - filename 

The destination does not have the same 

terminating name as the source 

'device_name'. 

The file being recovered could not be found in 

its staging location: filename 

The file 'filename' cannot be removed from the 

staging directory (errno). 

The function mm_retrieve() failed with the 

error: reason 

The function nsr_bind_recov_mm() failed with 

the error: reason 

The function nsr_end() failed with the error 

message: reason 

The function nsr_rstart() failed with the error: 

reason 

The function sbtinit2() has already been 

called. 

The functions sbtinit() or sbtinit2() have not 

been called. 

The index entry failed the cross check: 

cfx_name(backup_piece_name) 

save_time(save_time) 

The lookup of 'backup_piece_name' on server 

'server' failed - 'reason' 

The name of the NSR client could not be 

determined. 

The name of the NSR server could not be 

determined. 



The file filename involved in a proxy backup was 

not recognized as a regular file or raw volume. For 

proxy backups, NMO supports only regular files 

and raw volumes. 

A proxy restore of a raw device was attempted to 

a location with a different basename from the 

backed-up source. For example, c1t2d0s2 is the 

basename (or terminating name) of 

/dev/rdsk/c1t2d0s2. 

During a proxy restore, an error occurred at the 

point where the file filename was to be moved 

from the staging directory .nworapc to the 

destination directory. 

During a proxy restore of the file filename, a file 

with the same name was found in the .nworapc 

subdirectory, probably left there by a previous 

failed restore. The errno is the error number from 

the failed attempt to remove the existing file. 

During a restore, a call of the NetWorker core 

function, mm_retrieve(), failed due to the given 

reason. 


function, nsr_bind_recov_mm(), failed due to the 

given reason. 

A call of the NetWorker core function, nsr_end(), 



function, nsr_rstart(), failed due to the given 

reason. 

This is an internal error caused by Oracle calling 

the function sbinit2() twice. 

This is an internal error caused by Oracle not 

calling the two SBT initialization routines. 

During an index lookup, the entry was located in 

the client file index but not in the media database. 

NMO could not locate backup_piece_name in the 

indexes due to the reason. The indexes might be 

corrupted. 

The name of the NetWorker client could not be 

determined. 

The name of the NetWorker server could not be 

determined. 


Ensure that filename is either a regular file or raw 

volume, as required for proxy backups. 

Perform a proxy restore of the raw device to a 

location with the same basename as the 

backed-up source. 

Ensure that there are no permission or other 

problems with the destination directory and the 

staging directory .nworapc, and then restart the 

proxy restore. If the error recurs, report it to 

Technical Support. 

Remove the file file_name from the .nworapc 

subdirectory, and restart the proxy restore. 



Support. 



Support. 



Support. 



Support. 



Restart the NetWorker services, and use the 

mminfo and nsrinfo commands to verify the 

backup information in the indexes. Run the nsrck 

program to resolve any corruption of the indexes. 

Run the nsrck program to resolve any corruption 

of the indexes. 

Set the parameter NSR_CLIENT to the NetWorker 

client name by using the send command. 

Set the parameter NSR_SERVER to the 

NetWorker server name by using the send 

command. 



228 

The NMO BRCAPI version version is outside 

the range supported by the BRC service: 

earliest_version - latest_version 

The NSR client name could not be 

determined. 

The NSR server name could not be 

determined. 

NMO release 5.0 does not support the 

PowerSnap Module release that was used for a 


The name of the NetWorker client could not be 

determined. 

The name of the NetWorker server could not be 

determined. 

The NSR_CLIENT parameter was not set. The name of the NetWorker client could not be 

determined. 

The NSR_DMO_BENCHMARK_1 parameter is 

no longer supported. 

The undocumented parameter 

NSR_DMO_BENCHMARK_1 was specified, but it 

is no longer supported. 

The NSR_SERVER parameter was not set. The name of the NetWorker server could not be 

determined. 

The NW authentication for client 'client' was 

refused by server 'server' because 'reason'. 

NMO could not obtain the required authentication 

to connect to the NetWorker client file index due 

to the given reason. The client might not be 

configured as a client on the server. 

The NW client has not been set. The name of the NetWorker client could not be 

determined. 

The NW server does not have a valid NMO 

proxy copy license. 

The NetWorker server attempted a proxy 

operation without the required license. 

The NW server has not been set. The name of the NetWorker server could not be 

determined. 

The NWORA file ID could not be XDR'd. 

xdrm: 0xvalue 

NWORA fid: 0xvalue 

ssid: 0xvalue 

ssoff: 0xvalue 

The NWORA resource file does not exist. 

Please create it with nsrnmoadmin. 

The NWORA resource lock file does not exist. 

Please create it by running 'nsrnmoadmin -r 

list' 

The NWORA resource 

NSR_ORACLECAT_MODE is in the 

'undetermined' state. 





A proxy backup failed because the NWORA 

resource file did not exist. 

A proxy backup failed because the NWORA 

resource lock file did not exist. 

In the NWORA resource file, 

NSR_ORACLECAT_MODE was set to the default 

value of undetermined. 

The object 'filename' is not a file. A proxy backup failed because the file filename is 

not a data file—neither a raw file nor a regular file. 


Ensure that a supported release of the PowerSnap 

Module is installed. The EMC Information 


Powerlink website provides details on supported 

releases. 





command. 



Do not set the unsupported 

parameter NSR_DMO_BENCHMARK_1. 



command. 


message. 



Ensure that the NetWorker server has the required 

license for the proxy operation. 



command. 


Create the NWORA resource file by using the 

nsrnmoadmin command, and restart the proxy 

backup. “The NWORA resource file” on page 183 


Create the NWORA resource lock file by using the 

nsrnmoadmin -r list command, and restart the 

proxy backup. “The NWORA resource file” on 


Set the value of NSR_ORACLECAT_MODE to 

either enabled or disabled (as required) by using 

the nsrnmoadmin command. 

Perform a proxy backup of a supported type of 

data file only.

The ORACLE_SID must be set when 

performing proxy copy backups. 

The OS file name has been specified multiple 

times by Oracle: filename 

During a scheduled proxy backup, the parameter 

ORACLE_SID was not set in the nsrnmo script. 

This is an internal Oracle error caused by Oracle 

specifying the same filename twice during a proxy 

operation. 

The parameter file cannot be open: filename The configuration file specified by the parameter 

NSR_PROXY_PFILE could not be opened. The 

file should contain PowerSnap parameter settings 

for a proxy backup or restore. 

The pb_cancel() call for object 'object_name' 

returned the error message: 

error 

The pb_inquiry() call failed for object 

'object_name': 

error 

The pb_inquiry() for object 'object_name' 

failed because: 

error 

The pb_inquiry() of object 'object_name' 

returned error: 

error 

The pb_restore() for object 'object_name' 

failed with error: 

error 

The pb_save() of object 'object_name' 

returned error: 

error 

The pb_snapshot() call for object 

'object_name' failed with error: 

error 

The record obtained has the wrong save time 

'save_time1'. The save time queried was 

'save_time2'. 

The removal of SSID 'save_set_id' failed with 

error: reason 

The restore destination path is not valid: 

filename 



The restore operation for the file failed for an 

unknown reason: filename 

The pb_cancel() function call failed during a proxy 

operation. 

The pb_inquiry() function call failed during a proxy 

operation. 


operation. 


operation. 

The pb_restore() function call failed during a 


The pb_save() function call failed during a proxy 

operation. 

The pb_snapshot() function call failed during a 


NMO located an index record in the client file 

index, but it had an unexpected save time. The 

indexes might be corrupted. 

An index deletion operation failed for the given 

reason. 

During a proxy restore operation, NMO found the 

specified restore destination, filename, to be 

invalid. 

During a proxy restore, an error occurred at the 

point where the file filename was to be moved 

from the staging directory .nworapc to the 

destination directory. 

The savefile_fini() call failed. reason During a restore, a call of the NetWorker core 

function, savefile_fini(), failed due to the given 

reason. 


In the nsrnmo script, set the parameter 

ORACLE_SID to the SID value of the Oracle 

database. 


Ensure that the value specified by the parameter 

NSR_PROXY_PFILE is a valid pathname of the 

configuration file. 








Restart the NetWorker services, and run the nsrck 



the status of the index record. If required, report 

the error to Technical Support. 

Ensure that the specified restore destination is a 

valid pathname. 

Ensure that there are no permission or other 

problems with the destination directory and the 

staging directory .nworapc, and then retry the 

proxy restore. If the error occurs again, report it to 

Technical Support. 



Support. 



230 

The SBTPC object could not determine the 

destination of the restore. 

The SBTPC object is not in the 

PB_TYPE_PREPARE state: object_name 

The SBTPC object is not in the 

SBTPCSTATUS_NOTREADY state: 

object_name 

The SBTPC object 'object_name' failed with 

the error message: 

reason 

The SBTPC object 'object_name' is entering 

the SBTPCSTART backup state but its BRC 

type is: type 


the SBTPCSTART restore state but its BRC 

type is: type 


the SBTPCSTART state but its status is: 

status 

The SBTPC object 'object_name' is leaving 

the BRC prepare state but its status is: status 


the BRC save state but its status is: status 


the BRC snapshot state but its status is: status 

The SBTPC object 'object_name' was aborted 

by the BRC service. Please check the 

PowerSnap logs for an explanation. 

The sbtpccommit() function was called during 

restore. 

During a proxy restore operation, NMO was 

unable to determine where to restore the file. 

During a proxy operation, NMO and the 

PowerSnap Module became unsynchronized as 

to the status of the object object_name. 




The proxy backup or restore of a file failed during 

a PowerSnap Module operation, for the given 

reason. 



















The PowerSnap Module terminated the proxy 

operation. 

This is an internal Oracle error that occurred 

during a proxy restore. 

The sfhead could not be XDR'd. This is an internal XDR error caused by a network 

write operation. 

The SS browse time is not in the future: 

current time: current_time 

browse: browse_time 

The SS retention time is not in the future: 

current time: current_time 

retention: rentention_time 

The staging directory 'directory' has invalid 

permissions (errno). 



The specified browse policy time was in the past. 

This might be due to a problem with the operating 

system time setting. 

The specified retention policy time was in the 

past. This might be due to a problem with the 

operating system time setting. 

During a proxy restore, NMO was unable to write 

to the staging directory, directory. The errno is the 

error number from the function call that failed. 












Examine the PowerSnap Module logs for a 

possible reason for the termination. 



Ensure that the browse policy time is set correctly. 

If required, ensure that the operating system time 

is set correctly. 

Ensure that the retention policy time is set 

correctly. If required, ensure that the operating 

system time is set correctly. 

Ensure that the staging directory has valid 

permissions for a proxy restore.

The UNIX attributes could not be XDR'd. 

xdrm: 0xvalue 

ua: 0xvalue 

There are no SBTPC objects that have not 

returned their status. 



This backup piece name is already used in the 

SBTPC session: backup_piece_name 



This is an internal error during a proxy operation 

caused by Oracle expecting more files to be 

processed whereas NMO has completed its file 

processing. 

This is an Oracle error caused by Oracle 

specifying the same backup piece name twice 

during a proxy operation. 

Error messages from the nsrnmoadmin program 





Table 15 on page 231 lists error messages generated by the nsrnmoadmin program, 

in alphabetical order. 


nsrnmoadmin: error_message 

where error_message is the text of the error message, as shown in the table. 

Table 15 Error messages from the nsrnmoadmin program (page 1 of 3) 


Command line arguments are not understood. The nsrnmoadmin command included one or 

more invalid options. 

Could not create the NWORA resource file 

(errno) 

Could not create the NWORA resource lock 

file (errno) 

The nsrnmoadmin command could not create 

the NWORA resource file, possibly due invalid 

permissions. 

The nsrnmoadmin command could not obtain 

the required lock file in the /nsr/tmp or 

NetWorker_install_path\tmp directory. The lock 

file is required for accessing the NWORA 


Could not open resource file 'filename' (errno). The nsrnmoadmin command could not open the 

NWORA resource file, possibly due invalid 

permissions. 

No command line parameters are set. The nsrnmoadmin command options were 

missing. 

NSR_ORACLECAT_MODE can only be set to 

'enabled', 'disabled' or 'undetermined'. 

In the nsrnmoadmin command, the 

NSR_ORACLE_CAT_MODE parameter resource 

was set to a value other than enabled, disabled, 

or undetermined. 

Use the nsrnmoadmin command with the correct 

options. “Configuring the NWORA resource file 

with the nsrnmoadmin program” on page 188 


Ensure that valid permissions exist to allow the 

nsrnmoadmin command to create the NWORA 

resource file. “The NWORA resource file” on 



Verify that the NWORA resource file exists and 

has valid permissions. If required, create or repair 

the file by using the nsrnmoadmin command, or 

modify the file permissions. 


options. 

In the nsrnmoadmin command, set the 

NSR_ORACLE_CAT_MODE parameter resource 

to enabled or disabled for instant backups. 

“Configuring the NWORA resource file with the 

nsrnmoadmin program” on page 188 provides 

details. 



232 

NSR_REMOVE_ON_FAILURE can only be 

set to 'TRUE' or 'FALSE'. 

NWORA parameter resources must be 

specified in the 'ResourceName 

ResourceValue' format. 

NWORA SID resource must be specified 

when doing deletion. 

In the nsrnmoadmin command, the 

NSR_REMOVE_ON_FAILURE parameter 

resource was set to a value other than TRUE or 

FALSE. 

In the nsrnmoadmin command, an NWORA 

parameter resource name and value were not 

specified in the correct format. 

In the nsrnmoadmin command with the -r delete 

option, the SID value of an Oracle database was 

not specified. 

The '-r' flag cannot be set multiple times. The nsrnmoadmin command contained more 

than one -r option. 

The '-r' option requires an NWORA resource 

specification. 

The '-r' option requires either an 'add', 

'update', 'list' or 'delete' option. 

The first NWORA resource is not a header 

(errno). 

The NWORA resource file does not contain 

the NSR_NWPATH resource. 

The nsrnmoadmin command with the -r option 

did not include the required resource 

specification. 

In the nsrnmoadmin command, the -r option did 

not include one of the required keywords: add, 

update, list, or delete. 


In the nsrnmoadmin command, set the 

NSR_REMOVE_ON_FAILURE parameter 

resource to either TRUE or FALSE only. 

In the nsrnmoadmin command, specify the 

NWORA parameter resource name and value in 

the correct format. 


option, specify the correct SID value. 

Use the nsrnmoadmin command with only one -r 

option. 

In the nsrnmoadmin command with the -r option, 

specify the required resource name and value. 

In the nsrnmoadmin command, include one of the 

required keywords with the -r option. “Configuring 

the NWORA resource file with the nsrnmoadmin 

program” on page 188 provides details. 

The NWORA resource file is probably corrupted. Verify the contents of the NWORA resource file. If 

required, repair the resource file by using the 

nsrnmoadmin command. 

The NWORA resource file does not contain the 

mandatory NSR_NWPATH parameter resource. 

The file might be corrupted. 

Verify the contents of the NWORA resource file. If 

required, repair the resource file by using the 


The NWORA resource file does not exist. The NWORA resource file does not yet exist. Create the NWORA resource file by using the 


The NWORA resource named 

'resource_name' is not found. 



The NWORA resource parameter list can only 

contain one entry. 

The NWORA resource parameter list contains 

the invalid element 'resource_name'. 

The NWORA resource parameter list for a SID 

requires the item1, item2 and item3 


The NWORA resource 'resource_name' is not 

a SID resource. 

The NWORA resource specified is not 

supported: resource_name = resource_value 

The nsrnmoadmin command specified the name 

of a resource that does not exist in the NWORA 


The NWORA resource file includes multiple 

values for a resource, which is not supported. The 

file is probably corrupted. The file might have 

been edited manually, which is not supported. 

The NWORA resource file contains an invalid 

resource name. The file is probably corrupted. 

The file might have been edited manually, which 

is not supported. 

The nsrnmoadmin command for creating or 

updating an NWORA SID resource was missing 

the required items. 

The nsrnmoadmin command with the -r delete 

option did not include a valid name of an NWORA 

SID resource. 

In the nsrnmoadmin command, an invalid name 

or value were specified for an NWORA parameter 

resource. 

In the nsrnmoadmin command, specify a valid 

resource name from the NWORA resource file. 

Repair the NWORA resource file by using the 


Repair the NWORA resource file by using the 

nsrnmoadmin command. “Configuring the 

NWORA resource file with the nsrnmoadmin 

program” on page 188 provides details. 

In the nsrnmoadmin command for creating or 

updating an NWORA SID resource, include the 

required items. 


option, specify a valid name of an NWORA SID 

resource. 


name and value for an NWORA parameter 

resource. “NWORA parameter resources” on 

page 184 provides details.

The NWORA SID resource for 'sid_value' 

already exists. 

Error messages from the nsrnmoinfo program 

The nsrnmoadmin command attempted to add 

an NWORA SID resource that already existed. 

The SID token 'connect' is an empty string. The nsrnmoadmin command did not include the 

required pathname of the RMAN connection file 

with the connect keyword. 

The SID token 'home' is an empty string. The nsrnmoadmin command did not include the 

required pathname of the Oracle home directory 

with the home keyword. 

The SID token 'ORACLE_SID' is invalid. In the nsrnmoadmin command with the sid 

keyword, the specified SID value of the Oracle 

database was invalid. 

The SID token 'sid' is an empty string. The nsrnmoadmin command did not include the 

required SID value of the Oracle database with 

the sid keyword. 

The tokens 'sid', 'home' and 'connect' must be 

set when adding a SID. 

The nsrnmoadmin command to add an NWORA 

SID resource did not include the settings of the 

mandatory sid, home, and connect keywords. 

The value of the NWORA resource is missing. In the nsrnmoadmin command with the -r 

update option, the NWORA resource value was 

not specified with the resource name. 

Unrecognized argument 'option'. The nsrnmoadmin command included the 

unrecognized option option. 

You must be the super-user to update the 

NWORA resource file. 



The nsrnmoadmin command was typed by the 

wrong user. 


In the nsrnmoadmin command, specify the 

values for a new NWORA SID resource. 


pathname of the RMAN connection file with the 

connect keyword. “Configuring the NWORA 

resource file with the nsrnmoadmin program” on 



pathname of the Oracle home directory with the 

home keyword. 


SID value with the sid keyword. 


SID value with the sid keyword. 

In the nsrnmoadmin command to add an 

NWORA SID resource, include the settings of the 

sid, home, and connect keywords. 

In the nsrnmoadmin command with the -r update 

option, specify the NWORA resource value with 

the resource name. 


options. “Configuring the NWORA resource file 

with the nsrnmoadmin program” on page 188 


Type the nsrnmoadmin command as the root 

user on UNIX, or as a member of the Microsoft 

Windows Administrators group. 

Table 16 on page 234 lists error messages generated by the nsrnmoinfo program, in 



The NW volume information lookup failed: 

error_message 

where error_message is the text of the error message, as shown in the table. 



234 

Table 16 Error messages from the nsrnmoinfo program 


A connection to NW server 'server' could not 

be established because 'reason'. 

Could not locate the LNM save file 

'backup_piece_name' on server 'server'. 

Could not locate the LNM save time 

'save_time' on server 'server'. 

NMO could not connect to the NetWorker client 

file index due to the given reason. The client 

might not be configured as a client on the server. 

NMO could not locate an index record for the 

backup piece. The index record is probably 

missing. 

NMO could not locate an index record for the save 

time in the client file index. The index record is 

probably missing. 

Error in mmdb lookup by time: reason A lookup in the media database failed for the 

given reason. 

Exceeded the number of retries. The 

NetWorker server may be down or 

unreachable. 

NMO could not contact the NetWorker index 

service nsrindexd. This was probably caused by 

the NetWorker services being shutdown. 

The file 'filename' could not be opened. The file specified with the -f option of the 

nsrnmoinfo command could not be accessed. 

The file name provided is NULL. In the nsrnmoinfo command, the -f option did not 

include the required filename. 

The index entry failed the cross check: 

cfx_name(backup_piece_name) 

save_time(save_time) 

The lookup of 'backup_piece_name' on server 

'server' failed - 'reason' 

The NW authentication for client 'client' was 

refused by server 'server' because 'reason'. 

The record obtained has the wrong save time 

'save_time1'. The save time queried was 

'save_time2'. 

During an index lookup, the entry was located in 

the client file index but not in the media database. 

NMO could not locate backup_piece_name in the 

indexes due to the reason. The indexes might be 

corrupted. 

NMO could not obtain the required authentication 

to connect to the NetWorker client file index due 

to the given reason. The client might not 

configured as a client on the server. 

NMO located an index record in the client file 

index, but it had an unexpected save time. The 

indexes might be corrupted. 



message. 





Use the mminfo command to verify the status of 

the media database record. Take the corrective 

action suggested by the error message. 


required. 

Ensure that the specified file exists, and then type 

the nsrnmoinfo command again with the -f option. 

In the nsrnmoinfo command, include the required 

filename with the -f option. 

Restart the NetWorker services, and use the 

mminfo and nsrinfo commands to verify the 

backup information in the indexes. Run the nsrck 


Run the nsrck program to resolve any corruption 

of the indexes. 


message. 

Restart the NetWorker services, and run the nsrck 

program to resolve any corruption of the indexes.

Error messages from the nsrnmoprobe program 


Table 17 on page 235 lists error messages generated by the nsrnmoprobe program, in 


Table 17 Error messages from the nsrnmoprobe program 


Could not connect to the Oracle database 

Oracle_service at Oracle_home. 

The configuration information is not valid: 

string 

The connect string was missing the user or the 

password. 

The nsrnmoprobe command does not support 

databases with more than one sthread. 

The nsrnmoprobe program could not connect to 

the specified Oracle database. 

The Command Options attribute in the NetWorker 

Probe resource was not configured properly. 

The RMAN connection file (specified through 

NSR_ORACLE_CONNECT_FILE in the NWORA 

resource file) used for the NMO probe did not 

contain the username or password. 

The nsrnmoprobe program does not support a 

RAC database, where the database has multiple 

threads (instances). 

The nwora.res file has not been created. ORACLE_SERVICE was set in the Command 

Options attribute in the NetWorker Probe 

resource, but the NWORA resource file did not 

exist. 

The v$database_incarnation SQL statement 

could not be run because: reason. 

The nsrnmoprobe program could not determine 

the database incarnation information due to the 

reason given in the error message. 

Ensure the following: 

The connection strings (database username 

and password), Oracle Net service name, and 

ORACLE_HOME value that nsrnmoprobe 

uses are correct. 

You can manually connect to that Net service 

name by using Oracle client tools, such as 

sqlplus. 

“Configure a probe-based backup” on page 97 


Correct the Command Options attribute setting in 

the NetWorker Probe resource, according to 

“Configure a probe-based backup” on page 97. 

Edit the connection file to correct the problem. 

Do not use the nsrnmoprobe program with a RAC 

database. 

Create the NWORA resource file according to the 

information in “Configure a probe-based backup” 

on page 97. 

This error usually indicates that the Oracle 

database version is not supported. The EMC 

Information Protection Software Compatibility 

Guide on Powerlink provides details on the 

supported Oracle database versions. 



236 

Error messages from the nsrnmostart program 

Table 18 on page 236 lists error messages generated by the nsrnmostart program, in 


Table 18 Error messages from the nsrnmostart program 


Authentication denied 

or 

Authentication denied for user username 

client: WARNING! The NWORA resource file 

'save' process output error messages. 

client: Please check the save log file for more 

information: log_file 

ORACLE_HOME is not defined. Cannot start 

RMAN. 

The lockbox that stored the database connection 

credentials was not accessible by the super-user 

on the client where the backup failed with this 

error message. 

The NWORA resource file could not be backed up 

after a successful RMAN backup. 

ORACLE_HOME was not set properly in the 


The backup config did not contain a string. The nsrnmostart program was run with the -C 

option, but the Backup Config attribute was not 

set properly in the Client resource. 

The NSR client resource for client_name does 

not contain any backup configuration. 

The temporary file 'rman_script_path' could 

not be created (errno). 

The nsrnmostart program was run with the -C 

option, but the Backup Config attribute was not 

set properly in the Client resource. 

The scheduled backup binary, nsrnmostart, 

could not create the file rman_script_path to write 

the RMAN script generated by the backup 



Use the NetWorker Management Console (NMC) 

to ensure that the Lockbox resource is created for 

the given client and the Users attribute contains 

the super-user of the client. 

Analyze the log_file and if it includes an error 

message, take the corrective action suggested by 

the error message. 

Set ORACLE_HOME properly in the nsrnmo 

script. 

Remove this Client resource, and re-create the 

Client resource by using the backup configuration 

wizard. 

Remove this Client resource, and re-create the 

Client resource by using the backup configuration 

wizard. 

Ensure that the root user on UNIX or the Windows 

Administrator has "write" permissions on the 

directory path of the rman_script_path file.

This glossary contains the definitions of terms found in this manual. Most of the 

terms are specific to the NetWorker Module for Oracle (NMO) software. For terms 

specific to the NetWorker software, refer to the latest NetWorker administration 

guide. 

A 

? Oracle placeholder for the main directory of the Oracle database instance identified as 

$ORACLE_HOME. 

administrator Person who normally installs, configures, and maintains software on network 

computers, and who adds users and defines user privileges. 

Administrators group Microsoft Windows user group whose members have the rights and privileges of 

users in other groups, plus the ability to create, modify, and manage the users and 

groups in the domain. 

API (application 

programming 

interface) 

ASM (application 

specific module) 

Agreed-upon set of computer library routines, protocols, and tools used to 

communicate and accomplish tasks within software applications. 

Program that, when used in a directive, specifies the way a set of files or directories is 

to be backed up and recovered. 

archived redo log Archived copy of a filled online Oracle redo log that preserves older redo log data for 

recovery operations. See also “redo log.” 

attribute Feature of a NetWorker resource. It is a service or information that the “resource” 

provides. 

auto media 

management 

autochanger See “library.” 

Feature that enables the storage device controlled by the NetWorker server to 

automatically label, mount, and overwrite a volume it considers unlabeled. Volumes 

that are eligible for reuse are also automatically recycled. 

B 

Glossary 

backup Operation that saves data to a volume. An Oracle backup of several datafiles may 

include several backup sets. 


Glossary 

238 

backup cycle See “scheduled backup cycle.” 

backup group See “group.” 

backup host See “proxy client host.” 

backup level See “level.” 

Backup Operators 

group 

Microsoft Windows user group whose members have the capability to log in to a 

domain from a workstation or a server, back it up, and restore the data. Backup 

Operators can also shut down servers or workstations. 

backup piece Binary file created during an NMO backup that corresponds to one save set and 

contains Oracle backup data in an RMAN-specific format from one or more database 

files. See “backup set.” 

backup set Group of one or more backup pieces, created through the RMAN backup command 

during an NMO backup. 

backup volume See “volume.” 

bootstrap Save set that is essential for NetWorker disaster recovery procedures. The bootstrap 

consists of three components that reside on the NetWorker server: the media 

database, the resource database, and a server index. 

browse policy NetWorker policy that specifies the time period during which backup entries for 

regular Oracle backups and proxy live backups are stored in the online NetWorker 

client file index and the associated backup files are readily accessible to users. 

catalog 

synchronization 

C 

Process that removes a proxy Oracle backup entry from the RMAN catalog when the 

corresponding backup piece is removed from the NetWorker indexes. See “NWORA 

resource file.” 

client Computer, workstation, or fileserver whose data can be backed up and restored. 

client file index Database maintained by the NetWorker server that tracks every data object, file, or 

“file system” backed up. The NetWorker server maintains a single index file for each 

client computer. 

cluster Two or more independent network servers that operate and appear to clients as if 

they are a single unit. The cluster configuration enables work to be shifted from one 

server to another, providing "high availability" that allows application services to 

continue despite most hardware or software failures. See also “high-availability 

system.” 

cold Oracle backup See “offline backup.” 

command line Line on a display screen, also known as a command prompt or shell prompt, where 

you type software commands. 

connection port Port that NetWorker processes use to perform backup and restore sessions through a 

firewall. 


D 

daemon Process on UNIX systems that runs in the background and performs a specified 

operation at predefined times or in response to certain events. 

database Database instance of a third-party “DBMS” vendor. NMO backs up and restores 

Oracle database files. 

deduplication 

backup 

DBA Abbreviation for database administrator, the person that is typically responsible for 

installing, configuring, and maintaining Oracle database systems. 

DBMS Abbreviation for database management system, which refers to the primary 

architecture of an Oracle database. 

Glossary 

Type of backup from the client to an Avamar server (NetWorker deduplication 

node), where the server identifies redundant data blocks on the client and backs up 

only the unique blocks (not entire files) that contain changes. Only a single instance of 

any unique data block is maintained on the server. 

deferred live backup Type of proxy Oracle backup where an existing point-in-time copy (snapshot), 

created during an instant backup, is backed up to secondary storage such as tape. The 

snapshot is retained on the primary storage. 

device ◆ Storage unit that reads from and writes to backup volumes (see “volume”) during 

backups and restores. The storage unit can be a tape device, optical drive, 

“autochanger,” or file connected to the “server” or “storage node.” 

◆ When dynamic drive sharing (DDS) is enabled, refers to the access path to the 

physical drive. 

directive Instruction that directs NetWorker software to take special actions on a given set of 

files for a specified client during a backup or recovery operation. Directives are 

ignored in manual (unscheduled) backups. 

drive Hardware device through which media can be read or written to. See also “device.” 

E 

enabler code Special code that activates the software. The enabler code that unlocks the base 

features for software is called a base enabler. Enabler codes for additional features or 

products (for example, library support) are called add-on enablers. 

event-based backup See “probe-based backup.” 

exit code Indicator that specifies whether a backup or restore session succeeded. 

◆ Exit code of zero (0) indicates the session completed successfully. 

◆ Nonzero exit code indicates the session did not complete successfully. 

expiration date Date when the status of a volume changes from read/write to read-only. 

expired save set Save set whose browse time has been reached. The save set can no longer be browsed 

because it has been removed from the client file index. 


Glossary 

240 

F 

failover Safeguard capability that automatically switches activity from a failed or abnormally 

terminated computer server, disk drive, or network to a redundant standby server, 

drive, or network, with little or no disruption of service. Failover is a feature of 

systems that require high reliability and continuous availability. 

file index See “client file index.” 

file system ◆ Software interface used to save, retrieve, and manage files on storage media by 

providing directory structures, data transfer methods, and file association. 

◆ Entire set of all files. 

fileserver Computer with disks that provides services to other computers on the network. 

firewall System designed to prevent unauthorized access to or from a private network. All 

messages entering or leaving the intranet pass through the firewall, which examines 

each message and blocks those that do not meet the specified security criteria. There 

are several types of firewall techniques. The NetWorker software supports client 

backups from computers that are protected by packet filtering. 

full backup See “level.” 

high-availability 

system 

G 

group Client or group of client computers that are configured to back up files at a 

designated time of day. 

H 

System of multiple computers configured as cluster nodes on a network that ensures 

the application services continue despite a hardware or software failure. Each cluster 

node has its own IP address with private resources or disks that are available only to 

that computer. 

host Computer on a network. 

hot Oracle backup See “online backup.” 

I18N 

(internationalization) 

immediate live 

backup 

incremental backup See “level.” 

I 

Capability of the NMO software to operate in a non-English environment or locale 

without itself generating non-ASCII data. After I18N is set up, NMO can process and 

display non-ASCII data that is passed to it by the operating system, NetWorker 

software, and Oracle software. See also “L10N (localization).” 

Type of proxy Oracle backup where a point-in-time copy (snapshot) is created during 

an instant backup and immediately backed up to secondary storage, such as tape. The 

snapshot is automatically deleted from the primary storage. 

index policy Policy that specifies how long file and data index entries should remain valid. Clients 

specify which index policies they wish to use. 

instance Combination of processes that runs each time a database starts up. 


instant backup Type of proxy backup that creates a snapshot of Oracle data as a point-in-time copy 

on a primary storage unit. See “proxy backup.” 

instant restore Type of proxy restore that restores Oracle data from a mounted point-in-time copy 

that was created during an instant backup. See “proxy restore.” 

L 

L10N (localization) Capability of the NMO software to generate non-ASCII character and numeric data 

based on the locale of the user, and output the data to the user interface. This 

capability requires the installation of the appropriate NMO language packs in 

non-English locales. See also “I18N (internationalization).” 

Glossary 

level Backup configuration option that specifies how much data is saved during a 

scheduled or manual backup. An NMO backup level is specified by an RMAN 

command in the RMAN backup script only: 

◆ A full NMO backup backs up all of the data blocks in the database, regardless of 

when they last changed. 

◆ An incremental NMO backup backs up only data blocks that have changed since 

the last backup. 

library Hardware device containing one or more removable media drives, as well as slots for 

pieces of media, media access ports, and a robotic mechanism for moving pieces of 

media between these components. Libraries automate media loading and mounting 

functions during backup and recovery. The term library is synonymous with 

autochanger, autoloader, carousel, datawheel, jukebox, and near-line storage. 

license enabler Enabler code that is required to run a feature or product. 

live backup One of the following two types of proxy Oracle backup: 

◆ “deferred live backup” 

◆ “immediate live backup” 

M 

manual backup Backup that a user performs from the client, also known as an unscheduled backup. 

The user specifies the files, file systems, and directories to be backed up. A manual 

backup does not generate a “bootstrap” save set. 

media Physical storage, such as magnetic tape, optical disk, or file system, to which backup 

data is written. See also “volume.” 

media database Database that contains indexed entries about the storage volume location and the 

lifecycle status of all data and volumes the NetWorker server manages. See also 

“volume.” 

media index See “media database.” 

media manager NetWorker database that tracks save sets stored on backup volumes. 

media pool Feature to sort backup data to selected storage volumes. 

MML (media 

management library) 

Library of media management routines provided by the NMO software and linked 

with the Oracle kernel software during the installation of NMO on the Oracle Server 

host. 


Glossary 

242 

MTTR (mean time to 

recover) 

mount To make a database available for use, or to place a removable tape or disk volume 

into a drive for reading or writing. 

Set time required to perform an instance or media recovery for an Oracle database. 

For example, you might set 10 minutes as the goal for media recovery from a disk 

failure. 

multiplexing NetWorker feature that permits data from more than one save set to be 

simultaneously written to the same storage device. 

N 

NetWorker Network-based EMC software product that backs up and restores file systems. 

NetWorker client See “client.” 

NetWorker Module for 


NetWorker resource See “resource.” 

NetWorker server See “server.” 

NetWorker storage 

node 

NetWorker add-on module for the NetWorker server software that enables backups 

and restores of an Oracle DBMS. See also “NMO.” 

See “storage node.” 

NMO Abbreviation for “NetWorker Module for Oracle.” 

notification Message generated and sent to the NetWorker administrator about important 

NetWorker events. 

nsrhost Logical hostname of the computer that is the NetWorker server. 

NWORA resource file Resource file installed during the NMO installation, which must be extended to 

include specific additional resources to enable proxy Oracle backups and (optionally) 

catalog synchronization. 

O 

offline backup Offline Oracle backup performed while the Oracle instance is shut down and 

unavailable to users. 

online backup Online Oracle backup performed while the Oracle instance is running and available 

to users. 

online indexes Databases located on the NetWorker server that contain all the information 

pertaining to the client backups (“client file index”) and backup volumes (“media 

database”). 

operator Person who monitors the server status, loads backup volumes into storage devices, 

and executes the day-to-day NetWorker tasks. 

Oracle Enterprise 

Manager 

Oracle Enterprise Manager Backup Management Tools, which include an optional 

graphical user interface to the RMAN utility. 

Oracle10g Server Computer running an Oracle10g release 10.x DBMS. See “DBMS.” 


Oracle11g Server Computer running an Oracle11g release 11.x DBMS. See “DBMS.” 

override Different backup level that is used in place of the regularly scheduled backup level. 

P 

parallelism Method that backs up or restores data for multiple clients, or multiple save sets for 

one client, at the same time. 

pathname Set of instructions to the operating system for accessing a file: 

◆ An absolute pathname indicates how to find a file starting from the root directory 

and working down the directory tree. 

◆ A relative pathname indicates how to find a file starting from the current location. 

physical host Node or host that forms part of a cluster. 

point-in-time copy Fully usable copy of a defined collection of data, such as a consistent file system, 

database, or volume, which contains an image of the data as it appeared at a single 

point in time. A point-in-time (PiT) copy is also called a shadow copy or a snapshot. 

A snapshot of Oracle data is created on a supported type of primary storage during 

an instant backup. 

policy Set of constraints that specify how long the save sets for a client are available for 

recovery: 

◆ For a regular Oracle backup and proxy live backup, the NetWorker Client 

resource specifies a browse policy and a retention policy. The nsr_policy(5) man 

page and NetWorker command reference guide provide more information. 

◆ For a proxy instant backup, the NetWorker Group resource specifies a snapshot 

policy that is configured with a Snapshot Policy resource. The NetWorker 

PowerSnap Module documentation provides more information. 

policy uniformity Consistency of the browse and retention policies in a group of co-dependent save sets 

from the same scheduled backup cycle or save set bundle, enforced by NMO to 

ensure that incremental backups do not persist after other backups they depend on 

have expired. 

pool Feature to sort backup data to selected storage volumes. 

PowerSnap EMC technology that provides point-in-time snapshots of data to be backed up. 

Applications that are running on the host system continue to write data during the 

snapshot operation, and data from open files is included in the snapshots. 

PowerSnap Module EMC software module that exports services of a storage subsystem by interfacing 

with vendor-specific APIs. The module is independent of applications and backup 

and recovery interfaces. NMO operates with a PowerSnap Module to perform proxy 

Oracle backups. 

preconfigured Initial default selections or configurations for software features. 

primary storage Server storage subsystem that contains the Oracle source data and any persistent 

snapshot backups of the data. The NetWorker PowerSnap Module documentation 

provides information on the supported types of primary storage. 

probe Query operation to determine if a specified condition is met on a client. 

Glossary 


Glossary 

244 

probe-based backup Type of scheduled backup, also known as an event-based backup, where the 

NetWorker server initiates the backup only when specified conditions are met, as 

determined by one or more probes. 

proxy client Surrogate client that performs the NetWorker save operation for the client that 

requests the backup. A proxy client is required to perform a serverless backup. 

proxy client host Host used in proxy Oracle backups that is separate from the Oracle Server host, with 

access to the primary storage unit. During a proxy live backup, either the Oracle 

Server host or proxy client host backs up an Oracle database point-in-time copy 

(snapshot) to secondary storage. 

proxy backup Backup of Oracle data that creates a point-in-time copy (snapshot) on primary 

storage through the PowerSnap Module. The snapshot is optionally backed up to 

secondary storage, with or without deletion of the snapshot on primary storage. Two 

types of proxy Oracle backup are the “instant backup” and “live backup.” 

proxy restore Restore of Oracle data from a proxy Oracle backup through the PowerSnap Module. 

Three types of proxy Oracle restore are the “instant restore,” “rollback restore,” and 

“restore from secondary storage.” 

RDBMS (relational 

database 

management system) 

purging Process of deleting all entries for files on a volume from the client file index, but 

allowing entries for the save sets to remain in the media database. 

R 

Type of “DBMS” that stores data in the form of related tables. 

recover To apply archived redo logs and online redo logs to an Oracle database to make the 

database consistent with a given point in time. 

Recovery Catalog Collection of Oracle database tables maintained by RMAN, including information 

about Oracle backup sets and pieces, image and proxy copies, archived redo logs, 

stored scripts, and the “target database” schema. 

recyclable save set Save set whose browse and retention policies have expired. Recyclable save sets are 

removed from the media database. 

recyclable volume Volume whose data has exceeded both its browse and retention policies and is now 

available to be relabeled and reused. 

redo log Online log of an Oracle database, consisting of at least two redo log files (separate 

from the datafiles) that record all the most current changes made in the database 

instance. See also “archived redo log.” 

remote device Storage device that is attached to a NetWorker storage node. 

resource Component of either the NetWorker server configuration or the NWORA resource 

file: 

◆ A NetWorker resource describes the NetWorker server or its clients. Devices, 

schedules, clients, groups, and policies are examples of NetWorker resources. 

Each resource has attributes that define its properties. 

◆ The NWORA resource file contains resources that enable proxy backups and 

(optionally) catalog synchronization. 


esource database Database of information about each of the configured NetWorker resources. 

restore from 

secondary storage 

restore Process of retrieving individual datafiles from backup storage and copying the files 

to disk. 

Type of proxy restore that restores a proxy backup from a secondary storage 

medium, such as tape. See “proxy restore.” 

retention policy NetWorker policy setting that determines how long save set entries for a regular 

Oracle backup or proxy live backup are retained in the NetWorker media database 

and the corresponding backup data is recoverable. 

RMAN (Recovery 

Manager) 

Glossary 

Oracle utility that acts as an intelligent interface to Oracle databases and works with 

third-party media management products, such as NMO, to back up and restore 

Oracle database objects. 

RMAN catalog RMAN repository that stores information about each Oracle backup piece in either a 

control file of the target database or an RMAN Recovery Catalog. 

RMAN script Script of RMAN commands used to perform an NMO backup or restore or an Oracle 

database duplication. 

rollback restore Type of proxy Oracle restore that restores a specific point-in-time copy (snapshot) of 

Oracle data to the source location by using the hardware’s particular capabilities. A 

rollback is a destructive save set restore. See “proxy restore.” 

rollover save set Save set that is backed up to tape from a snapshot. Whether this snapshot is retained 

or not depends on a snapshot policy. When a snapshot is rolled over to tape, entries 

are made in the client file index and media database, which enable the save set to be 

browsed for restore. 

RPC (remote 

procedure call) 

root ◆ On UNIX, the superuser account. 

◆ On Microsoft Windows and UNIX, the highest level of the system directory 

structure. 

Protocol that the NetWorker server uses to perform client requests over a network. 

S 

save NetWorker command that backs up client files to backup volumes and makes data 

entries in the online index. 

save set Group of files or a file system from a single client computer, which is backed up on 

storage media. 

save set bundle Group of co-dependent save sets from the same scheduled backup cycle of an Oracle 

database object, assembled by NMO into a bundle according to configuration 

settings. 

save set bundle join Creation, during an incremental scheduled NMO backup, of a combined save set 

bundle from co-dependent save sets in different save set bundles. 

save set bundling Process whereby NMO automatically creates a save set bundle for each scheduled 

backup cycle of an Oracle database object, by grouping all the dependent save sets 

from the same backup cycle into a save set bundle. 


Glossary 

246 

save set ID Internal identification number that NetWorker software assigns to a save set. 

save set status NetWorker attribute that indicates whether a save set is browsable, recoverable, or 

recyclable. The save set status also indicates whether the save set was successfully 

backed up. 

save stream Data and save set information that is written to a storage volume during a backup. A 

save stream originates from a single save set. 

scanner NetWorker command used to read a backup volume when the online indexes are not 

available. 

scheduled backup Type of backup that is configured to start automatically at a specified time for a 

group of one or more NetWorker clients. A scheduled backup generates a 

“bootstrap” save set. 

scheduled backup 

cycle 

Full or level 0 backup of an Oracle database object and all the subsequent incremental 

backups that are dependent on the level 0 backup. If “save set bundling” is enabled, a 

separate save set bundle is created for each scheduled backup cycle. 

secondary storage Storage library attached to the NetWorker server or storage node, used to store 

traditional or snapshot backups. 

server Computer on a network that runs the NetWorker server software, contains the online 

indexes, and provides backup and restore services to the clients and storage nodes on 

the same network. 

server index File that lists all the server files backed up during a scheduled backup. 

service port Port used by a server or storage node to listen for backup and restore requests from 

clients through a firewall. 

shared disk Storage disk that is connected to multiple nodes in a cluster. 

shell prompt Cue for input in a shell window where you type a command. 

SID (system identifier) Unique name for an Oracle database instance. This value is typically set in an 

ORACLE_SID parameter. 

silo Repository for holding hundreds or thousands of volumes. Silo volumes are 

identified by barcodes, not by slot numbers. 

skip Backup level in which designated files are skipped and not backed up. See also 

“level.” 

snap set Group of files, volumes, or file systems from a single client that describes the 

collection of data for which a point-in-time copy is created on an external disk 

subsystem, such as a storage array. 

snapshot Point-in-time copy of Oracle data created on a supported type of primary storage 

during an instant backup. 

snapshot policy Policy configured through a NetWorker Snapshot Policy resource, to control the 

lifecycle of snapshots created during instant backups. The snapshot policy specifies 

the frequency of instant backups, and how long snapshots are retained before 

recycling. 


ssid See “save set ID.” 

staging Moving data from one storage medium to a less costly medium, and later removing 

the data from its original location. 

stand-alone device Type of “storage device” that contains a single drive for backing up data. Stand-alone 

devices cannot store or automatically load backup volumes. 

storage device Hardware that reads and writes data during backup, restore, or other NetWorker 

operations. 

storage node Storage device physically attached to a computer other than the NetWorker server, 

whose backup operations are administered from the controlling NetWorker server. 

system administrator Person normally responsible for installing, configuring, and maintaining NetWorker 

software. 

T 

tablespace Oracle database structure that consists of one or more datafiles. 

target database Database that the NetWorker server backs up as a safeguard against data loss. 

temporary enabler Code that enables operation of the NMO software for an additional 45 days beyond 

the evaluation period. 

TNS (Transparent 

Network Substrate) 

Oracle networking technology that provides a single interface to all standard 

network protocols. 

traditional restore Type of proxy Oracle restore, performed as a regular Oracle restore that restores a 

point-in-time copy from a secondary storage medium, such as tape. See “proxy 

restore.” 

traditional storage See “secondary storage.” 

unscheduled backup See “manual backup.” 

U 

user Person who uses NetWorker software from a computer to back up and restore files. 

V 

versions Date-stamped collection of available backups for any single file. 

volume Backup volume used to store backup data. Backup data cannot be stored on an 

archive volume or a clone volume. 

volume ID Internal identification that the NetWorker software assigns to a backup volume. 

volume name Name assigned to a backup volume when it is labeled. 

volume pool See “pool.” 

Glossary 


Glossary 

248 


A 

ADDRESS_LIST parameter 144 

Administrator attribute 

in Server resource 63 

Administrator program, NetWorker 

Stop button 111 

Administrator, NetWorker 

Client resource 87, 170 

Device resource 66 

Group resource 86, 169 

Label Template resource 67 

Pool resource 66, 169 

Schedule resource 87 

Server resource 63 

Snapshot Policy resource 150, 154, 169 

User Group resource 64 

AES encryption 122, 201 

allocate channel command 

parms option 215 

API, SBT 52, 57, 58 

archived redo log 

backup 20, 131, 147 

restore 148 

sharing across RAC nodes 147 

attributes for resources 

Client resource 87 


autochanger 66, 105, 123 

automatic catalog synchronization for proxy backups 181, 

191 

automatic channel allocation 26, 75, 77 

B 

backup 


command 165, 214 

command (pool option) 210 

command (trace option) 217 

copies 27 

devices, multiple 47 

error messages 221, 222 


level (full or incremental in RMAN script) 66 


sessions 54 

backup and recovery system 49, 50, 152 

Backup Command attribute 

in Client resource 88, 170, 195, 196 

backup copies during manual backups 27 

backup current control file command 132 

Backup Snapshots attribute 

in Snapshot Policy resource 158 

backup spfile command 132 

backup types 

archived redo log 20, 131, 147 

control file 130, 132 

deduplication 21, 93 

deferred live 150, 158, 173 

immediate live 150, 156 

instant 150, 154, 173, 182 

manual 21, 48, 54, 104 

NetWorker bootstrap 48, 53, 106, 155 

NWORA resource file 173, 176 

password file 130 

probe-based 23, 97 

proxy 24, 150, 154, 171 

registry files 130 

scheduled 21, 48, 110, 154 

BACKUP_TAPE_IO_SLAVES parameter 216 

bootstrap, NetWorker 48, 53, 106, 155 

Browse Policy attribute 

in Client resource 88, 170 

browse policy uniformity 37 

bundling, save set 39 

C 

canceling 

manual backup 107 

nonresponding backup 107 

proxy backup 174 

scheduled backup 78, 111 

catalog synchronization for proxy backups 181, 191 

change backuppiece...unavailable command 216 

change...crosscheck command 210, 216 

change...delete command 192 

channel option, send command 212 

Index 


Index 

client file index 47, 175, 176 


Client resource attributes 

Backup Command 88 

Browse Policy 88 

Group 88 

Name 88 

Remote Access 89 

Retention Policy 89 

Save Set 89 

Schedule 89 

Client Retries attribute 

in Group resource 194 

Client Retries attribute in Group resource 195 

cluster systems 29, 138, 194 

command 

allocate channel, parms option 215 

backup 165, 214 

backup (pool option) 210 

backup (trace option) 217 

backup current control file 132 

backup spfile 132 

change backuppiece...unavailable 216 

change...crosscheck 210, 216 

change...delete 192 

configure channel, parms option 167, 200 

crosscheck 210, 216 

delete expired backup 210 

nsrnmoinfo 123 

restore 214 

rman 82, 105, 126 

rman send 200, 213, 215 

rman.exe 105, 126 

savefs 53, 154, 156 

savegrp 53, 106, 154, 156 

send 166, 200, 211 

send (channel option) 212 

send (device_type option) 212 

send (NSR_ENV keyword) 211 

send (precedence rules) 215 

set 81, 200 

set duplex 215, 216 

setenv 81, 200 

su 84, 85 

Command attribute 

in Probe resource 98 

Command Options attribute 


configuration 






Oracle system 63 



roadmap 62 


scheduled backup 110 

250 





configuration wizard 62 

configure channel command 

parms option 167, 200 

connection file, for catalog synchronization 184, 186, 188 

control file 

backup 130, 132 

control files, mirrored 130 

crosscheck command 210, 216 

D 

database 

manual backup 48, 54, 104 

scheduled backup 48, 110, 154 

Datazone pass phrase attribute 


DBID 130, 131 

deduplication 

backup 21, 93 

restore 21 

deferred live backup 150, 158, 173 

delete expired backup command 210 

destructive restores 

overview 151 


device_type option, send command 212 

devices, multiple 47 

disaster recovery 

preparation 130 

types 133 

E 

email notification 91 

enabling 

policy uniformity 93 

save set bundling 92 

encryption 

AES encryption 122, 201 

environment variable 

LC_ALL 68 

NLS_LANG 68 

error messages 

NetWorker Module for Oracle 222 

RMAN 221 

F 

failover 

backup 139, 140, 145 

connect-time 139, 144 


FAILOVER parameter 144 

force_rollback option, not supported 178 

G 

Group attribute 

in Client resource 88, 170


GUI, NetWorker 


I 

I18N (internationalization) 33, 35, 67, 68 

immediate live backup 150, 156 

initialization parameter file 

initoracle_sid.ora 145 

PFILE 130, 131, 132 

SPFILE 130, 132 

INSTANCE_NAME parameter 145 

instant backup 150, 154, 173, 182 

instant restore 151, 160, 177 

internationalization (I18N) 33, 35, 67, 68 

L 

L10N (localization) 35, 69 


LC_ALL environment variable 68 

LD_LIBRARY_PATH parameter 81, 82 

LIBPATH parameter 82 

live backup 

deferred 150, 158, 173 

immediate 150, 156 

LOCAL_LISTENER parameter 145 

localization (L10N) 35, 69 

LOG_THRESHOLD parameter 98 

M 

mandatory parameters 81, 98, 202, 203, 204, 206, 207 


canceling 107 

monitoring 108 

procedure for running 104 

roadmap 104 

manual catalog synchronization for proxy backups 191 

media database 47, 175, 176 

media management 

storage devices 66 

volume pools 66 

media management library (MML) 52, 153, 160, 161 

mirrored 

control files 130 

online redo logs 130 

MML 52, 153, 160, 161 

MML catalog 181 

monitoring 



multiple backup devices 47 

N 

Name attribute 

in Client resource 88 



network files 

listener.ora 130, 131, 144 

sqlnet.ora 130, 131 

tnsnames.ora 130, 131, 144 


bootstrap backup 48, 53, 106, 155 

client file index 47, 175, 176 

configuration 


media database 47, 175, 176 

media database service, nsrmmdbd 55, 58, 155 

media service, nsrmmd 54, 57 

processes 

restore 163 

software features 47 

staging 39 

NetWorker Administrator program 


NetWorker configuration 






roadmap 62 




NetWorker Module for Oracle 

API, SBT 52, 57, 58 

error messages 222 

features 48 

MML 153, 160, 161 

troubleshooting 220, 221 

NetWorker PowerSnap Modules 24, 48, 65, 150, 163 

NLS_LANG environment variable 68 

NMO internationalization (I18N) 33, 35, 67, 68 

NMO localization (L10N) 35, 69 

NMO wizard 62 

nmo.messages.raw file 217, 222 

NOCATALOG mode 146 

nonresponding Oracle backup, canceling 107 

notification by email 91 

NSR_AES_ENCRYPTION parameter 76, 201 

NSR_BUNDLING parameter 92 

NSR_CHECKSUM parameter 201 

NSR_CLIENT parameter 126, 178, 201 

NSR_COMPRESSION parameter 201 

NSR_DATA_MOVER parameter 167 

NSR_DATA_VOLUME_POOL* parameters 67, 78, 202, 

216 

NSR_DEBUG_FILE parameter 83, 98, 203 

NSR_DEBUG_LEVEL parameter 203 

NSR_DEDUP_BACKUP parameter 203 

NSR_DEDUP_CACHE_ENABLED parameter 203 

NSR_DEDUP_CACHE_TAG parameter 204 

NSR_DEDUP_CHUNK_SIZE parameter 204 

NSR_DEDUP_NODE parameter 204 

NSR_DPRINTF parameter 204 

NSR_ENCRYPTION_PHRASES parameter 122, 205 

NSR_ENV keyword in send command 211 

Index 


Index 

NSR_GROUP parameter 78, 205 

NSR_INCR_EXPIRATION parameter 93 

NSR_MAX_STREAMS parameter 168 

NSR_MMDB_RETRY_TIME parameter 205 

NSR_NO_BUSY_ERRORS parameter 205 

NSR_NO_MULTIPLEX parameter 205 

NSR_NWPATH parameter 184, 206 

NSR_ORACLE_CONNECT_FILE parameter 98, 186 

NSR_ORACLE_HOME parameter 186 

NSR_ORACLE_LIB_PATH parameter 187 

NSR_ORACLE_NLS_LANG parameter 69 

NSR_ORACLE_NLS_LANG parameter resource 185 

NSR_ORACLE_SID parameter 187 

NSR_ORACLE_TNS_ADMIN parameter 187 

NSR_ORACLECAT_DEBUG_FILE parameter resource 

184 

NSR_ORACLECAT_LOG_FILE parameter resource 184 

NSR_ORACLECAT_MODE parameter resource 185, 193 

NSR_PROXY_PFILE parameter 206 

NSR_PS_SAVE_PARALLELISM parameter 167 

NSR_RECOVER_POOL parameter 206 

NSR_REMOVE_ON_FAILURE parameter resource 185 

NSR_RETENTION parameter 89 

NSR_RETENTION_DISABLED parameter 206 

NSR_RMAN_ARGUMENTS parameter 82 

NSR_SAVESET_BROWSE parameter 88, 206 

NSR_SAVESET_RETENTION parameter 207 

NSR_SB_DEBUG_FILE parameter 83 

NSR_SERVER parameter 78, 126, 207 

NSR_SERVER_NIC parameter 207 

nsrexecd service 53, 54, 57, 154 

nsrindexd service 55, 57, 155 

nsrmmd service 54, 57 

nsrmmdbd service 55, 58, 155 

nsrnmo script 53, 81, 154, 157 

parameters 79, 80 

nsrnmoadmin program 185, 187, 188, 190 

nsrnmoinfo command 123 

nsrnmoprobe program 24, 98, 99 

nsrnmostart program 53, 154, 157 

nsroraclecat program 182, 191, 194 

nsrsnapck program 154, 157, 191, 192, 194 

NWORA parameter resources 

NSR_ORACLE_NLS_LANG 185 

NSR_ORACLECAT_DEBUG_FILE 184 

NSR_ORACLECAT_LOG_FILE 184 

NSR_ORACLECAT_MODE 185, 193 

NSR_REMOVE_ON_FAILURE 185 

NWORA resource file 183, 185, 186, 187 

backup 173, 176 

NWORA SID resources 186, 187 

nworapc directory 178 

O 

online NetWorker indexes 47 

online redo logs, mirrored 130 


backup and recovery system 49, 50, 152 

DBID 130, 131 

manual backup script 75, 165, 214 

252 


media management library (MML) 52 

mirrored 

control files 130 

online redo logs 130 


recover 20, 127 

Recovery Catalog 49, 50, 51, 152 

Recovery Catalog database 

connection to 78 

Recovery Manager (RMAN) 49, 57, 152, 159 

restore 20, 48, 121, 123, 148 

sbtio.log file 217, 222 

scheduled backup script 77 

Server sessions 54 

System Backup to Tape (SBT) API 52, 57, 58 

system configuration 63 

Oracle ASM 44 

See also Oracle Automated Storage 

Oracle Automated Storage 44 

Oracle Enterprise Manager 

See Oracle Enterprise Manager Backup Management 

Tools 

Oracle Enterprise Manager Backup Management Tools 52, 

57, 105, 126, 159 

Oracle Net 63, 86, 140, 141, 144 

ORACLE_HOME parameter 81, 83, 98 

ORACLE_SERVICE parameter 98 

ORACLE_SID parameter 83 

ORACLER_USER parameter 83 

P 

parallel save stream 47 

Parallelism attribute 

in Client resource 170 


parameter 

ADDRESS_LIST 144 

FAILOVER 144 

INSTANCE_NAME 145 

LOCAL_LISTENER 145 

SERVICE_NAME 144, 145 

SID_LIST_LISTENER 144, 145 

parameter resources 


NSR_ORACLECAT_DEBUG_FILE 184 

NSR_ORACLECAT_LOG_FILE 184 

NSR_ORACLECAT_MODE 185, 193 

NSR_REMOVE_ON_FAILURE 185 

parameters 

BACKUP_TAPE_IO_SLAVES 216 

in nsrnmo script 79, 80 

LD_LIBRARY_PATH 81, 82 

LIBPATH 82 

LOG_THRESHOLD 98 

mandatory 81, 98, 202, 203, 204, 206, 207 

NSR_AES_ENCRYPTION 76, 201 

NSR_BUNDLING 92 

NSR_CHECKSUM 201 

NSR_CLIENT 126, 178, 201 

NSR_COMPRESSION 201

NSR_DATA_MOVER 167 

NSR_DATA_VOLUME_POOL* 67, 78, 202, 216 

NSR_DEBUG_FILE 83, 98, 203 

NSR_DEBUG_LEVEL 203 

NSR_DEDUP_BACKUP 203 

NSR_DEDUP_CACHE_ENABLED 203 

NSR_DEDUP_CACHE_TAG 204 

NSR_DEDUP_CHUNK_SIZE 204 

NSR_DEDUP_NODE 204 

NSR_DPRINTF 204 

NSR_ENCRYPTION_PHRASES 122, 205 

NSR_GROUP 78, 205 

NSR_INCR_EXPIRATION 93 

NSR_MAX_STREAMS 168 

NSR_MMDB_RETRY_TIME 205 

NSR_NO_BUSY_ERRORS 205 

NSR_NO_MULTIPLEX 205 

NSR_NWPATH 184, 206 

NSR_ORACLE_CONNECT_FILE 98, 186 

NSR_ORACLE_HOME 186 

NSR_ORACLE_LIB_PATH 187 


NSR_ORACLE_SID 187 

NSR_ORACLE_TNS_ADMIN 187 

NSR_PROXY_PFILE 206 

NSR_PS_SAVE_PARALLELISM 167 

NSR_RECOVER_POOL 206 

NSR_RETENTION 89 

NSR_RETENTION_DISABLED 206 

NSR_RMAN_ARGUMENTS 82 

NSR_SAVESET_BROWSE 88, 206 

NSR_SAVESET_RETENTION 207 

NSR_SB_DEBUG_FILE 83 

NSR_SERVER 78, 126, 207 

NSR_SERVER_NIC 207 

ORACLE_HOME 81, 83, 98 

ORACLE_SERVICE 98 

ORACLE_SID 83 

ORACLE_USER 83 

PATH 81 

POSTCMD 85 

PowerSnap 165, 166, 167 

PRECMD 84 

RESTORE_TYPE_ORDER 168, 177, 178, 179 


SHLIB_PATH 82 

TNS_ADMIN 86 

parms option 

allocate channel command 215 

configure channel command 167, 200 


backup 130 

PATH parameter 81 

persistent settings 25, 26, 77 

PFILE 130, 131, 132 

physical cluster client, proxy backups from 196 

point-in-time copy 24, 150, 151, 160, 169, 170, 175 

policy 

browse 88 

retention 89 

policy uniformity 37 

pool option, backup command 210 


pool, volume 

defined 66 

label template for 66 

pool types 66 

POSTCMD parameter 85 

postcommand script 85, 131, 134 

postprocessing scripts 85 

PowerSnap Modules 24, 48, 65, 150, 163 

PowerSnap parameters 165, 166, 167 

precedence rules for send command 215 

PRECMD parameter 84 

preprocessing scripts 84 

primary storage 24, 150, 153, 163, 171 

Probe resource 

attributes 

Command 98 

Command Options 98 

Name 98 

probe-based 

backup 23, 97 

processes 

restore 163 

program 

nsrd 53, 54, 57, 154, 156 

nsrexecd 53, 154 

nsrindexd 55, 57, 155 

nsrmmd 54, 57 

nsrmmdbd 55, 58, 155 

nsrnmo 53, 154, 157 

nsrnmoadmin 185, 187, 188, 190 

nsrnmoprobe 24, 98, 99 

nsrnmostart 53, 154, 157 

nsroraclecat 182, 191, 194 

nsrsnapck 154, 157, 191, 192, 194 

savefs 53, 154, 156 

savegrp 53, 154, 156 

proxy 

backup 24, 150, 154, 171 

restore 151, 159, 177 

psrollback.res file 179 

R 

RAC nodes as storage nodes 142 

RAC systems 29, 138, 140 

recover 20, 127 


Recovery Catalog database 


Recovery Catalog, backup 130, 132 

Recovery Manager (RMAN) 49, 52, 57, 152, 159 

backup scripts 75 

commands 209 

error messages 221 

features 50 

manual backup scripts 76 

proxy backup scripts 165 

proxy restore scripts 177 

Index 


Index 


restore scripts 121 

scheduled backup scripts 77, 78 

redo logs, mirrored 130 

registry files 

backup 130 

relocating files during proxy restores 179, 180 

Remote Access attribute 

in Client resource 89, 170, 195, 196 

remote procedure call (RPC) protocol 47 

resource 

types of 

Client 87, 170 

Device 66 

Group 86, 169 

Label Template 67 

Pool 66, 169 

Schedule 87 

Server 63 

Snapshot Policy 150, 154, 169 

User Group 64 

restore 

archived redo log 148 

command 214 

deduplication 21 

determining required volumes 123 

from secondary storage 151 

instant 151, 160, 177 

Oracle data 20, 48, 121, 123 

processes 163 

proxy 151, 159, 177 

rollback 151, 160, 177, 179 

to a different host 126, 180 

RESTORE_TYPE_ORDER parameter 168, 177, 178, 179 

Retain Snapshots attribute 

in Snapshot Policy resource 182 

Retention Policy attribute 


retention policy uniformity 37 

RMAN 

See Recovery Manager (RMAN) 

RMAN catalog 181 

rman command 82, 105, 126 

RMAN repository 181 

rman send command 200, 213, 215 

rman.exe command 105, 126 

roadmap 



rollback restore 151, 160, 177, 179 

RPC (remote procedure call) 47 

S 

Save Set attribute 

in Client resource 89, 170, 195 

save set bundling 39 

savefs command 53, 154, 156 

savegroup completion report for proxy backup 173 

savegrp command 53, 106, 154, 156 

SBT API 52, 57, 58 

254 


sbtio.log file 217, 222 

Schedule attribute 




automatic backup of client indexes and server 

bootstrap 106 

canceling 78, 111 

configuring Group resource 86 

configuring Schedule resource 87 

monitoring 112 

parameters 79, 110 

postprocessing scripts 85 

preprocessing scripts 84 

roadmap 110 

script 

nsrnmo 53, 154, 157 

secondary storage 150, 151 

send command 166, 200, 211 

channel option 212 

device_type option 212 

NSR_ENV keyword 211 

precedence rules 215 

Server resource 

attributes 

Datazone pass phrase 63 

Name 63 

Parallelism 63 

Server resource attributes 

Administrator 63 

service 

nsrd 53, 54, 57, 154, 156 

nsrexecd 53, 154 

nsrindexd 55, 57, 155 

nsrmmd 54, 57 

nsrmmdbd 55, 58, 155 

SERVICE_NAME parameter 144, 145 

set command 81, 200 

set duplex command 215, 216 

setenv command 81, 200 

SHLIB_PATH parameter 82 

SID_LIST_LISTENER parameter 144, 145 

silo 66 

snapshot 24, 150, 151, 160, 169, 170, 175 

Snapshot attribute in Group resource 171, 172 


Snapshot Pool attribute in Group resource 169 

SPFILE 130, 132 

staging 39 

Stop button 

in NetWorker Administrator program 111 

stopping 


nonresponding backup 107 


storage devices 


volume pool 66, 67 

Storage Nodes attribute 

in Client resource 170

su command 84, 85 

synchronization 

automatic catalog 181, 191 

manual catalog 191 

System Backup to Tape (SBT) API 52, 57, 58 

T 

tablespace 



target database 


TNS_ADMIN parameter 86 

trace option, backup command 217 

troubleshooting 


NetWorker Module for Oracle 220, 221 


types of backup 

archived redo log 20, 131, 147 

manual 48, 54, 104 

NetWorker bootstrap 48, 53, 106, 155 

scheduled 48, 110, 154 

U 

uniformity, policy 37 


V 

virtual cluster client, proxy backups from 195 

volume pool 

Default pool 78 

defined 66 

resource 66, 169 

specifying 78 

types 66 

volumes, determining for restore 123 

W 

wizard, configuration 62 

Index 


Index 

256

EMC NetWorker Module for Oracle Release 5.0 Administration Guide

Create successful ePaper yourself

Delete template?

Save as template?