EMC NetWorker Module for Databases and Applications Release 1.0

EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide P/N 300-009-220 REV A01 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 www.emc.com

Copyright 2009 EMC Corporation. All rights reserved. Published November, 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. 2 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Contents Preface Chapter 1 Overview of Product Software and Features Naming conventions used in this guide... 22 Importance of backups... 23 NMDA product features... 24 NMDA software... 24 Basic backup and recovery features... 24 Scheduled backups versus manual backups... 25 Deduplication backups and restores... 26 Probe-based (event-based) backups... 26 PowerSnap snapshot backups and restores... 28 VMware support... 28 Cluster backups and restores... 29 Configuration wizards... 29 Internationalization (I18N)... 31 Multiple database support on the same host... 33 Parallelism... 33 DB2-specific NMDA features... 34 Full and incremental DB2 backups... 34 DB2 DPF and multinode backups and restores... 34 DB2 history pruning... 35 DB2 transaction log backups... 35 DB2-specific I18N support... 35 Informix-specific NMDA features... 36 Full and incremental Informix backups... 36 Logical log backups... 36 Informix-specific I18N support... 37 Lotus-specific NMDA features... 38 Files backed up during Lotus backups... 38 Full and incremental Lotus backups... 38 Backups of Lotus database or directory links... 38 Lotus DAOS backups and restores... 39 Types of Lotus restores... 39 NetWorker User for Lotus program... 39 Lotus-specific I18N support... 40 Partitioned Domino servers... 40 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 3

Contents Oracle-specific NMDA features...42 Full and incremental Oracle backups... 42 Archived redo log backups... 42 Control file autobackup... 43 Automatic channel allocation... 43 Backup and restore optimization... 44 Backup copies... 44 Backup of backup sets... 46 Oracle Data Guard support... 46 Oracle RAC backups and restores... 47 Oracle-specific I18N support... 47 Policy uniformity... 48 Recovery configuration wizard... 48 Restartable backups... 49 Retention policies... 49 Save set bundling... 50 Other Oracle features... 54 Sybase-specific NMDA features...59 Full and incremental Sybase backups... 59 Password-protected database backup and restore... 59 Database backup and restore verification... 60 Exclusion of multiple user-defined temporary databases from backup... 60 NetWorker User for Sybase program... 61 Sybase ASE Cluster Edition... 61 Sybase-specific I18N support... 62 NMDA components...63 NMDA backup and restore processes...65 Regular scheduled backup processes... 65 Regular restore processes... 66 Chapter 2 Software Configuration Software configuration roadmap... 70 Verifying the database or application server configuration... 72 Verifying the basic resource configurations... 72 NetWorker Server resource... 72 NetWorker user group privileges... 72 NetWorker Client resource... 74 NetWorker Schedule resource... 74 NetWorker Device resources... 75 NetWorker Pool and Label Template resources... 75 Firewall support... 77 Configuring I18N support... 78 Requirements for I18N support... 78 Configure I18N support... 78 Converting a legacy configuration with the nsrdaadmin command...80 Performing server-side configuration with the NMC wizard...81 About the backup configuration wizard... 81 Convert an NMDA client-side configuration for the wizard... 82 Requirements for using the backup configuration wizard... 85 Configure a scheduled backup with the wizard... 85 Performing client-side configuration with the NMC nonwizard method...87 About client-side configuration with NMC... 87 Perform client-side configuration with NMC... 87 Configure a Group resource with NMC... 88 4 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Contents Configure a Schedule resource with NMC... 88 Customize a Client resource with NMC... 89 Configuring DB2 backups... 93 Configure DB2 transaction log backups for rollforward recovery... 93 Configure a DB2 parallel (multiple session) backup... 95 Configuring Informix backups... 97 Configure Informix continuous logical log backups... 98 Configure Informix backup parallelism... 98 Informix-specific requirements for I18N support... 98 Configuring Lotus backups... 99 Ensure the environment settings for Lotus operations... 99 Configure Lotus backup parallelism... 99 Configuring Lotus DAOS backups... 100 Configuring Oracle backups... 103 RMAN scripts for manual backups... 103 RMAN scripts for scheduled backups... 105 Oracle-specific requirements for NetWorker user group privileges... 107 Oracle-specific requirements for NSR_DATA_VOLUME_POOL... 108 Configure an Oracle parallel (multi-channel) backup... 108 Oracle-specific requirements for I18N support... 109 Configure save set bundling... 110 Configure policy uniformity... 111 Configuring Sybase backups... 112 Set up Sybase roles and permissions... 113 Sybase backup levels... 113 Sybase transaction log backups... 113 Ensure the environment settings for Sybase backups on HP-UX... 115 Configure Sybase parallel (multistripe) backups... 116 Configure a threshold procedure... 117 Configuring a deduplication backup... 119 Requirements for a deduplication backup... 119 Best practices for a deduplication backup... 119 Configure a scheduled deduplication backup... 122 Configure a manual deduplication backup... 123 Ensure the environment settings for Sybase deduplication operations. 124 Configuring a probe-based backup... 125 Requirements for a probe-based backup... 125 Configure a probe-based backup... 126 Chapter 3 Backup Procedures Manual backup procedures... 134 Perform a manual backup... 134 DB2 manual backup... 135 Informix manual backup... 137 Lotus manual backup... 138 Oracle manual backup... 143 Sybase manual backup... 144 Cancel a manual backup... 151 Perform a NetWorker bootstrap and index backup... 152 Monitor a manual backup... 153 Scheduled backup procedures... 156 Prepare for a scheduled backup... 156 Test a scheduled backup... 156 Cancel a scheduled backup... 157 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 5

Contents Monitor a scheduled backup... 159 Verifying the backup information in NetWorker indexes...161 Regular backup information in NetWorker indexes... 161 Deduplication backup information in NetWorker indexes... 162 Chapter 4 Chapter 5 Data Restore and Recovery About data restore and recovery...166 NetWorker indexes and policies used for restores... 166 DB2 data restore and recovery... 168 Requirements for DB2 data restore... 168 Recover DB2 data to the same instance... 170 Recover DB2 data to a different instance... 171 Recover DB2 data with rollforward of transaction logs... 174 Informix data restore and recovery... 179 Requirements for Informix data restore... 179 Informix restore modes... 180 Informix data restore through the onbar command... 181 Informix data restore through the IECC... 181 Lotus data recovery... 182 Requirements for Lotus data recovery... 182 Considerations for Lotus DAOS recovery... 183 Lotus database recovery through the nsrnotesrc command... 183 Lotus database recovery through NetWorker User for Lotus... 188 Document-level recovery through the nsrdocrc command... 198 Document-level recovery through the Notes client GUI... 200 Oracle data restore and recovery... 202 Requirements for Oracle data restore... 202 RMAN scripts for restore and recovery... 205 Recovery configuration wizard (Oracle only)... 206 Restore through the RMAN command line interface... 208 Restore with Oracle Enterprise Manager Backup Management Tools... 209 Recover the Oracle data... 209 Sybase data restore and recovery... 210 Requirements for Sybase data restore... 210 Sybase data restore through the nsrsybrc command... 211 Sybase data restore through NetWorker User for Sybase... 215 Disaster Recovery About disaster recovery...224 Preparing for disaster recovery...225 Prepare a DB2 server for disaster recovery... 225 Prepare an Informix server for disaster recovery... 225 Prepare a Lotus server for disaster recovery... 227 Prepare an Oracle server for disaster recovery... 227 Prepare a Sybase server for disaster recovery... 230 Performing disaster recovery...231 NetWorker server recovery... 231 DB2 disaster recovery... 231 Informix disaster recovery... 232 Lotus disaster recovery... 234 Oracle disaster recovery to a new host... 240 Sybase disaster recovery... 242 6 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Contents Chapter 6 Chapter 7 Chapter 8 Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems Cluster systems... 248 Backup failover... 250 Cluster backup configuration... 250 Deduplication setup in cluster environments... 256 Recovery in a cluster... 256 DB2 DPF systems... 257 Manual backup in a DPF environment... 258 Scheduled DPF backup in a DB2 9.1.x environment... 260 Scheduled DPF backup in a DB2 9.5 or later environment... 261 Restoring a DPF backup... 263 Oracle RAC systems... 264 RAC terminology... 264 RAC backups and restores... 264 Backup configuration in a RAC system... 264 Setting up RAC nodes to back up to a local storage node... 265 Connect-time failover... 267 Creating RMAN backup scripts... 269 Creating RMAN restore scripts... 270 Archived redo logs... 271 Sybase ASE Cluster Edition systems... 272 ASE Cluster Edition terminology... 272 ASE Cluster Edition backups and restores... 272 Single backup server configuration... 273 Multiple backup server configuration... 274 Backup of temporary databases... 275 Backup and recovery of the quorum device... 275 Recovery of the master database on clusters... 275 Multiple Domino Installations and Partitioned Domino Servers Multiple Domino installations on UNIX... 278 Manual backups with multiple Domino installations... 278 Scheduled backups with multiple Domino installations... 278 Recovery with multiple Domino installations... 279 Partitioned Domino servers... 280 Manual backups of partitioned Domino servers... 280 Scheduled backups of partitioned Domino servers... 280 Recovery of partitioned Domino servers... 281 Snapshot Backups and Restores PowerSnap snapshot operations... 284 Supported environments for PowerSnap snapshot operations... 284 Required software for PowerSnap snapshot operations... 285 Types of supported PowerSnap backups... 286 Types of supported PowerSnap restores... 287 PowerSnap backup processes... 288 Oracle PowerSnap operations... 290 Configuring Oracle PowerSnap backups... 290 Oracle PowerSnap backup requirements... 299 Oracle PowerSnap backup information in NetWorker indexes... 302 Oracle PowerSnap restore requirements... 305 Catalog synchronization for Oracle PowerSnap backups... 309 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 7

Contents PowerSnap backups and restores on cluster systems... 322 DB2 PowerSnap operations...326 Configuring DB2 PowerSnap backups... 326 Restoring a DB2 PowerSnap backup... 330 Managing and deleting DB2 PowerSnap backups... 330 Replication Manager snapshot operations with Oracle ASM...332 About NMDA integration with Replication Manager... 332 Requirements for snapshot backups of Oracle ASM data... 333 Configuring snapshot backups of Oracle ASM data... 334 Performing backups and restores of Oracle ASM data... 341 Sample preprocessing and postprocessing scripts... 342 Appendix A Appendix B Appendix C NMDA Parameters for Backups and Restores About NMDA parameters... 346 NMDA configuration file... 347 Syntax rules for the NMDA configuration file... 348 Common NMDA parameters... 350 DB2-specific NMDA parameters... 355 Settings not to use for DB2 operations... 355 DB2-specific NMDA parameter definitions... 355 Informix-specific NMDA parameters... 360 Lotus-specific NMDA parameters... 362 Wildcard restrictions for Lotus operations... 362 Lotus comfort span... 362 Lotus-specific NMDA parameter definitions... 363 Oracle-specific NMDA parameters... 368 Setting the NMDA parameters for Oracle operations... 368 Oracle-specific NMDA parameter definitions... 369 Sybase-specific NMDA parameters... 373 Oracle RMAN Commands The delete expired backup command... 378 The change...crosscheck and crosscheck commands... 378 The pool option of the backup command... 378 The send command... 379 Syntax rules... 379 Two ways to run the send command... 381 Precedence rules... 383 The set duplex command... 383 The trace option of the backup command... 385 Sybase isql Commands Syntax for isql commands... 388 Loading and dumping a database... 388 Dump a database... 388 Load a database... 388 Loading and dumping a transaction log... 389 Dump a transaction log... 389 Load a transaction log... 389 Find the timestamp for a save set... 390 Recovering a database and transaction logs... 390 8 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Contents Appendix D Troubleshooting and Error Messages General troubleshooting tips... 394 Viewing group backup details and messages... 395 Wizard creation of backup fails, authentication denied... 395 The backup hangs... 396 Debug log files... 396 NMDA error messages... 398 DB2-specific troubleshooting tips and error messages... 399 DB2-specific troubleshooting tips... 399 DB2-specific error messages... 400 Informix-specific troubleshooting tips and error messages... 403 Informix-specific troubleshooting tips... 403 Informix-specific error messages... 406 Lotus-specific troubleshooting tips and error messages... 407 Lotus-specific troubleshooting tips... 407 Lotus-specific error messages... 409 Oracle-specific troubleshooting tips and error messages... 412 Oracle-specific troubleshooting tips... 412 Oracle-specific error messages... 413 Sybase-specific troubleshooting tips and error messages... 427 Sybase-specific troubleshooting tips... 427 Sybase-specific error messages... 427 Glossary Index EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 9

Contents 10 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Figures Title Page 1 Regular scheduled NMDA backup... 66 2 NetWorker User for Lotus Backup window... 139 3 NetWorker User for Lotus Backup Options dialog box... 141 4 NetWorker User for Lotus Backup Status window... 141 5 NetWorker User for Lotus Properties window... 143 6 NetWorker User for Sybase Backup window... 147 7 NetWorker User for Sybase Backup Options dialog box... 149 8 NetWorker User for Sybase Backup Status window... 150 9 Backup messages in Sessions tab of Monitoring window... 154 10 Backup messages in Devices tab of Monitoring window... 155 11 Backup messages in Log tab of Monitoring window... 155 12 Group details for regular scheduled backups... 160 13 NetWorker User for Lotus Recover window... 189 14 NetWorker User for Lotus Recover Options dialog box... 191 15 NetWorker User for Lotus Recover Status window... 192 16 Versions window... 192 17 Change Browse Time dialog box... 193 18 Required Volumes window... 195 19 NetWorker User for Sybase Recover window... 216 20 NetWorker User for Sybase Recover Options dialog box... 218 21 NetWorker User for Sybase Recover Status window... 219 22 Change Browse Time dialog box... 220 23 Required Volumes window... 221 24 Single DB2 node with failover capability... 249 25 Multiple DB2 nodes with failover capability... 249 26 Multiple DB2 nodes with mutual failover capability... 249 27 Single DPF host with shared memory... 257 28 Two DPF hosts with single nodes... 258 29 Two DPF hosts with multiple nodes... 258 30 Software used in the NMDA environment for PowerSnap backups and restores... 286 31 PowerSnap live backup and restore data flow... 289 32 Application Credentials window in the Replication Manager console... 335 33 Advanced Replication Settings in the Replication Manager console... 336 34 Mount options in the Replication Manager console... 337 35 Starting the Job window in the job wizard... 338 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 11

Figures 12 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Tables Title Page 1 Naming conventions... 22 2 NetWorker User for Lotus toolbar buttons... 40 3 NetWorker User for Sybase toolbar buttons... 61 4 NMDA components... 63 5 NetWorker Server resource attributes... 72 6 User group privileges for common NMDA operations... 73 7 Options of the nsrdaadmin command for configuration conversion... 84 8 Backup levels specified in NetWorker Schedule resource... 89 9 NetWorker Client resource attributes... 90 10 User group privileges for Oracle-specific NMDA operations... 107 11 Sybase roles and permissions... 113 12 Transaction log options for full backups... 114 13 Transaction log options for incremental backups... 115 14 Threshold procedure location... 118 15 NetWorker Probe resource attributes... 126 16 Toolbar buttons on the NetWorker User for Lotus Backup window... 140 17 Consistency check options of the nsrsybcc command... 145 18 Toolbar buttons on the NetWorker User for Sybase Backup window... 147 19 Toolbar buttons on the NetWorker User for Lotus Recover window... 189 20 Toolbar buttons on the NetWorker User for Sybase Recover window... 217 21 Typical configuration for PowerSnap snapshot operations with NMDA... 285 22 PowerSnap parameters... 294 23 Sample NetWorker Group resource attributes for a snapshot backup... 296 24 NWORA parameter resources... 311 25 NWORA SID resource components... 313 26 Sample NetWorker Group resource attributes for a snapshot backup... 327 27 DB2 resource file parameters... 328 28 Common NMDA parameters... 350 29 DB2-specific NMDA parameters... 356 30 Informix-specific NMDA parameters... 360 31 Lotus-specific NMDA parameters... 363 32 Oracle-specific NMDA parameters... 369 33 Sybase-specific NMDA parameters... 373 34 Option values in the send command... 381 35 Set duplex command values... 384 36 Trace option values and conditions traced... 385 37 Path and suffix for the load libnsrdb2 command... 400 38 DB2 SQL error messages... 400 39 Error messages from Lotus backups... 409 40 Error messages from Lotus recoveries... 410 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 13

Tables Title Page 41 Error messages from the libnsrora library... 414 42 Error messages from the nsroraadmin program... 422 43 Error messages from the nsrorainfo program... 424 44 Error messages from the nsrdaprobe program... 425 45 Error messages from the nsrdasv program... 426 46 Error messages from the nsrsybcc program... 428 47 Error messages from the nsrsybrc program... 429 48 Error messages from the nsrdasv program... 431 49 Sybase backup server and libnsrsyb error messages... 433 50 NetWorker XBSA and libnsrsyb error messages... 435 14 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Examples Title Page 1 Using the configure channel command with parms option for automatic channels.. 43 2 Specifying parameter values per automatic channel... 44 3 Using the set backup copies command in the RMAN script... 45 4 Using automatic channels for backup copies... 46 5 Save set bundling for a one-week scheduled backup cycle of a tablespace... 53 6 Save set bundle join... 54 7 Splitting a save set bundle across volumes... 54 8 Using save set consolidation to re-unite a save set bundle... 54 9 RMAN script for a manual backup... 104 10 RMAN script for a scheduled backup... 105 11 Oracle RMAN script for a manual deduplication backup... 123 12 Possible Command Options settings for the nsrdaprobe program... 129 13 Multiple probes for a probe-based backup... 130 14 Informix manual backup through onbar commands... 137 15 Recovery of a previous database version... 184 16 Recovery of specific Lotus databases... 185 17 Recovery of all Lotus data in a directory... 185 18 Recovery of all Lotus database files... 185 19 Recovery of a database with a change of the DBIID... 185 20 Recovery of a full backup without the transaction logs... 186 21 Relocation of a linked database during Lotus recovery... 186 22 Recovering deleted documents for a logged database... 199 23 Sample nsrorainfo commands for Oracle restores... 204 24 Volume information displayed by the nsrorainfo command... 204 25 RMAN script to restore a tablespace... 205 26 RMAN script to restore from a specified pool... 205 27 Restores of single or multiple Sybase databases... 211 28 Point-in-time restore of Sybase data... 212 29 Sample postcommand script on UNIX... 241 30 Sample postcommand script on Windows... 241 31 Recover the master database... 243 32 Recover user databases after database device failure... 244 33 Lotus scheduled backup configuration in a cluster system... 253 34 Sybase scheduled backup configuration in a cluster system... 254 35 Setting up RAC nodes as storage nodes... 266 36 RMAN script for a manual Oracle backup on a RAC system... 269 37 RMAN script for an Oracle restore on a RAC system... 270 38 RMAN scripts with multiple channels... 292 39 PowerSnap parameter settings... 295 40 PowerSnap parameter settings for a Celerra NAS device... 295 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 15

Examples Title Page 41 Oracle PowerSnap backup failure... 300 42 Oracle PowerSnap backup entries in the client file index... 303 43 Oracle PowerSnap backup entries in the media database... 304 44 Resource file backup entry in the client file index... 304 45 Resource file backup entry in the media database... 304 46 RESTORE_TYPE_ORDER parameter settings... 305 47 Symbolic link specified in the set newname command... 308 48 Relocation of a raw volume... 308 49 Default NWORA parameter resources... 313 50 NWORA SID resource... 314 51 Connection file contents... 315 52 PowerSnap backup entries in the index of a physical cluster client... 324 53 PowerSnap backup entries in the index of a virtual cluster client... 324 54 A send command sets the parameters for a specified channel... 380 55 An rman send command sets a parameter for all channels... 382 56 Order of parameters set according to the precedence rules... 383 57 Loading the master database... 389 16 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

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 about 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 Related documentation This document is part of the EMC NetWorker Module for Databases and Applications (NMDA) documentation set, and is intended for use by system administrators or database administrators (DBAs) who are responsible for installing software and maintaining backup and recovery systems for databases or applications. Operators who monitor backups may also find this document useful. Readers of this document are expected to be familiar with the following topics: Backup, recovery, and maintenance of a database or application client Backup, recovery, and maintenance of a database or application server Disaster recovery procedures on a database or application 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 Databases and Applications release 1.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 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 17

Preface The following additional documentation may be useful: Database or application server documentation Database or application backup and recovery documentation Conventions used in this document 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 command line User input variables < > Angle brackets enclose parameter or variable values supplied by the user [ ] Square brackets enclose optional values 18 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Preface 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: http://powerlink.emc.com Technical support For technical support, go to Powerlink and select Support. On the Support page, you will see several options, including one for making a service request. Note that to open a service request, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or with 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: techpubcomments@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. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 19

Preface 20 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

1 Overview of Product Software and Features This chapter includes the following major sections: Naming conventions used in this guide... 22 Importance of backups... 23 NMDA product features... 24 DB2-specific NMDA features... 34 Informix-specific NMDA features... 36 Lotus-specific NMDA features... 38 Oracle-specific NMDA features... 42 Sybase-specific NMDA features... 59 NMDA components... 63 NMDA backup and restore processes... 65 Overview of Product Software and Features 21

Overview of Product Software and Features Naming conventions used in this guide This guide uses the naming conventions outlined in Table 1 on page 22. Table 1 Naming conventions Term Client-side configuration Configuration wizard Server-side configuration Database host or application host Microsoft Administrator user NMC NMDA NMDB2 NMI NML NMO NMS Notes user PowerSnap snapshot backup or restore Regular backup or restore Restore and recover UNIX Windows Description Backup configuration that is created with the EMC NetWorker Management Console (NMC), withou the configuration wizard. Configuration wizard, integrated with the NMC GUI, that can be used to configure the following: NMDA DB2, Lotus Domino/Notes, or Oracle scheduled backup NMDA Oracle recovery Backup configuration that is created with the configuration wizard. Host where both the particular database or application software and NMDA software are installed. Member of the Microsoft Windows Administrators group. NetWorker Management Console user interface. NetWorker Module for Databases and Applications. NetWorker Module for DB2. NetWorker Module for Informix. NetWorker Module for Lotus. NetWorker Module for Oracle. NetWorker Module for Sybase. User that runs a Domino server or Notes client where Lotus data is being backed up or restored. Backup or restore that is implemented by using snapshot technologies through the EMC NetWorker PowerSnap x Module software. NMDA backup or restore that does not use snapshot technologies through the PowerSnap Module software. Unlike NetWorker, which uses the term recover for all backup retrieval activities, NMDA distinguishes between restore and recovery of a database: Restore means to retrieve individual datafiles from backup and store the files on disk. Recover means to apply the transaction, redo, or logical logs to make the database consistent. Both UNIX and Linux operating systems, unless specified otherwise. All the supported Microsoft Windows operating systems, unless specified otherwise. The Glossary provides a complete list of terms used in this guide. 22 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Importance of backups 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 require database or application restores from backup storage media. For the complete protection of a database or application system, a viable backup strategy must include regular backups of the following: Database files Transaction (or archived) logs NetWorker bootstrap records (the media database, resource database, and server index that reside on the NetWorker server) These backups are important for the following reasons: Without transaction logs, you can recover a database only to the time of its last consistent backup. Without backups and transaction logs, you cannot recover a database at all. Without the bootstrap records, you may not be able to recover essential file and configuration data after a disaster, such as a disk crash or NetWorker server failure. The NetWorker server maintains an online client file index and online media database, which together comprise the online indexes. 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. Importance of backups 23

Overview of Product Software and Features NMDA product features The following sections provide an overview of the NMDA software and its major features, including features supported with specific databases and applications. NMDA software As an add-on module for the NetWorker server, NMDA works with the NetWorker server to provide a storage management solution that addresses the need for cross-platform support of enterprise applications. The NMDA software works with the supported database or application software and the NetWorker software to provide backup and restore services for DB2, Informix, Lotus Domino/Notes, Oracle, and Sybase data. The NMDA software includes the following features: Capability to perform the following for DB2, Informix, Lotus, Oracle, and Sybase: Manual database or application backups Scheduled database or application backups Restores of database or application backup data Automated media management Capability to integrate database and file system backups, which relieves 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 If PowerSnap is supported with a particular database or application (for example, on a DB2 or Oracle server), NMDA works with the NetWorker PowerSnap Module to perform snapshot backups and restores. Basic backup and recovery features The NMDA software supports the following basic backup and recovery features: Online backup NMDA can back up an online database or application, without requiring any down time. Full or block-level incremental backup Application-specific sections of this guide provide details on the supported types of backups. For example, Table 8 on page 89 describes the backup levels supported for a scheduled backup of each type of database or application. Backup of transaction logs and other files required for recovery NMDA can back up all the database or application components required for recovery, including transaction logs. Application-specific sections of this guide provide details. Automatic recovery of a database or application to the current time or to any point in time. Recovery to the original location or to an alternate location. 24 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Granular backup or recovery NMDA supports the following backup and recovery granularities: DB2 database or tablespace level backup or recovery Informix IDS instance or dbspace level backup or recovery Lotus database backup, and Lotus database or document-level recovery Oracle database, tablespace, or datafile level backup or recovery Note: In addition, Oracle can perform block-level recovery. Sybase ASE server level or database level backup or recovery Scheduled backups versus manual backups An NMDA backup can be either a scheduled or manual (unscheduled) backup: An NMDA scheduled backup includes the following features: The scheduled backup is initiated by the NetWorker server. The scheduled backup start time depends on the settings in the NetWorker resources. The scheduled backup automatically backs up the NetWorker bootstrap and client index, which are required for disaster recovery. A regular (time-based) scheduled backup starts at a time specified in the NetWorker Group resource. A probe-based backup is a type of scheduled backup that starts when specified conditions are met, as described in Probe-based (event-based) backups on page 26. A PowerSnap snapshot backup is supported only by using a scheduled backup, as described in PowerSnap snapshot backups and restores on page 28. An NMDA manual backup includes the following features: The manual backup is initiated by a user on the application host through a database or application-specific command or procedure that runs the appropriate backup utility. The manual backup procedure is specific to each database or application, as described in Manual backup procedures on page 134. The manual backup does not back up the NetWorker bootstrap or client index, which are required for disaster recovery. The bootstrap and client index backup may be done separately. Chapter 2, Software Configuration, provides details on the configuration of both scheduled and manual backups. Chapter 3, Backup Procedures, provides details on the procedures for both scheduled and manual backups. NMDA product features 25

Overview of Product Software and Features Deduplication backups and restores NMDA software provides support for deduplication backups and restores. The EMC NetWorker Module for Databases and Applications Release Notes provides details on the limitations and NetWorker requirements of deduplication operations. Main features of deduplication operations An EMC Avamar server interacts with the NetWorker server and NMDA 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 NMDA clients. 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 NMDA client host and backs up only the unique blocks that contain changes. Since data deduplication is performed on the client host, deduplication backups typically require less time, network bandwidth, and storage space than regular NMDA backups. Note: Deduplication can be offloaded to a proxy host for the application that supports snapshot-based backups. The EMC NetWorker Module for Databases and Applications Release Notes provides details on the required PowerSnap release. The PowerSnap documentation provides more details on deduplication support. A deduplication backup can be a manual or scheduled backup, which includes probe-based backups. The application of browse and retention policies and the selection of media pools is the same for a deduplication backup as for a regular NMDA backup. Only the backup metadata (hash information) is stored on the NetWorker backup device, which generates a very small save set. The device should be configured as an advanced file type device (AFTD). The EMC NetWorker Administration Guide provides more details. You must configure a scheduled or manual deduplication backup according to Configuring a deduplication backup on page 119. Deduplication backup information in NetWorker indexes on page 162 describes the backup information that is stored in the NetWorker indexes, and how to delete the backups. Probe-based (event-based) backups NMDA software provides support for probe-based backups, also known as event-based backups. A probe-based backup is a type of scheduled backup. The following is a comparison of a probe-based backup and regular scheduled backup: A regular (time-based) scheduled backup is started by the NetWorker server based on a time interval. A probe-based backup is started by the NetWorker server when specified conditions are met. 26 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features The EMC NetWorker Module for Databases and Applications Release Notes provides details on the limitations and NetWorker requirements of probe-based backups. Workflow of probe-based backups An NMDA probe-based 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 probe-based backup. (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. Types of probes NMDA supports two types of probes, an NMDA-specific probe and user-defined probes. NMDA-specific probe The NMDA-specific probe is implemented through the NMDA program nsrdaprobe. The nsrdaprobe program returns a successful result, which signifies that the condition being checked has been met, when the program detects the following: The number of DB2, Informix, or Oracle logs generated since the last probe-based backup equals or exceeds a number known as the change threshold. The size of Lotus Domino transaction logs generated since the last full backup equals or exceeds a number known as the change threshold. The number of Sybase transaction log pages generated since the last probe-based backup equals or exceeds a number known as the change threshold. On an Oracle system only, a new database incarnation (reset log) has occurred since the last probe-based backup. NMDA product features 27

Overview of Product Software and Features User-defined probes A user-defined probe checks if any user-defined condition has been met since the previous probe-based backup. Configuring a probe-based backup on page 125 provides details on how to configure a probe-based backup. PowerSnap snapshot backups and restores PowerSnap snapshot backups and restores provide continuous snapshot-based protection and availability of DB2 or Oracle data. The NMDA software works with the NetWorker server and NetWorker PowerSnap Module software to perform snapshot backups and restores of DB2 or Oracle server data that resides on specific types of primary storage. PowerSnap snapshot backups create point-in-time copies or snapshots of DB2 or Oracle data, store the snapshots on primary storage devices supported by the PowerSnap Modules (for EMC Symmetrix, EMC CLARiiON, and so on), and optionally back up the data to secondary storage from the point-in-time copies. NMDA supports scheduled PowerSnap backups only. If you attempt to run a manual (unscheduled) PowerSnap backup, you receive an error message. PowerSnap restores can be used to restore the DB2 or Oracle data that was backed up by using PowerSnap snapshot backups. The procedure to restore PowerSnap backups is the same as to restore regular backups, except that certain PowerSnap Module parameters might need to be set. Chapter 8, Snapshot Backups and Restores, provides more information. The EMC Information Protection Software Compatibility Guide on the EMC Powerlink website provides details on the supported PowerSnap Modules and primary storage. The NetWorker PowerSnap Module documentation provides details on the PowerSnap Module software. VMware support NMDA 1.0 software provides support for regular backups and restores of the database or application installed on a VMware Virtual Machine (VM) on an ESX server. NMDA also supports 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 that run on the virtual machines, and users do not experience disconnections. If a migration occurs during an NMDA 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 NMDA backup or restore, the backup or restore is not interrupted. 28 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features High Availability (HA) The HA feature enables VMware to be restarted on the same ESX server, on a different ESX server, or on a physical machine, depending on the type of VMware cluster configured. During a restart, users are disconnected, and must reconnect. If a restart occurs during an NMDA backup or restore, the backup or restore fails. A manual backup or restore must be restarted manually when the guest operating system is restarted. In the case of a scheduled backup, the NetWorker server retries the backup if the Client Retries attribute in the Group resource is set to a nonzero value. Restartable backups on page 49 provides details on Oracle RMAN options for restartable backups. The EMC NetWorker Module for Databases and Applications Release Notes provides details on the NetWorker requirements for the support of VMware features. The EMC NetWorker Release Notes provides additional details on limitations of VMware support. Cluster backups and restores The NMDA software supports backups and restores of cluster systems for high availability or improved computer performance. 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, NMDA can be used with NetWorker server software to back up and restore a database or application associated with the service, independent of the actual node that provides the service. The following sections provide more information on the supported database and application-specific features for cluster systems: DB2 DPF and multinode backups and restores on page 34 Oracle RAC backups and restores on page 47 Sybase ASE Cluster Edition on page 61 Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems, provides more detail about these systems and their configuration for NMDA backups and restores. The EMC Information Protection Software Compatibility Guide provides details on the types of cluster environments that NMDA software supports. Configuration wizards The NMDA software provides support for backup and recovery configuration wizards that are integrated with the NetWorker Management Console (NMC). You can run the NMDA 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. The EMC NetWorker Module for Databases and Applications Release Notes provides details on the limitations and NetWorker requirements of the NMC-based configuration wizards. NMDA product features 29

Overview of Product Software and Features Main features of the wizards The NMDA software supports the following configuration wizards: Backup configuration wizard that configures scheduled backups (either typical or custom) of DB2, Lotus, and Oracle data. Performing server-side configuration with the NMC wizard on page 81 provides details on using the backup configuration wizard. Recovery configuration wizard that generates RMAN restore and recovery scripts designed to: Restore Oracle data to the original host. Create a duplicate Oracle database on a local or remote host. Recovery configuration wizard (Oracle only) on page 206 provides details on using the recovery configuration wizard. The wizards provide security and ease of management for backup and recovery configurations. For example, the wizards use NetWorker lockbox services to store sensitive data. Features of the backup configuration wizard The backup configuration wizard can do the following: Configure a new NetWorker Client resource for an NMDA backup. Configure a new NetWorker Group resource, or use an existing resource, for the backup Client resource. Configure new browse and retention policies, or use existing policies, for the backup Client resource. Save a copy of the configuration settings to a configuration file on the NMDA host. Modify a backup configuration that was created with the NMDA configuration wizard. Note: A backup configuration created with the wizard is known as a server-side configuration. Modify a backup configuration that was created by configuring the NetWorker resources with NMC, without the NMDA wizard. However, the backup configuration wizard can modify these configurations only after they have been converted according to Configuration conversion on page 31. Note: A backup configuration created with the NMC method, without the wizard, is known as a client-side configuration. Performing server-side configuration with the NMC wizard on page 81 provides information on using the wizard to create or modify a backup configuration. Performing client-side configuration with the NMC nonwizard method on page 87 provides information on using the NMC nonwizard method to create or modify a backup configuration. 30 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Backup configuration storage with the wizard The backup configuration wizard stores the configuration information (except for sensitive data, such as passwords) in a 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. Note: The backup configuration wizard stores sensitive data securely by using NetWorker lockbox services. Configuration conversion The NMDA backup configuration wizard stores the scheduled backup configuration in the Client resource by using a configuration storage framework that is incompatible with a configuration that was created with the NMC method, without the wizard. You must convert these scheduled backup configurations before you can use the NMDA wizard to modify the configurations: A backup configuration that was created with the wizard from a legacy NetWorker module. An NMDA client-side configuration that was created with the NMC configuration method, without the wizard. The NMDA wizard can modify NMDA server-side configurations only. The recommended conversion method is to use the nsrdaadmin command. Note: Conversion of a PowerSnap snapshot backup configuration is not supported. You can use the nsrdaadmin -W command to convert an NMDA client-side configuration to an NMDA server-side configuration, which uses the configuration storage framework supported by the NMDA wizard. This conversion does not create a new Client resource, but modifies an existing Client resource, such that you can then use the wizard to modify it. Convert an NMDA client-side configuration for the wizard on page 82 provides details on how to convert an NMDA client-side to server-side configuration with the nsrdaadmin -W command. You can use the nsrdaadmin -M command to do either of the following: Convert the client-side configuration of a legacy NetWorker module to an NMDA client-side configuration. Convert the server-side configuration of a legacy NetWorker module to an NMDA server-side configuration. The EMC NetWorker Module for Databases and Applications Installation Guide provides details on how to convert the backup configuration of a legacy NetWorker module. Internationalization (I18N) NMDA I18N is the capability of the NMDA software to operate in a non-english environment or locale without itself generating non-ascii data. After you set up NMDA I18N as described in Configuring I18N support on page 78, NMDA can NMDA product features 31

Overview of Product Software and Features process and display non-ascii data that is passed to it by the operating system, NetWorker software, and database or application software. The non-ascii data can include text messages, dates, times, numbers, and so on. The term internalization is used differently in the NetWorker documentation (as opposed to this NMDA 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 NMDA I18N support is dependent on the following: I18N support that is provided by the operating system on the NMDA 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 database or application 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), NMDA cannot support non-ascii data in that resource attribute. The NetWorker documentation includes more information on I18N support. When NMDA I18N support is set up as described in Configuring I18N support on page 78, NMDA supports non-ascii data in the following for all databases and applications: Directory pathname in the NSR_DIAGNOSTIC_DEST parameter in the NMDA configuration file Filenames and pathnames in the PRECMD and POSTCMD parameters in the NMDA configuration file Strings passed as command line options to the nsrdaadmin(.exe) and nsrdasv(.exe) commands Tablespace names and datafile paths The following sections provide details on I18N support for specific databases and applications: DB2-specific I18N support on page 35 Informix-specific I18N support on page 37 Lotus-specific I18N support on page 40 Oracle-specific I18N support on page 47 Sybase-specific I18N support on page 62 The deduplication backup process, nsravtar, on the NMDA client generates messages in English only. When NMDA I18N support is set up, NMDA generates debug messages in English only. NMDA generates error messages in the nmda_app.messages.raw file in a language-independent binary form, readable by the nsr_render_log program only. (The log file does not contain database or application server errors.) The EMC NetWorker Administration Guide provides information on how to use the nsr_render_log program to read any language-independent binary file, such as nmda_app.messages.raw. The PowerSnap Module documentation provides details on the PowerSnap options that support non-ascii values. 32 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Configuring I18N support on page 78 describes how to set up NMDA I18N support. Multiple database support on the same host The NMDA software supports multiple instances or installations of the same application or different applications on the same host. For 32-bit and 64-bit application coexistence, the NMDA software installation requires additional post-installation steps, as described in the EMC NetWorker Module for Databases and Applications Installation Guide. Multiple Domino installations on UNIX on page 278 provides details on how to perform manual or scheduled backups and recovery operations with multiple Domino installations on UNIX. Parallelism Parallelism is a feature that enables NMDA backup or restore streams of data from several clients, or many data streams from one client, at the same time. The following sections include configuration settings that enable different types of parallelism during NMDA operations: NetWorker Server resource on page 72 Customize a Client resource with NMC on page 89 The following sections provide details on how to specify parallelism settings for application-specific backups: Configure a DB2 parallel (multiple session) backup on page 95 Configure Informix backup parallelism on page 98 Configure Lotus backup parallelism on page 99 Configure an Oracle parallel (multi-channel) backup on page 108 Configure Sybase parallel (multistripe) backups on page 116 NMDA product features 33

Overview of Product Software and Features DB2-specific NMDA features The following sections provide details on product features that are specific to the DB2 backup and restore operations performed with the NMDA software. Full and incremental DB2 backups NMDA supports all the backup types that DB2 supports: Full backup A DB2 full backup is the building block of any recovery strategy. Without a full backup, you cannot start to restore. If an online backup is performed, you require the logs of all the transactions that transpired during the backup, unless the include logs options is specified during the online backup. Incremental backup A DB2 incremental backup includes all the changes since the last full backup. Delta backup A DB2 delta backup backs up all the changes since the last backup of any type. The DB2 documentation provides details on recovering the DB2 full, incremental, and delta backups. DB2 DPF and multinode backups and restores Cluster backups and restores on page 29 provides an overview of cluster backups and restores, as supported by the NMDA software. For DB2 operations, NMDA also supports the DB2 Database Partitioning Feature (DPF). The DB2 DPF offers environments where a single database, divided by logical nodes, may reside on multiple partitions, either on the same host or on multiple hosts. Partitioned databases can manage high volumes of data, and provide benefits such as increased performance and high availability. The NMDA software provides backup and restore support, including disaster recovery and the backup and rollforward recovery of transaction logs, for the following DB2 configurations: Partitioned DB2 databases with the IBM DPF Multinode DB2 databases (on a single host or across multiple hosts) Clustered DB2 databases (with or without failover support) Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems, provides details on the supported DPF configurations and procedures for the following: Configuring and performing manual and scheduled backups in supported DPF environments. Restoring DB2 DPF backups. The NMDA software does not support probe-based (event-based) backups in DB2 DPF environments. 34 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features DB2 history pruning The NMDA software supports the synchronous removal of snapshot backup entries from the DB2 history file when the corresponding entries expire and are removed in the NetWorker indexes. For regular backups, the backup entries for databases or tablespaces may be deleted from both the DB2 server and NetWorker server with the db2 prune command. Deleting backup entries may be necessary if the NetWorker index and DB2 history files become excessively large and the retention period is high. Delete DB2 backups from the DB2 server and NetWorker server on page 135 provides details. Note: The db2 prune command is not supported for deleting snapshot backups. Delete DB2 snapshots on page 331 provides details. Configuring DB2 PowerSnap backups on page 326 includes configuration details for the synchronous removal ( pruning ) of snapshot entries from the DB2 history file when the entries expire and are removed from the NetWorker indexes. DB2 transaction log backups The NMDA software supports DB2 backups of transaction logs and rollforward recovery with the DB2 transaction logs. The DB2 transaction logs keep records of changes made to DB2 databases between full backups. DB2 software provides two types of transaction logging: Circular logging is the default behavior when a new DB2 database is created. With this type of logging, the transaction logs are deleted with each full backup and only full backups may be restored. Only full, offline backups of databases are allowed. This method is not used with any NMDA operations. Archive logging is used specifically for online backups and rollforward recovery. With this type of logging, the transaction logs are retained as archive logs. This allows a database or tablespace to be restored to a specific point in time by rolling forward through the transaction logs in sequence until the specified point. DB2-specific I18N support Internationalization (I18N) on page 31 provides general information on I18N support with the NMDA software. When NMDA I18N support is set up as described in Configuring I18N support on page 78, NMDA supports non-ascii data in the following DB2-specific items: Filenames and pathnames in the NSR_DR_FILE_LIST parameter in the NMDA configuration file DB2 parameters specified in db2 commands, as documented and supported by DB2 Strings passed as command line options to the nsrdb2rlog(.exe) command DB2-specific NMDA features 35

Overview of Product Software and Features Informix-specific NMDA features The following sections provide details on product features that are specific to the Informix backup and restore operations performed with the NMDA software. Full and incremental Informix backups NMDA supports all the Informix backup levels that the IDS ON-Bar utility supports: Level 0 backup An Informix level 0 backup is a full backup, which includes all the (full) records in the selected dbspaces. This is the only type of Informix backup that allows a complete restore without performing any recovery steps, such as applying logs and incremental backups. Level 1 backup An Informix level 1 backup is an incremental backup, which backs up the (incremental) records that have changed since the last level 0 backup in the selected dbspaces. Level 2 backup An Informix level 2 backup backs up the records that have changed since the last level 1 backup in the selected dbspaces. Logical log backups NMDA supports the following types of IDS logical log backups: Automatic, continous logical log backups (recommended) Manual logical log backups To ensure that ON-Bar automatically backs up the IDS logical logs as they become full, modify the automatic log backup script, log_full.sh (UNIX) or log_full.bat (Windows) on the IDS machine to include the following lines: For UNIX: NSR_LOG_VOLUME_POOL=NetWorker_volume_pool NSR_SERVER = NetWorker_server_name export NSR_LOG_VOLUME_POOL export NSR_SERVER For Windows: set NSR_LOG_VOLUME_POOL=NetWorker_volume_pool set NSR_SERVER = NetWorker_server_name You can create a default volume pool for logical logs after the NMDA installation on the IDS machine. To have NMDA back up the logical logs to this default pool, set NSR_LOG_VOLUME_POOL to the volume pool name. Alternatively, set NSR_LOG_VOLUME_POOL to the name of a customized volume pool for the logical logs. The Informix ALARMPROGRAM configuration option can be used to start the backups on demand when the logical logs fill. After a log file is successfully backed up, ON-Bar closes the file, frees the space used by the file, and opens a new file for transaction logging. A logical log backup is always performed as a level full (ON-Bar level 0) backup. 36 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features! IMPORTANT For continuous log backups, Informix recommends dedicating a backup device to the logical log backup process. This ensures that a device on the backup server is always available to receive the logical log data. Informix-specific I18N support Internationalization (I18N) on page 31 provides general information on I18N support with the NMDA software. When NMDA I18N support is set up as described in Configuring I18N support on page 78, NMDA supports non-ascii data in the following Informix-specific items: Filenames and pathnames in the following parameters in the NMDA configuration file: INFORMIXDIR INFORMIXSQLHOSTS NSR_DR_FILE_LIST ONCONFIG Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters and configuration file. Command line options to onbar commands, as documented and supported by Informix Informix-specific NMDA features 37

Overview of Product Software and Features Lotus-specific NMDA features The following sections provide details on product features that are specific to the Lotus Domino and Notes backup and restore operations performed with the NMDA software. Files backed up during Lotus backups The NMDA software considers.nsf,.ntf, and.box files to be Lotus databases. The software backs up these files by using the Domino Backup application programming interface (API) for databases. The NMDA software considers.ncf,.njf,.dic,.dsk,.id, and notes.ini files to be normal files and backs up these files at the file system level. The NMDA software can also be used to back up any other files that exist in a Lotus directory, such as.gif,.html, and.doc files. Full and incremental Lotus backups The NMDA software supports full and incremental backups of Lotus data: Full backup Backs up the specified database files, regardless of whether or not they have changed since the last backup operation. If Lotus transactional logging is enabled (and set to archive mode), the logs are not backed up unless specifically requested by a user through the configuration parameter NSR_BACKUP_LOGS_MODE. This is the default backup configuration. Incremental backup Backs up only the specified database files that have changed since the previous backup. The behavior of an incremental backup is based on the settings for Lotus transactional logging on the Domino server: If Lotus transactional logging is enabled and set to archive mode, then an incremental backup will back up transaction logs, and any database files that are not logged and have changed since the last full backup. If Lotus transactional logging is enabled and the database instance ID (DBIID) property has changed since the last backup of the database, then a full backup of the database is automatically performed before the logs are backed up. If Lotus transactional logging is disabled (or enabled but not set to archive mode), then an incremental backup backs up only the database files that have changed since the last backup. Backups of Lotus database or directory links By default during Lotus backups, the NMDA software follows directory and database links when it forms the file list for backup. NMDA backs up both the Lotus link files and the data files or directories that the link files point to. To prevent NMDA from following the directory and database links, ensure that the following parameter is set through the wizard or in the NMDA configuration file: NSR_FOLLOW_LINKS = FALSE If a database link, link.nsf, or directory link, link.dir, has a bad reference (either the destination database or directory does not exist or cannot be opened properly), NMDA cannot determine whether the file is a link or an actual database or directory. 38 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features In this case, the link is not backed up because NMDA does not know whether to back it up as a database, directory, or regular operating system file. The backup fails unless the parameter NSR_SKIPDBERRORS is set to TRUE in the NMDA configuration file. Lotus DAOS backups and restores The NMDA software supports backups and restores of the attachments managed by the Domino Attachment Object Service (DAOS), supported by Domino 8.5 and later. You can configure a manual or scheduled NMDA backup to back up the DAOS base directory, separate DAOS subdirectories, or individual DAOS objects after the Domino database data is backed up. DAOS filenames end in.nlo; the DAOS files are called NLO files by IBM. The appropriate IBM documentation provides details on the features and setup of DAOS directories and NLO files. Configuring Lotus DAOS backups on page 100 provides details on how to configure backups of Domino with DAOS enabled. Lotus data recovery on page 182 provides details on how to properly restore the databases that contain links to missing DAOS files. Types of Lotus restores The NMDA software supports the following types of restore methods for Lotus data: Database-level (file-level) restore Restores the databases associated with a Domino server. Document-level restore Restores modified or deleted Notes documents in a single database, whether the database is logged or not. You can perform document-level recovery of deleted Notes documents in the local database through the nsrdocrc command-line program. On Windows only, you can perform document-level recovery of modified and deleted Notes documents in either the local Notes or Domino database or a remote Domino database through the Lotus Notes client GUI. The behavior of a recovery operation is based on the settings for Lotus transactional logging on the Domino server: If Lotus transactional logging is enabled, a database or document can be recovered to any point in time, provided the transaction logs for that time period are available. If Lotus transactional logging is disabled, a database or document can be restored to the time of the last backup only. NetWorker User for Lotus program On Windows only, the NetWorker User for Lotus graphical user interface program (nwbml.exe) is installed with the NMDA software. The NetWorker User for Lotus program provides a graphical interface for configuring and performing backup and recovery operations, including directed recovery of Lotus database files. Lotus-specific NMDA features 39

Overview of Product Software and Features Table 2 on page 40 describes the toolbar buttons in the main window of the NetWorker User for Lotus program. Table 2 NetWorker User for Lotus toolbar buttons Button Operation Description Backup Displays the Backup window for configuring and running backups. Recover Displays the Recover window for configuring and running recoveries. Select NetWorker Server Displays the Change Server dialog box for connecting to a different NetWorker server. The following chapters provide more information on how to use the NetWorker User for Lotus program for backups and restores: Chapter 3, Backup Procedures Chapter 4, Data Restore and Recovery Lotus-specific I18N support Internationalization (I18N) on page 31 provides general information on I18N support with the NMDA software. When NMDA I18N support is set up as described in Configuring I18N support on page 78: NMDA supports non-ascii data in settings of the following Lotus-specific parameters in the NMDA configuration file: Notes_ExecDirectory NSR_BACKUP_PATHS NSR_CATALOGFILE NSR_EXCLUDE_FILE NSR_LOG_DIR NSR_LOTUS_DATA_DIR NSR_RELOCATION_DEST NSR_RESOURCE_DIR PATH Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters and configuration file. NMDA supports non-ascii data in the REMOTE_RECOVCMD environment variable that is used for Lotus remote recovery, as described in How to configure a directed recovery on page 196. Partitioned Domino servers The NMDA software supports the backup and recovery of partitioned Domino servers. 40 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Partitioned Domino servers on page 280 provides details on how to perform manual or scheduled backups, and recovery operations of partitioned Domino servers. Disaster recovery of partitioned Domino servers on page 237 provides details on how to perform disaster recovery of partitioned Domino servers. Lotus-specific NMDA features 41

Overview of Product Software and Features Oracle-specific NMDA features The following sections provide details on product features that are specific to the Oracle Server backup and restore operations performed with the NMDA software. Full and incremental Oracle backups The NMDA software supports full or incremental backups of Oracle data: 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. Note: A full backup cannot be the parent of a subsequent incremental backup. Incremental backups cannot be dependent on a stand-alone full backup. 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. Note: 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. Archived redo log backups 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. Backing up all archived logs from each node on page 271 provides a sample script to back up the archived redo log files in an Oracle Real Application Cluster (RAC) system. The appropriate Oracle backup and recovery documentation provides more information on setting up and running archived redo log backups. 42 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Control file autobackup RMAN performs a control file autobackup after each RMAN backup command if the control file autobackup has been enabled. 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 /NMDA_%f/ If the control file autobackup is set to on and the RMAN backup is performed with NMDA, the control file autobackup will also be performed. Note: Oracle also supports autobackup of the current server parameter file together with control file autobackup. Automatic channel allocation 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 NMDA 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 NMDA. 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 NMDA backup. Do not use the send command or option to set the NSR* parameters for automatic channels if you plan to use scheduled backups. The following tables lists all the NSR* parameters and their requirements for Oracle operations: Table 28 on page 350 Table 32 on page 369 Example 1 Using the configure channel command with parms option for automatic channels Automatic channels are configured for NMDA backups with the NetWorker data volume pool called Oracle by typing the following configure channel...parms... command: configure channel device type sbt_tape parms ENV=(NSR_DATA_VOLUME_POOL=Oracle) This command sets the default parameters for all the automatic channels. Oracle-specific NMDA features 43

Overview of Product Software and Features Example 2 Specifying parameter values per automatic channel Specific NSR* parameter values can be set for different channels (for example, a separate setting of parameter NSR_DATA_VOLUME_POOL for each channel) by typing the configure channel n device type...parms... command, where n represents a channel number. A NetWorker data volume pool is specified for the second automatic channel by typing the following configure channel command: configure channel 2 device type sbt_tape parms ENV=(NSR_DATA_VOLUME_POOL=Oracle2) Backup and restore optimization 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. 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 NMDA backups and restores, run the crosscheck command regularly to synchronize the Recovery Catalog and NetWorker indexes. This ensures that backups which were 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 Oracle documentation provides details on the crosscheck command. 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. Backup copies! IMPORTANT If more than one RMAN channel is used for backup copies of an NMDA 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, NMDA does not support the use of RMAN backup copies commands during scheduled backups. NMDA supports backup copies with manual backups only. 44 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Use the RMAN commands for backup copies only during manual backups when the following parameters are set with the parms option, not with the send command or option: NSR_SERVER NSR_DATA_VOLUME_POOL NSR_DATA_VOLUME_POOL1 NSR_DATA_VOLUME_POOL2 NSR_DATA_VOLUME_POOL3 The set duplex command is deprecated. It is 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 NMDA 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 383 provides more information on the command and setup of NetWorker pools for each copy. 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 NMDA. For example, specify persistent settings for duplex copies of datafiles and archived redo logs (respectively) in NMDA 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=nmda1, NSR_DATA_VOLUME_POOL1=nmda2, NSR_DATA_VOLUME_POOL2=nmda3, NSR_DATA_VOLUME_POOL3=nmda4) ; backup format '%d_%u' tag tag_name (tablespace 'SYSTEM' ); release channel ch1; } Oracle-specific NMDA features 45

Overview of Product Software and Features 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; configure channel device type sbt_tape parms ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmda1, NSR_DATA_VOLUME_POOL1=nmda2, NSR_DATA_VOLUME_POOL2=nmda3, NSR_DATA_VOLUME_POOL3=nmda4) ; 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'); } Backup of backup sets RMAN supports the backup of backup sets. If Oracle data has been backed up with device type disk, NMDA 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 Oracle Data Guard support NMDA 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 does the following: Transfers this redo data to the standby sites. Applies the redo data to the standby databases, synchronizing the standby databases 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 can be used to recover the primary or 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. 46 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features To configure NMDA 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 NMDA 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, add the hostname of the physical standby host in the Remote Access attribute if you set NSR_CLIENT to the primary database hostname in the step 4. 4. Create an RMAN script for the primary database and the standby database. Set 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. Oracle RAC backups and restores The NMDA software supports backups and restores of cluster and Real Application Cluster (RAC) systems for high availability and parallelism. 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, NMDA enables Oracle backups on either a single node or several nodes of the RAC system. A parallel Oracle backup uses Oracle instances that run in parallel on multiple nodes of the cluster. NMDA 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, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems, provides details on cluster and RAC systems and how to configure the systems for Oracle backup and restore operations that use the NMDA software. Oracle-specific I18N support Internationalization (I18N) on page 31 provides general information on I18N support with the NMDA software. When NMDA I18N support is set up as described in Configuring I18N support on page 78, NMDA supports non-ascii data in the following Oracle-specific items: Filenames and pathnames in parameters in the NMDA configuration file: NSR_ORACLECAT_LOG_FILE NSR_RMAN_ARGUMENTS Pathnames of RMAN scripts Strings passed as command line options to the commands nsroraadmin(.exe), nsrorainfo(.exe), and nsroraclecat(.exe) Oracle-specific NMDA features 47

Overview of Product Software and Features The format string of an RMAN backup command (unless the nsrdaadmin command is used for conversion of a legacy backup configuration on Windows) The tag string of an 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. Support of non-ascii values for ORACLE_SID and TNS_ADMIN is dependent on the Oracle software. 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 Policy uniformity If policy uniformity is enabled, NMDA automatically enforces the uniformity of the browse and retention policies between all the dependent save sets in a scheduled Oracle 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 NMDA performs an incremental Oracle 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 NMDA program nsrdasv changes the policies of all save sets in the cycle to match the longest policy of the new incremental save sets. NMDA 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 NMDA software does not enforce policy uniformity for an Oracle manual backup, except when a subsequent scheduled backup is dependent on the manual backup. 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 111 provides information on how to configure policy uniformity for NMDA backups. Recovery configuration wizard The NMDA software provides support for a recovery configuration wizard that generates RMAN restore and recovery scripts to do the following: Restore Oracle data to the original host. Create a duplicate Oracle database on a local or remote host. Recovery configuration wizard (Oracle only) on page 206 provides details on using the recovery configuration wizard. 48 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Restartable 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 two 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 any datafile to determine if it requires backup. The appropriate Oracle backup and recovery documentation provides more information. The following sections provide more information on how to cancel NMDA backups: Monitor a manual backup on page 153 Cancel a scheduled backup on page 157 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. NMDA supports the Oracle retention policy with some restrictions. The NetWorker server has its own browse and retention policies to specify how long data is available for recovery. The NetWorker 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. To avoid conflicts, perform either of the following: If you want to use only the NetWorker server policy, disable the Oracle retention 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 so 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. Customize a Client resource with NMC on page 89 provides more information on how to set NetWorker policies for NMDA backups.! IMPORTANT Run the crosscheck command on the NMDA backups before running a report obsolete, or delete obsolete backups of the device type sbt_tape. This ensures that backups which the NetWorker server considers to be expired are flagged as expired Oracle-specific NMDA features 49

Overview of Product Software and Features 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 If NMDA save set bundling is configured, NMDA automatically creates a save set bundle for each scheduled backup cycle of an Oracle database object. NMDA groups 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. All subsequent incremental backups that are dependent on the full backup. Full and incremental Oracle backups on page 42 provides details on NMDA support of full and incremental Oracle backups. Note: NMDA does not support save set bundling for PowerSnap snapshot backups. NMDA performs save set bundling for regular Oracle backups only. During staging operations with a supported NetWorker server release 7.4 or later, if the staging criteria determine that a particular NMDA 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 EMC NetWorker Administration Guide provides details on how to work with staging policies and perform automatic and manual staging operations through the NetWorker server. NMDA scheduled backups and save set bundling on page 51 describes NMDA save set bundling during regular scheduled backups, and how to configure save set bundling. If policy uniformity is configured, NMDA 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. This ensures that incremental backups do not persist after the backups they depend on have expired. Other Oracle features on page 54 provides more information on how policy uniformity relates to save set bundling. Save set bundling and policy uniformity can be enabled and disabled independently. 50 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features NMDA 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 NMDA scheduled backups. Both are performed to prepare for staging operations with NetWorker server 7.4 and later. Configure save set bundling on page 110 provides information on how to configure save set bundling for NMDA scheduled backups. RMAN backup sets and NMDA save sets NMDA save set bundling is performed at the backup set level. An NMDA 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 NMDA 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 NMDA 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 NMDA save sets from a backup set are placed into the same save set bundle.) At the end of a full or level 0 scheduled backup, the NMDA 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, NMDA 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. Oracle-specific NMDA features 51

Overview of Product Software and Features 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 NMDA cannot find a preceding dependent backup in any existing bundles, NMDA 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 NMDA 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 NMDA debug file. How the nsrdasv program performs save set bundling The NMDA program nsrdasv automatically places save sets into a save set bundle at the end of a scheduled backup. Configure save set bundling on page 110 provides more details on the nwora.res file, and the requirements of save set bundling. To perform save set bundling, the nsrdasv 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 NMDA configuration file to search the nwora.res file for the NSR_ORACLE_CONNECT_FILE parameter, and uses the connection strings from the specified connection file. After connecting to the Oracle database, the nsrdasv program obtains all the required information about the backups by using the V$ views, which use the Oracle control file. 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 nsrdasv 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. 52 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features The name that the nsrdasv program assigns to a save set bundle is a number that corresponds to the save time of the oldest save set in the bundle. NMDA 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 53. Example 5 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 NMDA save set bundling, consider the following NetWorker staging restrictions: The NetWorker server 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 7 on page 54 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 NMDA backup cycle to be staged before the cycle is complete. For example, if a one-week NMDA 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 NMDA 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 EMC NetWorker Administration Guide provides details on how to work with staging policies and perform automatic and manual staging operations through the NetWorker server. Save set bundling information in the media database The NMDA software stores information about each save set bundle in the NetWorker media database. Importance of backups on page 23 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" Oracle-specific NMDA features 53

Overview of Product Software and Features 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 EMC 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 6 Save set bundle join This example describes a method, known as a save set bundle join, that combines existing bundles into a new save set bundle. 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, NMDA combines all three backups into the same save set bundle. If the original file A backup has the oldest backup time, NMDA places the new backup set (from the level 1 backup) into the save set bundle of the (level 0) file A backup. NMDA then moves the original (level 0) file B backup into the save set bundle with the other two backups. Example 7 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. Example 8 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. Other Oracle features This section describes additional supported features of the Oracle Server software. The NMDA software supports the Oracle releases on specific platforms, as outlined in the EMC Information Protection Software Compatibility Guide on the Powerlink website. 54 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features The EMC NetWorker Module for Databases and Applications Release Notes describes known NMDA limitations related to specific Oracle releases. Examples of the Oracle RMAN features that NMDA 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). Replication Manager snapshot operations with Oracle ASM on page 332 provides details on how to use EMC Replication Manager with NMDA to perform snapshot backups and restores of Oracle ASM data. Management of backup duration and throttling. Backups and restores of data that reside 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 NMDA, 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 NMDA 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; NMDA supports channel backup failover and backup piece restore failover. 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. Oracle-specific NMDA features 55

Overview of Product Software and Features 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 NMDA 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. Oracle11g specific features NMDA 1.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 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 Backup of read-only transportable tablespaces Oracle Enterprise Manager enhancements, with new interfaces for the Data Recovery Advisor Oracle Globalization Support enhancements Oracle11gR2 specific features on page 56 describes features specific to Oracle11gR2 that NMDA supports. To enable NMDA 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 57 and Archival backup feature on page 57. The appropriate Oracle documentation provides more information on the Oracle11g features. Oracle11gR2 specific features NMDA 1.0 supports the following major features that are specific to Oracle11gR2: Enhanced DUPLICATE command that can duplicate a database without connecting to a target database, by using the NMDA backups of the target database (connections to a catalog and auxiliary database are required) 56 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Tablespace Point-in-Time Recovery (TSPITR) enhancement that recovers a dropped tablespace and recovers to a point in time before the tablespace is brought online Advanced Compression Option Note: Do not enable both Oracle and NetWorker compression for NMDA Oracle backups. Oracle Grid infrastructure for either a standalone database or a RAC Oracle ASM Dynamic Volume Manager (Oracle ADVM), a new feature of Oracle ASM that provides volume management services and a standard disk device driver interface to clients Policy-managed RAC databases 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 NMDA 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 NMDA parameters may also be specified for the automatic channel configuration. To enable the use of Data Recovery Advisor with Oracle11g and NMDA: If automatic channels have not been configured for NMDA, use the following commands to ensure the basic automatic channel configuration: configure channel device type sbt_tape parms ENV=(NSR_SERVER=NetWorker_server_name, NSR_CLIENT=NMDA_client_name) ; configure channel device type 'sbt_tape' parallelism number_of_restore_channels; If automatic channels are already configured for NMDA, 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 NMDA: 1. Configure an Archive 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. Oracle-specific NMDA features 57

Overview of Product Software and Features 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 NMDA. The EMC NetWorker Administration Guide provides more information on how to configure resources and specify pool selection criteria through the NetWorker server. 58 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features Sybase-specific NMDA features The following sections provide details on product features that are specific to the Sybase ASE backup and restore operations performed with the NMDA software. Full and incremental Sybase backups A full Sybase backup sends the dump database command to Sybase, which backs up the entire database, including both the data and transaction log. If incremental backups are not allowed for a database, the inactive portion of the transaction log is truncated. An incremental Sybase backup sends the dump transaction command to Sybase, which backs up the transaction log and truncates the inactive portion of the transaction log. An incremental backup is not allowed under the following conditions: The database and transaction logs are on the same device. The select into/bulk copy option is selected and the database contains unlogged data. The truncate log on checkpoint option is selected. A full backup has never been performed. When an incremental Sybase backup is not allowed, the backup is promoted to full if the NSR_PROMOTE_FULL parameter is set to TRUE in the NMDA configuration file. After the backup, the inactive portion of the database log is truncated. Password-protected database backup and restore The NMDA software provides full support for password-protected Sybase database backup and restore. If the Sybase data is password-protected at the time of backup, the same password must be provided to restore the backed-up data. If the password does not match the one used at the time of backup, then the restore fails and an appropriate error message is added to the log file. The password must be between 6 and 30 characters long. A password with less than 6 characters or more than 30 characters is not acceptable. The NMDA software does not continue with the backup if an invalid password is provided. Use one of the following methods to password-protect the Sybase data: Use the NSR_ASE_PASSWORD parameter in the NMDA configuration file to specify the password for the backup. The password is added with the passwd= clause to the Sybase dump command used for the backup. If the parameter value is left blank, then the backup data is not password-protected. The password set with NSR_ASE_PASSWORD is stored in unencrypted form in the configuration file. Use the -r option with the nsrsybrc restore command to specify the password for the restore: nsrsybrc -r password Sybase-specific NMDA features 59

Overview of Product Software and Features Database backup and restore verification The NMDA software provides support for Sybase database backup and restore verification. NMDA supports verification at the header or a full verification. Use one of the following methods to specify the verification level: Use the NSR_ASE_VERIFY parameter in the NMDA configuration file to specify the backup verification level. Set the parameter to one of the following values: header Specifies to verify the page header information only. full Specifies to verify both the header information and rows structure (full verification of the backup). For example, the following NSR_ASE_VERIFY setting specifies to perform a full verification of the backup: NSR_ASE_VERIFY=full Use the -V option with the nsrsybrc restore command to specify the restore verification level: nsrsybrc -V [header full verifyonly] where: header Specifies to verify the page header information only. full Specifies to verify both the header information and rows structure (full verification of the backup). verifyonly Specifies to verify only the restore command options that are provided. If you do not specify a verification value, then no verification is carried out and a message is added to the log file. Exclusion of multiple user-defined temporary databases from backup The Sybase server supports multiple user-defined temporary databases. In addition to the system-defined temporary database, tempdb, you can create user-defined temporary databases. These temporary databases are attached with a specific user login or a database. Creating temporary databases enhances the performance of a database where many transactions take place at a time. Also, creating temporary databases prevents the critical applications from failing when the system-defined database fails. The NMDA software excludes user-defined temporary databases during backup. During a backup, the NMDA software communicates with the Sybase server to determine whether a database is a user-defined temporary database (to exclude from the backup) or a normal database. If the NSR_DEBUG_LEVEL parameter is set to a nonzero value when NMDA excludes a user-defined temporary database from the backup, then NMDA writes the following message to the debug log file: User-defined temporary database database_name excluded from backup where database_name is the name of the user-defined temporary database. 60 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features NetWorker User for Sybase program On Windows machines only, the NetWorker User for Sybase graphical user interface program (nwbms.exe) is installed with the NMDA software. The NetWorker User for Sybase program provides a graphical interface for configuring and performing Sybase backup and recovery operations. Table 2 on page 40 describes the toolbar buttons in the main window of the NetWorker User for Sybase program. Table 3 NetWorker User for Sybase toolbar buttons Button Operation Description Backup Displays the Backup window for configuring and running backups. Recover Displays the Recover window for configuring and running recoveries. Select NetWorker Server Displays the Change Server dialog box for connecting to a different NetWorker server. The following chapters provide more information on how to use the NetWorker User for Sybase program for backups and restores: Chapter 3, Backup Procedures Chapter 4, Data Restore and Recovery Sybase ASE Cluster Edition The NMDA software supports backups and restores of Sybase ASE Cluster Edition systems for high availability and parallelism. A Sybase ASE Cluster Edition system enables multiple ASE server instances across multiples nodes to access the same Sybase database simultaneously. ASE Cluster Edition is a shared-disk cluster implementation of ASE 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 ASE Cluster Edition and the associated cluster system are properly configured, NMDA enables Sybase backups on either a single node or several nodes of the ASE Cluster Edition system. A parallel Sybase backup uses Sybase instances running in parallel on multiple nodes of the cluster. NMDA software supports restores of the Sybase data to any physical node in the cluster, regardless of which physical node originally performed the backup. Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems, provides details on Sybase ASE Cluster Edition systems, and how to configure the systems for Sybase backup and restore operations with the NMDA software. Sybase-specific NMDA features 61

Overview of Product Software and Features Sybase-specific I18N support Internationalization (I18N) on page 31 provides general information on I18N support with the NMDA software. When NMDA I18N support is set up as described in Configuring I18N support on page 78, NMDA supports non-ascii data in the following Sybase-specific items: Filenames and pathnames in the following parameters in the NMDA configuration file: NSR_ASE_PASSWORD NSR_BACKUP_PATHS SYBASE Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters and configuration file. Strings passed as command line options to the commands nsrsybcc(.exe) and nsrsybrc(.exe) 62 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features NMDA components Table 4 on page 63 lists the major software components that are installed on the NMDA client host during the NMDA installation. Unless specified otherwise, the files are located in the same directory as the NetWorker client software. Table 4 NMDA components (page 1 of 2) Component name libcommonssl.7.6.build#.so libnsrdb2.xx libnsrifmx.xx libxbsa.dll libnsrora.xx libnsrsyb.xx nmda_db2.cfg nmda_informix.cfg nmda_lotus.cfg nmda_oracle.cfg nmda_sybase.cfg nsrdaadmin(.exe) nsrdaprobe(.exe) nsrdasv(.exe) nsrdb2cat(.exe) nsrdb2ra(.exe) nsrlotusra(.exe) nsrorara(.exe) nsrdb2rlog(.exe) nsrdoclb.dll nsrdocrc(.exe) nsrlotus_remrecov(.bat) nsrnmodrpostcmd(.bat) Description Located in a subdirectory under /usr/lib/nsr or /opt/networker/lib on UNIX only. NMDA library that is required for communication with NetWorker. NMDA library that interacts with the DB2 backup and restore utilities and the NetWorker server to perform backup, inquiry, and restore processes for DB2 data. NMDA libraries that interact with the Informix backup and restore utilities and the NetWorker server to perform backup, inquiry, and restore processes for Informix data. Located in the directory /usr/lib on UNIX only. Library (known as Media Management Library in Oracle documentation) that is loaded by an Oracle backup or restore process. NMDA library that interacts with the Sybase backup and restore utilities and the NetWorker server to perform backup, inquiry, and restore processes for Sybase data. Located in the directory /nsr/apps/config (UNIX) or NetWorker_install_path\apps\config (Windows). NMDA configuration file templates for DB2, Informix, Lotus, Oracle, or Sybase parameters that apply to nonwizard configurations only. Program that performs one of the following types of conversion: Conversion of the client-side configuration of another NetWorker module to an NMDA client-side configuration. A client-side configuration is created manually with NMC, without the backup configuration wizard. Conversion of the server-side configuration of another NetWorker module to an NMDA server-side configuration. A server-side configuration is created with the backup configuration wizard. Conversion of an NMDA client-side configuration to an NMDA server-side configuration. Program that probes for the number or size of generated logs as a condition that triggers a probe-based backup. Main NMDA program that invokes one of the following: A scheduled NMDA backup on a database or application server or client. A manual NMDA backup on a Lotus or Sybase server or client. Catalog synchronization program that prunes (removes) snapshot entries from the DB2 advanced copy services backup history as NetWorker removes expired snapshot entries from its index. Programs that perform operations for the NMDA configuration wizard on a local or remote DB2, Lotus, or Oracle host. Restore utility that copies DB2 transaction logs stored on the NetWorker server to a local file, and uses the logs to perform rollforward recovery. On Windows only. Library for document-level recovery of Lotus data. Program for document-level recovery of Lotus data. Script that enables NMDA to perform a remote recovery from the NetWorker User for Lotus program on Windows. Sample postcommand script that can be customized to back up specific files at the end of a scheduled backup, in preparation for disaster recovery. NMDA components 63

Overview of Product Software and Features Table 4 NMDA components (page 2 of 2) Component name nsrnotesrc(.exe) nsroraadmin(.exe) nsroraclecat(.exe) nsrorainfo(.exe) nsrsbtcn.exe orasbt.dll nsrsybcc(.exe) nsrsybrc(.exe) nwbml.dll nwbml.exe nwbms.dll nwbms.exe Description Program for recovery of Lotus database files. Program that is used to create resource settings in the NWORA resource file for an Oracle backup configuration. Not available on Linux Itanium, Solaris AMD64/EM64T, or Windows Itanium (platforms that do not support PowerSnap backups). Program that is used to remove RMAN catalog entries during automatic catalog synchronization for PowerSnap backups of Oracle data. Program that determines the NetWorker volumes required to restore specified Oracle backup pieces from NMDA backups. On Windows only. The orasbt.dll file is the main NMDA library (known as Media Management Library in Oracle documentation) that is loaded by the Oracle backup or restore thread. The orasbt.dll library uses nsrsbtcn.exe to perform any corresponding NetWorker operations. Program for database consistency check of Sybase database files. Program for recovery of Sybase database files. On Windows only. Library and program for the NetWorker User for Lotus. On Windows only. Library and program for the NetWorker User for Sybase. 64 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features NMDA backup and restore processes The following sections describe the processes involved in regular (not snapshot) NMDA backups and restores. Chapter 8, Snapshot Backups and Restores, provides information on the processes involved in snapshot backups and restores. Regular scheduled backup processes 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, which sends information back to the savegrp program. 3. The savegrp program contacts the nsrexecd service to start the backup. 4. For each client in the backup group and each of the client s save sets, the nsrexecd service starts the nsrdasv program, and the following steps occur, depending on the type of database or application backup: For a DB2, Informix, Oracle, or Sybase backup: a. The nsrdasv program communicates with the appropriate database or backup server to start a backup session through one of the following: DB2 API Informix onbar Oracle RMAN executables Sybase Open Client/Server API b. Each backup session, created by the database or backup server, loads the NMDA shared library for the specific database to perform the backup. Note: This step and the following steps also occur during a manual backup. For a Lotus backup: a. The nsrdasv program invokes another nsrdasv process called the parent process. b. The parent nsrdasv process determines the Lotus Domino or Notes files that require backup and starts the child nsrdasv processes to back up the files. The number of processes spawned depends on the number of files to be backed up and the specified parallelism. Note: This step and the following steps also occur during a manual backup. 5. The NMDA shared library (for DB2, Informix, Oracle, or Sybase) or the child nsrdasv process (for Lotus) performs the following: Contacts the NetWorker server service, nsrd, to obtain the required authorization. Sends the backup data to the NetWorker media service, nsrmmd, to store on the appropriate backup volumes. NMDA backup and restore processes 65

Overview of Product Software and Features 6. The NetWorker online indexes store the tracking information: The nsrmmd service records tracking information in the NetWorker media database by using the nsrmmdbd service. The backup session sends tracking information to the NetWorker client file index by using the nsrindexd service. Note: At the end of a scheduled backup, the savegrp program also automatically backs up the NetWorker server bootstrap and the corresponding client file indexes. The bootstrap and client indexes are not automatically backed up at the end of a manual NMDA backup. Figure 1 on page 66 shows how the database or application server, NetWorker server, and NMDA processes interact during a regular scheduled NMDA backup. Database or application server (NetWorker client) Client file index NetWorker server Media database Storage medium tracking information Database or applicationspecific backup components nsrindexd data nsrmmdbd nsrmmd savefs nsrdasv interprocess communication nsrexecd savegrp nsrd GEN-001176 Figure 1 Regular scheduled NMDA backup Regular restore processes A regular restore includes the following interactions, depending on the type of database or application restore. For a DB2, Informix, Oracle, or Sybase restore 1. A user starts the restore by running the proper database or NMDA restore utility through one of the following: DB2 command interface Informix onbar command Oracle RMAN interface Sybase NMDA nsrsybrc command or Sybase load command 66 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Overview of Product Software and Features 2. The restore session loads the NMDA shared library for the proper database, which performs the following: a. Translates the object names requested for restore into a format that the NetWorker server understands. b. Forwards the restore object names to the NetWorker service, nsrindexd, which verifies that the objects exist in the client file index. 3. The restore session works with the NetWorker server services to mount the volumes required for the restore and read the data from the volumes. 4. The restore session passes the data to the database or backup server, which writes the data to the disk. For a Lotus restore 1. A user starts the restore by running the NMDA nsrnotesrc binary program. 2. The nsrnotesrc process performs the following: a. Queries the NetWorker server to obtain a list of Domino files to recover, based on options specified by the user. b. Spawns child nsrnotesrc processes to recover Domino data. The number of processes spawned depends on the number of Domino files to be recovered and the specified parallelism. c. When the child processes finish the recovery successfully, restores the Domino logs, if requested by the Domino server. 3. Each child nsrnotesrc process performs the following for the subset of files that it restores: a. Works with the NetWorker server services to mount the volumes required for the restore and read the data from the volumes. b. Writes the data to the disk. NMDA backup and restore processes 67

Overview of Product Software and Features 68 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

2 Software Configuration This chapter includes the following major sections: Software configuration roadmap... 70 Verifying the database or application server configuration... 72 Verifying the basic resource configurations... 72 Configuring I18N support... 78 Converting a legacy configuration with the nsrdaadmin command... 80 Performing server-side configuration with the NMC wizard... 81 Performing client-side configuration with the NMC nonwizard method... 87 Configuring a deduplication backup... 119 Configuring a probe-based backup... 125 Software Configuration 69

Software Configuration Software configuration roadmap The database or application server and the NetWorker server must be properly configured before the NetWorker Module for Databases and Applications (NMDA) software can be used for backup and restore operations. Before configuring these servers, ensure the following: The NetWorker software is installed on the required hosts according to the instructions in the EMC NetWorker Installation Guide. The NMDA software is installed on the required host according to the instructions in the EMC NetWorker Module for Databases and Applications Installation Guide. To perform the required configuration procedures, use either of the following through NetWorker Management Console (NMC): Server-side configuration with the configuration wizard Client-side configuration with NMC nonwizard method To configure a regular backup, use the instructions in the following sections that apply to the particular environment: 1. Verify the database or application server configuration, according to Verifying the database or application server configuration on page 72. 2. Verify that the basic NetWorker resources are properly configured, according to Verifying the basic resource configurations on page 72. 3. If required, configure internationalization (I18N) support, according to Configuring I18N support on page 78. 4. If you have upgraded from a legacy NetWorker module to NMDA and want to keep the existing scheduled backup configuration, use the nsrdaadmin command to convert that configuration to the NMDA configuration, according to Converting a legacy configuration with the nsrdaadmin command on page 80. The legacy NetWorker modules include the following: NetWorker Module for DB2 (NMDB2) NetWorker Module for Informix (NMI) NetWorker Module for Lotus (NML) NetWorker Module for Oracle (NMO) NetWorker Module for Sybase (NMS) 5. Complete the backup configuration by using either the wizard or the NMC nonwizard method: Performing server-side configuration with the NMC wizard on page 81 Performing client-side configuration with the NMC nonwizard method on page 87 Ensure that you confirm any additional configurations required for a specific database or application backup: Configuring DB2 backups on page 93 Configuring Informix backups on page 97 Configuring Lotus backups on page 99 Configuring Oracle backups on page 103 Configuring Sybase backups on page 112 70 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The following sections provide additional information on configuring a deduplication backup or probe-based backup: Configuring a deduplication backup on page 119 Configuring a probe-based backup on page 125 Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems, provides information on configuring any required cluster systems. Software configuration roadmap 71

Software Configuration Verifying the database or application server configuration The database or application server system must be properly installed and configured before the NetWorker server and NMDA software is configured. Ensure that the database or application server software is installed and configured, along with any required target databases, networking software, and other components. Components must be installed and configured according to the appropriate DB2, Informix, Lotus, Oracle, or Sybase server documentation. Verifying the basic resource configurations Verify that the basic NetWorker resources are configured on the NetWorker server, according to the information in the following sections. These resources are required for all backup and restore operations. NetWorker Server resource 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 5 on page 72 describes the main NetWorker Server resource attributes. Verify that the attribute settings in the Server resource are valid for the NMDA backup environment. Modify the settings as required. Table 5 NetWorker Server resource attributes Attribute Name Parallelism Datazone pass phrase Description Specifies the hostname of the NetWorker server. 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. Specifies the key or pass phrase to use for AES encryption of data during an NMDA backup. The pass phrase is required to restore the data from the backup. NSR_AES_ENCRYPTION on page 350 provides more information. The NetWorker server online help and the EMC NetWorker Administration Guide provide more information on how to configure a NetWorker Server resource and its attributes. NetWorker user group privileges Certain NMDA operations require specific NetWorker privileges that are specified through the User Group resource. The NetWorker server includes an access control feature that 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. 72 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The NetWorker server is installed with two preconfigured user groups: Administrators group 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 group 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. 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: Backup Local Data Monitor NetWorker Recover Local Data These default user group configurations are sufficient for NMDA backup and restore operations. 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 common NMDA operations, as described in Table 6 on page 73. The EMC NetWorker Administration Guide provides information on user groups and on setting user group privileges. Oracle-specific requirements for NetWorker user group privileges on page 107 provides additional details. Note: PowerSnap backups and restores of DB2 or Oracle data require the same privileges as regular backups and restores, plus the privileges required by the PowerSnap Module. The NetWorker PowerSnap Module documentation provides more information on the required privileges. Table 6 User group privileges for common NMDA operations (page 1 of 2) Operation Operating system user that performs operation Required user group privileges Deduplication backup or restore Conversion of a scheduled backup configuration with the nsrdaadmin command Regular manual backup Database user on the database or application server Root user, or a member of the Microsoft Windows Administrators group, on the database or application server Database user on the database or application server Backup Local Data Monitor NetWorker Recover Local Data (These privileges are set by default.) Configure NetWorker, and all its prerequisite privileges Backup Local Data Monitor NetWorker Recover Local Data (These privileges are set by default.) Verifying the basic resource configurations 73

Software Configuration Table 6 User group privileges for common NMDA operations (page 2 of 2) Operation Operating system user that performs operation Required user group privileges Regular scheduled backup Regular restore Database user on the database or application server Root user, or a member of the Microsoft Windows Administrators group, on the database or application server Database user on the database or application server Backup Local Data Monitor NetWorker Recover Local Data (These privileges are set by default.) Backup Local Data Monitor NetWorker (These privileges are set by default.) Recover Local Data (This privilege is set by default.) NetWorker Client resource Before the NMDA software can be used for backups or restores, a NetWorker Client resource must be exist for the NMDA client host. If the NetWorker server software is installed on the NMDA client host, a basic Client resource is created automatically for the NMDA client during the NetWorker installation. The Client resource must be customized for an NMDA backup. A basic NetWorker Client resource is required for running manual NMDA backups. If a Client resource does not yet exist for the NMDA host, configure the resource with NMC, and set only the following attributes for manual backups: Name Specifies the hostname of the NMDA client host. Aliases Specifies all known aliases for the system where the NMDA software is installed. If you use the configuration wizard, the wizard automatically creates the Client resource. If you do not use the configuration wizard, Customize a Client resource with NMC on page 89 provides details on how to customize a Client resource for scheduled backups by using the NMC nonwizard method (client-side configuration). The EMC NetWorker Administration Guide and NMC online help provide more information on how to create and modify Client resources. NetWorker Schedule resource The NetWorker Schedule resource is required for scheduled NMDA backups only. You can specify the schedule for an NMDA client backup by using either the backup configuration wizard (server-side configuration) or the NMC nonwizard method (client-side configuration). Set the backup schedule to one of the existing schedules provided by the Schedule resources on the NetWorker server. You must configure the required Schedule resource through NMC, as described in Configure a Schedule resource with NMC on page 88. A NetWorker Schedule resource provides a graphical calendar for configuring a backup schedule to specify the following: Days of the week to run scheduled backups Levels of scheduled backups 74 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The levels specified in the Schedule resource are interpreted differently for each supported type of database or application backup. Configure a Schedule resource with NMC on page 88 provides details on how the backup levels are interpreted. The EMC NetWorker Administration Guide provides more information on the features of a Schedule resource. NetWorker Device resources The NetWorker server uses a supported tape or disk storage device to do the following: Write data during an NMDA backup. Read data during an NMDA 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 EMC 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 EMC 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 Pool and Label Template resources The NetWorker server 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 databases and transaction 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 NMDA, 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. The label provides an automated method to identify the media assigned to a pool. NetWorker software uses pools of volumes and label templates to track where the data is on each volume. Note: If a customized volume pool is not specified for backup volumes, the NetWorker server routes data for an NMDA backup to the appropriate volume pool. Configure the required NetWorker Pool resources and corresponding Label Template resources by using the NMC program. The EMC NetWorker Administration Guide and NMC online help provide more information. Verifying the basic resource configurations 75

Software Configuration Setting the NSR_DATA_VOLUME_POOL parameter You can set the NSR_DATA_VOLUME_POOL parameter to send backup data to a specific pool: For DB2, Informix, Lotus, or Sybase backups, set the parameter in the NMDA configuration file. For Oracle backups, set the parameter in the RMAN backup script. Oracle-specific requirements for NSR_DATA_VOLUME_POOL on page 108 provides more information. To have a 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. Then that parameter s setting takes precedence over any pool associated with the scheduled backup group. If NSR_DATA_VOLUME_POOL is set 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 for a scheduled backup. Note: In the case of PowerSnap backups of DB2 or Oracle data, NSR_DATA_VOLUME_POOL 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 Configure the NetWorker Pool resources on page 296. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NSR_DATA_VOLUME_POOL parameter. Setting the NSR_LOG_VOLUME_POOL parameter You can set the NSR_LOG_VOLUME_POOL parameter to send transaction log backup data to a specific pool for DB2, Informix, or Sybase backups. The parameter must be set in the NMDA configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NSR_LOG_VOLUME_POOL parameter. Using NSR_LOG_VOLUME_POOL for incremental Sybase backups on page 76 provides special considerations for volumes pools used with incremental Sybase backups. Using NSR_LOG_VOLUME_POOL for incremental Sybase backups An NMDA Sybase backup creates a separate save set for the backup metadata. For example, an NMDA Sybase backup of the database SYBASE:/SERVER/sybdb produces two save sets: SYBASE:/SERVER/sybdb Contains the metadata for the backup. SYBASE:/SERVER/sybdb.1 Contains the actual data for the backup. During an incremental Sybase backup, NMDA backs up only the transaction log of each database. You can send the logs to a special log volume pool by setting the NSR_LOG_VOLUME_POOL parameter, as described in NSR_LOG_VOLUME_POOL on page 375. For example, an incremental backup of SYBASE:/SERVER/model produces the save set SYBASE:/SERVER/model.1 that contains the log data, which is backed up to the log pool specified by NSR_LOG_VOLUME_POOL. However, the metadata save set from the backup, SYBASE:/SERVER/model, is not backed up to the log pool. 76 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The metadata from an incremental Sybase backup is backed up to a regular (not log) volume pool, for example, as specified by NSR_DATA_VOLUME_POOL. Firewall support The NMDA software provides firewall support. The ports that the NMDA software uses for the firewall depend on the corresponding ports configured for the NetWorker server. To configure the firewall that the NMDA software uses, follow the firewall configuration instructions in the EMC NetWorker Administration Guide for the particular NetWorker server platform. Verifying the basic resource configurations 77

Software Configuration Configuring I18N support Internationalization (I18N) on page 31 describes the features of NMDA internationalization (I18N) support. To configure I18N support: 1. Ensure that you meet the Requirements for I18N support on page 78. 2. Follow the configuration steps in Configure I18N support on page 78. Requirements for I18N support Ensure that all of the following I18N requirements are met: The NMDA client host includes a supported internationalized version of the operating system, properly configured to operate in the non-english locale. The database or application software provides the required National Language Support (NLS) or globalization support. The database is configured with the required non-ascii character set. The appropriate DB2, Informix, Lotus, Oracle, or Sybase documentation provides details. Supported NetWorker software is installed: Internationalized NetWorker server software is installed, either on the NMDA 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 NMDA client. The EMC Information Protection Software Compatibility Guide on the Powerlink website provides details on the different languages supported, and the operating system and NetWorker version requirements for I18N support. The EMC NetWorker Installation Guide provides details on installation of the NetWorker software. For I18N support during PowerSnap snapshot operations, a supported release of the PowerSnap Module is installed and configured, as described in the EMC NetWorker Module for Databases and Applications Release Notes. The NetWorker documentation provides details on any other I18N requirements. Configure I18N support To configure I18N support on the NMDA client host on UNIX only: 1. Log in as the root user. 2. Shut down the NetWorker services. 3. Set the environment variable LC_ALL to the appropriate locale. 4. Restart the NetWorker services. For example, in a Japanese locale on Solaris, set LC_ALL as follows: # nsr_shutdown # export LC_ALL=JA_jp.eucJP # /etc/init.d/networker start 78 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The following sections provide additional configuration requirements for specific applications: Informix-specific requirements for I18N support on page 98 Oracle-specific requirements for I18N support on page 109 Configuring I18N support 79

Software Configuration Converting a legacy configuration with the nsrdaadmin command After you upgrade from a legacy NetWorker module to NMDA, you must convert the old scheduled backup configuration to the new NMDA scheduled backup configuration. Otherwise, the scheduled backup will fail after the upgrade. The legacy NetWorker modules include the following: NetWorker Module for DB2 (NMDB2) NetWorker Module for Informix (NMI) NetWorker Module for Lotus (NML) NetWorker Module for Oracle (NMO) NetWorker Module for Sybase (NMS) The recommended method for the backup configuration conversion is to use the nsrdaadmin command. This conversion method reduces the configuration effort for a scheduled backup, and enables you to continue using the previous backup configuration with the NMDA software. As an alternative to conversion, you can manually change the existing backup configuration to work with NMDA after you upgrade from the NetWorker module. The nsrdaadmin command can convert any scheduled backup configuration of a legacy NetWorker module to an NMDA configuration, no matter which method (wizard or nonwizard) was used to originally create the backup configuration. The EMC NetWorker Module for Databases and Applications Installation Guide provides details on the following: How to use the nsrdaadmin command to convert from a legacy backup configuration. How to use manual conversion steps (without the nsrdaadmin command) to convert from a legacy backup configuration. 80 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Performing server-side configuration with the NMC wizard Server-side configuration is the configuration of an NMDA scheduled backup with the backup configuration wizard. Note: NMDA release 1.0 supports the backup configuration wizard for the configuration of DB2, Lotus, and Oracle scheduled backups only. The wizard cannot be used to configure Informix or Sybase scheduled backups. To perform server-side configuration with the backup configuration wizard: 1. Review the information in About the backup configuration wizard on page 81. 2. If you have created a backup configuration with the nonwizard method and you want to start using the wizard to modify the configuration, convert the configuration according to Convert an NMDA client-side configuration for the wizard on page 82. 3. Ensure that you meet the Requirements for using the backup configuration wizard on page 85. 4. Follow the configuration steps in Configure a scheduled backup with the wizard on page 85. About the backup configuration wizard The NMDA software supports the backup configuration wizard (also known as Client Backup Configuration in NMC) that is integrated with a supported NMC release. Configuration wizards on page 29 describes the main features of the backup configuration wizard. The wizard configures 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 Verifying the basic resource configurations on page 72. The wizard provides options for a typical or custom configuration. The "typical" option provides a more simplified workflow that generates predefined values. The wizard help provides details on the predefined settings used for a typical scheduled backup. To use the NMDA wizard to modify a client-side configuration that was not created with the wizard, you must first convert the client-side configuration to a server-side configuration according to Convert an NMDA client-side configuration for the wizard on page 82. The following sources provide more information on the configuration wizard: EMC NetWorker Module for Databases and Applications Installation Guide EMC NetWorker Module for Databases and Applications Release Notes EMC NetWorker Administration Guide EMC NetWorker Release Notes Descriptive inline text in the wizard Online help in the wizard Performing server-side configuration with the NMC wizard 81

Software Configuration Convert an NMDA client-side configuration for the wizard Note: NMDA release 1.0 supports conversion of the client-side configuration of a DB2, Lotus, or Oracle scheduled backup only. The conversion method described in this section cannot be used to convert an Informix or Sybase client-side configuration. Before you can use the wizard to modify an NMDA client-side configuration, created with the NMC method (without the wizard), you must first convert the configuration to an NMDA server-side configuration with the nsrdaadmin -W command. The conversion with the nsrdaadmin - W command converts the scheduled backup configuration to the configuration storage framework supported by the wizard. After the conversion, you must use the wizard only to modify the configuration. Note: To convert the client-side configuration of a legacy NetWorker module to an NMDA server-side configuration, you must first convert the legacy configuration to an NMDA client-side configuration by using the nsrdaadmin -M command, as described in the EMC NetWorker Module for Databases and Applications Installation Guide. Then you can use the following instructions to convert the NMDA client-side to server-side configuration. To convert an NMDA client-side to server-side scheduled backup configuration with the nsrdaadmin command: 1. Review the information in Resource values set by the conversion on page 82. 2. Ensure that you meet the Requirements for using the nsrdaadmin command on page 83. 3. Use the proper nsrdaadmin command and options, according to the Syntax and options of the nsrdaadmin conversion command on page 84. Resource values set by the conversion The configuration conversion updates the NetWorker resources as follows: In the Client resource: Backup Command attribute is changed to: nsrdasv -T app [-c client] where: app is db2, lotus, or oracle, depending on the database or application. client is the client name, if it was included in the old value of the Backup Command attribute. Backup Config attribute (hidden attribute) is created to contain: Information from the DB2, Lotus, or Oracle client-side configuration. For Oracle only, information from the RMAN scripts specified in the Save Set attribute. Backup Type attribute is created to contain the value DB2, Lotus, or Oracle. The NetWorker Lockbox resource is updated with sensitive data from the client-side configuration, such as the database username or password. The following entries are also added to the ACL of the Lockbox resource: system@client_hostname (Windows) or root@client_hostname (UNIX) Other ACL entries provided by the user during the conversion 82 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Requirements for using the nsrdaadmin command Before using the nsrdaadmin command to convert an NMDA client-side to server-side configuration, ensure that the following requirements are met: The nsrdaadmin command must be started on the operating system command line by an administrative user, either the root user on UNIX or Linux, or a member of the Microsoft Windows Administrators group. The administrative user that starts the nsrdaadmin command must have the Configure NetWorker user group privilege, as required to query and update the Client resources on a NetWorker server. The NetWorker documentation provides more information on user group privileges. For conversion of an Oracle configuration, you must also meet the Oracle-specific requirements for using the nsrdaadmin command on page 83.! IMPORTANT If you convert the backup configuration of a cluster virtual client, you must do one of the following to enable scheduled backups of the client: - During the conversion, when nsrdaadmin 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 conversion, 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. Refer to the NW105131 issue in the NMDA release notes for details on a limitation of the nsrdaadmin -W command for cluster client configuration. Oracle-specific requirements for using the nsrdaadmin command Note: If an existing RMAN script contains non-ascii characters on Windows, you cannot use the nsrdaadmin -W command to convert the NMDA client-side to server-side configuration. For this conversion,you must do either of the following: - Remove the non-ascii characters from the RMAN script, if possible. - Create a new configuration with the wizard by using the same configuration options and then delete the old configuration. Before using the nsrdaadmin command to convert an NMDA client-side configuration for an Oracle backup, ensure that the following additional requirements are met: The NMDA configuration file contains the mandatory ORACLE_HOME setting. The RMAN backup 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 Performing server-side configuration with the NMC wizard 83

Software Configuration The RMAN script does not contain any of the following commands: @ allocate channel for maintenance configure proxy Note: Conversion of a PowerSnap backup configuration is not supported. The RMAN script on Microsoft Windows does not include non-ascii characters. Syntax and options of the nsrdaadmin conversion command The nsrdaadmin command syntax and options for the conversion of an NMDA client-side to server-side configuration are as follows: nsrdaadmin -W -s server_name [-c client_name] [-g group_name] [-N save_set_name] [-Y] Command options and settings in brackets ([ ]) are optional. Do not include the brackets when typing the command. Table 7 on page 84 describes the nsrdaadmin command options. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides more details on the nsrdaadmin command. Table 7 Options of the nsrdaadmin command for configuration conversion Option Description -W Mandatory. Specifies the option for converting an NMDA client-side to server-side scheduled backup configuration. The nsrdaadmin 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. Converts each client-side configuration to the server-side configuration format that is supported by the NMDA wizard. Note: The nsrdaadmin program can only convert a configuration that physically resides on the host where the nsrdaadmin command is typed. To convert the Client resources for different physical hosts, you must run the nsrdaadmin program on each physical host, or write a script to automate the process. -c client_name Optional. Specifies the hostname of the NetWorker client being converted. Typically, this option specifies a virtual client in a cluster. The default value is the hostname of the local physical client. Note: Do not specify a hostname that is different from the name of the host where the nsrdaadmin command is run. -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 converted. -Y Optional. Specifies non-interactive mode, which causes the nsrdaadmin program to proceed with the conversion without prompting for confirmation. After the conversion, you must add the usernames to the NetWorker Lockbox resource for all the users that will use the wizard to modify the configuration. The EMC NetWorker Administration Guide provides details on the Lockbox resource. If the -Y option is not specified, the nsrdaadmin program displays all of the fields to be updated in the Client resource, and requests confirmation to proceed with the conversion. 84 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Requirements for using the backup configuration wizard Before you use the backup configuration wizard, ensure that all of the following requirements are met: The NMC user that starts the wizard (the wizard user) has the Configure NetWorker privilege and all of its prequisite privileges on the NetWorker server where the configuration is created. Communication between the NMC server, NetWorker server, and NMDA client uses NetWorker nsrauth authentication, which is the default NetWorker setting. The NetWorker documentation provides any requirements for nsrauth authentication. The required NetWorker releases are installed on the NMC server, NetWorker server, and NMDA client hosts, as described in the EMC NetWorker Module for Databases and Applications Release Notes. The wizard may be run on a host with no NetWorker software installed and with no direct communication with the NMDA client. Administrator privileges or root user privileges are not required. Configure a scheduled backup with the wizard To create or modify a scheduled 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 the 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. Start the wizard by the appropriate method: To create 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 NMDA client and select Client Backup Configuration > New. To modify an existing backup configuration, right-click the NMDA client in the right pane, and select Client Backup Configuration > Modify. Performing server-side configuration with the NMC wizard 85

Software Configuration 6. On each wizard screen that appears, specify the required options and values for the backup 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 titled Review and Accept the Client Configuration, click Create or Modify to create or modify the configuration, and click Finish to exit the wizard. If you choose to save configuration settings to a file on disk, you can later edit the file. For example, you can save an Oracle RMAN script to a file on disk, and then use the script for a manual Oracle backup. The resources required for a manual backup must be configured with the NMC 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. 86 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Performing client-side configuration with the NMC nonwizard method The following sections describe how to perform client-side configuration of backups by using NMC, without the configuration wizard, to create the required resources. Note: In NMDA release 1.0, the client-side configuration method with NMC is the only method supported for the configuration of Informix and Sybase backups. About client-side configuration with NMC NMDA supports the NMC configuration method without the backup configuration wizard. To configure a manual or scheduled backup, you can configure the required NetWorker resources manually with NMC. When you use NMC without the wizard to configure the NetWorker resources, you must also manually set the required NMDA parameters by using the proper method: For DB2, Informix, Lotus, and Sybase backups, the parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347. For Oracle backups, the parameters must be set in either the NMDA configuration file or the RMAN script, depending on the specific parameters and type of backup. Appendix A, NMDA Parameters for Backups and Restores, provides details on all of the NMDA parameters, including the procedures for setting the parameters. The following sections describe all of the database and application-specific procedures for client-side configuration of NMDA manual or scheduled backups. Perform client-side configuration with NMC To perform client-side configuration of backups with the NMC nonwizard method: 1. Ensure that the basic NetWorker resources are configured according to Verifying the basic resource configurations on page 72. 2. For scheduled backups only: a. Configure the required Group resource according to Configure a Group resource with NMC on page 88. b. Configured the required Schedule resource according to Configure a Schedule resource with NMC on page 88. c. Customize the Client resource according to Customize a Client resource with NMC on page 89. 3. Perform any additional configurations required for the specific database or application backup: Configuring DB2 backups on page 93 Configuring Informix backups on page 97 Configuring Lotus backups on page 99 Configuring Oracle backups on page 103 Configuring Sybase backups on page 112 Performing client-side configuration with the NMC nonwizard method 87

Software Configuration Configure a Group resource with NMC Configure the NetWorker Group resource with NMC to specify the attributes of the scheduled 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 are set in the Group resource: The Autostart attribute is Enabled. The Start Time for the backup is specified. 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 NMDA client 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. You can also create a probe-based Group resource to start the backup based on criteria that are different from the backup start time. Configuring a probe-based backup on page 125 provides details on configuration requirements for a probe-based Group resource.! IMPORTANT For a regular scheduled backup, the Snapshot attribute in the Group resource must be set to False. The EMC NetWorker Administration Guide and NMC online help provide more information on how to create and modify Group resources. Specify the name of the NetWorker group in the Group attribute of the Client resource. Configure a Schedule resource with NMC Review the summary information in NetWorker Schedule resource on page 74. Configure the NetWorker Schedule resource with NMC, to specify the days of the week when the scheduled backup runs. The NetWorker server provides several preconfigured schedules. Preconfigured schedules can be modified, but not created. Customized schedules can be both created and modified. 88 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Customize the NetWorker Schedule resource for the scheduled backup by selecting the backup level for each day of the week, as shown in Table 8 on page 89. The EMC NetWorker Administration Guide and NMC online help provide more information on how to create and modify Schedule resources. Specify the name of the NetWorker schedule in the Schedule attribute of the Client resource. Table 8 Backup levels specified in NetWorker Schedule resource Type of backup Supported backup levels DB2 Level full Full backup of all the database data. Level incr DB2 incremental backup. Level 1 to 9 DB2 delta backup. Level skip NetWorker server skips the backup on that day. To support the NetWorker backup levels, set the DB2_APPLY_NW_LEVELS parameter to TRUE and set the DB2 parameter TRACKMOD to ON: Set the DB2_APPLY_NW_LEVELS parameter to TRUE in the NMDA configuration file, as described in DB2_APPLY_NW_LEVELS on page 356. Ensure that the TRACKMOD parameter is set to ON with a DB2 command at the operating system command line: db2 update db cfg for sample using TRACKMOD ON where sample is the name of the database to be backed up. Informix Level full ON-Bar level 0 backup of all the (full) records in the selected dbspaces of the database instance. Level 1 ON-Bar level 1 backup of records that have changed in the selected dbspaces since the last level 0 (full) backup. Level 2 ON-Bar level 2 backup of records that have changed in the selected dbspaces since the last level 1 backup. Level skip NetWorker server skips the backup on that day. Note: ON-Bar does not support the NetWorker backup levels 3 to 9. If you specify a level 3 to 9 in the Schedule resource, ON-Bar uses a level 0 (full), 1, or 2. Lotus Sybase Level full Full backup of all the data. Level incr Incremental backup of only data that has changed since the last backup. Level skip NetWorker server skips the backup on that day. Note: NMDA does not support the NetWorker backup levels 1 to 9 for Lotus or Sybase backups. Oracle Level full, incr, or 1 to 9 NetWorker server runs the backup script on that day. The Oracle backup level is actually determined by the level that is set in the RMAN backup script only. Level skip NetWorker server skips the backup on that day. Customize a Client resource with NMC In addition to the attributes for manual backups described in NetWorker Client resource on page 74, the following attributes must be set for scheduled backups only: Application Information (DB2 backups only) Backup Command Browse Policy Group Parallelism Retention Policy Performing client-side configuration with the NMC nonwizard method 89

Software Configuration Save Set Schedule To customize the Client resource for a scheduled backup by using NMC, specify the required values for each attribute, according to Table 9 on page 90. Unless specified otherwise for a particular attribute, the attribute settings described in the table apply to the backups of all supported databases and applications.! IMPORTANT If multiple entries are specified in the Save Set attribute of the Client resource: - The backups for the entries are executed in arbitrary order, possibly in parallel. - If the NMDA configuration file also contains a setting for PRECMD or POSTCMD, the precommand and postcommand files will be: - Common for all of the backups - Executed once for each backup Also, if a scheduled backup is retried, the specified precommand and postcommand will be executed again for that backup. To include separate preprocessing and postprocessing for each backup, define a separate NetWorker Client resource for each backup. Leave the following attributes blank in the Client resource: Directive Archive Users Remote User Password On a Solaris system with Solaris zones, ensure that the security fields (such as Remote Access and Privileges) of NetWorker resources used during NMDA backups and restores refer to the hostname of the zone in which NMDA operates. Configuring a probe-based backup on page 125 provides details on configuration requirements for a probe-based backup. Configure the NetWorker Client resource on page 297 provides information on how to configure the Client resource for PowerSnap backups (DB2 or Oracle only). Table 9 NetWorker Client resource attributes (page 1 of 3) Attribute name Aliases Application Information Attribute setting Specify all known aliases for the system where the NMDA software is installed. For DB2 backups only. Specify the name of one or more DB2 database instances that require restore permissions on the same host or a different host: Separate database instances with a colon, and add a colon after the last instance. For example: DB2_R=database_name:db2inst1:db2inst2: This allows the instances db2inst1 and db2inst2 to restore the database database_name. Add additional lines in the Application Information attribute for other DB2 databases that you want to add to a Client resource. For example: DB2_R=database_name:db2inst1:db2inst2: DB2_R=second_database:db2inst3:db2inst4: Note: Always add a colon after the last instance. 90 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Table 9 NetWorker Client resource attributes (page 2 of 3) Attribute name Backup Command Attribute setting Specify the command to be used for the backup: nsrdasv(.exe) -z configuration_filepath where configuration_filepath is the complete pathname of the configuration file that contains the NMDA parameter settings for the scheduled backup. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, replace nsrdasv(.exe) with nsrdasv32.exe in the Backup Command attribute. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. On Windows only, if the configuration file pathname includes any spaces, do one of the following: Change the configuration file pathname so it does not include spaces. Use the Windows short pathname format. For example: nsrdasv(.exe) -z C:\Progra~1\Legato\nsr\apps\config\config.txt Use quotes and double backslashes in the pathname. For example: nsrdasv(.exe) -z C:\\Program Files\\Legato\\nsr\\apps\\config\\config.txt Appendix A, NMDA Parameters for Backups and Restores, provides details on the configuration file and NMDA parameters. Note: If you configure a DB2, Lotus, or Oracle scheduled backup through the configuration wizard, the wizard automatically sets this attribute to nsrdasv -T app, where app is db2, lotus, or oracle. In that case, do not modify this attribute. Browse Policy For scheduled backups only. Specify the length of time that the NetWorker server retains an entry for the backup in the online client file index. If the parameter is not set, the NetWorker server uses the most appropriate value for the browse policy. Note: If the parameter NSR_SAVESET_BROWSE is set as described in Appendix A, NMDA Parameters for Backups and Restores, its value overrides the Browse Policy attribute setting in the Client resource. The value of the Browse Policy attribute cannot exceed the value of the Retention Policy attribute. Group Name Parallelism Remote Access Retention Policy For scheduled backups only. Specify the NetWorker backup group to use for the scheduled backup. Configure a Group resource with NMC on page 88 provides more details on backup groups. Specify the hostname of the database or application server host where the NMDA software is installed. (Hidden attribute) Specify the maximum number of data streams that the database or application server sends in parallel to the NetWorker server or storage node during the backup. The following sections provide more information on parallelism settings for application-specific backups: Configure a DB2 parallel (multiple session) backup on page 95 Configure Informix backup parallelism on page 98 Configure Lotus backup parallelism on page 99 Configure an Oracle parallel (multi-channel) backup on page 108 Configure Sybase parallel (multistripe) backups on page 116 Specify 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 NMDA operates. Do not set this attribute if none of the following operations are required: Backup from a cluster. Backup in an Oracle Data Guard environment (Oracle only). Recovery to a host other than the one being backed up. For scheduled backups only. Specify the minimum length of time that the NetWorker server maintains information about the backup data in the online media database. If the parameter is not set, the NetWorker server uses the most appropriate value for the retention policy. Note: If the parameter NSR_SAVESET_RETENTION is set as described in Appendix A, NMDA Parameters for Backups and Restores, its value overrides the Retention Policy attribute setting in the Client resource. The value of the Retention Policy attribute must be greater than or equal to the value of the Browse Policy attribute. Performing client-side configuration with the NMC nonwizard method 91

Software Configuration Table 9 NetWorker Client resource attributes (page 3 of 3) Attribute name Attribute setting Save Set Type of client Save Set attribute setting DB2 Informix Lotus Specify the database and (optionally) node to be backed up: DB2:/database_name[/node_name] For a single-node partition, if DB2:/SAMPLE/NODE0000 is typed in the Client resource Save Set list, the save set names created in the media database will be: DB2:/SAMPLE/NODE0000 For a multiple-node partition, if DB2:/SAMPLE/NODE0000 and DB2:/SAMPLE/NODE0001 are typed in the Client resource Save Set list, the save set names created in the media database will be: DB2:/SAMPLE/NODE0000 DB2:/SAMPLE/NODE0001 Specify the database instance and (optionally) dbspace or blobspace to be backed up: INFORMIX:/instance[/[dbspace blobspace]] To specify more than one dbobject for backup, add a separate save set entry for each dbobject in the Save Set attribute. Specify the name for the backup save set stored on the media. The name must start with the prefix NOTES:, and the prefix may be followed by any descriptive text. For example, the following are valid names: NOTES: NOTES: Monday Full Backup Note: The Save Set attribute must contain only a single name, not multiple names. To specify the actual data to back up, set one of the following parameters: NSR_BACKUP_LOTUS_DIR To back up the Domino or Notes data directory, including the notes.ini file. NSR_BACKUP_PATHS To back up one or more specific directories, or files, or both. Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters. Oracle Sybase Specify the complete pathname of each RMAN script to be used for the 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, specify the complete file pathnames prepended by RMAN: in the Save Set attribute: RMAN:/disk/rman_scripts/archlogbkup RMAN:/disk/rman_scripts/fullbkup Each Oracle installation requires a separate Client resource. Specify either the entire Sybase server instance, or one or more Sybase databases for backup: SYBASE:/ASE_server_name[/database_name] To back up all of the databases for the Sybase server, specify the following in the Save Set attribute: SYBASE:/ASE_server_name To back up selected databases for the Sybase server, specify each database name separately in the Save Set attribute: SYBASE:/ASE_server_name/database_name Schedule For scheduled backups only. Specify the NetWorker backup schedule to use for the scheduled backup. Configure a Schedule resource with NMC on page 88 provides more details on backup schedules. 92 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring DB2 backups Note: Before configuring DB2 backups, it is recommended that you determine the files to back up on your system in preparation for disaster recovery. Prepare a DB2 server for disaster recovery on page 225 provides more information. To perform client-side configuration with NMC (without the wizard) of DB2 backups: 1. Set the NMDA parameters for the preferred type of backup in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. NMDA configuration file on page 347 provides details on the configuration file template that you can customize for your particular backup. The mandatory parameters are for DB2 scheduled backups only: DB2INSTANCE (UNIX only) DB2_NODE_NAME DB2PATH (Windows) DB2_TBS_LIST (tablespace backup only) DB2_USER INSTHOME (UNIX) USER_PSWD! IMPORTANT To set the encrypted DB2 user password in the USER_PSWD parameter for scheduled backups only, you must use the nsrdaadmin -P command, as described in USER_PSWD on page 359. 2. Ensure that the required NetWorker resources are configured. 3. If required, configure the backup of transaction logs for rollforward recovery according to Configure DB2 transaction log backups for rollforward recovery on page 93. 4. If required, configure a multiple session backup according to Configure a DB2 parallel (multiple session) backup on page 95. Configure DB2 transaction log backups for rollforward recovery By default, NMDA does not back up DB2 transaction log files. However, this DB2 functionality may be integrated into the DB2 backup process with NMDA by using a special configuration file. To configure NMDA backups of DB2 transaction logs: 1. Create a special configuration file, which will save DB2 transaction log files to the NetWorker server. For example, this configuration file could be named nmda_db2_tlogs.cfg. Configuring DB2 backups 93

Software Configuration Appendix A, NMDA Parameters for Backups and Restores, describes the syntax and parameters that must be used in the configuration file: The NSR_SERVER parameter is required. Set this parameter to the name of the NetWorker server used to back up the database on the client. If the configuration file is for a cluster environment, add the NSR_CLIENT parameter, which is typically set to the cluster virtual hostname. The following is a simple example of the configuration file contents for transaction log backups: NSR_SERVER=TURBO NSR_LOG_VOLUME_POOL=Default 2. To enable the automatic backup of transaction logs when they become full, configure the database with the command and options appropriate for the client operating system: On UNIX: $ db2 update db cfg for sample using logarchmeth1 VENDOR:/usr/lib/libnsrdb2.xx logarchopt1 @pathname/nmda_db2_tlogs.cfg On Microsoft Windows: $ db2 update db cfg for sample using logarchmeth1 VENDOR:NetWorker_install_dir\nsr\bin\libnsrdb2.dll logarchopt1 @pathname\nmda_db2_tlogs.cfg where: sample is the name of the database to be backed up. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname/nmda_db2_tlogs.cfg is the complete pathname of the configuration file (relative pathnames are not supported). NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. 3. Once the steps 1 to 2 are completed, manually perform a full backup of the database.! IMPORTANT An initial full backup of the database is required. DB2 manual backup on page 135 provides information on how to manually perform a backup of a DB2 database. 94 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configure a DB2 parallel (multiple session) backup The DB2 software supports backups that are performed with multiple sessions (also known as multiple streams, multiplexed, or multinode). This technology extracts multiple streams of data in parallel from a database, and writes them in parallel to multiple storage devices. This method can significantly enhance performance when a large amount of data is backed up or restored. To configure a DB2 multiple session backup, as either a manual or scheduled backup: 1. Determine the number of available devices for the DB2 backup. This will be the number of multiple sessions to use.! IMPORTANT Using a number of sessions greater than the number of devices can improve backup performance but can adversely affect recovery performance. 2. On the NetWorker server: a. Set the server parallelism to a value greater than the number of multiple sessions to be used for DB2 backups. NetWorker Server resource on page 72 provides details on the server parallelism setting. b. Set the client parallelism to a value the same as or greater than the number of multiple sessions that can run concurrently for DB2 backups on the client. Customize a Client resource with NMC on page 89 provides details on the client parallelism setting. c. Set each available device to one target session only, as recommended for DB2 backups. This will prevent the writing of more than one session to a single device, especially a tape drive, which can severely affect recovery performance. 3. Specify the backup to use the number of sessions equal to the number of available backup devices. There are various ways to do this: If the scheduled backup is configured with the backup configuration wizard, specify the number of DB2 backup sessions on the Specify the Backup Level and Type Options wizard page. If the scheduled backup uses an NMDA configuration file (for example, nmda_db2.cfg ), set the number of sessions in the DB2_SESSIONS parameter. If a manual backup is run, specify the number of sessions with the open sessions option of the db2 command on the operating system command line, for example: db2 backup db sample load /usr/lib/libnsrdb2.xx open 4 sessions options @/pathname/nmda_db2.cfg where: sample is the name of the DB2 database. xx is the platform-specific extension. 4 is the number of sessions. pathname/nmda_db2.cfg is the complete pathname of the NMDA configuration file for the DB2 backup. Configuring DB2 backups 95

Software Configuration Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. 96 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring Informix backups Note: Before configuring Informix backups, it is recommended that you determine the files to back up on your system in preparation for disaster recovery. Prepare an Informix server for disaster recovery on page 225 provides more information. To perform client-side configuration with NMC (without the wizard) of Informix backups: 1. Set the required NMDA parameters: For an Informix manual backup, set these mandatory parameters in the environment, not in the NMDA configuration file: NSR_SERVER Hostname of the NetWorker server to perform the backup. NSR_DATA_VOLUME_POOL NetWorker volume pool to use for the backup of IDS databases, dbspaces, and blobspaces. NSR_LOG_VOLUME_POOL NetWorker volume pool to use for the backup of IDS logical logs. If the volume pools do not yet exist, create the NetWorker Pool and associated Label Template resources for the specified pools. The recommended names to use by default for the volume pools are DBMIData for NSR_DATA_VOLUME_POOL and DBMILogs for NSR_LOG_VOLUME_POOL. NetWorker Pool and Label Template resources on page 75 provides more information on volume pools. Appendix A, NMDA Parameters for Backups and Restores, provides details on other parameters that can be set for an Informix manual backup. For an Informix scheduled backup, set the parameters in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. NMDA configuration file on page 347 provides details on the configuration file template that you can customize for your particular backup. These parameters are mandatory for Informix scheduled backups: INFORMIXDIR INFORMIXSQLHOSTS (UNIX) ONCONFIG 2. Ensure that the required NetWorker resources are configured. 3. If required, configure the continuous logical log backups according to Configure Informix continuous logical log backups on page 98. 4. If required, specify the backup parallelism according to Configure Informix backup parallelism on page 98. 5. If I18N support is required, ensure the required configurations according to: Configuring I18N support on page 78 Informix-specific requirements for I18N support on page 98 Configuring Informix backups 97

Software Configuration Configure Informix continuous logical log backups To have ON-Bar automatically back up logical logs as they become full, modify the automatic log backup script, log_full.sh (UNIX) or log_full.bat (Windows), on the OnLine Dynamic Server machine to include the following lines: On UNIX: NSR_LOG_VOLUME_POOL=log_pool_name NSR_SERVER = NetWorker_server_name export NSR_LOG_VOLUME_POOL export NSR_SERVER On Microsoft Windows: set NSR_LOG_VOLUME_POOL=log_pool_name set NSR_SERVER = NetWorker_server_name Replace log_pool_name with the name of the NetWorker volume pool to use for the logical log backups. After a log file is successfully backed up, ON-Bar closes the file, frees the space used by the file, and opens a new file for transaction logging. Logical log backups are always performed as level full (ON-Bar level 0) backups.! IMPORTANT Informix recommends dedicating a backup device for continuous log backups. This ensures that a device on the backup server is always available to receive logical log data. Configure Informix backup parallelism To configure the required parallelism for Informix backups, set the Informix parameter BAR_MAX_BACKUP in the $ONCONFIG file. The Informix IDS documentation on the IBM website provides more details on the the $ONCONFIG file and parameter settings. Informix-specific requirements for I18N support The default locale for Informix IDS is English (en_us). To enable I18N support for Informix scheduled backups in a non-english locale, ensure that the following parameters are set in the NMDA configuration file: DB_LOCALE DBLANG SERVER_LOCALE CLIENT_LOCALE The appropriate Informix documentation provides more details on these parameters. 98 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring Lotus backups Note: Before configuring Lotus backups, it is recommended that you determine the files to back up on your system in preparation for disaster recovery. Prepare a Lotus server for disaster recovery on page 227 provides more information. To perform client-side configuration with NMC (without the wizard) of Lotus backups: 1. Set the NMDA parameters for the preferred type of backup in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. NMDA configuration file on page 347 provides details on the configuration file template that you can customize for your particular backup. Note: Configuring Lotus DAOS backups on page 100 provides details on additional requirements for Lotus DAOS backups. These parameters are mandatory for both Lotus manual and scheduled backups: Notes_ExecDirectory NSR_RESOURCE_DIR (UNIX) PATH (UNIX) These parameters are mandatory for Lotus scheduled backups only: LOTUS_USER (UNIX) PATH (Windows) 2. Ensure that the required NetWorker resources are configured. 3. For a Lotus manual backup on Solaris or Linux only, ensure the environment settings according to Ensure the environment settings for Lotus operations on page 99. 4. Specify any required parallelism settings according to Configure Lotus backup parallelism on page 99. 5. For a Lotus DAOS backup only, ensure the additional required settings according to Configuring Lotus DAOS backups on page 100. Ensure the environment settings for Lotus operations For Lotus manual backups with a Domino server on Solaris or Linux only, ensure that the environment variable LD_LIBRARY_PATH is set to the complete pathname of the Lotus directory that contains the library files libnotes.so and libndgts.so. The variable must be set in the same shell in which you perform the operation. Configure Lotus backup parallelism Specify the required parallelism settings to enable streams of Lotus data from several clients, or many Lotus data streams from one client, at the same time: Set the Parallelism attribute in the NetWorker Server resource to specify the maximum number of backup save streams that the NetWorker software allows to arrive in parallel at the server. Configuring Lotus backups 99

Software Configuration Set the Parallelism attribute (a hidden attribute) in the NetWorker Client resource to specify the maximum number of data streams that can be sent in parallel to the NetWorker server or storage node during a Lotus backup. Set the NSR_PARALLELISM parameter in the NMDA configuration file to specify the maximum number of concurrent backup streams that can be sent to or from the NetWorker server during a Lotus backup. NSR_PARALLELISM on page 366 provides details. Configuring Lotus DAOS backups To configure an integrated backup of Domino database files and DAOS: 1. Review the Best practices for Lotus DAOS backups on page 100. 2. Follow the basic configuration steps in Configuring Lotus backups on page 99. 3. Follow the additional configuration steps in Configure a Lotus DAOS backup on page 101. If you want to back up only DAOS files without backing up Domino database files, then follow the steps in Configuring Lotus backups on page 99, and specify the following parameter settings in the LOTUS{} section of the configuration file: NSR_BACKUP_PATHS=DAOS_directory NSR_BACKUP_ALL_EXTENSIONS=TRUE Note: The NMDA wizard does not support the configuration of the integrated DAOS backup. Best practices for Lotus DAOS backups Review the IBM documentation for details on the required DAOS configuration and backup practices. The following list provides specific best practices for reference purposes: The DAOS deferred deletion interval should be set to a period longer than the backup cycle, which is the time period between full backups. Note: The Domino server deletes an attachment in a DAOS directory only when the last database referencing it is deleted and after a user-defined delay time called the deferred deletion interval. The NLO files should not be pruned from the DAOS repository before they have been backed up. This ensures that the NLO files will be recoverable. Lotus DAOS backups are set up to include the daos.cfg and daoscat.nsf files that are stored in the Lotus data directory, if required. Note: NMDA backs up the daos.cfg file only when it is explicitly included in the NSR_BACKUP_PATHS parameter or the backup of the Domino data directory is performed with NSR_BACKUP_ALL_EXTENSIONS=TRUE. The IBM documentation provides complete details on the requirements and recommendations for DAOS setup procedures. 100 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configure a Lotus DAOS backup This section provides information on how to configure a manual or scheduled integrated backup, where the Domino data is backed up first and the DAOS repository or part of it is backed up second during the same backup session. Note: The DAOS backup runs only if the Domino data backup succeeds. To configure the integrated backup, set the required parameters in a single configuration file: 1. Set the parameters required for the Domino data backup in the LOTUS{} section of the configuration file. For example, the following parameter in the LOTUS{} section specifies the backup of the Lotus data directory: NSR_BACKUP_LOTUS_DIR=TRUE The LOTUS{} section must include either NSR_BACKUP_LOTUS_DIR or NSR_BACKUP_PATHS, but not both, to specify at least one Domino data file for the backup.! IMPORTANT If the LOTUS{} section of the configuration file includes the parameter setting NSR_BACKUP_ALL_EXTENSIONS=TRUE and the DAOS directory is in the Domino data path to be backed up, add the DAOS directory to the exclude list in the NSR_EXCLUDE_LIST parameter in the LOTUS{} section, so the DAOS directory is not backed up as part of the Domino data backup. 2. Set the following mandatory parameters in the LOTUS_DAOS{} section of the configuration file: NSR_BACKUP_PATHS=DAOS_base_dirpath_or_list_of_subdirectory_paths NSR_BACKUP_ALL_EXTENSIONS=TRUE The parameter settings in the LOTUS_DAOS{} section apply only to the DAOS backup, not to the Domino data backup. The DAOS backup also backs up transaction logs if its backup level is incremental or the NSR_BACKUP_LOGS_MODE parameter is set for a full backup. Note: If you wish to back up the daos.cfg file in the Lotus data directory and the parameter settings in the LOTUS{} section do not include the backup of the file, you must add the filepath to the NSR_BACKUP_PATHS setting in the LOTUS_DAOS{} section.! IMPORTANT In the configuration file, the LOTUS_DAOS{} section must be located after the LOTUS{} section, to ensure that the DAOS files are backed up after the Domino database files. The LOTUS{} and LOTUS_DAOS{} sections can include different parameter settings that specify different backups levels and so on for the Domino data and DAOS backups. The DAOS backup inherits most of the parameters set in the LOTUS{} section, so if the same parameter is required for both backups (for example, Notes_ExecDirectory), then it is sufficient to set it in the LOTUS{} section only. For the DAOS backup, a parameter setting in the LOTUS_DAOS{} section overrides the setting of the same parameter in the LOTUS{} section. Configuring Lotus backups 101

Software Configuration The following parameters are not inherited from the LOTUS{} section, and apply only to the section in which they are specified: NSR_BACKUP_PATHS NSR_EXCLUDE_FILE NSR_EXCLUDE_LIST The following parameters do not apply to DAOS backups: NSR_BACKUP_LOTUS_DIR NSR_COMFORT_SPAN NSR_FOLLOW_LINKS NSR_SKIPDBERRORS PRECMD The catalog file is updated and the post-command is run after the DAOS backup ends. As a result, if NSR_CATALOGFILE and POSTCMD are set to different values in the LOTUS_DAOS{} section and in the LOTUS{} section, then the values from the LOTUS_DAOS{} section are used. You might want to set the following parameter values in the LOTUS_DAOS{} section, to different values than in the LOTUS{} section: NSR_BACKUP_LEVEL=incr, in case the databases are backed up as full. NSR_SAVESET_BROWSE and NSR_SAVESET_RETENTION, to keep the DAOS backups for a longer period of time. NSR_SAVESET_NAME, to specify a different name for DAOS save sets that differentiates them from Domino data save sets. For example, set NSR_SAVESET_NAME=NOTES_DAOS. If NSR_SAVESET_NAME is not set, the DAOS backup save set has the same name as the Domino data save set from the same integrated backup, such as NOTES_number. A save set with the same name appears twice in the scheduled backup details displayed in the NMC interface. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file and Lotus-specific parameters. 102 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring Oracle backups Note: Before configuring Oracle backups, it is recommended that you determine the files to back up on your system in preparation for disaster recovery. Prepare an Oracle server for disaster recovery on page 227 provides more information. To perform client-side configuration with NMC (without the wizard) of Oracle backups: 1. Create the appropriate RMAN script for the preferred type of backup: RMAN scripts for manual backups on page 103 RMAN scripts for scheduled backups on page 105 Specify any required parallelism settings in the RMAN script according to Configure an Oracle parallel (multi-channel) backup on page 108. 2. For a scheduled backup only, set the required NMDA parameters for the backup in the NMDA configuration file according to Oracle-specific NMDA parameters on page 368. NMDA configuration file on page 347 provides details on the configuration file template that you can customize for your particular backup. These parameters are mandatory for Oracle scheduled backups in specific cases, as described in Table 32 on page 369: NSR_PROXY_PFILE ORACLE_HOME ORACLE_SID TNS_ADMIN 3. Ensure that the required NetWorker resources are configured. 4. Customize specific resources for Oracle operations according to: Oracle-specific requirements for NetWorker user group privileges on page 107 Oracle-specific requirements for NSR_DATA_VOLUME_POOL on page 108 5. If I18N support is required, ensure the required configurations according to: Configuring I18N support on page 78 Oracle-specific requirements for I18N support on page 109 6. If required for a scheduled backup only, configure save set bundling according to Configure save set bundling on page 110. 7. If required for a scheduled backup only, configure policy uniformity according to Configure policy uniformity on page 111. RMAN scripts for manual backups Oracle-specific NMDA parameters must be set with the methods described in Setting the NMDA parameters for Oracle operations on page 368. For Oracle manual backups, all of the parameters must be in the RMAN backup script by using the send command where possible. The send command on page 379 provides more information. Configuring Oracle backups 103

Software Configuration Note: NSR_DATA_VOLUME_POOL* parameter settings are mandatory for Oracle manual backups that generate backup copies, as described in Appendix A, NMDA Parameters for Backups and Restores.. The NSR_SERVER parameter setting is recommended for a manual backup if the NetWorker server host is different from the client host. 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. If automatic channel allocation and persistent settings are used, the backup command can be run as a stand-alone command. Automatic channel allocation on page 43 provides more information. Example 9 on page 104 provides a sample RMAN script for a manual backup. Example 9 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 ; allocate channel t2 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); release channel t1; release channel t2; } To specify a Media Management (in this case, NMDA) 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 NMDA 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 an Oracle 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. 104 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration 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, Oracle RMAN Commands, provides important information on RMAN commands. Regular backup information in NetWorker indexes on page 161 describes the information stored for a manual backup in the NetWorker indexes. RMAN scripts for scheduled backups Oracle-specific NMDA parameters must be set with the methods described in Setting the NMDA parameters for Oracle operations on page 368.! IMPORTANT For scheduled backups (both regular and PowerSnap backups), do not include send as part of the allocate channel command. The send command must be separate. For example, NMDA 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: allocate channel t1 type SBT_TAPE ; send channel t1 NSR_ENV=(NSR_SERVER=mars.emc.com) ; Automatic channel allocation on page 43 provides information on automatic channel allocation. Example 10 on page 105 provides a sample RMAN script for a scheduled backup. Example 10 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 ; allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send NSR_ENV=(NSR_DATA_VOLUME_POOL=MondayFulls) ; backup full filesperset 4 format FULL_%d_%U (database); release channel t1; release channel t2; } 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 Configuring Oracle backups 105

Software Configuration 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. The appropriate Oracle documentation provides more information. Note: 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 157 provides more information on how to cancel a scheduled backup. The remainder of the scheduled backup script in Example 10 on page 105, starting with the first allocate channel command, is similar to the manual backup script in Example 9 on page 104 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. NMDA sets these two parameters to the values specified in the Client resource for the scheduled Oracle backup, and these values cannot be overridden. 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. 106 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration 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: 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. Oracle-specific requirements for NetWorker user group privileges NetWorker user group privileges on page 72 describes the user group privileges required for common NMDA operations. For Oracle-specific operations, verify that additional privileges exist, as described in Table 10 on page 107. Table 10 User group privileges for Oracle-specific NMDA operations Operation Operating system user that performs operation Required user group privileges RMAN crosscheck Oracle user on the Oracle Server Recover Local Data (This privilege is set by default.) RMAN backup deletion Oracle user on the Oracle Server Operate NetWorker, and all its prerequisite privileges Restore of NWORA resource file backup to the Oracle Server Save set bundling Root user, or a member of the Microsoft Windows Administrators group, on the Oracle Server Root user, or a member of the Microsoft Windows Administrators group, on the Oracle Server Recover Local Data (This privilege is set by default.) Operate NetWorker, and all its prerequisite privileges To enable NMDA to delete an RMAN backup from the NetWorker index, ensure that the Oracle user has the required NetWorker privileges. NMDA attempts to delete an entry from the NetWorker index in the following cases: If the RMAN delete command is used. If a running Oracle backup is canceled according to the instructions in one of the following sections: Monitor a manual backup on page 153 Cancel a scheduled backup on page 157 Note: If the Oracle user is not granted the required NetWorker privileges in these cases, NMDA 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. Configuring Oracle backups 107

Software Configuration 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, it is the operating system user that runs the Oracle service (OracleServiceoracle_sid). Oracle-specific requirements for NSR_DATA_VOLUME_POOL You can set the NSR_DATA_VOLUME_POOL parameter in the RMAN backup script to send backup data to a specific pool. Additional NSR_DATA_VOLUME_POOL* parameters can also be set for duplexed Oracle backups, as described in Oracle-specific NMDA parameter definitions on page 369. The NSR_DATA_VOLUME_POOL* parameters are mandatory for an Oracle manual backup that generates backup copies. Separate NetWorker pools must be defined for each backup copy. Backup copies on page 44 provides more information on how to generate backup copies during an Oracle manual backup. Appendix A, NMDA Parameters for Backups and Restores, provides more information on NSR_DATA_VOLUME_POOL* parameters. Configure an Oracle parallel (multi-channel) backup The Oracle software supports backup parallelism by allocating multiple RMAN channels for regular backups. NetWorker performs multiplexing of multiple backup streams on the same device if all the following conditions are true: The NetWorker device type is not AFTD. The number of parallel sessions or channels is greater than the number of devices available on NetWorker. The target session value on the device is not set to 1. However, Oracle does not recommend the use of NetWorker multiplexing with RMAN multiplexing. To ensure that NetWorker multiplexing is not used, set the NSR_NO_MULTIPLEX parameter, as described in NSR_NO_MULTIPLEX on page 370. Do not set this parameter if the device is AFTD. If you want to use NetWorker multiplexing in addition to RMAN multiplexing, ensure that at restore time, you disable the demultiplexing logic during the Oracle restore, to avoid restore performance degradation. For example: set parallelmediarestore off; run { allocate channel c1 type SBT_TAPE ; restore database; release channel c1; } 108 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration The parallel backup configuration is different for PowerSnap backups. Oracle PowerSnap operations on page 290 provides details. Note: The degree of PowerSnap 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 NMDA software on multiple nodes of a cluster. Oracle RAC systems on page 264 provides details. Oracle-specific requirements for I18N support Note: Configuration of PowerSnap snapshot backups or restores with the NMDA wizard is not supported. Wizard references in the following steps do not apply to the configuration of PowerSnap operations. The PowerSnap Module documentation provides details on the PowerSnap options that support non-ascii values. Perform the following for I18N support with Oracle operations: 1. 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; SQL> shutdown; SQL> startup; SQL> quit; 2. Set the NLS_LANG parameter in the NMDA configuration file to the same value as the environment variable NLS_LANG. For example, in a Japanese locale, set NLS_LANG in the NMDA configuration file 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. 3. To enable PowerSnap catalog synchronization, set the NSR_ORACLE_NLS_LANG parameter to the same value as the environment variable NLS_LANG by using the nsroraadmin command. For example, in a Japanese locale, set the parameter as follows: nsroraadmin -r add NSR_ORACLE_NLS_LANG JAPANESE_JAPAN.JA16EUC Configuring Oracle backups 109

Software Configuration Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin command. The command sets the parameter value in the NWORA resource file, which is described in NWORA resource file on page 310. Configure save set bundling 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 111. To enable save set bundling: Set the NSR_BUNDLING parameter value to enabled by typing the following command: nsroraadmin -r add NSR_BUNDLING enabled By default, the NSR_BUNDLING parameter is disabled. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin command. The command sets the parameter value in the NWORA resource file, which is described in NWORA resource file on page 310. Ensure that NMDA scheduled backups are configured properly according to the Software configuration roadmap on page 70. The user group privileges for the root or administrative user on the NMDA client must 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 72. 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 NMDA configuration file, as described in Setting the NMDA parameters for Oracle operations on page 368. 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 313. NMDA 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, NMDA 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 NMDA save set bundles. In a RAC system, ensure that all channels are allocated on the same NMDA 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: nsroraadmin -r update NSR_BUNDLING disabled 110 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configure policy uniformity 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 110, policy uniformity should also be enabled. To enable policy uniformity: Set the NSR_INCR_EXPIRATION parameter value to enabled by typing the following command: nsroraadmin -r add NSR_INCR_EXPIRATION enabled By default, the NSR_INCR_EXPIRATION parameter is disabled. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin command. The command sets the parameter value in the NWORA resource file, which is described in NWORA resource file on page 310. Ensure that NMDA scheduled backups are configured properly according to the Software configuration roadmap on page 70. Ensure that the user group privileges for the root or administrative user on the NMDA 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 72. 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 NMDA configuration file, as described in Setting the NMDA parameters for Oracle operations on page 368. 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 313. NMDA 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, NMDA 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 NMDA 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: nsroraadmin -r update NSR_INCR_EXPIRATION disabled Configuring Oracle backups 111

Software Configuration Configuring Sybase backups Note: Before configuring Sybase backups, it is recommended that you determine the files to back up on your system in preparation for disaster recovery. Prepare a Sybase server for disaster recovery on page 230 provides more information. To perform client-side configuration with NMC (without the wizard) of Sybase backups: 1. Ensure that the required Sybase roles and permissions are set up according to Set up Sybase roles and permissions on page 113. 2. Set the NMDA parameters for the preferred type of backup in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. NMDA configuration file on page 347 provides details on the configuration file template that you can customize for your particular backup. These parameters are mandatory for Sybase backups in specific cases, as described in Table 33 on page 373: LD_LIBRARY_PATH LD_LIBRARY_PATH_64 LIBPATH PATH SHLIB_PATH SYBASE SYBASE_USER USER_PSWD! IMPORTANT To set the encrypted Sybase user password in the USER_PSWD parameter, you must use the nsrdaadmin -P command, as described in USER_PSWD on page 376. Review the following sections for details on additional parameter settings: Sybase backup levels on page 113 Sybase transaction log backups on page 113 3. Ensure that the required NetWorker resources are configured. 4. For a Sybase backup on HP-UX only, ensure the environment settings according to Ensure the environment settings for Sybase backups on HP-UX on page 115. 5. If required, configure multistripe backups according to Configure Sybase parallel (multistripe) backups on page 116. 6. If required, configure a threshold procedure according to Configure a threshold procedure on page 117. Note: The NMDA software does not support probe-based backups with nsrdaprobe of a Sybase database that has the data and log segments on the same device. Requirements for a probe-based backup on page 125 provides details. 112 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Set up Sybase roles and permissions The Sybase administrator is the person who is responsible for Sybase backup and recovery. The NMDA software relies on the Sybase administrator s ability to dump and load databases when performing Sybase backup and recovery operations. The administrator must have the appropriate Sybase roles and permissions. Table 11 on page 113 lists the Sybase roles and permissions that NMDA requires for performing the Sybase administrative actions. Table 11 Sybase roles and permissions Role or permission Action NMDA command SA_role or create database privileges Create a database Not applicable SA_role, DBO (database ownership), or OPER_role Backup and restore databases nsrdasv nsrsybrc SA_role, DBO Run a database consistency check nsrsybcc During a scheduled backup or database consistency check, the nsrsybcc command runs when the USE_CONSISTENCY_CHECK parameter is set to TRUE. The Sybase OPER_role does not have permission to run a database consistency check. Therefore, an administrator with an OPER_role cannot run a scheduled backup of the Sybase server without first disabling the consistency check. If the Sybase OPER_role administrator backs up the database, the NMDA software requires that the Sybase user be a member of the database in order to check whether the database and log are on separate segments. If the Sybase administrator is not a member of the database, then the backup fails. However, this limitation does not apply to recovering the Sybase database. Sybase backup levels Full and incremental Sybase backups on page 59 provides details on full and incremental Sybase backups. Specify the Sybase backup level with the NSR_BACKUP_LEVEL parameter setting in the NMDA configuration file. NSR_BACKUP_LEVEL on page 374 provides more information. Setting the NSR_LOG_VOLUME_POOL parameter on page 76 provides special considerations for the volume pools used with Sybase incremental backups. Note: If an incremental backup is performed on the Sybase server instance, only the transaction log for each database is backed up. If a database is not configured for an incremental backup, an error appears and the transaction log is not backed up. Sybase transaction log backups Specify the appropriate option for a transaction log backup with the NSR_DUMP_LOG_OPT parameter setting in the NMDA configuration file. NSR_DUMP_LOG_OPT on page 374 provides more information. The Sybase documentation provides more details on when and how to use the options for transaction log backups. Configuring Sybase backups 113

Software Configuration To prepare for transaction log backups on the same or separate devices, review the following sections: Full backups on the same or separate devices on page 114 Incremental backups on the same or separate devices on page 115 Full backups on the same or separate devices Table 12 on page 114 describes the full backup results for the different NSR_DUMP_LOG_OPT settings when the database and transaction log are on the same or separate devices. Table 12 Transaction log options for full backups NSR_DUMP_LOG_OPT parameter setting Database and log on separate devices Database and log on the same device For non-read-only databases: no_log no_truncate truncate_only 1. Truncates the transaction log without logging the transaction. 2. Backs up the database. 1. Backs up the transaction log. 2. Backs up the database. 1. Truncates the transaction log. 2. Backs up the database. 1. Displays an error message stating that the setting is invalid and the no_log operation is ignored. 2. Backs up the database. 3. Truncates the transaction log. Backs up the database. 1. Truncates the transaction log. 2. Backs up the database. (No setting) Backs up the database. Backs up the database. For read-only databases: no_log no_truncate truncate_only 1. Truncates the transaction log without logging the transaction. 2. Backs up the database. 1. Backs up the transaction log. 2. Backs up the database. Displays an error message stating that the setting is invalid for read only databases. 1. Displays an error message stating that the setting is invalid and the no_log operation is ignored. 2. Backs up the database. 3. Truncates the transaction log. Backs up the database. Displays an error message stating that the setting is invalid for read only databases. (No setting) Backs up the database. Backs up the database. 114 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Incremental backups on the same or separate devices The NSR_DUMP_LOG_OPT settings are not valid for incremental backups when the database and transaction log are on the same device. Table 13 on page 115 describes the incremental backup results for different NSR_DUMP_LOG_OPT settings when the database and transaction log are on separate devices. Table 13 Transaction log options for incremental backups NSR_DUMP_LOG_OPT parameter setting Database and log on separate devices For non-read-only databases: no_log no_truncate truncate_only (No setting) 1. Displays an error message stating that the setting is not supported with incremental backups, and that a full backup must be performed instead. 2. Backs up the transaction logs. Backs up the transaction logs. 1. Displays an error message stating that the setting is not supported with incremental backups, and that a full backup must be performed instead. 2. Backs up the transaction logs. Backs up the transaction logs. For read-only databases: no_log no_truncate truncate_only (No setting) 1. Displays an error message stating that the setting is not supported with incremental backups, and that a full backup must be performed instead. 2. Backs up the transaction logs. Backs up the transaction logs. Displays an error message stating that the setting is invalid for read only databases. Backs up the transaction logs. Ensure the environment settings for Sybase backups on HP-UX For Sybase backups on HP-UX only, ensure the required setting of the LD_PRELOAD environment variable: 1. In the shell where the Sybase backup server will be started, as the Sybase user, set the variable for the particular platform: On HP-UX PA-RISC, set LD_PRELOAD to either of the following: Set the variable to the complete pathname of the libnsrsyb.sl library. For example: $ export LD_PRELOAD=$SYBASE/$SYBASE_ASE/lib/libnsrsyb.sl Set the variable to the complete pathname of the libpthread.sl library. For example: $ export LD_PRELOAD=/usr/lib/libpthread.sl Configuring Sybase backups 115

Software Configuration On HP-UX Itanium, set LD_PRELOAD to the following: For a system with NetWorker 7.4.x installed: LD_PRELOAD=/opt/networker/lib/apps/hpux32/libcommonssl.so: /usr/lib/libnsrsyb.so For a system with NetWorker 7.5 or later installed: LD_PRELOAD=/opt/networker/lib/hpux32/libcommonssl.so: /usr/lib/libnsrsyb.so Note: If NetWorker software has been relocated on the system, the libcommonssl.so directory must be modified accordingly in the LD_PRELOAD setting. 2. Start the Sybase backup server for the NMDA backup in the same shell where the LD_PRELOAD variable was set in step 1. Configure Sybase parallel (multistripe) backups The NMDA software supports the use of multistripe sessions for Sybase backups. Multistripe backups are one or more streams of data that can be extracted in parallel from a database, and written in parallel to one or more media devices. Multistripe backups can enhance performance significantly when a large amount of data is backed up with multiple tape drives. NMDA does not support multistripe backups for the backup of transaction logs (incremental backups). If the multistripe backup option is used for incremental backups, the NMDA software automatically converts the backup to a normal incremental backup. To configure a Sybase multistripe backup: 1. On the NetWorker server: a. Set the server parallelism to a value greater than the number of multiple sessions to be used for the Sybase multistripe backup. NetWorker Server resource on page 72 provides details on the server parallelism setting. b. Set the client parallelism to a value the same as or greater than the number of multiple sessions that can run concurrently for the Sybase multistripe backup on the client. Customize a Client resource with NMC on page 89 provides details on the client parallelism setting. c. Create devices for the multistripe backup. For example, if three sessions are used, create three devices. d. Set each available device to one target session only. 2. Determine the number of sessions for the multistripe backup by using the following rules: a. The number of sessions must be less than the NetWorker server and client parallelism. b. The number of sessions must not be greater than the total number of target sessions for devices to be used by the multistripe backup. The EMC NetWorker Performance Tuning Guide provides more information on how to achieve optimum performance in a production environment. 116 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration 3. Specify the number of multistripe sessions for the Sybase backup by setting the NSR_PARALLELISM parameter in the NMDA configuration file. NSR_PARALLELISM on page 375 provides details. Configure a threshold procedure A threshold procedure provides the following features: When the threshold of a Sybase database is reached, the NMDA software dumps the transaction log. If a dump of the transaction log is not allowed, then the NMDA software performs a full database dump and truncates the transaction log.! IMPORTANT If the threshold procedure or the isql command line is used for transaction log backups, set the environment variables in the shell that launches the Sybase Backup Server. This overrides the default settings for the NMDA parameters. If the NMDA software cannot perform a full database dump, then do either of the following: Add space to the transaction log. Terminate processes that were suspended when the threshold was crossed. The Sybase documentation provides detailed information on thresholds. Threshold procedure versus probe-based backup Sybase provides the functionality to register a threshold procedure to free up the log space for a database by performing the dump of the log when the threshold is reached. If there is not enough log space, the transactions will be either terminated or suspended. NMDA provides support for the threshold procedure through the threshold.sql file, as described in Sample threshold procedure on page 117. If the logs and data segments are on the same device, the procedure performs a dump of the database because Sybase does not support the dump of transaction logs in that case. An NMDA probe-based backup of Sybase data has a different purpose than the threshold procedure. A probe-based backup is used to back up a server (all databases) or an individual database, based on the number of transaction log pages generated. The main purpose of a probe-based backup is not to free the log space, but to determine if there has been enough database activity to start a backup. Configuring a probe-based backup on page 125 provides details on NMDA probe-based backups. Sample threshold procedure Use the sample threshold procedure described in this section to implement transaction log backups to free the log space. Edit the sample threshold procedure to suit the environment. Configuring Sybase backups 117

Software Configuration Table 14 on page 118 lists the default location for the sample threshold procedure: Table 14 Threshold procedure location Platform AIX HP-UX Solaris Linux Location /usr/bin/threshold.sql /opt/networker/bin/threshold.sql /usr/sbin/threshold.sql /usr/sbin/threshold.sql Install the sample threshold procedure in a database To use the sample threshold procedure: 1. Edit the threshold.sql file, and add the word go to the last line of the file. 2. Run the isql command with threshold.sql as an input file: isql -Usa -P password -S Sybase_server -D database_name -i threshold.sql where: password is the password of the Sybase SA account. Sybase_server is the name of the Sybase server. database_name is the name of the Sybase database. 3. Start an isql session, and verify that the threshold procedure is in place: isql -Usa -P password -S Sybase_server -D database_name 1> sp_help 2> go The procedure sp_thresholdaction must appear when the sp_help command is run. If it does not appear, then verify that the database used is the correct one. The Sybase documentation provides instructions about how to use the sp_addthreshold command to do the following: Add the NMDA threshold procedure to the Sybase server. Manage free space with thresholds. 118 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring a deduplication backup To configure a deduplication NMDA backup: 1. Review the following sections: Deduplication backups and restores on page 26 Requirements for a deduplication backup on page 119 Best practices for a deduplication backup on page 119 2. Follow the configuration steps in the appropriate section: Configure a scheduled deduplication backup on page 122 Configure a manual deduplication backup on page 123 Note: Cluster systems on page 248 provides considerations for a cluster, DB2 DPF, Oracle RAC, or Sybase ASE Cluster Edition environment. Requirements for a deduplication backup Before you configure a deduplication backup, ensure that all of the following requirements are met: The NetWorker client and server releases support NMDA deduplication. The EMC NetWorker Module for Databases and Applications 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, which receives only the backup metadata or hash information during the NMDA deduplication backup, is configured as an advanced file type device (AFTD), as described in the EMC NetWorker Administration Guide. The user that will perform deduplication backups or restores has the Monitor NetWorker user group privilege. NetWorker user group privileges on page 72 provides more information on user group privileges. Best practices for a deduplication backup This section provides recommendations on when to use NMDA deduplication, and configuration tips to improve the performance of a deduplication backup. The benefits of deduplication are dependent on the environment: Deduplication is most beneficial in a data warehouse environment where the data does not change frequently. Deduplication 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. Configuring a deduplication backup 119

Software Configuration During planning and configuration of a deduplication backup, keep in mind these best practices that can improve the backup performance: Do not include a deduplication client in the same Group resource 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 backups of the client, to take advantage of the client deduplication information stored on the node. 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 NMDA backup that runs during such a maintenance mode period may be suspended until the Avamar server resources become available. If NSR_AES_ENCRYPTION, NSR_CHECKSUM, or NSR_COMPRESSION is set for a deduplication backup, NMDA applies the AES encryption, checksumming, or compression, respectively, to only the metadata that is stored on the NetWorker backup media. NMDA does not support AES encryption, checksumming, or compression of deduplicated data through NSR_AES_ENCRYPTION, NSR_CHECKSUM, or NSR_COMPRESSION, respectively. Do not use more than four backup sessions. Setting the parallelism to a high value can cause the deduplication backup to fail. The following sections provide details on parallel backups: Configure a DB2 parallel (multiple session) backup on page 95 Configure Informix backup parallelism on page 98 Configure Lotus backup parallelism on page 99 Configure an Oracle parallel (multi-channel) backup on page 108 Configure Sybase parallel (multistripe) backups on page 116 Deduplication is not recommended for incremental backups. During an incremental backup, only the database blocks that have changed are backed up, which guarantees a very low rate of duplication. When the overhead of deduplicating data is added to the overhead of an incremental backup, the result is decreased performance and insignificant benefits for the amount of data stored. The application-specific sections of this guide provide details on the supported types of incremental backups. The following sections provide additional considerations for application-specific deduplication backups: DB2-specific best practices for deduplication on page 121 Oracle-specific best practices for deduplication on page 121 Avamar and NetWorker documentation provides more information on their requirements for deduplication backups. 120 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration DB2-specific best practices for deduplication During planning and configuration of a DB2 deduplication backup, keep in mind these best practices that can improve the backup performance: Do not use DB2 parallelism. DB2 parallelism is different from the NMDA DB2 parallel (multi-session) backups. The DB2 documentation provides details on DB2 parallelism. Do not use DB2 backup compression. If using the configuration file (for example, nmda_db2.cfg), ensure the DB2_OPTIONS parameter does not include DB2BACKUP_COMPRESS. Oracle-specific best practices for deduplication During planning and configuration of an Oracle deduplication backup, keep in mind these best practices that can improve the backup performance: Do not use RMAN multiplexing for a deduplication backup. To disable multiplexing, ensure that filesperset is set to 1.! IMPORTANT If you use the wizard in NMC 7.5.1 to configure a deduplication backup, refer to details on the wizard limitation, LGTsc30351, in the NMDA release notes. Do not use RMAN binary compression (for example, ZLIB) with a deduplication backup. Set the NSR_DEDUP_CACHE_TAG parameter to an appropriate value for the client-side configuration of an Oracle deduplication backup, which is configured without the wizard. NSR_DEDUP_CACHE_TAG on page 352 provides details. 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)'; allocate channel c2 type 'SBT_TAPE'; 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; release channel c2; } 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. Configuring a deduplication backup 121

Software Configuration Configure a scheduled deduplication backup To configure a scheduled deduplication backup, use either the configuration wizard (server-side configuration) or the NMC method without the wizard (client-side configuration). Server-side configuration To use the configuration wizard to configure a scheduled deduplication backup, follow the instructions in Performing server-side configuration with the NMC wizard on page 81. On the Specify the De-duplication Options screen, apply these additional settings: Select the attribute to enable deduplication. Select the hostname of the deduplication node (Avamar server) that will store the deduplicated backup data. Client-side configuration To use the NMC method (without the wizard) to configure a scheduled deduplication backup, follow the instructions in Performing client-side configuration with the NMC nonwizard method on page 87. Note: For a manual deduplication backup, the Client resource must include only the two attribute settings in step 1 on page 122. Apply these additional settings for a deduplication backup: 1. Set the following attributes in the NetWorker Client resource for the NMDA client: Select the De-duplication Backup attribute, to enable deduplication. For the De-duplication Node attribute, select the hostname of the deduplication node (Avamar server) that will store the deduplicated backup data. 2. If the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location, set NSR_NWPATH according to the method in NMDA configuration file on page 347. NSR_NWPATH on page 353 provides details on the parameter. 3. For an Oracle deduplication backup only, set the NSR_DEDUP_CACHE_TAG parameter in the RMAN script according to NSR_DEDUP_CACHE_TAG on page 352. 4. For a Sybase deduplication backup only, ensure any required settings of environment variables according to Ensure the environment settings for Sybase deduplication operations on page 124. 5. For normal operations, default settings should be used for the cache usage and chunk size. However, if for some reason nondefault settings are required, the following parameters may be modified with special care in the NMDA configuration file or Oracle RMAN script: NSR_DEDUP_CACHE_ENABLED on page 351 NSR_DEDUP_CHUNK_SIZE on page 352 Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA parameters. 122 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configure a manual deduplication backup To configure a manual deduplication backup: 1. Set the following attributes in the NetWorker Client resource for the NMDA client by using NMC: Select the De-duplication Backup attribute to enable deduplication. For the De-duplication Node attribute, select the hostname of the deduplication node (Avamar server) that will store the deduplicated backup data. The De-duplication Node attribute must have the same value as the NSR_DEDUP_NODE setting in step 2. 2. Set the following parameters in the NMDA configuration file for a DB2, Informix, Lotus, or Sybase backup, or in the RMAN script for an Oracle backup: NSR_DEDUP_BACKUP on page 351 NSR_DEDUP_NODE on page 352 3. If the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location, set NSR_NWPATH according to the method in NMDA configuration file on page 347. NSR_NWPATH on page 353 provides details on the parameter. 4. If you are configuring an Oracle manual deduplication backup, review the section Oracle-specific requirements for a manual deduplication backup on page 123. 5. For a Sybase manual deduplication backup, ensure any required settings of environment variables according to Ensure the environment settings for Sybase deduplication operations on page 124. Oracle-specific requirements for a manual deduplication backup For an Oracle manual deduplication backup, ensure that the parameter NSR_DEDUP_CACHE_TAG is set to an appropriate value in the Oracle RMAN script. NSR_DEDUP_CACHE_TAG on page 352 provides details. Example 11 on page 123 shows an Oracle RMAN script with the parameter settings for a manual deduplication backup. Example 11 Oracle RMAN script for a manual deduplication backup The following Oracle 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); release channel ch1; release channel ch2; } Configuring a deduplication backup 123

Software Configuration Ensure the environment settings for Sybase deduplication operations For Sybase deduplication backups or restores on HP-UX Itanium or Solaris AMD64/EM64T only, ensure the required setting of the environment variable LD_LIBRARY_PATH or LD_LIBRARY_PATH_64: 1. In the shell where the Sybase backup server will be started, as the Sybase user, set the environment variable required for the particular platform: On HP-UX Itanium, set LD_LIBRARY_PATH to include the directory where the libcommonssl.so library is located. For example: $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/networker/lib/hpux32 On Solaris AMD64/EM64T, set LD_LIBRARY_PATH_64 to include the directory where the libcommonssl.so library is located (/usr/lib/nsr/amd64 by default). For example: $ export LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH_64:/usr/lib/nsr/amd64 Note: If NetWorker software has been relocated on the system, the libcommonssl.so directory must be modified accordingly in the environment variable setting. 2. Start the Sybase backup server for the Sybase deduplication backup or restore in the same shell where the environment variable was set in step 1. 124 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Configuring a probe-based backup To configure a probe-based NMDA backup: 1. Review the following sections: Probe-based (event-based) backups on page 26 Requirements for a probe-based backup on page 125 2. Follow the configuration steps in Configure a probe-based backup on page 126. Requirements for a probe-based backup Before you configure a probe-based backup, ensure that the following requirements are met: The required NetWorker releases are installed, as described in the EMC NetWorker Module for Databases and Applications Release Notes. If you want to use the nsrdaprobe program provided with NMDA to check for a specific condition that triggers a probe-based backup, ensure that you have reviewed the details on nsrdaprobe in Configure a probe-based backup on page 126. The nsrdaprobe program checks for one of the following conditions, depending on the particular database or application: For DB2, Informix, or Oracle, the nsrdaprobe program checks for the number of logs generated since the last probe-based backup. For Lotus, the nsrdaprobe program checks for the size of Domino transaction logs generated since the last full backup. For Sybase, the nsrdaprobe program checks for the number of transaction log pages generated since the last probe-based backup.! IMPORTANT NMDA does not support probe-based backups with nsrdaprobe of a Sybase database that has the data and log segments on the same device. Due to a Sybase limitation, the NMDA software cannot determine the used log pages for such a Sybase database. If you configure a probe-based backup with nsrdaprobe of a Sybase database that has the data and log segments on the same device, every time the probe runs, the database backup will be performed. If you configure a probe-based backup with nsrdaprobe of the Sybase server itself (which includes a database with the data and log segments on the same device), NMDA will not use the log page information for that database in the calculation of the number of transaction log pages generated since the last probe-based backup. If you want to check for a user-defined condition (other than the number or size of generated logs) that triggers a probe-based backup, a script or program that meets the requirements of the Probe Command attribute of the Probe resource is created, as described in Configure a probe-based backup on page 126. For example, the user-defined condition that triggers a probe-based backup is when 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. Configuring a probe-based backup 125

Software Configuration 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. This condition triggers the probe-based backup. 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 EMC NetWorker Administration Guide provides more information on user-defined probes in the section on creating a client probe. Configure a probe-based backup The EMC NetWorker Administration Guide and NMC online help provide information on how to configure the attribute settings of the NetWorker resources for probe-based backups. To configure a probe-based NMDA backup: 1. Create a separate NetWorker Probe resource for the nsrdaprobe program and any other script/program that checks for a user-defined condition.! IMPORTANT A separate NetWorker Probe resource must also be created for each database that will be probed by the nsrdaprobe program or other probe script/program. Set the Probe resource attributes as described in Table 15 on page 126. Table 15 NetWorker Probe resource attributes (page 1 of 3) Attribute Name Probe Command Description Specify a name to identify the Probe resource for the probe script/program that checks 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. Specify the name of the probe script/program that checks ( probes ) for the condition that triggers a probe-based backup. The script/program must meet the following requirements: Name starts with nsr or save. Location is the same directory that contains 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 included with NMDA, set this attribute to nsrdaprobe (or nsrdaprobe32 if 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system). Note: Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. The nsrdaprobe program checks for the following value and triggers a new probe-based backup when this value equals or exceeds the change threshold (LOG_THRESHOLD value in the Command Options attribute): Number of DB2, Informix, or Oracle transaction logs generated since the last probe-based backup. Size of Lotus Domino transaction logs generated since the last full backup. Number of Sybase transaction log pages generated since the last probe-based backup. 126 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Table 15 NetWorker Probe resource attributes (page 2 of 3) Attribute Command Options Description Required for the nsrdaprobe program only, specify a comma-separated list of parameters with their settings. Example 12 on page 129 outlines the possible parameter settings. Parameter Type of client Description LOG_THRESHOLD DB2, Informix, Oracle Lotus Sybase Mandatory. Specify the change threshold, which is the minimum number of logs 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, nsrdaprobe triggers a probe-based backup. Mandatory. Specify the change threshold, which is the minimum size in KB of Lotus Domino transaction logs required to trigger a new probe-based backup. When the size of logs generated since the last full backup equals or exceeds the change threshold, nsrdaprobe triggers a probe-based backup. IMPORTANT: The calculated size of Lotus Domino transaction logs is reset to zero only when a full backup is performed. For Lotus circular and linear transaction logging, the change threshold value must be sufficiently smaller than the value specified by Maximum log space in the Domino server Transactional Logging configuration. This requirement ensures that a probe-based backup is triggered before the transaction log size exceeds the maximum log space value and causes transaction logs to be lost. Mandatory. Specify the change threshold, which is the minimum number of Sybase transaction log pages required to trigger a new probe-based backup. When the number of transaction log pages generated since the last probe-based backup equals or exceeds the change threshold, nsrdaprobe triggers a probe-based backup. The log page size is typically between 2 KB and 8 KB. Sybase documentation provides details on how to query the log page size used for databases. LOTUS_NSF_FILE Lotus Recommended. Specify the full pathname of a Domino database file that is used for transaction log querying. The specified database file can be any file that is backed up by the associated scheduled backup. If this parameter is not set, the default value used is admin4.nsf in the Lotus Notes data directory (UNIX) or C:\Program Files\IBM\Lotus\Domino\data\admin4.nsf (Windows). NSR_DEBUG_LEVEL All Optional. Specify the level of debug information generated by the probe and written to the debug log, located in the NSR_DIAGNOSTIC_DEST directory or the default directory. NSR_DEBUG_LEVEL on page 351 provides more details. NSR_DIAGNOSTIC_ DEST NSR_ORACLE_ CONNECT_FILE All Oracle Optional. Specify the directory location of the NMDA debug logs, including those generated by the probe. If this parameter is not set, the logs are located in the default directory, /nsr/apps/logs (UNIX) or NetWorker_install_path\apps\logs (Windows). NSR_DIAGNOSTIC_DEST on page 352 provides more details. For Oracle backups only, set if both of the following are true: The Client resource is not configured with the wizard; it is configured through the NMC nonwizard method. The NWORA resource file is not set up with the Oracle home and database connection information. Specify 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 12 on page 129 provides a sample setting of this parameter. Configuring a probe-based backup 127

Software Configuration Table 15 NetWorker Probe resource attributes (page 3 of 3) Attribute Command Options Description Parameter Type of client Description ORACLE_SERVICE Oracle For Oracle backups only, set if both of the following are true: The Client resource is not configured with the wizard; it is configured through the NMC nonwizard method. The NWORA resource file is set up with the Oracle home and database connection information through the command nsroraadmin r add sid=net_service_name home=oracle_home connect=connect_filepath. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin command. Specify 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. Example 12 on page 129 provides a sample setting of this parameter. Note: The State attribute of the Probe resource is visible only in diagnostic mode. At the end of a successful probe-based backup, the nsrdaprobe program stores information about the current transaction log and some other database information 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 EMC NetWorker Administration Guide (the section on creating and scheduling a probe group). The Group resource includes several attributes that must be set for a probe-based backup group. When probing is enabled through the Group resource attributes, each probe is run once when the probe interval is reached, 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 NMDA client according to the instructions in the appropriate section: Performing server-side configuration with the NMC wizard on page 81 Customize a Client resource with NMC on page 89 In the Client resource: For the Probe attribute, specify the name of the 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. 128 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration Example 13 on page 130 describes the configuration of a probe-based backup that is triggered by both nsrdaprobe and a user-defined probe. 4. If the backup configuration is created manually through NMC (without the configuration wizard), then ensure that the mandatory NMDA parameters for the scheduled backup are set in the NMDA configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details. Example 12 Possible Command Options settings for the nsrdaprobe program To use the nsrdaprobe program that is provided with the NMDA software, the Probe resource must be set up properly, as described in Configure a probe-based backup on page 126. 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_LEVEL and NSR_DIAGNOSTIC_DEST parameters are optional. For a Lotus backup only, the LOTUS_NSF_FILE parameter is recommended. For an Oracle backup only, three possible scenarios dictate the required settings in the Command Options attribute: a. The Client resource has been configured with NMC manually (without the wizard), and the NWORA resource file has not been set up with the Oracle home and database connection information. In this case, the Command Options attribute must include the parameters LOG_THRESHOLD and NSR_ORACLE_CONNECT_FILE. For example, the Command Options attribute is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_LEVEL=5, NSR_DIAGNOSTIC_DEST=/tmp, NSR_ORACLE_CONNECT_FILE=/RMAN/rmanpw b. The Client resource has been configured with the wizard. In this case, the Command Options attribute must include the LOG_THRESHOLD parameter. For example, the Command Options attribute is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_LEVEL=5, NSR_DIAGNOSTIC_DEST=/tmp c. The Client resource has been configured through NMC manually (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 nsroraadmin r add sid=net_service_name home=oracle_home connect=connect_filepath. The Command Options attribute 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. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin command. For example, the Command Options attribute is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_LEVEL=5, NSR_DIAGNOSTIC_DEST=/tmp, ORACLE_SERVICE=proddb.world Configuring a probe-based backup 129

Software Configuration Example 13 Multiple probes for a probe-based backup A probe-based backup may be configured with multiple probes. Depending on the Probe Success Criteria setting in the Group resource, a backup starts when the conditions for any or all of the probes are met. In the following Oracle-specific example, a probe-based backup is triggered when both of the following conditions are true: At least 25 Oracle log files are generated on an NMDA 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 NMDA client and storage node are Solaris machines. The nsrdaprobe program is installed with the NMDA software in /usr/sbin on the NMDA client. The nsrdaprobe program checks for the number of Oracle log files generated on the NMDA client. A script named nsrjukeboxprobe is also 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 this probe-based backup, the following process occurs: 1. A Probe resource is created for the nsrdaprobe program with the following attribute settings: Name: NMDA probe Probe Command: nsrdaprobe (or nsrdaprobe32 if 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system) Note: Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. Command Options: LOG_THRESHOLD=25, NSR_DEBUG_LEVEL=5, NSR_DIAGNOSTIC_DEST=/tmp 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 Note: This is a checkbox in NMC. Probe Success Criteria: All 130 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Software Configuration 4. A Client resource is created for the NMDA client through the configuration wizard. The Client resource includes the following attribute settings: Name: mars Backup Command: nsrdasv (or nsrdasv32 if 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system) Note: Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. Group: probe_group Probe: NMDA 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 Note: The Skip level is selected for every day in the period. 6. A dummy Client resource is created for the storage node through the manual NMC method (without the wizard). The Client resource includes the following attribute settings: Name: marmaris Backup Command: (blank) Group: probe_group Probe: Jukebox probe Save Set: SKIP Note: 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. Configuring a probe-based backup 131

Software Configuration 132 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

3 Backup Procedures This chapter includes the following major sections: Manual backup procedures... 134 Scheduled backup procedures... 156 Verifying the backup information in NetWorker indexes... 161 Note: This chapter does not describe how to perform cluster, DB2 DPF, Oracle RAC, Sybase ASE Cluster Edition, or snapshot backups. These are described separately in other chapters. Backup Procedures 133

Backup Procedures Manual backup procedures The following sections provide details on NetWorker Module for Databases and Applications (NMDA) manual backup procedures. Scheduled backups versus manual backups on page 25 describes the differences between NMDA manual (unscheduled) and scheduled backups. Scheduled backup procedures on page 156 provides details on NMDA scheduled backup procedures. Perform a manual backup To perform an NMDA manual backup: 1. Review information in NMDA product features on page 24 about the features that apply to the particular backup. 2. Ensure that the required backup configurations are in place, as described in Software configuration roadmap on page 70. 3. Follow the backup instructions in the appropriate section: DB2 manual backup on page 135 Informix manual backup on page 137 Lotus manual backup on page 138 Oracle manual backup on page 143 Sybase manual backup on page 144 4. Review the steps for canceling a manual backup in Cancel a manual backup on page 151.! IMPORTANT The NetWorker server bootstrap and client indexes are not automatically backed up at the end of a manual backup, as they are for a scheduled backup. After running a manual backup, perform a backup of the NetWorker server bootstrap and client indexes according to Perform a NetWorker bootstrap and index backup on page 152. Regular backups of the NetWorker server bootstrap and client indexes help to ensure adequate preparation for disaster recovery. Monitor a manual backup on page 153 provides information on how to monitor the status of manual backups. The following sections describe the backup information stored in the NetWorker indexes: Regular backup information in NetWorker indexes on page 161 Deduplication backup information in NetWorker indexes on page 162 134 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures DB2 manual backup Ensure that the DB2 manual backup is configured according to Configuring DB2 backups on page 93. Perform a DB2 manual backup by using the db2 backup command with the appropriate options at the operating system command line. To perform a DB2 manual backup: 1. On the DB2 client host, open a shell (UNIX) or the Command Prompt window (Microsoft Windows). 2. Type the backup command and options appropriate for the client operating system: On UNIX: $ db2 backup db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg On Microsoft Windows: $ db2 backup db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg where: sample is the name of the database to be backed up. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname/nmda_db2.cfg is the complete pathname of the NMDA configuration file that contains the parameter settings for the DB2 manual backup. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. The DB2 documentation provides details on the db2 backup command. Cancel a DB2 manual backup according to Cancel a manual backup on page 151. Delete DB2 backups from the DB2 server and NetWorker server DB2 backup entries for databases or tablespaces may be deleted from both the DB2 server and NetWorker server with the db2 prune command. Deleting backup entries might be necessary if the NetWorker index and DB2 recovery history files become excessively large and the retention period is high. Note: The db2 prune command is not supported for deleting snapshot backups. Delete DB2 snapshots on page 331 provides details. Manual backup procedures 135

Backup Procedures To delete DB2 backup entries on both the DB2 server and NetWorker server: 1. Ensure that the user who deletes the entries has the Operate NetWorker privilege and all its required privileges on the NetWorker server. 2. Set the DB2 database configuration VENDOROPT parameter to the pathname of the NMDA configuration file (nmda_db2.cfg) for the DB2 database or tablespace whose backups are to be deleted. For example: db2 update db cfg for sample using vendoropt @/db/pathname/nmda_db2.cfg where: sample is the name of the database or tablespace whose backups are to be deleted. pathname/nmda_db2.cfg is the complete pathname of the NMDA configuration file that contains the parameter settings for the DB2 backup. 3. Enable the automatic deletion of physical backup images and log files when the db2 prune command is used, by using the following command: db2 update db cfg for sample using AUTO_DEL_REC_OBJ ON where sample is the name of the database or tablespace whose backups are to be deleted. Note: Without this step 3, the db2 prune command removes entries only in the DB2 history file and does not remove the associated database backups and log files. 4. Remove unwanted backup entries with the db2 prune command. For example: $ db2 connect to sample $ db2 prune history timestamp and delete $ db2 terminate where: sample is the name of the database or tablespace whose backups are to be deleted. timestamp (in format yyyymmddhhmmss, with minimum yyyy) specifies deletion of entries that are less than or equal to the timestamp value. Note: The prune command does not remove the most recent full backup entry regardless of the timestamp value, unless with force option is included after the timestamp. 5. Inspect the DB2 history file and the NetWorker index to verify that the backup objects have been removed: Note: The NetWorker indexes may not update immediately. On the DB2 server, use the following command: $ db2 list history backup all for sample On the NetWorker server, use any one of the following commands: nsrinfo -v -s NetWorker_server -n db2 -X all NetWorker_server nsrinfo -n db2 NetWorker_server mminfo -c NetWorker_server where NetWorker_server is the name of the NetWorker server that contains the index with the backup entries. 136 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures The DB2 documentation provides more information on the db2 prune command as well as configuration parameters that can be set to help maintain the backup history, particularly REC_HIS_RETENTN and NUM_DB_BACKUPS. Informix manual backup Ensure that the Informix manual backup is configured according to Configuring Informix backups on page 97. Perform an Informix manual backup through either of the following methods: Informix manual backup through the onbar command on page 137 Informix manual backup through the IECC on page 137 Cancel an Informix manual backup according to Cancel a manual backup on page 151. Note: After completing an Informix manual backup, you can manually back up the following critical Informix files through a NetWorker file system backup, as additional disaster recovery and support information: - Informix ONCONFIG file - ixbar file - onconfig boot file - sqlhosts file - sm_versions file Informix manual backup through the onbar command You can perform an Informix manual backup of dbspaces, blobspaces, or logical log files by typing the appropriate onbar backup command at the command line as the informix user, to run the ON-Bar backup utility. Example 14 on page 137 shows the use of onbar backup commands. The Informix Backup and Restore Guide included with the Informix server software provides details on onbar backup commands. Example 14 Informix manual backup through onbar commands After logging in as the informix user on a Windows Informix server instance named venus, you run the following commands at the command line: onbar -b -L 0 dbspace01 onbar -l -c save -s NetWorker_server INFORMIXDIR\etc\ONCONFIG \ INFORMIXDIR\etc\ixbar.server_number \ INFORMIXDIR\etc\onconfig.instance_name These commands perform the following: Level 0 (NetWorker level full) backup of the dbspace named dbspace01 Closure of the currently active logical log Backup of the logical logs, not including the newly activated log Save of critical Informix files Informix manual backup through the IECC You can perform an Informix manual backup of database server instances by invoking the Informix Enterprise Command Center (IECC) as the informix user, to run the ON-Bar backup utility. Manual backup procedures 137

Backup Procedures The Informix Backup and Restore Guide included with the Informix server software provides details on the use of IECC for backups. Lotus manual backup Ensure that the Informix manual backup is configured according to Configuring Lotus backups on page 99. Perform a Lotus manual backup through either of the following methods: Lotus manual backup through the nsrdasv command on page 138 Lotus manual backup through NetWorker User for Lotus (Windows only) on page 138 Lotus manual backup through the nsrdasv command These parameters are mandatory for Lotus manual backups: Notes_ExecDirectory NSR_RESOURCE_DIR (UNIX) PATH (UNIX) The NSR_BACKUP_PATHS or NSR_BACKUP_LOTUS_DIR parameter is set in the NMDA configuration file to specify the Lotus directories or files to be backed up. Do not set both parameters at the same time. The following descriptions provide more details: NSR_BACKUP_LOTUS_DIR on page 364 NSR_BACKUP_PATHS on page 364 Setting NSR_NOTES_INI_PATH is also recommended for a Lotus backup. Note: Configuring Lotus DAOS backups on page 100 provides additional considerations for Lotus DAOS backups. You can perform a Lotus manual backup by typing the appropriate nsrdasv backup command at the command line, as the Lotus operating system user on the Domino or Notes host: nsrdasv(.exe) -z config_filepath where config_filepath is the complete pathname of the NMDA configuration file that contains the parameter settings for the Lotus manual backup. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, replace nsrdasv(.exe) with nsrdasv32(.exe) in the backup command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. Cancel a Lotus manual backup that was started with the nsrdasv command according to Cancel a manual backup on page 151. Lotus manual backup through NetWorker User for Lotus (Windows only) As an alternative, you can perform a Lotus manual backup by invoking the NetWorker User for Lotus program on Windows only. Note: The NetWorker User for Lotus supports the backup of local Lotus Domino or Notes databases. 138 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures To start the NetWorker User for Lotus program, select Start > Programs > EMC NetWorker > NetWorker User for Lotus. Cancel a Lotus manual backup that was started with the NetWorker User for Lotus according to Cancel a manual backup on page 151. About the Backup window You can configure and run backups of Lotus database files from the Backup window of the NetWorker User for Lotus program. To display the Backup window, perform one of the following in the NetWorker User for Lotus main window: From the Operation menu, select Backup. Click the Backup button. Press Alt+B. Figure 2 on page 139 shows the Backup window of the NetWorker User for Lotus program. Figure 2 NetWorker User for Lotus Backup window To view a list of files available for backup, select a directory in the left pane. The directory s contents appear in the right pane. Manual backup procedures 139

Backup Procedures Right-clicking an item in either pane of the Backup window displays a pop-up menu with the following options: Start Starts the backup operation. Font Changes the font of the display. Backup Options Displays the Backup Options dialog box. Table 16 on page 140 describes the Backup window toolbar buttons. Table 16 Toolbar buttons on the NetWorker User for Lotus Backup window Button Operation Description Mark Marks the selected (highlighted) files for backup. Unmark Clears the selected (marked) files. Backup Options Start Displays the options for backup compression and encryption, and the text box for specifying the configuration file pathname. Starts the backup of marked files. Database backup with NetWorker User for Lotus To perform a Lotus manual backup of specific database files with the NetWorker User for Lotus program: 1. Ensure that the services on the NetWorker server are running. 2. In the NetWorker User for Lotus window, select Backup from the Operation menu. The Backup window opens, as shown in Figure 2 on page 139. 3. Specify the database files to back up by using one of the following methods: Select the files, and click the Mark toolbar button. Select the checkbox (add a check mark) beside each file. To unmark files, use one of the following methods: Select the marked files, and click the Unmark toolbar button. Clear the checkboxes (remove the check marks) beside the files. 4. To specify the location of the NMDA configuration file: a. In the Backup window, select Backup Options from the Options menu. The Backup Options dialog box opens, as shown in Figure 3 on page 141. b. Enter the complete pathname of the configuration file in the Configuration File text box. c. Click OK. 140 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Figure 3 NetWorker User for Lotus Backup Options dialog box 5. To specify data compression or encryption: a. From the Options menu, select Backup Options. b. In the Backup Options dialog box, select the appropriate option: Compression Specifies that NMDA compresses the backup data before it is moved over the network or written to tape. AES Encryption Specifies that NMDA encrypts the backup data before it is moved over the network or written to tape. The 256-bit AES encryption method is used. NSR_AES_ENCRYPTION on page 350 provides more details on 256-bit AES encryption. c. Click OK. Note: Parameters specified in the Backup Options dialog box take precedence over the corresponding parameters specified in the NMDA configuration file. 6. To start the backup, click the Start toolbar button. The Backup Status window opens and displays information about the backup operations performed, as shown in Figure 4 on page 141. Figure 4 NetWorker User for Lotus Backup Status window Manual backup procedures 141

Backup Procedures Incremental backups with NetWorker User for Lotus The NMDA software supports incremental backups with the NetWorker User for Lotus program. To perform an incremental Lotus manual backup from the NetWorker User for Lotus program: 1. Ensure that the NMDA configuration file contains the required parameter setting for the backup level: NSR_BACKUP_LEVEL = incr 2. Follow the steps outlined for database backups in Database backup with NetWorker User for Lotus on page 140. Connecting to a different NetWorker server To connect the NetWorker User for Lotus program to a different NetWorker server to back up files, use one of the following methods: If the NetWorker User for Lotus program is not already running, use the following command to start the NetWorker User for Lotus program and type the server s name: nwbml -s NetWorker_server where NetWorker_server is the name of the NetWorker server to back up the files. If the NetWorker User for Lotus program is already running: a. In the NetWorker User for Lotus program, select Select NetWorker Server from the Operation menu. The Change Server dialog box opens. b. In the Change Server dialog box: Either select the server from the list or type the name of the server, and click OK. To refresh the list of NetWorker servers, click Update List. To change the default NetWorker server that the NetWorker User for Lotus uses to back up files: a. Right-click the NetWorker User for Lotus program icon, and select Properties from the menu. b. In the Properties window, type the following in the Target text box on the Shortcut tab: -s NetWorker_server where NetWorker_server is the name of the NetWorker server to back up the files, as shown in Figure 5 on page 143. 142 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Figure 5 NetWorker User for Lotus Properties window Oracle manual backup Ensure that the Oracle manual backup is configured according to Configuring Oracle backups on page 103. Perform an Oracle manual backup through either of the following methods: Oracle manual backup through the RMAN command line interface on page 144 Oracle manual backup through Oracle Enterprise Manager on page 144 Cancel an Oracle manual backup according to Cancel a manual backup on page 151. Manual backup procedures 143

Backup Procedures Oracle manual backup through the RMAN command line interface You can perform an Oracle manual backup by invoking the command line RMAN utility to run the RMAN backup script on the Oracle Server host. If the RMAN script for a manual backup from Example 9 on page 104 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 sys/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. Oracle manual backup through Oracle Enterprise Manager The NMDA software considers a backup scheduled through Oracle Enterprise Manager to be a manual backup. You can perform an Oracle manual backup by invoking the Oracle Enterprise Manager Backup Management Tools to run the RMAN backup script. The 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 NMDA 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 documentation provides more information on using the Oracle Enterprise Manager. Sybase manual backup Ensure that the Sybase manual backup is configured according to Configuring Sybase backups on page 112. To prepare for the Sybase manual backup, run a database consistency check according to Sybase database consistency check on page 144. Perform the Sybase manual backup through either of the following methods: Sybase manual backup through the nsrdasv command on page 145 Sybase manual backup through NetWorker User for Sybase (Windows only) on page 146 Sybase database consistency check Use the nsrsybcc command to perform the required database consistency check before you start a Sybase manual backup. The nsrsybcc command can perform the following types of consistency checks: dbcc checkalloc dbcc checkcatalog dbcc checkdb 144 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures dbcc checkdb (skip_ncindex) dbcc checkstorage If you do not include the -o option to specify the type of consistency check, then the nsrsybcc command performs the following: The dbcc checkstorage check when the dbccdb database is set up. The dbcc checkcatalog, dbcc checkalloc, and dbcc checkdb checks when the dbccdb database is not set up. Perform a database consistency check by typing the appropriate nsrsybcc command at the command line as the Sybase user: nsrsybcc -U user_id -P password -o dbcc_option SYBASE:/ASE_server_name[/database_name] where: user_id is the username of the Sybase user account. password is the password of the Sybase user account. dbcc_option is the option that specifies the type of database consistency check, as described in Table 17 on page 145. ASE_server_name is the Sybase server name. database_name is the name of the database on the Sybase server. Note: If you specify the Sybase server name only, SYBASE:/ASE_server_name, with the nsrsybcc command (without specifying a database name), the command performs a consistency check of every database on the Sybase server. If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, the command name is nsrsybcc32 instead of nsrsybcc. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. Table 17 Consistency check options of the nsrsybcc command -o option of narsybcc command Database consistency check performed by nsrsybcc command -o ckdb dbcc checkdb check -o ckal dbcc checkalloc check -o ckcat dbcc checkcatalog check -o ckdbnoidx dbcc checkdb (skip_noindex) check -o ckstor dbcc checkstorage check Note: Ensure that the dbccdb database is set up. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybcc command syntax and options. The Sybase documentation provides more details on performing a database consistency check. Sybase manual backup through the nsrdasv command Ensure that the NSR_BACKUP_PATHS parameter is set in the NMDA configuration file to specify the Sybase server instance or Sybase databases to be backed up. NSR_BACKUP_PATHS on page 374 provides more details. Manual backup procedures 145

Backup Procedures You can perform a Sybase manual backup by typing the appropriate nsrdasv backup command at the command line, as the Sybase operating system user: nsrdasv(.exe) -z config_filepath where config_filepath is the complete pathname of the NMDA configuration file that contains the parameter settings for the Sybase manual backup. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, replace nsrdasv(.exe) with nsrdasv32(.exe) in the backup command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. Cancel a Sybase manual backup that was started with the nsrdasv command according to Cancel a manual backup on page 151. Sybase manual backup through NetWorker User for Sybase (Windows only) As an alternative, you can perform a Sybase manual backup through the NetWorker User for Sybase program on Windows only. To start the NetWorker User for Sybase program, select Start > Programs > EMC NetWorker > NetWorker User for Sybase. Cancel a Sybase manual backup that was started from NetWorker User for Sybase according to Cancel a manual backup on page 151. About the Backup window You can configure and run Sybase backups from the Backup window of the NetWorker User for Sybase program. To display the Backup window: 1. Perform one of the following in the NetWorker User for Sybase main window: From the Operation menu, select Backup. Click the Backup button. Press Alt+B. 2. If the Sybase Server Login dialog box appears (the first time you display the Backup window): a. Enter the required values in the Sybase Server Login dialog box: In the Server name text box, enter the Sybase server name. In the User ID text box, enter the user ID for the backup. In the Password text box, enter the password for the user ID. b. Click OK. Figure 6 on page 147 shows the Backup window of the NetWorker User for Sybase program. 146 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Figure 6 NetWorker User for Sybase Backup window To view a list of databases available for backup, select the Sybase server name in the left pane. The databases of the Sybase server appear in the right pane. Right-clicking an item in either pane of the Backup window displays a pop-up menu with the following options: Start Starts the backup operation. Font Change the font of the display. Backup Options Displays the Backup Options dialog box. Table 18 on page 147 describes the Backup window toolbar buttons. Table 18 Toolbar buttons on the NetWorker User for Sybase Backup window Button Operation Description Mark Marks the selected (highlighted) files for backup. Unmark Clears the selected (marked) files. Backup Options Start Displays the options for backup levels, data compression, truncation of transaction logs, striping during backups, and volume pools to use for data and log backups. Starts the backup of marked files. Manual backup procedures 147

Backup Procedures Database backup with NetWorker User for Sybase To perform a Sybase manual backup of specific databases with the NetWorker User for Sybase program: 1. Ensure that the services on the NetWorker server are running. 2. In the NetWorker User for Sybase window, open the Backup window according to the instructions in About the Backup window on page 146. Note: The first time you open the Backup window, you must enter the required values in the Sybase Server Login dialog box. The Backup window appears as shown in Figure 6 on page 147. 3. Specify the databases to back up by using one of the following methods: Select the databases, and click the Mark toolbar button. Select the checkbox (add a check mark) beside each database. To unmark databases, use one of the following methods: Select the marked databases, and click the Unmark toolbar button. Clear the checkboxes (remove the check marks) beside the databases. 4. To specify the required backup options: a. In the Backup window, select Backup Options from the Options menu. The Backup Options dialog box opens, as shown in Figure 7 on page 149. b. Select the appropriate options in the Backup Options dialog box: Full backup Specifies that NMDA backs up the selected databases and their transaction logs, and then truncates the transaction logs. Incremental backup Specifies that NMDA backs up the transaction logs of the selected databases, and then truncates the transaction logs. Compress Specifies that NMDA compresses the backup data. Use Dump Options Specifies that NMDA applies the selected truncation option for the transaction logs. You must select one of the following truncation options: TRUNCATE_ONLY dump before backup NMDA truncates all committed transactions in the transaction logs before backup, and then backs up both the databases and transaction logs. NO_TRUNCATE dump before backup NMDA keeps the transaction logs from being truncated during the backup. NO_LOG dump before backup NMDA truncates the transaction logs before backup, and then backs up only the databases. Note: Truncation of a log before backup creates a gap in the log, so that previous log backups cannot be used to roll forward past the log truncation point. Use striped dump Specifies that NMDA enables striping during the backup. Specify the appropriate value for Stripe count. Use Pools Specifies that NMDA uses the given volume pools for database and log backups. You must specify the pool names as follows: Data pool Pool to use for full (database) backups. Log pool Pool to use for incremental (transaction log) backups. c. Click OK. 148 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Figure 7 NetWorker User for Sybase Backup Options dialog box 5. To start the backup, click the Start toolbar button. The Backup Status window opens and displays information about the backup operations performed, as shown in Figure 8 on page 150. Manual backup procedures 149

Backup Procedures Figure 8 NetWorker User for Sybase Backup Status window Full or incremental backups with NetWorker User for Sybase The NMDA software supports full and incremental level backups with the NetWorker User for Sybase program. To specify the level of Sybase manual backup from the NetWorker User for Sybase program: 1. In the Backup window, select Backup Options from the Options menu. The Backup Options dialog box opens, as shown in Figure 7 on page 149. 2. Select the appropriate option in the Backup Options dialog box: Full backup Specifies that NMDA backs up the selected databases and their transaction logs, and then truncates the transaction logs. Incremental backup Specifies that NMDA backs up the transaction logs of the selected databases, and then truncates the transaction logs. 3. Click OK. 4. Follow the steps outlined for database backups in Database backup with NetWorker User for Sybase on page 148. Connecting to a different NetWorker server To connect the NetWorker User for Sybase program to a different NetWorker server to back up files, use one of the following methods: If the NetWorker User for Sybase program is not already running, use the following command to start the NetWorker User for Sybase program and connect to the specified server: nwbms -s NetWorker_server_name where NetWorker_server_name is the name of the NetWorker server to back up the files. 150 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures If the NetWorker User for Sybase program is already running: a. In the NetWorker User for Sybase program, select Select NetWorker Server from the Operation menu. The Change Server dialog box opens. b. In the Change Server dialog box: 1. If required, click Update List to refresh the list of NetWorker servers. 2. Either select the server from the list or type the name of the server. 3. To specify that the server be used as the default NetWorker server by the NetWorker User for Sybase, select Save as Default Server. 4. Click OK. Cancel a manual backup To cancel a manual backup, follow the instructions in the appropriate section: Cancel a manual backup from the command line on page 151 Cancel a Lotus manual backup from NetWorker User for Lotus on page 152 Cancel a Sybase manual backup from NetWorker User for Sybase on page 152 Cancel a manual backup from the command line This section describes how to cancel any of the following manual backups: DB2 manual backup Informix manual backup Lotus manual backup started with the nsrdasv command Oracle manual backup, not including a backup initiated by Oracle Enterprise Manager Note: Cancel an Oracle manual backup on page 151 provides additional details on canceling an Oracle manual backup. Sybase manual backup started with the nsrdasv command To cancel any of these manual backups, do either of the following: Press Ctrl+C. Press the equivalent attention key combination on the system. Note: If the backup is canceled before completion, some of the backed-up data may be recoverable. Restart the canceled backup process from the beginning, and ensure that the backup successfully completes without interruption. Cancel an Oracle manual backup 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 an Oracle manual backup. NetWorker user group privileges on page 72 provides more information. If the method of canceling the Oracle backup described in Cancel a manual backup from the command line on page 151 is not successful, use the alter system kill command described in Cancel a scheduled backup on page 157. Manual backup procedures 151

Backup Procedures Cancel a nonresponding Oracle manual backup The following are the steps for canceling a nonresponding Oracle manual backup. However, if these steps do not work, contact Oracle for assistance. Note: When using these steps, NMDA 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 manual 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 10 on page 105 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 backup process: kill -9 pid where pid is the appropriate backup process ID. To cancel a nonresponding Oracle manual backup on Windows, stop the nsrsbtcn.exe process in Task Manager. Cancel a Lotus manual backup from NetWorker User for Lotus To cancel a Lotus manual backup in progress from the NetWorker User for Lotus program on Windows only, select End Backup from the File menu. Cancel a Sybase manual backup from NetWorker User for Sybase To cancel a Sybase manual backup in progress from the NetWorker User for Sybase program on Windows only, select End Backup from the File menu. Perform a NetWorker bootstrap and index 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 their respective states just before the bootstrap was created. At the end of a scheduled backup, the NetWorker server automatically performs a backup of the bootstrap and client indexes of the database or application host. Manual backups do not back up the bootstrap and client indexes. Note: If only manual backups are run, and the bootstrap and client indexes are not backed up manually, then no backups of the bootstrap and client indexes will be available for use in the event of a disaster recovery on the NetWorker server. After completing a manual backup, manually back up the NetWorker bootstrap and client indexes according to Back up the NetWorker server bootstrap and indexes on page 153. 152 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Back up the NetWorker server bootstrap and indexes To back up the NetWorker server bootstrap and indexes: 1. Log in as the root user (UNIX) or Microsoft Administrator user (Windows) on the NetWorker server. 2. Type the following savegrp command at the operating system command line: savegrp -O -l full -P printer_name -c client_hostname -s 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. client_hostname is the hostname of the database or application host. NetWorker_server_name is the hostname of the NetWorker server. After a successful backup of the bootstrap and indexes with the savegrp command: Confirmation of the savegrp completion appears in the NMC 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 that were backed up during the past month. With this information, you can 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: EMC NetWorker Administration Guide savegrp entry in the EMC NetWorker Command Reference Guide savegrp man page on UNIX The EMC NetWorker Administration Guide provides information on bootstrap backups. The EMC NetWorker Disaster Recovery Guide provides information on how to use the bootstrap backup during a disaster recovery. Monitor a manual backup At the command line or GUI where you start a manual NMDA backup, operational messages are displayed about the status of the backup. To monitor the status of the manual backup, you can also use the NMC program, which provides a centralized view of all the NetWorker server backup and restore activity. The NMC program also shows operations related to devices and libraries, and managed events that require user intervention. The NMC program displays progress and completion messages that advise when a backup is complete, and information on why a backup cannot proceed. The EMC NetWorker Administration Guide provides more information on viewing these types of messages with the NMC program. Monitor an Informix backup from the Informix server on page 159 provides additional information about monitoring Informix backups. Appendix D, Troubleshooting and Error Messages, provides information on how to obtain diagnostic and error messages. Manual backup procedures 153

Backup Procedures The following figures use an Oracle backup with NMDA as an example, and show the types of backup messages displayed in the Monitoring window of the NMC release 7.5 program: Figure 9 on page 154 shows messages displayed in the Sessions tab. Figure 10 on page 155 shows messages displayed in the Devices tab. Figure 11 on page 155 show messages displayed in the Log tab. The EMC NetWorker Administration Guide and NMC online help provide details on viewing information about backups in the NMC program. Figure 9 Backup messages in Sessions tab of Monitoring window 154 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Figure 10 Backup messages in Devices tab of Monitoring window Figure 11 Backup messages in Log tab of Monitoring window Manual backup procedures 155

Backup Procedures Scheduled backup procedures The following sections provide details on NMDA scheduled backup procedures. Scheduled backups versus manual backups on page 25 describes the differences between NMDA scheduled and manual (unscheduled) backups. Prepare for a scheduled backup An NMDA scheduled backup is initiated by the NetWorker server according to the backup schedule. To prepare for an NMDA scheduled backup: 1. Ensure that the required backup configurations are in place, including any preprocessing and postprocessing scripts (optional), as described in Software configuration roadmap on page 70. Note: The parameters NSR_SERVER and NSR_GROUP must not be set in the following locations: - For non-oracle backups, in the NMDA configuration file. - For Oracle backups, in the RMAN script. NMDA automatically passes server and group information received from the NetWorker server that started the backup to the database or application server processes. 2. Run a test scheduled backup according to Test a scheduled backup on page 156. Note: While the scheduled backup is configured as part of step 1, you can use the procedure in Test a scheduled backup on page 156 to test-run the backup before it is started on the schedule. 3. Review the steps for canceling a scheduled backup in Cancel a scheduled backup on page 157.! IMPORTANT At the end of a successful Oracle scheduled backup only, NMDA automatically backs up the NWORA resource file if it exists, as described in NWORA resource file backup on page 302. Monitor a scheduled backup on page 159 provides information on how to monitor the status of scheduled backups. Verifying the backup information in NetWorker indexes on page 161 describes the backup information stored in the NetWorker indexes. Test a scheduled backup After the NMDA environment and configuration for a scheduled backup is set up, test the scheduled backup manually by using the NMC program. Before performing a scheduled backup test, ensure that you have properly prepared for the backup according to Prepare for a scheduled backup on page 156. 156 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures To test the scheduled backup: 1. In your web browser, go to the URL http://nmc_server_name:9000 (the default port is 9000), and log in to the NMC console server. 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 server immediately backs up the clients in the backup group at the specified backup level (for example, full). The EMC NetWorker Administration Guide and NMC online help provide information on how to use the NMC interface to perform these steps. The scheduled backup results are provided in the following: NMC Monitoring window Savegroup completion report in email Cancel a scheduled backup on page 157 provides information on how to cancel the scheduled backup. Scheduled backup error messages If the scheduled backup fails, an error message is produced. The EMC NetWorker Administration Guide provides information on how to obtain more details about the scheduled backup by using the NMC program. For additional debug information, set the NSR_DEBUG_LEVEL parameter through one of the following methods: Use the configuration wizard to set the parameter in the Advanced Environment Options field on the appropriate wizard screen. Set the parameter in the NMDA configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details on NMDA parameters. Appendix D, Troubleshooting and Error Messages, provides more information on debug logs and troubleshooting. Cancel a scheduled backup To cancel a scheduled backup, follow the instructions in the appropriate section: Cancel a DB2, Informix, Lotus, or Sybase scheduled backup on page 157 Cancel an Oracle scheduled backup on page 158 Cancel a DB2, Informix, Lotus, or Sybase scheduled backup To cancel a DB2, Informix, Lotus, or Sybase scheduled backup in progress: 1. Start the NMC program. 2. Select the backup group in the monitor view. 3. Right-click the group to stop, and select Stop. Scheduled backup procedures 157

Backup Procedures Note: If a backup is canceled before completion, some of the backed-up data may be recoverable. To manually start a canceled backup from the beginning, right-click the group to start, and select Start. Ensure that the backup successfully completes without interruption. The EMC NetWorker Administration Guide provides details on how to stop a group. Cancel an Oracle scheduled backup 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 an Oracle scheduled backup. NetWorker user group privileges on page 72 provides more information. NMDA supports the use of the Stop button in the NMC program to cancel an Oracle scheduled backup. To cancel an Oracle scheduled backup in progress when the Stop button does not work, the running rman process must be interrupted on the Oracle Server host: 1. In the NMC program, click Stop to prevent NMDA from retrying the backup. 2. For each allocated channel, do the following: a. View the RMAN message log file to determine the Oracle session ID for the channel. The log filename is specified with the NSR_RMAN_ARGUMENTS parameter, set either through the Advanced Environment Options field in the wizard, or through the NMDA configuration file in a nonwizard configuration. 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 Oracle manual backup on page 152 describes how to also cancel a nonresponding Oracle scheduled backup. 158 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Monitor a scheduled backup Scheduled backups can be monitored the same way as manual backups. Monitor a manual backup on page 153 provides more information. In addition, messages appear in the appropriate Group window in the NMC program, and a report is generated upon completion of a scheduled backup. Information about scheduled NMDA backups is displayed on the Groups and Sessions tabs of the Monitoring window in the NMC program: Note: Depending on the NMC release, the names and locations of the tabs might be different in the NMC program. The NMC documentation provides more details. The Sessions tab lists the save sessions during the NMDA backup. The display shows the rate of data being backed up and total size of the backed-up data. During and after the backup, the Groups tab enables you to select the backup group and display details about the group. The Details window displays details of backups that are currently running, successfully completed, and failed. Figure 12 on page 160 uses an Oracle backup with NMDA as an example, and 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 protected by the deduplication backup. The display does not indicate that the data is for a deduplication backup that is stored on the Avamar server. The EMC NetWorker Administration Guide provides details on viewing information about scheduled backups in the NMC program. Monitor an Informix backup from the Informix server In addition to monitoring an Informix backup from NMC, you can use the ON-Bar activity log to monitor the backup from the Informix server. As ON-Bar backs up data, it periodically writes to the ON-Bar activity log. For example, when ON-Bar encounters an error or a warning condition, it writes a message to the activity log. The activity log also documents which storage spaces and logical logs were included in a backup, and the approximately how long the backup took to complete. Use the information in the activity log to determine whether a backup succeeded. You can specify the location of the activity log in the BAR_ACT_LOG configuration parameter in the IDS ONCONFIG file. The Informix IDS documentation provides more details. Scheduled backup procedures 159

Backup Procedures Figure 12 Group details for regular scheduled backups 160 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures Verifying the backup information in NetWorker indexes The following sections describe how to verify the backup information that is stored in the NetWorker online indexes for both regular and deduplication backups. Regular backup information in NetWorker indexes The NetWorker server maintains information about each backup in its online indexes. NetWorker indexes and policies used for restores on page 166 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 162 describes information about deduplication backups. 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 NMDA_client_hostname Note: To query the client file index for a different type of database or application backup, replace oracle with db2, informix, notes, or sybase after the -n option, as appropriate. To query the media database, use the mminfo command. For example: mminfo -v -s NetWorker_server_hostname -c NMDA_client_hostname The EMC NetWorker Command Reference Guide and the UNIX man pages provide more information on these NetWorker commands. The following examples show the command output for an Oracle backup with NMDA, where the backup piece is named 1hiu83f4_1_1: 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 2009 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 NMDA.001 ca-oracle1 12/11/09 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 (for an Oracle backup only) 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 backup save time. For example: mminfo -c ca-oracle1 -t 1192133159 nsrinfo -n oracle -t 12/11/09 16:05:59 ca-oracle1 Verifying the backup information in NetWorker indexes 161

Backup Procedures Deduplication backup information in NetWorker indexes This section describes information that is maintained in the NetWorker indexes for NMDA deduplication backups, and how to use NetWorker commands to query the index information. The following examples show the index query results from the nsrinfo and mminfo commands: The following nsrinfo query shows the information that is stored in the client file index for an NMDA deduplication backup of Lotus data: nsrinfo -n notes -vv win3e10-nml80 XBSA file 'NOTES:/C:/Program Files/IBM/Lotus/Domino/data/events4.nsf', size=404, off=404, app=notes(17), date=1236960727 3/13/2009 11:12:07 AM, copyid = 1236960727.1236960729 In this case, the size of the backup file, bolded in this nsrinfo output, is the size of the metadata (hash information) that is stored on the NetWorker backup media for the deduplication backup. To query the media database, use the mminfo command with the following options: -q dedupe option Displays only the save sets created through deduplication. -S option Lists the extended options for each save set in the save set completion report. The following mminfo query shows the information stored in the media database for an NMDA deduplication backup of Lotus data: mminfo -S -q dedupe ssid=3585770967 savetime=3/13/2009 11:12:06 AM (1236960726) win3e10-nml80:notes: level=full sflags=vf size=1608 files=4 insert=3/13/2009 create=3/13/2009 complete=3/13/2009 browse=4/13/2009 11:59:59 PM retent=3/13/2010 11:59:59 PM clientid=292ecd0b-00000004-49b194cd-49b194cb-00020c00-729b1c29 *Client path: /NetWorker/win3e10-nw75/win3e10-nml80; *Data set size: 71041152; *De-Dup session id: 158; *De-Dup snapup time: 2009-03-13; *De-duplication: Yes; *De-duplication host: bu-doppelganger.lss.emc.com; *Domain: /NetWorker/win3e10-nw75; *New data on De-Dup Node: 10483991.00; *New files: 4; *Size on De-Dup Node: 71041152.00; group: nml80; Clone #1: cloneid=1236960727 time=3/13/2009 11:12:07 AM retent=3/13/2010 flags=f frag@ 0 volid=3602548168 file/rec=3585770967/0 rn=0 last=3/13/2009 The save file size reported by mminfo, bolded in this sample output, is the size of the NetWorker save set stored on the backup media that contains the metadata only for the deduplication backup. The extended attributes reported by mminfo provide information on the total data protected by NetWorker and stored on the Avamar server, and the new data passed to the Avamar server during the deduplication backup. 162 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Backup Procedures 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 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. Verifying the backup information in NetWorker indexes 163

Backup Procedures 164 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

4 Data Restore and Recovery This chapter includes the following major sections: About data restore and recovery... 166 DB2 data restore and recovery... 168 Informix data restore and recovery... 179 Lotus data recovery... 182 Oracle data restore and recovery... 202 Sybase data restore and recovery... 210 Data Restore and Recovery 165

Data Restore and Recovery About data restore and recovery This chapter describes how to configure and perform data restore operations, and recover a database to a consistent state. Unlike the NetWorker software, which uses the term recover for all backup retrieval activities, the NetWorker Module for Databases and Applications (NMDA) software distinguishes between the restore and recovery of a database: Restore means to retrieve individual datafiles from backup and store the files on disk. Recover means to apply the transaction, redo, or logical logs to make the database consistent. Only the following data can be restored through the NMDA software: Data that has been backed up according to the instructions in Chapter 3, Backup Procedures. Data that has been backed up with a legacy NetWorker module that NMDA supports. Note: The NetWorker server interface or recover program cannot be used to restore data that was backed up with the NMDA software. To prepare for data restore and recovery, review the information in NetWorker indexes and policies used for restores on page 166. To restore and recover data, follow the appropriate instructions: DB2 data restore and recovery on page 168 Informix data restore and recovery on page 179 Lotus data recovery on page 182 Oracle data restore and recovery on page 202 Sybase data restore and recovery on page 210 NetWorker indexes and policies used for restores During an NMDA backup, the NetWorker server adds an entry for each backup object, such as a Lotus datafile or Oracle backup piece, in the online client file index and records information about each save set in the media database. These entries provide information required for restores: The client file index entry is maintained until the browse policy specified for the backup object expires. The media database entry is maintained until the retention policy specified for the client s save set expires. The browse and retention policy values are set in either of the following: NetWorker Client resource NSR_SAVESET_BROWSE and NSR_SAVESET_RETENTION parameters The lifecycle of a backup save set, during which the backup data may be recovered, is defined by the browse and retention policy settings. 166 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery When the browse policy expires, the entry is immediately removed from the client file index. 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. NMDA uses both the client file index and media database entries to restore the backed-up data. If any one of them is missing, the restore fails. To prevent such a failure: Set the browse policy to a period long enough to retain the client index entries for restoring the data. Set the retention policy to a period that is equal to or longer than the browse policy period. After a browse policy expires or the NetWorker indexes are lost, the NetWorker scanner program can be used to rebuild the indexes. Note: For Oracle backups, index entries regenerated by using scanner might cause the NetWorker indexes to become unsynchronized with the Oracle RMAN catalog and lead to problems. To avoid problems, ensure that the Oracle backup pieces have unique names, as described in RMAN scripts for manual backups on page 103. The EMC NetWorker Administration Guide provides more information on how the NetWorker server uses browse and retention policies to manage backup data and track the location and status of the data on backup volumes. About data restore and recovery 167

Data Restore and Recovery DB2 data restore and recovery To perform a restore and recovery of DB2 data: 1. Prepare for the DB2 restore and recovery by reviewing Requirements for DB2 data restore on page 168. 2. Perform the DB2 data restore and recovery through one of the following methods: Recover DB2 data to the same instance on page 170 Recover DB2 data to a different instance on page 171 Recover DB2 data with rollforward of transaction logs on page 174 Requirements for DB2 data restore Before starting a DB2 data restore, ensure that the required configurations and volumes are in place: The DB2 system is properly configured according to the appropriate DB2 documentation. The NMDA parameters required for the restore are set in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. These parameters are mandatory for specific restores: NSR_CLIENT Set for a redirected restore to a different host. NSR_NWPATH Set for a deduplication restore if the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location. NSR_SERVER Set to the name of the NetWorker server for the client. The volume required for the restore 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 number of devices and session to use for the DB2 restore, you can use the method described in Determine how many restore devices and sessions to use on page 168. Determine how many restore devices and sessions to use If multiple devices and multiple sessions were used to perform a DB2 backup, use the same number of devices and sessions for the DB2 restore operation.! IMPORTANT Restore with only one session per device. Restoring with multiple sessions per device can severely affect recovery performance. 168 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery To determine the number of sessions that were used for the DB2 backup, use the nsrinfo command: # nsrinfo -s server -n db2 -X all client grep sample where: server is the NetWorker server hostname. client is the NetWorker client hostname. sample is the name of the database. For example: # nsrinfo -s bu-deerlake -n db2 -X all bu-baby grep SAMPLE scanning client `bu-baby' for all savetimes from the db2 namespace on server bu-deerlake version=1, DB2, objectname=/sample/node0000 /DB_BACKUP.20090914101237.3, createtime=mon Sep 14 10:12:39 2009, copytype=bsacopytype_backup, copyid=1252937559.1252937560, restoreorder=1252937559.1, objectsize=0.0, resourcetype=database, BSAObjectType_DATABASE, BSAObjectStatus_ACTIVE, description=nmda_v10:db2_v952:full_backup:sample:tne, objectinfo=db2inst1:3 version=1, DB2, objectname=/sample/node0000 /DB_BACKUP.20090914101237.2, createtime=mon Sep 14 10:12:38 2009, copytype=bsacopytype_backup, copyid=1252937558.1252937559, restoreorder=1252937558.1, objectsize=0.0, resourcetype=database, BSAObjectType_DATABASE, BSAObjectStatus_ACTIVE, description=nmda_v10:db2_v952:full_backup:sample:tne, objectinfo=db2inst1:3 version=1, DB2, objectname=/sample/node0000 /DB_BACKUP.20090914101237.1, createtime=mon Sep 14 10:12:37 2009, copytype=bsacopytype_backup, copyid=1252937557.1252937558, restoreorder=1252937557.1, objectsize=0.0, resourcetype=database, BSAObjectType_DATABASE, BSAObjectStatus_ACTIVE, description=nmda_v10:db2_v952:full_backup:sample:teq, objectinfo=db2inst1:3 3 objects found The objectinfo value shows the number of sessions. For example: objectinfo=db2inst1:3 where: db2inst1 is the name of the database instance that was backed up. 3 is the number of sessions that were used for the backup. A restore operation for this example would use three sessions and three devices with one session per device. Configure a DB2 parallel (multiple session) backup on page 95 provides details on multiple sessions. DB2 data restore and recovery 169

Data Restore and Recovery Recover DB2 data to the same instance Use the procedure in this section to recover a DB2 database or tablespace to either of the following: To the same database name under the same instance. To a different database name under the same instance. To recover DB2 data to either the same or a different DB2 server host: 1. Ensure the following parameter settings in the NMDA configuration file: NSR_SERVER Set to the name of the NetWorker server for the client. NSR_CLIENT Set to the name of the NetWorker client that was backed up. NSR_CLIENT must be set for the restore only if NSR_CLIENT was set during the backup, or if data is restored to a different host than the one that was backed up. Note: Any parameters set in the configuration file that are not required for an operation are ignored. For example, the same configuration file may be used for manual, cluster, and DPF backups as well as for restore operations. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. 2. (Optional) If restoring the most recent backup of the database or tablespace, then skip this step. Otherwise, if recovering the data to a particular point in time, note the timestamp of the backup to restore. If the timestamp of the backup is unknown, then find it by a query of all backups with the following command: $ db2 list history backup all for sample where sample is the name of the database to be restored. 3. (Optional) If multiple sessions were used for the backup, note the number of sessions used. This value will be specified as the open sessions value in the db2 restore command. Determine how many restore devices and sessions to use on page 168 provides details. 4. (Optional) To redirect the restored data to a different DB2 server host (NetWorker client) than the original host, modify the NetWorker Client resource of the original host: Note: This step is used, for example, in disaster recovery, where the original DB2 server host (NetWorker client) is unavailable, and the data is to be recovered to a different host instead. Chapter 5, Disaster Recovery, provides more details. a. Start the NMC program, and open the NetWorker Client resource for the original host that was backed up. b. Set the Remote Access attribute to the name of the target DB2 server host (NetWorker client), in the form of username@host. 170 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 5. On the DB2 server host where the data is to be restored, type the db2 restore command appropriate for the operating system: On UNIX: $ db2 restore db sample load /usr/lib/libnsrdb2.xx open sessions n options @pathname/nmda_db2.cfg taken at yyyymmddtttt into sample2 On Microsoft Windows: $ db2 restore db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll open sessions n options @pathname\nmda_db2.cfg taken at yyyymmddtttt into sample2 where: sample is the name of the database to be restored. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. n is the number of restore sessions, if multiple sessions were used for the backup. This may be a value from 1 to the number determined in step 3. Note: Use only one restore device per restore session. pathname\nmda_db2.cfg is the complete pathname of the NMDA configuration file. yyyymmddtttt is the timestamp of the backup to restore, as noted in step 2. The taken at parameter should be skipped if restoring only the most recent backup of a database or tablespace. sample2 is the new name of the database, if restoring to a different database name. The into parameter should be skipped if restoring the database to its original database name. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. 6. If the data was restored to a new host, ensure that the new host is properly specified with a NetWorker Client resource. The DB2 documentation provides more information about the db2 restore command. Recover DB2 data to a different instance Use the procedure in this section to recover a DB2 database or tablespace to either of the following: To the same database name under a different instance. To a different database name under a different instance. DB2 data restore and recovery 171

Data Restore and Recovery To recover DB2 data to either the same or a different DB2 server host: 1. Set the following parameters in the NMDA configuration file: NSR_SERVER Set to the name of the NetWorker server for the client. NSR_CLIENT Set to the name of the NetWorker client that was backed up. NSR_CLIENT must be set for the restore only if NSR_CLIENT was set during the backup, or if data is restored to a different host than the one backed up. Note: Any parameters set in the configuration file that are not required for an operation are ignored. For example, the same configuration file may be used for manual, cluster, and DPF backups as well as for restore operations. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. 2. (Optional) If restoring the most recent backup of the database or tablespace, then skip this step. Otherwise, if recovering the data to a particular point in time, note the timestamp of the backup to restore. If the timestamp of the backup is unknown, then find it by a query of all backups with the following command: $ db2 list history backup all for sample where sample is the name of the database to be restored. 3. (Optional) If multiple sessions were used for the backup, note the number of sessions used. This value will be specified as the open sessions value in the generated redirection script. Determine how many restore devices and sessions to use on page 168 provides details. 4. On a DB2 server, generate a redirection script from the instance that backed up the database. Use the appropriate command for the operating system: On UNIX: $ db2 restore db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg redirect generate script pathname/my_redirect.ddl On Microsoft Windows: $ db2 restore db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg redirect generate script pathname\my_redirect.ddl where: sample is the name of the database to be restored. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. 172 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery pathname/nmda_db2.cfg is the complete pathname of the NMDA configuration file. pathname/my_redirect.ddl is the complete pathname of the generated redirect script. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. Note: Ensure that the new instance has read and write permission to the script. The DB2 Data Recover and High Availability Guide provides more information. 5. Grant the new instance (for example, db2inst2) permission to restore the database: a. Start the NMC program, and open the NetWorker Client resource for the original host that was backed up. b. In the Application Information attribute, set the following: DB2_R=sample:db2inst1:db2inst2: where: sample is the database name. db2inst1 and db2inst2 are the names of the instances permitted to restore the database, in this example the old (db2inst1) and new (db2inst2) instances. Note: Separate each instance with a colon (:) and insert a colon after the last instance. The Configure NetWorker privilege is required to modify the Application Information attribute. 6. Edit the generated script, and define the following parameters: OPTIONS (required) Complete pathname of the NMDA configuration file. ON (required) Complete pathname of the new database instance. INTO New database name, if redirecting the recovery to a new name. TAKEN AT Timestamp of the backup to recover, yyyymmddtttt, if restoring the data to a particular point in time, as noted in step 2. OPEN SESSIONS Number of restore sessions, if multiple sessions were used for the backup, as determined in step 3. Use only one restore device per restore session. For example: OPTIONS @/bigspace/home/db2inst2/nmda_db2.cfg ON /bigspace/home/db2inst2 INTO sample2 Note: If DMS tablespaces were created with the backup, you may need to set the SET TABLESPACE CONTAINERS parameter to the appropriate value. The DB2 Data Recover and High Availability Guide provides more information. DB2 data restore and recovery 173

Data Restore and Recovery 7. (Optional) To redirect the restored data to a different DB2 server host (NetWorker client) than the original host, modify the NetWorker Client resource: Note: This step is used, for example, in disaster recovery, where the original DB2 server host (NetWorker client) is unavailable, and the data is to be recovered to a different host instead. Chapter 5, Disaster Recovery, provides more details. a. Start the NMC program, and open the NetWorker Client resource for the client that was backed up. b. In the Remote Access attribute, specify the name of the target DB2 server host (NetWorker client), in the form of username@host. 8. On the DB2 server host, under the redirected different instance where the data is to be restored, run the redirection script: $ db2 -tvf my_redirect.ddl where my_redirect.ddl is the name of the generated redirection script. 9. If the data was restored to a different host, ensure that the new host is properly specified with a NetWorker Client resource. The DB2 Data Recover and High Availability Guide provides more details on data recovery to a different database instance. Recover DB2 data with rollforward of transaction logs Recover DB2 data with the stored transaction logs Restore and recover a DB2 database or tablespace with rollforward of DB2 transaction logs through one of following methods: Recover DB2 data with the stored transaction logs on page 174 Recover DB2 data with the fetched logs on page 175 Recover DB2 data with the db2 recover command on page 177 Note: In order to use rollforward recovery, the NMDA software must have backed up DB2 transaction logs. DB2 transaction log backups on page 35 provides details. The conventional DB2 method of rollforward recovery of a restored database applies the transaction logs that are stored on the backup media. To recover DB2 data with the stored transaction logs: 1. Use the db2 restore command and options appropriate for the host operating system to restore the full backup of the database or tablespace. The following sections provide more details: Recover DB2 data to the same instance on page 170 Recover DB2 data to a different instance on page 171 174 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery The following are examples: On UNIX: $ db2 restore db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg On Microsoft Windows: $ db2 restore db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg where: sample is the name of the database or tablespace to be restored. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname\nmda_db2.cfg is the complete pathname of the configuration file. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. Note: If the restored database or tablespace contains the needed data, then the recovery procedure is complete. Rollforward updates of the restored data, described in the next step, will not be necessary. Recover DB2 data with the fetched logs 2. Complete the recovery by updating the database with the transaction logs. To apply all transactions to the end of the logs, use the following command: $ db2 rollforward db sample to end of logs and complete To apply all transactions to a specific point in time, use the following command: $ db2 rollforward db sample to yyyy-mm-dd.hh.mm.ss using local time The DB2 documentation provides additional details on the db2 restore and db2 rollforward commands. Note: In order to use rollforward recovery, the NMDA software must have backed up DB2 transaction logs. DB2 transaction log backups on page 35 provides details. The fetched logs method of rollforward recovery of a database offers convenience and speed. It uses a local copy of the DB2 transaction logs, which is retrieved or fetched from the NetWorker server. This method facilitates the selection of specific logs to apply to the recovery, and can be faster than the conventional method of using transaction logs stored on the backup media, especially tape media. DB2 data restore and recovery 175

Data Restore and Recovery To recover DB2 data with the fetched logs method: 1. Use the db2 restore command and options appropriate for the host operating system, to restore the full backup of the database or tablespace. The following sections provide more details: Recover DB2 data to the same instance on page 170 Recover DB2 data to a different instance on page 171 The following are examples: On UNIX: $ db2 restore db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg On Microsoft Windows: $ db2 restore db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg where: sample is the name of the database or tablespace to be restored. xx is the platform-specific extension: o (AIX) sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname\nmda_db2.cfg is the complete pathname of the configuration file. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. Note: If the restored database or tablespace contains the needed data, then the recovery procedure is completed. Rollforward updates of the restored data, described in the next steps, will not be necessary. 2. Run the nsrdb2rlog command to retrieve or fetch a copy of the DB2 transaction logs from the NetWorker server to a local file. Note: To list the logs on the NetWorker server, use the nsrinfo command. For example, to retrieve all the transaction logs for a database, to the end of its logs, use the following command: $ nsrdb2rlog -s server -a sample -d destination_dir where: server is the name of the host on which the database resides. sample is the name of the database that the logs belong to. destination_dir is the directory where the log files are to be recovered. 176 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery The NMDA nsrdb2rlog man page and the EMC NetWorker Module for Databases and Applications Command Reference Guide provide more details on this command. 3. Complete the recovery by updating the database with the retrieved transaction logs. The following are examples of how to apply the transaction logs. To apply all transactions to the end of the logs, use the following command: $ db2 rollforward db sample to end of logs and complete overflow log path (c:\log_path) To apply all the transactions to a specific point in time, use the following command: $ db2 rollforward db sample to yyyy-mm-dd.hh.mm.ss using local time overflow log path (c:\log_path) where, in both of these examples: c:\log_path is the complete pathname of the retrieved transaction log file stored locally on the DB2 host. yyyy-mm-dd.hh.mm.ss is the date and time format. The DB2 documentation provides more details on the db2 restore and db2 rollforward commands. Recover DB2 data with the db2 recover command The db2 recover command combines the functions of the db2 restore and db2 rollforward commands. With this command, a backed-up database or tablespace may be restored complete with the transaction logs applied to a specified point in time. Use the db2 recover command and options appropriate for the host operating system, to recover the database or tablespace to the end of the logs or to a specific point in time. The following are examples: On UNIX: To apply all transactions to the end of the logs, use the following command: $ db2 recover db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg to end of logs and complete To apply transactions to a specific point in time, use the following command: $ db2 recover db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg to yyyy-mm-dd.hh.mm.ss using local time Microsoft Windows: To apply all transactions to the end of the logs, use the following command: $ db2 recover db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg to end of logs and complete To apply transactions to a specific point in time, use the following command: $ db2 recover db sample load NetWorker_install_dir\nsr\bin\libnsrdb2.dll options @pathname\nmda_db2.cfg to yyyy-mm-dd.hh.mm.ss using local time where: sample is the name of the database or tablespace to be backed up. xx is the platform-specific extension: o (AIX) DB2 data restore and recovery 177

Data Restore and Recovery sl (HP-UX) so (Linux, Solaris, HP-UX IA64) Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname\nmda_db2.cfg is the complete pathname of the configuration file. yyyy-mm-dd.hh.mm.ss is the date and time format. NetWorker_install_dir is the path on Microsoft Windows systems where the NetWorker software is installed. The DB2 documentation provides additional information on the db2 recover command. 178 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Informix data restore and recovery To perform a restore and recovery of Informix database instances or individual database objects: 1. Prepare for the Informix restore and recovery by reviewing the following: Requirements for Informix data restore on page 179 Informix restore modes on page 180 2. Perform the Informix data restore and recovery through one of the following methods: Informix data restore through the onbar command on page 181 Informix data restore through the IECC on page 181 You can monitor Informix data restores by using either NMC or the ON-Bar activity log on the Informix server. Monitor an Informix backup from the Informix server on page 159 provides more details on the activity log, which ON-Bar uses to record the same type of information for both restore and backup operations. Imported restore of an Informix server on page 232 provides details on performing an imported restore to transfer all the data from one Informix server instance to the same instance on a different host, as used in a disaster recovery situation. Requirements for Informix data restore Before starting an Informix data restore, ensure that the required configurations and volumes are in place: The Informix system is properly configured according to the appropriate Informix IDS documentation. The required NMDA parameters are set in the environment, as described in to Informix-specific NMDA parameters on page 360. Note: Specific environment variables are required for restore operations. These NMDA parameters are mandatory for specific restores, and must be set in the environment, not in the NMDA configuration file: NSR_CLIENT Set to the hostname of the backup client. NSR_NWPATH Set for a deduplication restore if the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location. NSR_SERVER Set to the name of the NetWorker server for the client. The volume required for the restore 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. Informix data restore and recovery 179

Data Restore and Recovery Informix restore modes You can perform an Informix restore with the database server in one of three modes, cold, warm, or mixed. The ON-Bar utility maintains a history of backup and restore operations in the sysutils database, and stores an extra copy of the backup history in the emergency boot file: ON-Bar uses the sysutils database in a warm restore when only a portion of the data is lost. ON-Bar uses the emergency boot file in a cold restore when the sysutils database cannot be accessed. The Informix onsmsync utility is used to regenerate the emergency boot file and expire old backups. Depending on the command options used, the onsmsync utility removes the following items from the sysutils database and the emergency boot file: Backups that the NetWorker server has expired. Old backups based on the age of backup. Old backups based on the number of times they were backed up. The onsmsync utility expires items in the IDS backup catalog, based on information in the NetWorker indexes, but does not delete items in the NetWorker indexes. The NetWorker policies determine how long the NetWorker index items are retained. The three restore modes are as follows: Cold restore mode Restores both critical and noncritical data when the database server is offline. The cold restore consists of the following, in this order: 1. A physical and logical restore of the critical dbspaces. 2. A physical and logical restore of the noncritical dbspaces. After a cold restore completes, the database server is left in quiescent mode. Note: A cold restore of selected dbspaces succeeds only if the critical dbspaces are included on the restore command line. Critical dbspaces are defined as the root dbspace and any dbspace that contains either physical or logical logs. Warm restore mode Restores noncritical data while the database server is online or quiescent. The warm restore consists of the following, in this order: 1. One or more physical restores. 2. A closing and backup of the current logical log. 3. A logical log restore. Mixed restore mode Consists of the following, in this order: 1. A cold restore of the critical dbspaces, with the database server in offline mode. 2. A warm restore of noncritical dbspaces, with the database server in online or quiescent mode. A mixed restore enables the quick recovery of critical dbspaces, plus any data to which users require immediate access. Once the database server is returned to quiescent mode, you can perform a warm restore of the other dbobjects. The Informix Backup and Restore Guide provides details on the different restore modes. 180 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Informix data restore through the onbar command You can perform an Informix restore of database instances or database objects by typing the appropriate onbar command at the command line as the informix user, to run the ON-Bar utility. Use the appropriate settings and onbar command to perform the following types of restores: Physical restore Replaces lost or corrupted Informix dbobjects from the NetWorker backup media. You can perform this type of restore as a whole-system or selected-dbspace restore. The following are sample settings and the onbar command for a physical restore: NSR_SERVER=inentelictd1c INFORMIXDIR=C:\Progra~1\IBM\Informix ONCONFIG=ONCONFIG.inentelictd1c onbar -r -p [dbspace_name] Logical Restore Recovers the server transactions made since the last dbobject backup, followed by a rolling forward of the logical log files backed up for the dbobjects. If different backup sessions are involved, the log rolls forward transactions made since the backup time recorded for each dbobject restored. The following shows a sample setting and onbar command for a logical restore: NSR_SERVER=inentelictd1c onbar -r -l Combined Restore Enables you to issue a single command to perform a physical restore, immediately followed by a logical restore. The following shows a sample setting and onbar command for a combined restore: NSR_SERVER=inentelictd1c onbar -r [dbspace_name] Point-in-time restore Involves performing a whole-system physical restore of the database server data from a whole-system backup to a specified time instead of the default, which is the time of the last database server backup. The following shows a sample setting and onbar command for a point-in-time restore: NSR_SERVER=inentelictd1c onbar -r -t 2009-11-24 00:00 -w -p The Informix Backup and Restore Guide included with the Informix server software provides details on the onbar command and options. Informix data restore through the IECC You can perform an Informix restore of database server instances or database objects by invoking the Informix Enterprise Command Center (IECC) as the informix user, to run the ON-Bar backup utility. The Informix Backup and Restore Guide included with the Informix server software provides details on the use of IECC for restores. Informix data restore and recovery 181

Data Restore and Recovery Lotus data recovery To perform a recovery of Lotus data: 1. Prepare for the Lotus data recovery by reviewing the following: Requirements for Lotus data recovery on page 182 Considerations for Lotus DAOS recovery on page 183 Note: Review this section only if you must recover Lotus DAOS files. 2. Perform the Lotus data recovery through one of the following methods: Lotus database recovery through the nsrnotesrc command on page 183 Lotus database recovery through NetWorker User for Lotus on page 188 Document-level recovery through the nsrdocrc command on page 198 Document-level recovery through the Notes client GUI on page 200 Requirements for Lotus data recovery Before starting Lotus data recovery, ensure that the required configurations and volumes are in place: The Lotus system is properly configured according to the appropriate Lotus Domino or Notes documentation. For recovery operations with a Domino server on Linux or Solaris, the required environment settings are in place, according to Ensure the environment settings for Lotus operations on page 99. The NMDA parameters required for the restore are set in the NMDA configuration file, according to Appendix A, NMDA Parameters for Backups and Restores. These parameters are mandatory for specific restores: Notes_ExecDirectory Set for all Lotus restores. NSR_CLIENT Set for a redirected restore to a different host. NSR_NWPATH Set for a deduplication restore if the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location. NSR_SERVER Set for a restore if the NetWorker server host is different from the client host. Note: Setting NSR_NOTES_INI_PATH is also recommended for a Lotus restore. The volume required for the restore is mounted in a configured backup device. You cannot perform in-place recovery of a logged database when the original database is still present. In this case, perform one of the following: Delete the original database. Direct the recovery to a new directory with the NSR_RELOCATION_DEST parameter, and change (zap) the database instance ID (DBIID) with the NSR_DBIID parameter in the NMDA configuration file. 182 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery! IMPORTANT After you change the DBIID of a recovered database, you cannot recover any subsequent changes to the database until the next full backup is performed. Perform a full manual backup after changing the DBIID of a recovered database. If an incremental backup is the next backup performed on a database after a DBIID change, NMDA automatically performs a full backup of the database instead. Considerations for Lotus DAOS recovery Configuring Lotus DAOS backups on page 100 provides information on backups of Lotus DAOS files. DAOS filenames end in.nlo; the DAOS files are called NLO files by IBM. The restore of DAOS files does not require any different configurations than the restore of Domino database files. Note: Any parameter settings in the LOTUS_DAOS{} section of the NMDA configuration file are ignored during restore operations. To restore a DAOS directory or specific NLO files, do one of the following: Specify the directory or filepaths by setting either NSR_BACKUP_PATHS or NSR_RECOV_LIST_FILE (not both) in the LOTUS{} section of the configuration file. The following provide details on these parameters: NSR_BACKUP_PATHS on page 364 NSR_RECOV_LIST_FILE on page 367 Select the files for restore in the NetWorker User for Lotus program (Windows only). For example, the following Domino command provides a list of missing NLO files referenced by the specified database: tell daosmgr listnlo -o output_file MISSING database.nsf You can specify the full path of output_file in the NSR_RECOV_LIST_FILE parameter instead of using the content of output_file for the NSR_BACKUP_PATHS parameter setting. After restoring the DAOS directory or NLO files, you must resynchronize the DAOS repository. For example, run the following command to resynchronize the repository: tell daosmgr resync [force] This command also updates or re-creates the daos.cfg and daoscat.nsf files in the Lotus data directory. The IBM documentation provides details on resynchronizing the DAOS repository. Lotus database recovery through the nsrnotesrc command You can recover Lotus database files through the nsrnotesrc command. The nsrnotesrc command also supports directed recovery to a different client or to a different location on the same client, as described in Directed recovery to a different client or location on page 187. Lotus data recovery 183

Data Restore and Recovery! IMPORTANT On UNIX or Linux, you must run the nsrnotesrc command as the Lotus user that starts the Domino server. Do not run the command as the root user. You must specify the Lotus database files to be recovered by setting the NSR_BACKUP_PATHS parameter in the NMDA configuration file. Note: Filepaths are case-sensitive for all platforms, including Microsoft Windows. If you are uncertain about the case of filenames, use the nsrinfo command to verify the backup entries in the NetWorker client file index. Ensure that any other parameters required for the recovery are set in the configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details. To perform the Lotus database recovery, run the nsrnotesrc command from the command line: nsrnotesrc(.exe) -z config_filepath where config_filepath is the complete pathname of the NMDA configuration file that contains the parameter settings for the Lotus recovery. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, replace nsrnotesrc(.exe) with nsrnotesrc32(.exe) in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. If the nsrnotesrc command prompts with a message that an existing file has the same name as a file being recovered, reply with the value n, N, y, Y, r, or R, as described in NSR_RECOV_INTERACT on page 366. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrnotesrc command. The following examples describe parameters to set in the NMDA configuration file for different types of Lotus database recoveries. After the parameters are set in the file, the nsrnotesrc -z command is run to perform the recovery. Cancel a Lotus database recovery according to Cancel a Lotus recovery started through the nsrnotesrc command on page 188. Example 15 Recovery of a previous database version By default, the NMDA software recovers the most recent Lotus backup available. The following parameter setting in the NMDA configuration file specifies a recovery of an earlier version of a Lotus database: LOTUS { Notes_ExecDirectory = /opt/lotus/notes/latest/solaris NSR_RECOVER_TIME = "Wed November 25 2009 14:23" } The NSR_RECOVER_TIME parameter value is the time in nsr_getdate format of the database backup to be restored. Note: The browse time cannot be earlier than the time of the first backup because the client file index does not have any entries before that time. 184 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Example 16 Recovery of specific Lotus databases The following parameter settings in the NMDA configuration file specify a recovery of Lotus database files named account.nsf and names.nsf: On UNIX or Linux: NSR_BACKUP_PATHS = /lotusdata/account.nsf, /lotusdata/names.nsf On Windows: NSR_BACKUP_PATHS = C:\Lotus\Domino\data\account.nsf, C:\Lotus\Domino\data\names.nsf Example 17 Recovery of all Lotus data in a directory The following parameter settings in the NMDA configuration file specify a recovery of all the Lotus database files within the directory /space/notesdata/mail: The NetWorker client where the files originated is jupiter.emc.com. The NetWorker server from which the backup is recovered is mars.emc.com. LOTUS { Notes_ExecDirectory = /opt/lotus/notes/latest/solaris NSR_BACKUP_PATHS = /space/notesdata/mail NSR_CLIENT = jupiter.emc.com NSR_SERVER = mars.emc.com } Example 18 Recovery of all Lotus database files The following parameter settings in the NMDA configuration file specify a recovery of all the Lotus database files backed up from the given NetWorker client: LOTUS { Notes_ExecDirectory = /opt/lotus/notes/latest/solaris NSR_BACKUP_PATHS = NOTES: NSR_RECOVER_TIME = "Tue December 15 2009 19:23" } The NSR_RECOVER_TIME parameter value is the time in nsr_getdate format when a full backup was performed on the client.! IMPORTANT Use the NOTES: option with caution because the NMDA software attempts to restore the data for all partitions of a partitioned Domino server, or for all Domino installations when there are multiple Domino installations on the client. Note: If the NOTES: option is used without specifying the backup time, only the latest versions of all the backed-up Lotus databases are recovered. Example 19 Recovery of a database with a change of the DBIID When recovering a database that may still be in use, use the NSR_DBIID parameter to change or zap the DBIID. The Domino server does not allow two databases to exist with the same instance ID. Changing the DBIID and relocating the database to another directory prevents error messages from appearing in the Recovery Manager on the Domino server. Lotus data recovery 185

Data Restore and Recovery The following parameter settings in the NMDA configuration file specify a recovery of the backed-up database named budget2009.nsf to the directory C:\tmpdir and a change of the DBIID:! LOTUS { Notes_ExecDirectory = C:\Lotus\Domino\Data NSR_BACKUP_PATHS = C:\Lotus\Domino\Data\budget2009.nsf NSR_DBIID = 1 NSR_RELOCATION_DEST = C:\tmpdir } IMPORTANT After you change the DBIID of a recovered database, you cannot recover any subsequent changes to the database until the next full backup is performed. Perform a full backup after changing the DBIID of a recovered database. If an incremental backup is the next backup performed on a database after a DBIID change, NMDA automatically performs a full backup of the database file instead. Example 20 Recovery of a full backup without the transaction logs The following parameter settings in the NMDA configuration file specify the recovery of a full backup of database accounting.nsf to the directory C:\temp and a change of the database s DBIID without applying the transaction logs: LOTUS { Notes_ExecDirectory = C:\Lotus\Domino\Data NSR_APPLY_LOGS = FALSE NSR_BACKUP_PATHS = C:\Lotus\Domino\Data\accounting.nsf NSR_DBIID = 1 NSR_RELOCATION_DEST = C:\temp } If you recover a point-in-time full backup of a database by using the parameter NSR_RECOVER_TIME without the parameter setting NSR_APPLY_LOGS=FALSE, the following error message might appear: Recovery Manager: Backup was later than recovery point in time. Use the parameter setting NSR_APPLY_LOGS=FALSE to prevent the error message. Example 21 Relocation of a linked database during Lotus recovery By default, when the nsrnotesrc command recovers a link file, the database or directory that the link points to is also recovered. The recovery is to the location where the database or directory was backed up from. If NSR_RELOCATION_DEST is set in the NMDA configuration file, the database file that a link points to is recovered to the specified relocation directory. During the recovery, the relative directory structure of the database file is also recovered. For example, the link file /space1/notes/data/link.nsf points to the database file /space2/notes/data.nsf. When the link file is backed up, the database file is also backed up by default. NSR_RELOCATION_DEST is set to /space3/new in the NMDA configuration file. The Lotus recovery is performed through the nsrnotesrc -z config_filepath command. The link file and database file are relocated during the recovery to these locations: Recovered link file: /space3/new/space1/notes/data/link.nsf Recovered database file (pointed to by the link file): /space3/new/space2/notes/data.nsf 186 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Directed recovery to a different client or location The following sections describe how to direct a Lotus recovery through the nsrnotesrc command to a different client, and to a different location on the same client. Note: If you are recovering logged database files, set the NSR_DBIID parameter to change the DBIID of the recovered files. Recovery to a different client To recover a database file to a different NetWorker client than where the file originated: 1. Ensure that the target client has the same organization name, site name, domain name, and configuration as the original client. 2. Ensure that the target client is specified in the Remote Access attribute of the NetWorker Client resource of the original client. 3. On the target client: a. Ensure that the NMDA configuration file has this parameter setting: NSR_CLIENT = client_name where client_name is the hostname of the NetWorker client where the files originated. b. Ensure that the NMDA configuration file includes any other required parameters, as described in Appendix A, NMDA Parameters for Backups and Restores. c. Perform the recovery through the nsrnotesrc(.exe) -z config_filepath command. Recovery to a different location on the same client By default, the destination for recovered files is the directory where the files originated on the NetWorker client. Set the following parameter in the NMDA configuration file to specify a different destination directory: NSR_RELOCATION_DEST = destination_path where destination_path is the complete pathname of the new directory for the recovered files. When recovered files are relocated with this parameter, the relative directory structure of the files is preserved, as described in Example 21 on page 186. Perform the recovery through the nsrnotesrc(.exe) -z config_filepath command.! IMPORTANT During a directed recovery to a different directory on the same client, the nsrnotesrc command does not prompt when an existing file has the same name as the file being recovered. Instead, the existing file is overwritten. Lotus data recovery 187

Data Restore and Recovery Cancel a Lotus recovery started through the nsrnotesrc command To cancel a Lotus recovery that was started through the nsrnotesrc command, press Ctrl + C.! IMPORTANT Using any other method to cancel a recovery in progress can corrupt the database being recovered. If you cancel a recovery, rerun it to ensure that the database files are successfully recovered. Lotus database recovery through NetWorker User for Lotus As an alternative, you can recover Lotus database files by invoking the NetWorker User for Lotus program on Windows only. The NetWorker User for Lotus also supports directed recovery, whereby Lotus database files are recovered to a client computer by initiating the recovery from another client.! IMPORTANT The NetWorker User for Lotus must not be used for disaster recovery. Starting the NetWorker User for Lotus To start the NetWorker User for Lotus program, select Start > Programs > EMC NetWorker > NetWorker User for Lotus. Cancel a Lotus database recovery that was started from the NetWorker User for Lotus according to Cancel a Lotus recovery from NetWorker User for Lotus on page 198. About the Recover window You can configure and run recoveries of Lotus database files from the Recover window of the NetWorker User for Lotus program. To display the Recover window, perform one of the following in the NetWorker User for Lotus main window: From the Operation menu, select Recover. Click the Recover button. Press Alt + R. Figure 13 on page 189 shows the Recover window of the NetWorker User for Lotus program. 188 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Figure 13 NetWorker User for Lotus Recover window To view a list of files available for recovery, select a directory in the left pane. The directory s contents appear in the right pane. Note: When a file does not exist on the computer (it has been deleted since the backup), the file s icon may appear incorrectly as a folder icon in the Recover window, instead of as an "unidentified file" icon or the expected icon for the given type of file. This incorrect icon display does not affect the success of the file recovery. Right-clicking an item in either pane of the Recover window displays a pop-up menu with the following options: Start Starts the recovery operation. Font Changes the font of the display. Recover Options Displays the Recover Options dialog box. Table 19 on page 189 describes the Recover window toolbar buttons. Table 19 Toolbar buttons on the NetWorker User for Lotus Recover window (page 1 of 2) Button Operation Description Mark Unmark Required Volumes Change Browse Time View Versions Marks the selected (highlighted) files for recovery. Clears the selected (marked) files. Lists the backup volumes that need to be mounted to recover the marked files. Specifies a date and time for recovery of the marked files. The hour and minutes entries are based on a 12-hour clock. Displays the backup history of the currently selected database. Versions are sorted according to backup time, with the most recent backup at the top of the list. Lotus data recovery 189

Data Restore and Recovery Table 19 Toolbar buttons on the NetWorker User for Lotus Recover window (page 2 of 2) Button Operation Description Recover Options Start Displays the options for: Relocating recovered data Changing the database instance ID Applying transaction logs with the recovery Specifying the configuration file pathname Starts the recovery of marked files. Prepare for data recovery For Lotus data recovery with the NetWorker User for Lotus program, set specific parameters in the NMDA configuration file, so you do not have to re-enter them every time you run the recovery.! IMPORTANT For Lotus data recovery, the NMDA configuration file must be located on the destination client where the database files are to be recovered. NetWorker User for Lotus supports the following restore parameters: Notes_ExecDirectory NSR_NO_BUSY_ERRORS NSR_RELOCATION_DEST PATH Appendix A, NMDA Parameters for Backups and Restores, provides information on these parameters. The parameter Notes_ExecDirectory is the only Lotus restore parameter that is mandatory in the NMDA configuration file. You must specify the location of the NMDA configuration file in the Recover Options dialog box of the NetWorker User for Lotus program, as described in Perform data recovery on page 190. Perform data recovery To recover a Lotus database by using the NetWorker User for Lotus program: 1. Ensure that the NetWorker server services are running. 2. In the NetWorker User for Lotus window, select Recover from the Operation menu. The Recover window opens, as shown in Figure 13 on page 189. 3. To view the different database versions or change the browse time, use the following procedures: View the database versions on page 192 Change the browse time on page 192 4. Specify the files to recover by using one of the following methods: Select the files, and click the Mark toolbar button. Select the checkbox (add a check mark) beside each file. 190 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery To unmark files, use one of the following methods: Select the marked files, and click the Unmark toolbar button. Clear the checkboxes (remove the check marks) beside the files. 5. To specify the location of the NMDA configuration file: a. In the Recover window, select Recover Options from the Options menu. The Recover Options dialog box opens, as shown in Figure 14 on page 191. b. Enter the complete pathname of the configuration file in the Configuration File text box. c. Click OK. Figure 14 NetWorker User for Lotus Recover Options dialog box Note: All the values set in the Recover Options dialog box overwrite the corresponding parameter values set in the NMDA configuration file. 6. (Optional) To recover a logged database, use the instructions in Recover logged databases on page 193. 7. Specify the recover options according to the following: Relocate recovered data on page 194 Change the database ID on page 194 How to change the database ID and replica ID on page 194 Recover without applying transaction logs on page 194 8. Determine the backup volumes for the recovery, and ensure that the volumes are loaded and mounted. Determine the required volumes on page 195 provides more information. 9. To begin the recovery process, click the Start toolbar button. The Recover Status window opens and displays information about the recovery operations, as shown in Figure 15 on page 192. Lotus data recovery 191

Data Restore and Recovery Figure 15 NetWorker User for Lotus Recover Status window View the database versions To view the versions of a directory or file that have been backed up: 1. In the Recover window, select the database file or directory to recover. 2. From the View menu, select Versions. The Versions window opens, as shown in Figure 16 on page 192. The window displays the backup history of the currently selected database. Versions are sorted according to backup time, with the most recent backup at the top of the list. Figure 16 Versions window Change the browse time From the Recover window of the NetWorker User for Lotus program, you can browse the entries in the NetWorker client file index for each file previously backed up. You can view the entries for the backed-up files from a specific point in time. 192 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery To change the browse time: 1. In the Recover window, select Change Browse Time from the View menu. The Change Browse Time dialog box opens, as shown in Figure 17 on page 193. Figure 17 Change Browse Time dialog box 2. Set a new date by selecting a day from the calendar. 3. Click Previous Month or Next Month to change from the current month. 4. In the Time text box, enter a time to browse, where: The hour and minutes entries are based on a 12-hour clock. The entry a represents A.M. The entry p represents P.M. The browse time cannot be earlier than the time of the first backup because the client file index does not have entries before that time. To verify the browse and retention policies, check the Client resources for the Lotus client or server by using the NetWorker Administrator program. Recover logged databases The Domino server does not support in-place recovery of logged databases. To recover a logged database on a Domino server, either delete the database before the recovery or perform the following: 1. Recover the logged database to a temporary directory and change (zap) the database ID during the recovery by using the instructions in the following: Relocate recovered data on page 194 Change the database ID on page 194 2. Delete the original database from the Domino server. 3. Copy the recovered database from the temporary directory to the location of the original database. Lotus data recovery 193

Data Restore and Recovery Relocate recovered data By default, when you recover Lotus data, the NMDA software copies the data from the backup volume to the original directory. To relocate the recovered data by designating a different directory: 1. In the Recover window, select Recover Options from the Options menu. The Recover Options dialog box opens, as shown in Figure 14 on page 191. 2. In the Relocate Recovered Data to Another Location text box, type the destination directory for the data recovery. This relocation path overwrites the NSR_RELOCATION_DEST parameter setting if it exists in the NMDA configuration file. 3. Click OK.! IMPORTANT If an existing datafile in the relocation directory has the same name as the one being recovered, NMDA overwrites the file without prompting. Change the database ID To change (zap) the database ID for a recovered database: 1. In the Recover window, select Recover Options from the Options menu. The Recover Options dialog box opens, as shown in Figure 14 on page 191. 2. Select Zap Database ID. 3. Click OK.! IMPORTANT After you the change the database instance ID (DBIID) of a recovered database file, you cannot recover any subsequent changes to the database until the next full backup is performed. For the best results, perform a full backup after changing the DBIID of a recovered database. However, if an incremental backup is the next backup performed on a database after a DBIID change, the NMDA software automatically performs a full backup of the database file instead. How to change the database ID and replica ID To change (zap) both the database ID and replica ID for a recovered database: 1. In the Recover window, select Recover Options from the Options menu. The Recover Options dialog box opens, as shown in Figure 14 on page 191. 2. Select Zap Database and Replica ID. 3. Click OK. Recover without applying transaction logs To recover a database without applying transaction logs: 1. In the Recover window, select Recover Options from the Options menu. The Recover Options dialog box opens, as shown in Figure 14 on page 191. 2. Select Do Not Apply Transaction Logs. 3. Click OK. 194 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Determine the required volumes To determine the volumes required for a recovery: 1. In the Recover window, mark the database files to recover. 2. From the View menu, select Required Volumes. The Required Volumes window opens with the backup volumes listed, as shown in Figure 18 on page 195. Figure 18 Required Volumes window Connecting to a different NetWorker server To connect to a different server from NetWorker User for Lotus, use one of the following methods: If the NetWorker User for Lotus program is not already running: 1. Start the NetWorker User for Lotus program, and connect to the selected server by typing the following command: nwbml -s server_name where server_name is the name of the NetWorker server from which to recover files. If the server cannot be connected, the following message appears: Unable to connect to server server_name. Do you want to connect to another server? 2. Do one of the following: Select Yes. In the Change Server dialog box that appears, either select or type the name of the server, and click OK. To refresh the list of NetWorker servers, click Update List. Select No to return to the command prompt. If the NetWorker User for Lotus program is already running: 1. In the NetWorker for Lotus program, select Select NetWorker Server from the Operation menu. The Change Server dialog box opens. 2. In the Change Server dialog box, either select or type the name of the server, and click OK. To refresh the list of NetWorker servers, click Update List. Lotus data recovery 195

Data Restore and Recovery To change the default NetWorker server that the NetWorker User for Lotus uses to back up files: 1. Right-click the NetWorker User for Lotus program icon and select Properties. 2. In the Target text box on the Shortcut tab, add the following option: -s server_name where server_name is the name of the NetWorker server to back up the files. Figure 5 on page 143 provides an example of the Target attribute setting. Directed recovery through NetWorker User for Lotus A directed recovery allows you to use the NetWorker User for Lotus program to initiate the recovery of Lotus database files that were backed up on a different computer. In the sections that follow, these terms refer to the client computers involved in a directed recovery: Source client The computer where the backup of the Lotus database files was performed. Destination client The computer to which the Lotus database files will be recovered. Performing client The computer where you initiate the directed recovery by using the NetWorker User for Lotus program. How to configure a directed recovery To configure a directed recovery, perform the appropriate steps: When the performing client or destination client is different than the source client: 1. On the NetWorker server that has the backup to be restored, create a NetWorker Client resource for the performing client or destination client, if one does not yet exist. 2. In the Remote Access attribute of the Client resource for the source client, add a valid username and hostname for the performing client or destination client: user=username, host=performing_client_hostname or user=username, host=destination_client_hostname The EMC NetWorker Administration Guide provides more information on creating a NetWorker Client resource and setting the Remote Access attribute. When the performing client is different than the destination client: 1. Edit the nsrlotus_remrecov script on the destination client. The comments in the script file provide details on editing the script. Note: The script file is installed in the NMDA installation directory. On Windows, the script file is named nsrlotus_remrecov.bat. On UNIX, the script file is named nsrlotus_remrecov. Do not move the script from the installation directory, but you can rename the script as long as the name starts with nsr or save. If 32-bit NMDA is installed for 32-bit Lotus on a 64-bit system where 32-bit Lotus coexists with a 64-bit NMDA application, you must change nsrnotesrc to nsrnotesrc32 within the script. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. 196 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 2. On the performing client, set the REMOTE_RECOVCMD environment variable to the filename of the nsrlotus_remrecov script that you modified on the destination client. If this variable is not set, the NetWorker User for Lotus program uses nsrlotus_remrecov, by default. Note: Set REMOTE_RECOVCMD in the environment of the performing client, not in the NMDA configuration file, and include any filename extension (for example,.bat), as required. For example: REMOTE_RECOVCMD=nsr_remrecov.bat The script name must not be in quotes. On Windows, the script name must not contain any spaces. 3. In the /nsr/res/servers file on a destination client only, specify the hostname of the performing client. 4. On a Linux or UNIX destination client, do one of the following: Set the required environment variables, for example, LD_LIBRARY_PATH. Create symbolic links in the /usr/lib directory to the required Lotus Domino libraries, for example, libnotes.so, libntdgs.so, and libxmlproc.so, depending on the Domino version. How to run a directed recovery To run a directed recovery: 1. On the performing client, start the NetWorker User for Lotus program. 2. From the Operation menu, select Directed Recover. The Source Client window opens. 3. In the Source Client window, select the source client from which to recover, and click OK. The Destination Client window opens. 4. In the Destination Client window, select the client to recover to. 5. If required, set the recover options. To do this, select Recover Options from the Options menu. Note: If you are recovering a logged database to a new destination host, select Do Not Apply Transaction Logs in the Recover Options dialog box. 6. In the Recover window, select the files to recover.! IMPORTANT When the performing client is different than the UNIX or Linux destination client, the total length of all pathnames marked for recovery must not exceed the limit of 10 KB. Otherwise, the directed recovery fails. When the performing client is different than the Windows destination client, if you select to restore any Lotus file that contains a space in its pathname, the directed recovery fails. 7. To start the recovery, click the Start toolbar button. Lotus data recovery 197

Data Restore and Recovery Cancel a Lotus recovery from NetWorker User for Lotus To cancel a Lotus recovery in progress from the NetWorker User for Lotus program, select End Recover from the File menu. This method does not cancel a remote recovery of a Windows client. A workaround in this case is to terminate the nsrlotus_remrecov process through the Task Manager on the remote Windows client.! IMPORTANT The use of any other method to cancel a recovery in process can corrupt the database. If you cancel a recovery, rerun it to ensure that the database files are successfully recovered. Document-level recovery through the nsrdocrc command You can recover deleted Notes documents (not modified Notes documents or design documents) in a local database through the nsrdocrc command. This document-level recovery allows recovery to any point in time if the following applies: The database is logged. Backups of the database and transaction logs are available. To recover deleted documents from a database file, perform the following steps as the Lotus user: 1. Ensure that the NMDA configuration file contains the required parameter settings. For example: NSR_BACKUP_PATHS = database_pathname NSR_RECOVER_TIME = recover_time NSR_RELOCATION_DEST = destination_pathname NSR_SERVER = NetWorker_server_name Appendix A, NMDA Parameters for Backups and Restores, provides details on parameters in the NMDA configuration file. 2. On an AIX (64-bit), Linux, or Solaris client, set the required environment variable for the library locations: On a 64-bit AIX client, set the environment variable LIBPATH to the complete pathname of the Lotus directory that contains the library files libxmlproc_r.a, libndgts_r.a, and libnotes_r.a. For example, set LIBPATH to the pathname of the Lotus directory: export LIBPATH=/opt/ibm/lotus/notes/latest/ibmpow On a Linux or Solaris client, set the environment variable LD_LIBRARY_PATH to the complete pathname of the Lotus directory that contains the library files libxmlproc.so, libndgts.so, and libnotes.so. For example, set LD_LIBRARY_PATH to the pathname of the Lotus directory: export LD_LIBRARY_PATH=/opt/lotus/notes/latest/sunspa 198 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 3. Type the nsrdocrc command at the command line: nsrdocrc(.exe) -z config_filepath where config_filepath is the complete pathname of the NMDA configuration file. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, replace nsrdocrc(.exe) with nsrdocrc32(.exe) in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrdocrc command. Example 22 on page 199 provides an example of document-level recovery with the nsrdocrc command. Document-level recovery of database links on page 201 provides details on recovering documents from a linked database. Cancel a document-level recovery according to Cancel a document-level recovery started through the nsrndocrc command on page 199. Example 22 Recovering deleted documents for a logged database To recover deleted documents in the database F:\Lotus\Domino\data\account.nsf that was backed up on October 13 from the client saturn to the server mars: 1. Enter the nsrinfo command to obtain the backup time of the directory that contains account.nsf: nsrinfo -s mars -n notes saturn grep "Dec 13" NOTES:/F:/Lotus/Domino/data/, date=984492446 Tue Oct 13 08:07:26 2009... NOTES:/F:/Lotus/Domino/data/account.nsf, date=984492440 Tue Oct 13 08:07:20 2009 2. Ensure that the NMDA configuration file contains the following parameter settings, including the backup time of the F:\Lotus\Domino\data directory: NSR_BACKUP_PATHS = F:\Lotus\Domino\data\account.nsf NSR_RECOVER_TIME = 984492446 NSR_RELOCATION_DEST = D:\tempdir NSR_SERVER = mars 3. To perform the document recovery, type the nsrdocrc command: nsrdocrc.exe -z config_filepath Note: Recovering deleted documents from one large database to another large database can take considerable time. Cancel a document-level recovery started through the nsrndocrc command To cancel a document-level recovery that was started through the nsrdocrc command, press Ctrl + C.! IMPORTANT Using any other method to cancel a recovery in progress can corrupt the database being recovered. If you cancel a recovery, rerun it to ensure that the database files are successfully recovered. Lotus data recovery 199

Data Restore and Recovery Document-level recovery through the Notes client GUI On Windows only, you can use the Lotus Notes client GUI to recover deleted or modified Notes documents (not design documents) in either of the following: A local Notes or Domino database A remote Domino database Document-level recovery through the Notes client GUI allows recovery only up to the time of the selected backup. The document-level recovery feature must be added to the Lotus Notes client, as described in the EMC NetWorker Module for Databases and Applications Installation Guide. The database with the documents to be recovered can be physically located on either the local computer or a remote Domino server, but the database must be accessible through the Notes client. Document-level recovery of deleted or modified documents To recover deleted or modified documents from a database file: 1. Ensure that the services for the NetWorker server are running. 2. If recovering documents in a remote Domino database, ensure the following: The user that runs the Notes client program on the local host is: Listed in the Remote Access attribute in the NetWorker Client resource of the remote Domino server. Granted administrative privileges on the remote Domino server. A NetWorker Client resource is configured on the same NetWorker server for the host where Notes client program runs. 3. Start the Lotus Notes client GUI. 4. Open the database that contains the documents to recover. 5. Select the documents to recover. Note: Skip this step if you are recovering deleted documents. 6. From the Actions menu, select either NMDA Lotus - Restore Selected Documents or NMDA Lotus - Restore Deleted Documents. The NetWorker Module dialog box opens. For a successful recovery, each field in the dialog box except Encryption Phrase must contain a valid value, as required. 7. In the NetWorker Module dialog box, perform the following: a. In the Database text box, type the complete pathname of the database that contains the documents to recover. Document-level recovery of database links on page 201 provides details on recovering documents from a linked database. b. In the Temporary Directory for Restore text box, type a temporary directory on the local host, where the database backup is to be restored. c. In the NetWorker Server text box, type the hostname of NetWorker server that contains the backup to restore. d. In the NetWorker Client text box, type the name of the NetWorker client file index that contains information about the backup to be restored. 200 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Note: If the database is located on a remote host, the default name listed in the NetWorker Client text box might not be correct. This can result in a restore failure. e. In the Show Backups in Last text box, type the number of past days (since the current date) for which to display backup information on the specified database. For example, the value 5 causes backups from the past five days to be displayed. f. Click Refresh to display a list of the database backups under List of Backups. g. In the List of Backups display, select a database backup to be restored. h. In the Encryption Phrase text box, type the encryption phrase that was used to back up the database if the datazone pass phrase on the NetWorker server changed since the backup. Note: Encryption keys typed in the text box are cached in memory and continue to be used for recoveries until the Notes client program is exited and restarted. 8. To start the recovery process, click Restore. 9. When the recovery is complete, press F9 to refresh the Lotus Notes screen and display the recovered files. Document-level recovery of database links To perform a document-level recovery of a linked database, specify the complete pathname of the link file that points to the database, by doing one of the following: Type the link filepath in the Database field of the Lotus Notes client, as described in Document-level recovery of deleted or modified documents on page 200. Specify the link filepath with the NSR_BACKUP_PATHS parameter in the NMDA configuration file, as described in NSR_BACKUP_PATHS on page 364, for a nsrdocrc restore. Note: Document-level recovery of directory links is not supported. If the directory link file C:\Domino\data\link.dir points to the directory D:\Lotus\dir that contains a database db22.nsf, perform a document-level recovery of the database by specifying the complete pathname of the database D:\Lotus\dir\db22.nsf (not the directory link). Lotus data recovery 201

Data Restore and Recovery Oracle data restore and recovery To perform a restore and recovery of Oracle data: 1. Prepare for the Oracle data restore and recovery by reviewing the following: Requirements for Oracle data restore on page 202 RMAN scripts for restore and recovery on page 205 Recovery configuration wizard (Oracle only) on page 206 2. Perform the Oracle data restore and recovery by using either of the following methods: Restore through the RMAN command line interface on page 208. Restore with Oracle Enterprise Manager Backup Management Tools on page 209. 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 Recover the Oracle data on page 209. Requirements for Oracle data restore Before starting an Oracle data restore, ensure that the required configurations, volumes, and scripts are in place: The Oracle system is properly configured according to the appropriate Oracle Server documentation. If using an RMAN restore script, the script is created according to RMAN scripts for restore and recovery on page 205. 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 nsrorainfo command, as described in Determine the volumes for restore through the nsrorainfo command on page 202. If NetWorker multiplexing is used with NMDA for Oracle backups, prevent degradation of the Oracle restore performance with Oracle 10.2 or later according to the instructions in Prevent possible degradation of Oracle restore performance with Oracle 10.2 or later on page 204. Determine the volumes for restore through the nsrorainfo command To determine the NetWorker volumes that contain the Oracle backup pieces to be restored, you can use the nsrorainfo(.exe) command. The program is installed with the NMDA software in the same directory as the NetWorker client software. 202 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery The nsrorainfo(.exe) command syntax and options are as follows: nsrorainfo[.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 nsrorainfo(.exe) command, specify the names of the backup pieces by either or both of the following: List the backup piece names as options of the command. List the backup piece names in a text file, and specify the name of the file with the -f option of the command. The nsrorainfo(.exe) command displays a list of one or more volumes required for the Oracle restore: For each backup piece, the list includes the accessible volumes that contain 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 nsrorainfo(.exe) 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 23 and Example 24 on page 204 show how to use the nsrorainfo(.exe) command and the type of output produced by the command. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides more details on the nsrorainfo(.exe) command. Oracle data restore and recovery 203

Data Restore and Recovery Example 23 Sample nsrorainfo commands for Oracle restores Each of the following nsrorainfo 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: nsrorainfo -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. nsrorainfo -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. nsrorainfo -c mars backupc_3 -f backup3.txt Example 24 Volume information displayed by the nsrorainfo command The following nsrorainfo command searches in the NetWorker index of the local host on the server mars for information on the volumes that contain the backup pieces backup1 and backup2: nsrorainfo -s mars backup1 backup2 The nsrorainfo 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. Prevent possible degradation of Oracle restore performance with Oracle 10.2 or later Due to an Oracle limitation, degradation of NMDA restore performance might occur with Oracle 10.2 or later if NetWorker multiplexing is used with NMDA for Oracle backups. If NetWorker multiplexing is enabled, you can prevent the restore performance degradation by including the set parallelmediarestore off command in the RMAN restore script that is used for the Oracle restore. 204 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery For example, the following RMAN restore script contains the required Oracle command to disable the multiplexing during the Oracle restore: set parallelmediarestore off; run { allocate channel c1 type SBT_TAPE ; restore database; release channel c1; } 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 (Oracle only) on page 206 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. Oracle-specific parameters in the script must be set by the methods described in Setting the NMDA parameters for Oracle operations on page 368. The use of the send command is recommended where possible. The send command on page 379 provides more information. Example 25 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 Recover the Oracle data on page 209: run { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_CLIENT=server1.emc.com) ; sql alter tablespace users offline immediate ; restore tablespace users; recover tablespace users; sql alter tablespace users online ; release channel t1; release channel t2; } RMAN scripts for manual backups on page 103 provides more information on setting NSR* parameters in an RMAN script. Example 26 RMAN script to restore from a specified pool By default, NMDA and NetWorker use configuration settings and information in the media database to determine the backup volume to use for an NMDA 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 page 370 provides more information. Oracle data restore and recovery 205

Data Restore and Recovery 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 { allocate channel c1 type 'SBT_TAPE'; send channel c1 NSR_ENV=(NSR_SERVER=backup01, NSR_RECOVER_POOL=OracleClonePool2) ; restore database; release channel c1; } Recovery configuration wizard (Oracle only) The NMDA software supports a recovery configuration wizard that is integrated with the NetWorker Management Console (NMC). The recovery configuration wizard can be used to configure a restore and recovery of Oracle data only, which was backed up by NMDA. 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 by specifying the Console server URL. The EMC NetWorker Module for Databases and Applications Release Notes provides details on the NetWorker requirements for the support of the configuration wizards. To configure a restore with the wizard: 1. Review the information in Features of the recovery configuration wizard on page 206. 2. Ensure that you meet the Requirements for using the recovery configuration wizard on page 207. 3. Follow the steps in Configure a restore with the wizard on page 208. 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, by 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 206 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 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. Oracle data restore and recovery on page 202 provides more information about RMAN scripts for restore and recovery. 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 EMC NetWorker Module for Databases and Applications Release Notes Requirements for using the recovery configuration wizard Before you use the recovery configuration wizard, ensure that all of the following requirements are met: The NMC user that starts the wizard (the wizard user) has the Remote Access NetWorker privileges on the NetWorker server where the NMDA client configuration is stored. Communication between the NMC server, NetWorker server, and NMDA client uses NetWorker nsrauth authentication. The NetWorker documentation provides any requirements for nsrauth authentication. The required NetWorker releases are installed on the NMC server, NetWorker server, and NMDA client hosts, as described in the EMC NetWorker Module for Databases and Applications Release Notes. The NetWorker Client resource for the NMDA client was created through one of the following: Backup configuration wizard in NMDA Conversion of a legacy NetWorker module configuration with the nsrdaadmin command NMC configuration method (without the wizard), where the value of the Save Set attribute of the Client resource has the RMAN: prefix Oracle data restore and recovery 207

Data Restore and Recovery 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 NMDA 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 After 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. This requirements applies if your particular database will not be open when the sql commands are run. Restore through the RMAN command line interface You can start an Oracle data restore through the RMAN command line interface on the Oracle Server host. If the RMAN restore script on page 205 is stored in the file /disk1/scripts/restore.txt and the Net service has been configured to connect to the databases payroll and rcvcatdb, start the Oracle restore with the following command: rman target internal/oracle@payroll rcvcat rman/rman@rcvcatdb cmdfile \ /disk1/scripts/restore.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 commands. 208 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 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. You can use this interface 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 NMDA backup or restore, the Oracle Enterprise Manager job queue history may display 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 documentation provides more information on using the Oracle Enterprise Manager Backup Management Tools. Recover the Oracle data After restoring the NMDA 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 205. After the RMAN restore script has completed successfully, use the Oracle command line (for example, SQL* Plus) or graphical interfaces to run the recovery. The appropriate Oracle backup and recovery documentation provides more information on Oracle data recovery procedures. Oracle data restore and recovery 209

Data Restore and Recovery Sybase data restore and recovery To perform a restore and recovery of the Sybase server or individual databases: 1. Prepare for the Sybase restore and recovery by reviewing Requirements for Sybase data restore on page 210. 2. Perform the Sybase data restore and recovery through one of the following methods: Sybase data restore through the nsrsybrc command on page 211 Sybase data restore through NetWorker User for Sybase on page 215 Requirements for Sybase data restore Before starting a Sybase data restore, ensure that the required configurations and volumes are in place: The Sybase system is properly configured according to the appropriate Sybase ASE documentation. The Sybase server and Sybase Backup Server are running. The target database exists to which data will be recovered. The database is at least as large as the size of the database backup. Note: To create a new database for recovery, use the for load option. The target database to which data will be recovered is not currently in use. The database is taken offline during the recovery. For an imported restore, the Remote Access attribute of the Client resource contains the hostname of the client on which the data will be restored. The NMDA parameters required for the restore are set in the environment or as nsrsybrc command options, as described in Sybase-specific NMDA parameters on page 373. These parameters are mandatory for specific restores: NSR_CLIENT Set for a redirected restore to a different host. NSR_NWPATH Set for a deduplication restore if the nsravtar binary (part of the NetWorker client package) is installed in a nondefault location. NSR_SERVER Set for a restore if the NetWorker server host is different from the client host. The volume required for the restore 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. 210 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Sybase data restore through the nsrsybrc command You can perform a Sybase restore of the whole Sybase server or individual databases by running the appropriate nsrsybrc command from the command line, as the operating system user that was used to launch the Sybase Backup Server.! IMPORTANT In the nsrsybrc command used for the restore, the Sybase server and database names are case-sensitive, and the names must be in the same case as recorded in the corresponding backup entries in the NetWorker indexes. By default, the nsrsybrc command restores the most recent database backup and rolls transactions forward by recovering the transaction logs. After the restore operation completes, the database is brought back online. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on a 64-bit system, the command name is nsrsybrc32 instead of nsrsybrc. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybrc command. After the recovery operation completes, perform the following: 1. Check the database to ensure that the data has been recovered. 2. Run a database consistency check according to Sybase database consistency check on page 144. 3. Run a full backup of the database. Example 27 on page 211 restores the Sybase server and single or multiple databases. Example 28 on page 212 describes a point-in-time restore. The following sections describe the other supported types of Sybase data restores: Redirected restores of Sybase data on page 212 Imported restores of Sybase data on page 214 Multistripe restores of Sybase data on page 215 Example 27 Restores of single or multiple Sybase databases The following commands perform restores of single or multiple Sybase databases: This command restores a single Sybase database: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name/database_name where: user_id is the username of the Sybase user account. password is the password of the Sybase user account. NetWorker_server_name is the hostname of the NetWorker server. ASE_server_name is the Sybase server name. database_name is the name of the database on the Sybase server. Sybase data restore and recovery 211

Data Restore and Recovery Note: The Sybase server and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. This command restores multiple Sybase databases: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name/database1_name SYBASE:/ASE_server_name/database2_name SYBASE:/ASE_server_name/database3_name This command restores all the databases on the Sybase server, except the master database: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name Example 28 Point-in-time restore of Sybase data A point-in-time restore recovers the Sybase data to a specific time in the past, without restoring the entire transaction log. The nsrsybrc command uses the time specified with the -t option to restore data to a specific point in time. It loads the most recent full backup before the designated time, and then applies any transaction log backups made before that time. The following command performs a point-in-time recovery: nsrsybrc -U user_id -P password -s NetWorker_server_name -t MM/DD/YY HH:MM:SS SYBASE:/ASE_server_name/database_name where MM/DD/YY HH:MM:SS indicates the month, day, year, hour, minute and seconds to recover data to. The ASE_server_name and database_name must be in the same case as recorded in the backup entries in the NetWorker indexes. Note: Since the NetWorker server and client can have different date and time values, set the -t option to a value of the local time on the Sybase server. After the restore operation, the database is brought online.! IMPORTANT After performing a point-in-time recovery, the Sybase server restarts the database log sequence. Performing an incremental backup before a full backup is performed causes future recovery operations to fail. Redirected restores of Sybase data A redirected restore loads the backup of an old database to a new database. The NMDA software supports the following types of redirected restores of Sybase data: Same Sybase server but a different database name on page 213 Different Sybase server but the same database name on page 213 Different Sybase server and a different database name on page 214 212 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Same Sybase server but a different database name To restore data to the same Sybase server but to a different database name: 1. Ensure that the new database has been created with the same device allocations as the original database. 2. Type the following command as the Sybase user: nsrsybrc -U user_id -P password -s NetWorker_server_name -d SYBASE:/ASE_server_name/new_database_name SYBASE:/ASE_server_name/old_database_name where: user_id is the username of the Sybase user account. password is the password of the Sybase user account. NetWorker_server_name is the hostname of the NetWorker server. ASE_server_name is the Sybase server name. new_database_name is the name of the database on the Sybase server to which the data is restored. old_database_name is the name of the database on the Sybase server that was backed up. Note: The Sybase server and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. Different Sybase server but the same database name To restore data to a different Sybase server but to the same database name: 1. Ensure that the new database has been created with the same device allocations as the original database. 2. Type the following command as the Sybase user: nsrsybrc -U user_id -P password -s NetWorker_server_name -d SYBASE:/new_Sybase_server_name/database_name SYBASE:/old_Sybase_server_name/database_name where: new_sybase_server is the name of the Sybase server to which the data is restored. old_sybase_server is the name of the Sybase server from which the data was backed up. Note: The username and password are for the new Sybase server. The Sybase server and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. Sybase data restore and recovery 213

Data Restore and Recovery Different Sybase server and a different database name To restore data to a different Sybase server and to a different database name: 1. Ensure that the new database has been created with the same device allocations as the original database. 2. Type the following command as the Sybase user: nsrsybrc -U user_id -P password -s NetWorker_server_name -d SYBASE:/new_Sybase_server_name/new_database_name SYBASE:/old_Sybase_server_name/old_database_name where: new_database_name is the name of the new database on the new Sybase server. old_database_name is the name of the old database on the old Sybase server. Note: The username and password are for the new Sybase server. The Sybase server and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. Imported restores of Sybase data An imported restore recovers a backup to a Sybase server on another NetWorker client. To recover data to a Sybase server different than the original host which was backed up, ensure that the Remote Access attribute in the NetWorker Client resource of the original host contains the name of the target Sybase server host, in the form of username@host. To perform an imported restore, use the -c option with the nsrsybrc command, or set the NSR_CLIENT parameter to the NetWorker client. For example: nsrsybrc -U user_id -P password -s NetWorker_server_name -c NetWorker_client_name SYBASE:/ASE_server_name/database_name where NetWorker_client_name is the hostname of the NetWorker client where the database resides. The ASE_server_name and database_name must be in the same case as recorded in the backup entries in the NetWorker indexes. Note: Although the -d option indicates the destination for recovery, it is not used in this case because the destination server name and database name are the same as the original NetWorker client. Combination of relocated and imported restores You can combine a relocated and imported restore together, to relocate recovered data to a different NetWorker client computer. The following example recovers a database from a Sybase server to a different Sybase server, which is the computer where the nsrsybrc command is run: nsrsybrc -U user_id -P password -s NetWorker_server_name -c NetWorker_client_name -d SYBASE:/new_Sybase_server_name/database_name SYBASE:/old_Sybase_server_name/database_name where: NetWorker_client_name is the hostname of the computer where the database resides. new_sybase_server_name is the name of the new Sybase server. 214 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery old_sybase_server_name is the name of the old Sybase server. database_name is the name of a database on the Sybase server. Note: The Sybase server and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. Multistripe restores of Sybase data The NMDA software supports multistripe sessions for restoring Sybase data. A multistripe restore involves one or more streams of data for a database that can be read in parallel from one or more media devices. A multistripe restore can enhance performance significantly when a large amount of data is backed up and restored with multiple tape drives. Before starting a multistripe restore, ensure the following: The NetWorker server has been properly configured to use the same settings as the multistripe Sybase backup. All of the devices used by the multistripe backup are available and mounted. The nsrsybrc command syntax for a multistripe restore is the same as for a normal database restore. If data was backed up as a multistripe backup, the multistripe restore is automatically enabled and uses the same session number as the multistripe backup. To perform a multistripe restore of a database that was backed through a multistripe backup, use the following command: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name/database_name The ASE_server_name and database_name are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. Cancel a Sybase restore started through the nsrsybrc command To cancel a Sybase restore in progress that was started through the nsrsybrc command, press Ctrl + C.! IMPORTANT Using any other method to cancel a restore in progress can corrupt the database being recovered. If you cancel a restore, rerun it to ensure that the database files are successfully restored. Sybase data restore through NetWorker User for Sybase As an alternative, you can perform a Sybase data restore by invoking the NetWorker User for Sybase program on Windows only. The GUI supports the restore of local Sybase data only. Starting the NetWorker User for Sybase To start the NetWorker User for Sybase program, select Start > Programs > EMC NetWorker > NetWorker User for Sybase. Cancel a Sybase data restore that was started from the NetWorker User for Sybase according to Cancel a Sybase data restore from NetWorker User for Sybase on page 222. Sybase data restore and recovery 215

Data Restore and Recovery About the Recover window You can configure and run restores of Sybase data from the Recover window of the NetWorker User for Sybase program. To display the Recover window: 1. Perform one of the following in the NetWorker User for Sybase main window: From the Operation menu, select Recover. Click the Recover button. Press Alt + R. 2. If the Recover Sybase Server dialog box appears (the first time you open the Recover window), perform the following steps: a. Enter the required values in the Recover Sybase Server dialog box: In the Server name text box, enter the Sybase server name. In the Host name text box, enter the operating system hostname of the Sybase server. b. Click OK.! IMPORTANT For restores with the NetWorker User for Sybase, the Sybase server and database names that you enter in the GUI are case-sensitive, and the names must be in the same case as recorded in the corresponding backup entries in the NetWorker indexes. Figure 19 on page 216 shows the Recover window of the NetWorker User for Sybase program. Figure 19 NetWorker User for Sybase Recover window To view a list of databases available for restore, select the Sybase server name in the left pane. The backed-up databases of the Sybase server appear in the right pane. 216 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Note: When a database does not exist on the computer (it was deleted since the backup), the database s icon may appear incorrectly as a folder icon in the Recover window, instead of an "unidentified file" icon or the expected icon for the given type of file. This incorrect icon display does not affect the success of the recovery. Right-clicking an item in either pane of the Recover window displays a pop-up menu with the following options: Start Starts the restore operation. Font Changes the font of the display. Recover Options Displays the Recover Options dialog box. Table 20 on page 217 describes the Recover window toolbar buttons. Table 20 Toolbar buttons on the NetWorker User for Sybase Recover window Button Operation Description Mark Unmark Required Volumes Change Browse Time Recover Options Start Marks the selected (highlighted) files for restore. Clears the selected (marked) files. Lists the backup volumes that need to be mounted to restore the marked files. Specifies a date and time for restore of the marked files. The hour and minutes entries are based on a 12-hour clock. Displays the options for relocating restored data. Starts the restore of marked files. Prepare for a Sybase data restore For a Sybase data restore with the NetWorker User for Sybase program, set specific parameters in the environment. Requirements for Sybase data restore on page 210 provides information on the parameters for Sybase restores. Perform a Sybase data restore To restore Sybase data by using the NetWorker User for Sybase program: 1. Ensure that the services on the NetWorker server are running. 2. In the NetWorker User for Sybase window, open the Recover window according to the instructions in About the Recover window on page 216. Note: The first time you open the Recover window, you must enter the required values in the Recover Sybase Server dialog box. The Recover window appears as shown in Figure 19 on page 216. 3. To change the browse time, use the instructions in Change the browse time on page 219. 4. Specify the databases to restore by using one of the following methods: Select the databases, and click the Mark toolbar button. Select (mark) the checkbox beside each database. Sybase data restore and recovery 217

Data Restore and Recovery To unmark databases, use one of the following methods: Select the marked databases, and click the Unmark toolbar button. Clear (unmark) the checkboxes beside the databases. 5. To specify the recover options: a. In the Recover window, select Recover Options from the Options menu. The Recover to Sybase Server dialog box opens, as shown in Figure 20 on page 218. b. Specify the required values in the Server name and Database name text boxes for the restore. Note: The Sybase server and database names are case-sensitive and must be entered in the same case as recorded in the backup entries in the NetWorker indexes. c. Click OK. Figure 20 NetWorker User for Sybase Recover Options dialog box 6. To relocate the recovered data, follow the instructions in Relocate recovered data on page 220. 7. Determine the backup volumes for the recovery, and ensure that the volumes are loaded and mounted. Determine the required volumes on page 221 provides more information. 8. To begin the restore, click the Start toolbar button. The Recover Status window opens and displays information about the restore operations performed, as shown in Figure 21 on page 219. 218 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery Figure 21 NetWorker User for Sybase Recover Status window Change the browse time From the Recover window of the NetWorker User for Sybase program, you can browse the entries in the NetWorker client file index for each database previously backed up. You can view the entries for the backed-up databases from a specific point in time. To change the browse time: 1. In the Recover window, select Change Browse Time from the View menu. The Change Browse Time dialog box opens, as shown in Figure 22 on page 220. Sybase data restore and recovery 219

Data Restore and Recovery Figure 22 Change Browse Time dialog box 2. Set a new date by selecting a day from the calendar. 3. Click Previous Month or Next Month to change from the current month. 4. In the Time text box, type a time to browse, where: The hour and minutes values are based on a 12-hour clock. The value AM represents A.M. The value PM represents P.M. The browse time cannot be earlier than the time of the first backup because the client file index does not have entries before that time. To verify the browse and retention policies, check the Client resources for the Sybase client or server by using the NetWorker administration program. Relocate recovered data To relocate the recovered data: 1. In the Recover window, select Recover Options from the Options menu. The Recover to Sybase Server dialog box opens, as shown in Figure 20 on page 218. 2. Ensure that any new database is created with the same device allocations as the original database. 220 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Data Restore and Recovery 3. Specify the appropriate values in the Recover to Sybase Server dialog box: Note: If you leave the Server name or Database name text box blank, NMDA uses the old Sybase server name or old database name by default for the relocated restore. The Sybase server and database names are case-sensitive and must be typed in the same case as recorded in the backup entries in the NetWorker indexes. To restore data to the same Sybase server but to a different database name: a. In the Server name text box, optionally type the old Sybase server name. b. In the Database name text box, type the new database name. To restore data to a different Sybase server but to the same database name: a. In the Server name text box, type the new Sybase server name. b. In the Database name text box, optionally type the old database name. To restore data to a different Sybase server and to a different database name: a. In the Server name text box, type the new Sybase server name. b. In the Database name text box, type the new database name. 4. Click OK. Determine the required volumes To determine the volumes required for a recovery: 1. In the Recover window, mark the database files to recover. 2. From the View menu, select Required Volumes. The Required Volumes window opens with the backup volumes listed, as shown in Figure 23 on page 221. Figure 23 Required Volumes window Sybase data restore and recovery 221

Data Restore and Recovery Connecting to a different NetWorker server To connect to a different server from NetWorker User for Sybase, use one of the following methods: If the NetWorker User for Sybase program is not already running, use the following command to start the NetWorker User for Sybase program and connect to the specified server: nwbms -s NetWorker_server_name where NetWorker_server_name is the name of the NetWorker server from which to recover files. If the server cannot be connected, the following message appears: Unable to connect to server server_name. Do you want to connect to another server? In this case, do one of the following: Select Yes. In the Change Server dialog box that appears, select or type the name of the server, and click OK. To refresh the list of NetWorker servers, click Update List. Select No to return to the command prompt. If the NetWorker User for Sybase program is already running: a. In the NetWorker for Sybase program, select Select NetWorker Server from the Operation menu. The Change Server dialog box opens. b. In the Change Server dialog box: 1. If required, click Update List to refresh the list of NetWorker servers. 2. Either select the server from the list or type the name of the server. 3. To specify that the server be used as the default NetWorker server by the NetWorker User for Sybase, select Save as Default Server. 4. Click OK. Cancel a Sybase data restore from NetWorker User for Sybase To cancel a Sybase data restore in progress from the NetWorker User for Sybase program, select End Recover from the File menu.! IMPORTANT The use of any other method to cancel a recovery in process can corrupt the database. If you cancel a recovery, rerun it to ensure that the database files are successfully recovered. 222 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

5 Disaster Recovery This chapter includes the following major sections: About disaster recovery... 224 Preparing for disaster recovery... 225 Performing disaster recovery... 231 Note: This chapter describes how to recover from a disaster such as a disk failure. It should be used in conjunction with Chapter 4, Data Restore and Recovery, and the EMC NetWorker Disaster Recovery Guide. Disaster Recovery 223

Disaster Recovery About disaster recovery Computer hardware and environmental failures can produce catastrophic results. In a network environment, where users depend on shared data and the amount of data continually grows, the need to protect system and business information from disaster is crucial. For the purpose of this guide, a disaster is any loss of data in which the computing environment required to restore that data is not available. Ordinary data recovery procedures are not sufficient to recover the computing environment and its data to normal day-to-day operations. A disaster can result from any of the following situations: Computer viruses that corrupt the computing system Hardware and software failures Infrastructure interruptions, inconsistencies, or loss of services, such as communications or network connections, which result in damage to the computing environment 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 the data after a crash. The following sections describe how to prepare for disaster recovery on the database or application server where NetWorker Module for Databases and Applications (NMDA) is installed or on the NetWorker server host, and how to perform an 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 the following: ASM environments (for example, requiring backups of ASM metadata) PowerSnap Module environments DB2 DPF, Oracle RAC, or Sybase ASE Cluster Edition environments 224 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery Preparing for disaster recovery The following sections provide guidelines on how to prepare for disaster recovery: Prepare a DB2 server for disaster recovery on page 225 Prepare an Informix server for disaster recovery on page 225 Prepare a Lotus server for disaster recovery on page 227 Prepare an Oracle server for disaster recovery on page 227 Prepare a Sybase server for disaster recovery on page 230 Prepare a DB2 server for disaster recovery To prepare a DB2 server environment for disaster recovery, implement a backup strategy that includes regular backups of the following: DB2 database files Transaction logs NetWorker bootstrap records (media database, resource database, and server index that reside on the NetWorker server) After manual backups, perform regular backups of the NetWorker server bootstrap and client file index by using the procedure described in Perform a NetWorker bootstrap and index backup on page 152. Perform regular scheduled backups of the DB2 server instances and transaction logs, with the NSR_DR_BACKUP_INFO parameter set to TRUE in the NMDA configuration file. This parameter setting ensures that additional disaster recovery and support information is backed up along with the scheduled backup. NSR_DR_BACKUP_INFO on page 358 provides details. You can set the NSR_DR_FILE_LIST parameter in the NMDA configuration file for schedules backups, to specify a file that contains a list of extra files to be backed up in addition to the scheduled backup. NSR_DR_FILE_LIST on page 358 provides details. Prepare an Informix server for disaster recovery To prepare an Informix server environment for disaster recovery, implement a backup strategy that includes regular backups of the following: Informix database files Logical logs NetWorker bootstrap records (media database, resource database, and server index that reside on the NetWorker server) After manual backups, perform regular backups of the NetWorker server bootstrap and client file index by using the procedure described in Perform a NetWorker bootstrap and index backup on page 152. Preparing for disaster recovery 225

Disaster Recovery Perform regular scheduled backups of the Informix server instances and logical logs, with the NSR_DR_BACKUP_INFO parameter set to TRUE in the NMDA configuration file. This parameter setting ensures that the following critical files are backed up along with the scheduled backup, as additional disaster recovery and support information: Informix ONCONFIG file ixbar file onconfig boot file sqlhosts file sm_versions file NSR_DR_BACKUP_INFO on page 360 provides details. After a manual backup, you can manually back up these critical Informix files through a NetWorker file system backup in preparation for disaster recovery. You can set the NSR_DR_FILE_LIST parameter in the NMDA configuration file for schedules backups, to specify a file that contains a list of extra files to be backed up in addition to the scheduled backup. NSR_DR_FILE_LIST on page 360 provides details. To prepare for an imported restore of an Informix server, follow the instructions in Prepare for an imported restore of an Informix server on page 226. Prepare for an imported restore of an Informix server To prepare for an imported restore of an Informix server, back up the database files on the original Informix server. To back up the Informix database files: 1. Set the following environment variables: NSR_SERVER = NetWorker_backup_server NSR_DATA_VOLUME_POOL = DBMIData NSR_LOG_VOLUME_POOL = DBMILogs 2. Perform a full backup of the source database server, for example: onbar -b -L 0 3. Back up copies of the following critical files located in the $INFORMIXDIR/etc (UNIX) or %INFORMIXDIR%\etc (Windows) directory. You must restore these files when you perform an imported restore to another computer. On the Informix IDS Server: oncfg_source_dbservername.servernum ixbar.servernum On UNIX: $ONCONFIG sqlhosts On Windows: %ONCONFIG% Use regedit to copy the sqlhosts information from the source computer to the target computer. Use the following registry entry: HKEY_LOCAL_MACHINE/SOFTWARE/Informix/SQLHOSTS/... 226 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery For all co-server numbers, copy the oncfg files: oncfg_source_db_server_name.server_number.coserver_number sqlhosts xcfg_source_computer_.server_number Imported restore of an Informix server on page 232 provides details on how to perform an imported restore. Prepare a Lotus server for disaster recovery To prepare a Lotus server environment for disaster recovery, implement a backup strategy that includes regular backups of the following: Domino notes.ini file Lotus data directory, unless you need to protect only certain subdirectories in the data directory Note: Transaction logs are backed up only if logging is enabled and set to archive mode. NetWorker bootstrap records (media database, resource database, and server index that reside on the NetWorker server) By default, the NMDA software backs up only specific types of files, as described in Files backed up during Lotus backups on page 38. If required, enable the backup of all types of files by setting the parameter NSR_BACKUP_ALL_EXTENSIONS=TRUE. NSR_BACKUP_ALL_EXTENSIONS on page 363 provides details. After manual backups, perform regular backups of the NetWorker server bootstrap and client file index by using the procedure described in Perform a NetWorker bootstrap and index backup on page 152. Prepare an Oracle server for disaster recovery To prepare an Oracle server for disaster recovery, back up the following minimum list of files: Oracle database (all the datafiles) Archived redo logs 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 that contains 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 Preparing for disaster recovery 227

Disaster Recovery 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. 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 Perform a NetWorker bootstrap and index backup on page 152. Perform the following steps to back up the required files in preparation for disaster recovery: 1. Create the DBID text file on page 228 2. Set up a postcommand script for backup of Oracle-related files on page 228 3. Set up RMAN backups of the database and related files on page 229 4. Set up RMAN backups of Recovery Catalog on page 229 Create the DBID text file 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 228. In the sample postcommand script provided with the NMDA software, the DBID text file is assumed to be dbid.txt, located in the $ORACLE_HOME directory. Sample Oracle postcommand script on page 240 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 that contains the Oracle DBID, as described in Create the DBID text file on page 228 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 228 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery 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 NMDA software. On UNIX, you can use any name for the postcommand script. On Windows, the script name must end in.bat. Note: During a scheduled NMDA backup, the nsrdasv 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 NMDA 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 NMDA configuration file. Sample Oracle postcommand script on page 240 provides details on the postcommand script that is provided with the NMDA software. Set up RMAN backups of the database and related files Set up an RMAN backup with NMDA to back up the following files: Oracle database (all the datafiles) Archived redo logs 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 NMDA. 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 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 228 provides details on setting up the postcommand script. Set up RMAN backups of Recovery Catalog 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 229. Oracle documentation provides more information on setting up and running Recovery Catalog backups. Preparing for disaster recovery 229

Disaster Recovery Prepare a Sybase server for disaster recovery To prepare a Sybase server environment for disaster recovery, implement a backup strategy that includes regular backups of the following: Sybase server instance and databases Transaction logs NetWorker bootstrap records (media database, resource database, and server index that reside on the NetWorker server) After manual backups, perform regular backups of the NetWorker server bootstrap and client file index by using the procedure described in Perform a NetWorker bootstrap and index backup on page 152. Perform the following additional tasks to prepare for disaster recovery: Keep up-to-date printouts of the Sybase system tables. Keep up-to-date printouts of the scripts for disk init and create databases. Do not store user databases or any databases other than master, tempdb, model, and sybsystemdb on the master device. Back up the master database after performing actions such as initializing database devices, creating or altering databases, or adding a new server login. The appropriate Sybase documentation provides more details. 230 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery Performing disaster recovery The following sections provide guidelines for performing disaster recovery operations: NetWorker server recovery on page 231 DB2 disaster recovery on page 231 Informix disaster recovery on page 232 Lotus disaster recovery on page 234 Oracle disaster recovery to a new host on page 240 Sybase disaster recovery on page 242 The EMC NetWorker Disaster Recovery Guide, available on Powerlink, provides information on how to recover a NetWorker server, client, or storage node from various types of disasters. NetWorker server recovery 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 disaster severity 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 NMDA backups. If only manual NMDA backups are performed, back up the bootstrap and client index manually. Perform a NetWorker bootstrap and index backup on page 152 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 Bootstrap information DB2 disaster recovery NetWorker software can be used to recover from different types of disasters on a DB2 server. The disaster severity determines the procedures that must be performed to recover the data. NetWorker server recovery on page 231 describes the types of information and records to maintain, and items required for a comprehensive disaster recovery. The NetWorker bootstrap and client index must be available on the NetWorker server before it can restore data to a DB2 server that has suffered a disaster. Perform a NetWorker bootstrap and index backup on page 152 provides details on how to back up the critical NetWorker server files with each DB2 backup. Performing disaster recovery 231

Disaster Recovery The DB2 backup and recovery documentation provides information on how to recover a DB2 database. DB2 data restore and recovery on page 168 provides details and procedures. Note: If the original DB2 server is not available because of a disaster, then the restore operation can be redirected to a different host, as described in the procedures. Informix disaster recovery The following sections provide information on disaster recovery procedures on an Informix IDS server. Imported restore of an Informix server You can use the imported restore feature to transfer all the data from one Informix server instance to the same instance on a different host. For example, you can restore objects to a different database server instance than the one it was backed up from. You can perform imported restores by using either whole system (serial) or storage-space (parallel) backups. Use the imported restore feature in the following cases: Server upgrade Disaster recovery High Availability Data Replication (HDR) server synchronization Before you perform an imported restore, you must back up the database files on the original Informix server according to Prepare for an imported restore of an Informix server on page 226. When performing an imported restore to a remote computer, you might not want to transfer data over a slow network. You could use the NetWorker storage node feature to improve restore performance. After physically transferring media (for example, tapes) containing the backup of the storage spaces and logical logs to the remote location, install the storage node on the remote computer and configure the NetWorker server to use the remote device of the storage node. The EMC NetWorker Administration Guide provides information on storage nodes. Perform an imported restore on the target Informix server on page 232 explains how to perform an imported restore of the database files on the new Informix server when you do not need to restore and rebuild the NetWorker server. Perform an imported restore on the target Informix server If the source INFORMIXDIR does not match the target INFORMIXDIR, you must create a symbolic link to recover the bootstrap from the source computer. For example, if INFORMIXDIR on the source computer is /usr2/informix and INFORMIXDIR on the target computer is /usr/local/informix, create the /usr2 directory on the target computer and the symbolic link as follows: On UNIX: mkdir /usr2 In -s /usr/local/informix /usr2/informix On Windows: Create a shortcut from the source INFORMIXDIR to the target INFORMIXDIR. The operating system documentation provides details on creating a shortcut. 232 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery For instructions on how to set up a new database, refer to the Informix Dynamic Server Administration Guide.! IMPORTANT To perform an imported restore, you must use the same database server number on the target computer that was used on the source computer. You can change the database server name in an imported restore. Shut down the target database server before doing a restore. For an IDS Dynamic Server, type the following: onmode -ky To restore the database files on the target Informix server: 1. Set up the target Informix server with exactly the same disk layout as the one you are transferring the data from. 2. Install the NetWorker client software, and install and enable NMDA. The EMC NetWorker Installation Guide provides installation instructions. 3. Set the required environment variables. For example: NSR_CLIENT = source machine host name NSR_SERVER = bu_server NSR_DATA_VOLUME_POOL = same value in original database NSR_LOG_VOLUME_POOL = same value in original database 4. Enable remote access rights for the source Informix server s client files and indexes on the NetWorker server. In the Remote Access attribute of the NetWorker Client resource of the source Informix server, add the hostname of the target Informix server. For example, add the following in the Remote Access attribute: *@target_dbservername 5. Restore the following Informix critical files: For the Informix server: $INFORMIXDIR/etc/oncfg_original_dbservername.servernum ixbar.servernum oncfg_source_dbservername.servernum ixbar.servernum For UNIX: $ONCONFIG sqlhosts For Windows: %ONCONFIG% Use regedit to copy the sqlhosts information from the source computer to the target computer. Use the following registry entry: HKEY_LOCAL_MACHINE/SOFTWARE/Informix/SQLHOSTS/... For all co-server numbers, copy the oncfg files: oncfg_source_dbservername.servernumber.coservernumber sqlhosts xcfg_sourcecomputer.servernumber Performing disaster recovery 233

Disaster Recovery 6. Rename the $INFORMIXDIR/etc/oncfg_original_dbservername.servernum file and replace the source server name with the target server name. For example: $INFORMIXDIR/etc/oncfg_ol_tgt_dbservername.servernum 7. Update the sqlhosts file and include the proper shared memory and network settings for the target Informix server. 8. Update the ONCONFIG file and replace the source server name with the target server name. For example: DBSERVERNAME ol_tgt_dbservername 9. Create the data spaces in the same path location as on the source server. 10. Perform a full system restore with the following onbar command: onbar -r Recovery from an Informix server disk crash To restore a damaged primary disk that contains critical Informix server dbobjects and NetWorker client binaries: 1. Reinstall the NetWorker client binaries, the NMDA software, and the Informix server software, if required. If you perform regular NetWorker backups of the system binaries, you can use NetWorker to recover the system data. 2. Use NetWorker to recover the emergency boot file and configuration file for the Informix server instance: recover -a \ $INFORMIXDIR/etc/sqlhosts \ $INFORMIXDIR/etc/onconfig.std \ $INFORMIXDIR/etc/ixbar.server_number \ $INFORMIXDIR/oncfg_server_name.server_number 3. If the physical media that contains the logical logs must be replaced before beginning the restore, manually salvage the current logical log file with the following onbar command: onbar -l -s 4. Restore data from the most recent backup with the following onbar command: onbar -r Once the restore completes, the Informix server is left in quiescent mode. The Informix server documentation provide more information on using the onbar command to restore data from NetWorker backup media. Lotus disaster recovery The following sections provide information on disaster recovery in the event that any of the following are damaged or lost: Lotus transaction logs Lotus Notes client Domino server data or binaries 234 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery Perform Lotus disaster recovery according to the instructions in the appropriate section: Recovery of a Lotus installation and databases on page 235 Recovery of a Lotus installation, databases, and transaction logs on page 236 Disaster recovery of partitioned Domino servers on page 237 Recovery of a Lotus installation and databases To recover a computer that has lost the Lotus installation and databases: 1. Reinstall the Lotus Notes client or Domino server in the same location as before, but do not configure it. 2. Recover the notes.ini file by using the nsrnotesrc command with the parameter setting NSR_NO_NOTES_INIT = TRUE in the NMDA configuration file. For example, to recover the notes.ini file on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_SERVER = NetWorker_server_name NSR_BACKUP_PATHS = C:\Lotus\Domino\notes.ini NSR_NO_NOTES_INIT = TRUE b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath c. When prompted whether to overwrite the current notes.ini file, type y. Note: To prevent the prompting, you can set the parameter NSR_RECOV_INTERACT = Y in the configuration file. 3. Recover all the databases by using the NOTES: option. You must recover the databases to a new location by using the nsrnotesrc command with the parameter setting NSR_RELOCATION_DEST = destination_path in the NMDA configuration file. For example, to recover all the databases: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_SERVER = NetWorker_server_name NSR_BACKUP_PATHS = NOTES: NSR_RELOCATION_DEST = destination_pathname b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath 4. After the databases are recovered, copy them to the Lotus data directory, and start the Lotus Notes client or Domino server. 5. Once the disaster recovery process is complete, perform a full backup of the Lotus Notes client or Domino server to avoid any future loss of data. Performing disaster recovery 235

Disaster Recovery Recovery of a Lotus installation, databases, and transaction logs To recover database backups up to the last committed transaction in the archived transaction logs, the following requirements must be met: The Domino server to be recovered must have had Lotus transactional logging enabled and set to Archive style. A backup of an up-to-date notes.ini file is available for the Domino server. A set of recoverable database backup files is available. The archived log extents (transaction log files) are backed up and available, from the time of the last full backup. To recover a computer that has lost the Lotus installation, databases, and transaction logs: 1. Reinstall the Domino server in the same location as before, but do not configure it. 2. Recover the Domino notes.ini file by using the nsrnotesrc command with the parameter setting NSR_NO_NOTES_INIT = TRUE in the NMDA configuration file. For example, to recover the notes.ini file on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_SERVER = NetWorker_server_name NSR_BACKUP_PATHS = C:\Lotus\Domino\notes.ini NSR_NO_NOTES_INIT = TRUE b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath c. When prompted whether to overwrite the current notes.ini file, type y. Note: To prevent the prompting, you can set the parameter NSR_RECOV_INTERACT = Y in the configuration file. 3. Check the Domino notes.ini file to determine the original log directory for the server, as specified by the TRANSLOG_Path setting. Ensure that this directory exists and it contains no old files. 4. Recover the last archived log extent that was backed up since that most recent full backup. Recover the log file to a temporary directory by using the nsrnotesrc command with the following restore parameters set in the NMDA configuration file: NSR_NO_NOTES_INIT = TRUE NSR_NUMBER_LOGS = 1 NSR_RELOCATION_DEST = temporary_directory_path For example, to recover the archived log file to the temporary directory D:\temp\Lotus directory on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_NO_NOTES_INIT = TRUE NSR_NUMBER_LOGS = 1 NSR_RELOCATION_DEST = D:\temp\Lotus 236 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath 5. Copy the recovered log files from the temporary directory to the original log directory for the server, as specified by the TRANSLOG_Path setting. 6. Enable the creation of the control file by setting the following parameter in the Domino notes.ini file: TRANSLOG_Recreate_Logctrl=1 7. Prepare the data directory by first recovering all of the required database files into a temporary directory. 8. After the databases are recovered, copy them to the Lotus data directory. 9. For a Domino server on Windows, copy the recovered notes.ini file to its original directory. By default, the notes.ini file is not located in the data directory. 10. Start the Domino server. 11. Once the disaster recovery process is complete, perform a full backup of the Domino server to avoid any future loss of data. Disaster recovery of partitioned Domino servers To perform disaster recovery of partitioned Domino servers, follow the appropriate instructions. Recovery of a Lotus installation and databases on a partitioned Domino server To recover a partitioned Domino server that has lost the Lotus installation and databases: 1. Reinstall the Domino server in its previous location, but do not configure it. 2. Ensure that the PATH parameter in the NMDA configuration file lists the Domino data directory of the partition to be recovered before the data directory of any other Domino server partition. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. 3. Recover the notes.ini file for the Domino server partition by using the nsrnotesrc command with the parameter setting NSR_NO_NOTES_INIT = TRUE in the NMDA configuration file. For example, to recover the notes.ini file on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_SERVER = NetWorker_server_name NSR_BACKUP_PATHS = C:\Lotus\Domino\data1\notes.ini NSR_NO_NOTES_INIT = TRUE b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath c. When prompted whether to overwrite the current notes.ini file for the partition, type y. 4. Recover all the databases for the server partition by using the nsrnotesrc command with the required parameter settings in the NMDA configuration file. Specify the partition s data path in the NSR_BACKUP_PATHS parameter. You must recover the databases to a new location by specifying the NSR_RELOCATION_DEST parameter. Performing disaster recovery 237

Disaster Recovery For example, to recover all the databases on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_CLIENT = client_name NSR_BACKUP_PATHS = C:\Lotus\Domino\data1 NSR_RELOCATION_DEST = D:\temp\Lotus\Server1 b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath 5. After the databases are recovered, copy them to the Lotus data directory for the appropriate Domino server partition. 6. For each Domino server partition, repeat step 2 through step 5. 7. Once all the Domino server partitions have been recovered, start each Domino server. Recovery of a Lotus installation, databases, and transaction logs on a partitioned Domino server To recover database backups on a partitioned Domino server up to the last committed transaction in the archived transaction logs, the following requirements must be met: The Domino server partitions to be recovered must have had Lotus transactional logging enabled and set to archive mode. A backup of an up-to-date notes.ini file is available for each server partition. A set of recoverable database backup files is available for each server partition. The archived log extents (transaction log files) for each server partition are backed up and available from the time of the last full backup. To recover a partitioned Domino server that has lost the Lotus installation, databases, and transaction logs: 1. Reinstall the Domino server in its previous location, but do not configure it. 2. Ensure that the PATH parameter in the NMDA configuration file lists the Domino data directory of the partition to be recovered before the data directory of any other Domino server partition. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. 3. Recover the notes.ini file for the Domino server partition by using the nsrnotesrc command with the parameter setting NSR_NO_NOTES_INIT = TRUE in the NMDA configuration file. For example, to recover the notes.ini file on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_SERVER = NetWorker_server_name NSR_BACKUP_PATHS = C:\Lotus\Domino\data1\notes.ini NSR_NO_NOTES_INIT = TRUE b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath c. When prompted whether to overwrite the current notes.ini file for the partition, type y. 238 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery 4. Check the notes.ini file to determine the original log directory of the Domino server partition, as specified by the TRANSLOG_Path setting. Ensure that this directory exists and it contains no old files. 5. Recover the last archived log extent that was backed up for the partition since that most recent full backup. Recover the log file to a temporary directory by using the nsrnotesrc command with the following restore parameters set in the NMDA configuration file: NSR_LOG_DIR = original_log_dirpath_of_partition_being_recovered NSR_NO_NOTES_INIT = TRUE NSR_NUMBER_LOGS = 1 NSR_RELOCATION_DEST = temporary_dirpath For example, to recover the archived log file to the temporary directory D:\temp\Lotus directory on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_LOG_DIR = C:\Lotus\Domino\data1\logs1 NSR_NO_NOTES_INIT = TRUE NSR_NUMBER_LOGS = 1 NSR_RELOCATION_DEST = D:\temp\Lotus b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath 6. Copy the recovered log file from the temporary directory to the original log directory for the server partition, as specified by the TRANSLOG_Path setting in the notes.ini file. 7. Enable the creation of the control file by setting the following parameter in the notes.ini file for the server partition: TRANSLOG_Recreate_Logctrl=1 8. Recover all the required database files for the server partition into a temporary directory. For example, to recover all the database files on Windows: a. Ensure that the NMDA configuration file contains the following parameter settings: NSR_CLIENT = client_name NSR_BACKUP_PATHS = NOTES:partition_datapath NSR_RELOCATION_DEST = temporary_dirpath b. Type the nsrnotesrc command to perform the recovery: nsrnotesrc -z config_filepath 9. Overwrite the data directory for the server partition with the contents of this temporary data directory. 10. For each Domino server partition, repeat step 2 through step 9. 11. Once all the Domino server partitions have been recovered, start each Domino server. Performing disaster recovery 239

Disaster Recovery Oracle disaster recovery to a new host To perform an Oracle disaster recovery to a new host: 1. Install the Oracle software on the new host. 2. Install NetWorker client and NMDA 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. Note: This is a requirement for directed recovery with the NetWorker software. 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 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. Sample Oracle postcommand script 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 228. The NMDA software includes a sample postcommand script that you can modify for your environment. The NMDA installation provides a sample postcommand script that is specific to UNIX or Windows, depending on the platform where NMDA 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 NMDA backup, the nsrdasv process passes the options -s server_name -g group_name to the postcommand script if the script name begins with nsrnmodr. Example 29 and Example 30 on page 241 describe the sample postcommand script that is installed with the NMDA software. 240 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery Example 29 Sample postcommand script on UNIX The sample postcommand script named nsrnmodrpostcmd is installed with the NMDA 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 30 Sample postcommand script on Windows The sample postcommand script named nsrnmodrpostcmd.bat is installed with the NMDA 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 Performing disaster recovery 241

Disaster Recovery :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 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 Sybase disaster recovery Perform Sybase disaster recovery according to Recover the Sybase server after a disaster on page 242. Note: For disaster recovery of Sybase ASE Cluster Edition, refer to Sybase documentation for the disaster recovery steps, and use NMDA to recover the databases and files. The following examples include procedures for recovering the Sybase master database and user databases in the event of a disaster: Example 31 on page 243 Example 32 on page 244 Recover the Sybase server after a disaster To recover the Sybase server after a disaster: 1. Reinstall the following software, if required: NetWorker client NMDA Sybase server If regular NetWorker backups of the system binaries are performed, use the NetWorker software to recover them. 2. Use the printout of database device allocations to re-create the databases. The Sybase documentation provides details on the information that should be tracked for disaster recovery. 3. Recover the Sybase system databases and user databases. The Sybase documentation provides details. 4. Use the nsrsybrc command to recover the Sybase data. Sybase data restore and recovery on page 210 provides details. 242 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery Example 31 Recover the master database The master database may be lost or corrupted in the event of disaster. The master database controls the operation of the Sybase server and stores information about all user databases and their associated database devices. Sybase documentation provides details on how to recover the master database in different scenarios. The following provides an example of a procedure that can be used to recover the master database on Sybase ASE version 15.0 and later under the following conditions: The master device is completely lost. A valid dump exists. The valid dump has a default sort order. All other devices are undamaged and do not require inspection.! IMPORTANT If the master database is recovered to a different Sybase server, all the device allocations are copied to the new Sybase server. If the master database is recovered to another Sybase server on the same computer as the original, they both attempt to use the same database files. Sybase documentation provides details on how to recover the master database to a different Sybase server. To recover the master database: 1. Rebuild the lost master device by using the dataserver command. 2. Start the Sybase server in single-user mode. This mode is also called master-recover mode. 3. Ensure that the Sybase server has the correct name for the Sybase Backup Server in the sysservers table. 4. Use the following nsrsybrc command to recover the master database from the backup: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name/master where: user_id is the username for the Sybase user account. password is the password for the Sybase user account. NetWorker_server_name is the name of the NetWorker server. ASE_server_name is the name of the Sybase server. Note: In the nsrsybrc command, the ASE_server_name is case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybrc command. After the master database is loaded, the Sybase server performs post-processing checks and validations and then shuts down. 5. Restart the Sybase server. Performing disaster recovery 243

Disaster Recovery 6. If required, recover the model and other databases that were on the master device. 7. Log in as Systems Administrator and inspect the databases on the Sybase server to ensure that all of the databases are present. Example 32 Recover user databases after database device failure The following provides an example of a procedure to recover Sybase user databases after the database device, not the log device, fails. Sybase documentation provides details on how to recover user databases. To recover a database after the database device fails: 1. Perform an incremental backup of each database on the failed device by using the nsrdasv command: nsrdasv -z config_filepath where config_filepath is the pathname of the NMDA configuration file. The configuration file must contain the following parameter settings: NSR_BACKUP_LEVEL=incr NSR_BACKUP_PATHS=SYBASE:/ASE_server_name/database_name NSR_DUMP_LOG_OPT= no_truncate NSR_SERVER=NetWorker_server_name SYBASE_USER=Sybase_username USER_PSWD=encrypted_password where: ASE_server_name is the name of the Sybase server. database_name is the name of the database on the Sybase server. NetWorker_server_name is the hostname of the NetWorker server. Sybase_username is the username for the Sybase user account. encrypted_password is the encrypted password for the Sybase user account, as set through the nsrdaadmin -P command. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA parameters. 2. Examine the space usage of each database on the failed device. For example, on the isql command line, type the following commands: select segmap, size from sysusages where dbid = db_id("database_name") sp_helpdb database_name where database_name is the name of the database on the failed device. 3. After the information for all databases on the failed device has been obtained, drop each database by using the drop database command. If the system reports errors because the database is damaged, use the dropdb option with the dbcc dbrepair command. On the isql command line, type the following command: dbcc dbrepair (database_name, dropdb) where database_name is the name of a database on the failed device. 4. Drop the failed device by using the sp_dropdevice system procedure. 244 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Disaster Recovery 5. Initialize the new devices by using the disk init command. 6. Re-create each database, one at a time, by using the create database command. 7. Recover each damaged database from the most recent database backup. For example: nsrsybrc -U user_id -P password -s NetWorker_server_name SYBASE:/ASE_server_name/database_name where: user_id is the user name for the Sybase user account. password is the password for the Sybase user account. NetWorker_server_name is the hostname of the NetWorker server. ASE_server_name is the name of the Sybase server. database_name is the name of a database on the Sybase server. Note: In the nsrsybrc command, ASE_server_name and database_name are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. The nsrsybrc command recovers the last full database backup of the specific database, and applies all of the associated transaction log backups in the order that they were created. The database is automatically brought online after the recovery operation. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybrc command. Performing disaster recovery 245

Disaster Recovery 246 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

6 Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems This chapter includes the following major sections: Cluster systems... 248 DB2 DPF systems... 257 Oracle RAC systems... 264 Sybase ASE Cluster Edition systems... 272 Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems 247

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Cluster systems A computer cluster is a group of linked computers that work closely together and in many respects may function as a single computer. Clusters are usually implemented for high availability solutions or to improve computer performance. 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. This is also known as an active-passive cluster. Two active-passive clusters might be referred to as active-active clusters in some cluster or application documents, but NMDA documents refer to them as active-passive clusters. Figure 26 on page 249 shows an example of two active-passive clusters. Note: Lotus Domino documents use the term active-active cluster for the Domino cluster configuration where each node has a Domino server on it and the node is able to take over if other nodes in the cluster fail. However, NMDA documents consider this configuration to be another form of an active-passive cluster. Together, the NetWorker Module for Databases and Applications (NMDA) and NetWorker server software can back up and restore a 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 if the configurations have been performed as described in Cluster backup configuration on page 250. After properly configuring a cluster service as a NetWorker client, NMDA 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. The EMC Information Protection Software Compatibility Guide provides details on all the supported cluster environments. Cluster backup configuration on page 250 provides details on the configuration of a cluster system for backup operations with the NMDA software. The following figures show examples of supported cluster configurations for DB2 systems: Figure 24 on page 249 Figure 25 on page 249 Figure 26 on page 249 248 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Storage Disk A B DB2 Node 0 (ACTIVE) A fails over to B DB2 Node 0 (PASSIVE) GEN-001079 Figure 24 Single DB2 node with failover capability Storage Disk A B DB2 Node 0 (ACTIVE) DB2 Node 1 (ACTIVE) A (NODE0, NODE1) fails over to B DB2 Node 0 (PASSIVE) DB2 Node 1 (PASSIVE) GEN-001080 Figure 25 Multiple DB2 nodes with failover capability Storage Disk A B DB2 Node 0 (ACTIVE) DB2 Node 1 (PASSIVE) A (NODE0) fails over to B B (NODE1) fails over to A DB2 Node 0 (PASSIVE) DB2 Node 1 (ACTIVE) GEN-001081 Figure 26 Multiple DB2 nodes with mutual failover capability Cluster systems 249

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Backup failover When a node failure occurs during a manual (unscheduled) backup, a database administrator (DBA) must restart the backup after instance recovery. When a node failure occurs during a scheduled 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. Cluster backup configuration The following sections provide the requirements and procedures for cluster backup configuration. Requirements for cluster backup configuration Before configuring backups in a cluster system, ensure the following: The cluster is properly set up according to the appropriate database server documentation. The NetWorker and NMDA software is properly installed on each physical node of the cluster. The EMC NetWorker Module for Databases and Applications Installation Guide provides details. DB2-specific cluster requirements Cluster backups may be configured differently for the various supported versions of DB2 databases: In supported DB2 version 9.1.x cluster environments, the same database cannot be backed up at the same time from each of the cluster nodes, but the backups must be done in sequence. When the backup runs, the next host in the cluster group displays the following message: The database is still in use In supported DB2 version 9.5 and later cluster environments, a single NetWorker Client resource, Group resource, and NMDA configuration file may be used to back up the cluster nodes. Lotus-specific cluster requirements The following Lotus-specific requirements apply to backups and restores in a supported cluster: Manual Lotus backups in a cluster To perform a manual backup from the command line of a Domino server on a supported cluster, follow the instructions in Manual backups of partitioned Domino servers on page 280. Note: Do not use the NetWorker User for Lotus program to perform a manual backup on a cluster because the index is then saved by using the physical node name. Scheduled Lotus backups in a cluster Lotus scheduled backup configuration in a cluster system on page 253 provides a configuration example for a Domino server in a cluster. 250 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Lotus recovery in a cluster To recover Lotus data in a supported cluster, you must perform a directed recovery from the virtual host to the local computer: Directed recovery to a different client or location on page 187 provides instructions on how to perform a directed recovery from the command line. Directed recovery through NetWorker User for Lotus on page 196 provides instructions on how to perform a directed recovery from the NetWorker User for Lotus program. Note: In this case, there is no limitation on applying transaction logs for a regular recovery because the transaction logs are on the shared disks. NSR_CLIENT setting for cluster systems The NSR_CLIENT parameter must be set correctly according to the methods described in Appendix A, NMDA Parameters for Backups and Restores. During an NMDA backup, the NetWorker server creates entries about the backed-up data in the online client file index. During an NMDA restore, the data is retrieved by first searching this client file index. The NSR_CLIENT parameter 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. 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. It is recommended that the NSR_CLIENT parameter be set to the virtual hostname in a cluster environment, to enable the restore of backup data no matter which physical host was used during the backup. Note: For an Oracle backup or restore only, set NSR_CLIENT to the same value for all channels allocated during the backup. Procedures for cluster backup configuration To configure database backups with NMDA in a cluster system: 1. Ensure that the cluster requirements are met in Requirements for cluster backup configuration on page 250. 2. Ensure that the required database server and NetWorker configurations are completed according to the Software configuration roadmap on page 70. Cluster systems 251

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 3. Ensure that the NetWorker client and NMDA software is properly installed on each physical node of the cluster. 4. Create an NMDA-specific Client resource on the NetWorker server for each virtual host that will run backups and restores, according to Customize a Client resource with NMC on page 89: The Save Set attribute must be set to the required value, as described in Table 9 on page 90. The Remote Access attribute must contain the name of each physical host that can store and retrieve the backups. Note: It is recommended that the NSR_CLIENT parameter be set to the virtual hostname. Cluster systems on page 248 provides details. The Remote Access attribute must include the following for each physical host: user=database_username,host=physical_hostname On Windows clusters only, the Remote Access attribute must also include the following for each physical host: user=system,host=physical_hostname For example, if physical nodes clus_phys1 and clus_phys2 are clustered together to form the virtual node in a Windows cluster, specify the following in the Remote Access attribute of the Client resource for the virtual host in a Lotus scheduled backup configuration: user=lotus_user,host=clus_phys1 user=lotus_user,host=clus_phys2 user=system,host=clus_phys1 user=system,host=clus_phys2 The following example shows the attribute settings in a Client resource configuration for a virtual host in a DB2 cluster on UNIX: Backup Command: nsrdasv -z pathname/nmda_db2.cfg Group: db2group Remote Access: dbinst@physical_hostname_for_node1.com dbinst@physical_hostname_for_node2.com Save Set: DB2:/SAMPLE/NODE0001 Other configuration examples are as follows: Lotus scheduled backup configuration in a cluster system on page 253 Sybase scheduled backup configuration in a cluster system on page 254 5. Create a generic ( dummy ) Client resource for each physical host that will run backups and restores, if a Client resource does not yet exist for a given physical host. The following is an example of the attribute settings in a dummy Client resource: Backup Command: (blank) Group: same_group_as_virtual_host Save Set: SKIP Note: A keyword is required in this attribute. Schedule: SkipAll 252 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Note: The Skip level in the SkipAll schedule causes the backup to be skipped on the physical host. 6. For deduplication support in the cluster system, ensure that the required configurations are completed, as described in Cluster systems on page 248. Example 33 Lotus scheduled backup configuration in a cluster system In the following procedure, the physical nodes clus_phys1 and clus_phys2 are clustered together to form the virtual node clus_vir1. To configure a Lotus scheduled backup in the cluster system: 1. Ensure that the Lotus software is installed on the cluster computers according to the Lotus cluster documentation. 2. Ensure that the NetWorker client and NMDA software is installed on each physical node, clus_phys1 and clus_phys2. 3. Create the NMDA configuration file in one of the following locations: On the virtual host s shared disk. In the same location on the local disk of each physical node. A copy of the configuration file must exist in the same location on each physical node. The configuration file must contain the mandatory Lotus backup parameters and any other required parameter settings. Ensure that the file includes this parameter setting in the Lotus section: NSR_CLIENT = clus_vir1 4. On the NetWorker server: a. Create a default NetWorker Client resource for each of the physical nodes, for example, clus_phys1 and clus_phys2. b. Create a NetWorker Client resource for each Domino virtual host. In each Client resource of a virtual host: 1. In the Save Set attribute, specify the data to be backed up. For example: For a typical active-passive Domino cluster configuration, type: NOTES: For a Domino cluster where each node has a Domino server on it and the node is able to take over if other nodes in the cluster fail, type: NOTES:/partition_data_dir 2. In the Backup Command attribute, type the nsrdasv(.exe) -z config_filepath command, where config_filepath is the complete pathname of the NMDA configuration file. 3. In the Group attribute, select the NetWorker group for the scheduled backup. Cluster systems 253

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 4. In the Remote Access attribute, add the following: user=lotus_user,host=clus_phys1 user=lotus_user,host=clus_phys2 Note: On Windows, also add the following in the Remote Access attribute: user=system,host=clus_phys1 user=system,host=clus_phys2 Example 34 Sybase scheduled backup configuration in a cluster system In the following procedure, the physical nodes, primary node clus_phys1 and secondary node clus_phys2, are clustered together to form the virtual node clus_vir1. The Sybase ASE server and Sybase Backup Server are set up in an active-passive cluster configuration. Failover can be performed from either node in the cluster. To configure a Sybase scheduled backup in the cluster system: 1. Ensure that the NetWorker client and NMDA software is installed on each physical node, clus_phys1 and clus_phys2. 2. On UNIX or Linux systems, create the required symbolic link to the Sybase library: If the Sybase ASE binaries are installed on the shared disk, ensure that the symbolic link to the Sybase library is created on the shared disk. If the Sybase ASE binaries are installed on each node in the cluster, ensure that the symbolic link to the Sybase library is created on each node where the NMDA software is installed and backups will be performed. The EMC NetWorker Module for Databases and Applications Installation Guide describes how to create the symbolic link to the Sybase library. 3. Create the NMDA configuration file in one of the following locations: On the virtual host s shared disk. In the same location on the local disk of each physical node. A copy of the configuration file must exist in the same location on each physical node. The configuration file must contain the mandatory Sybase backup parameters and any other required parameter settings. Ensure that the file includes this parameter setting in the Sybase section: NSR_CLIENT = clus_vir1 254 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 4. Ensure that all the required configurations are performed, as described in Software configuration roadmap on page 70. The basic NetWorker resources must be properly configured, according to Verifying the basic resource configurations on page 72. The Device, Group, Pool, and other resources must be set. A NetWorker Client resource must be created for each of the physical nodes and the virtual host. In the Client resource of the virtual host, clus_vir1: a. The Remote Access attribute must contain the following values: user=sybase_user,host=clus_phys1 user=sybase_user,host=clus_phys2 Note: On Windows, also add the following in the Remote Access attribute: user=system,host=clus_phys1 user=system,host=clus_phys2 b. The Backup Command attribute must contain the nsrdasv(.exe) -z config_filepath command, where config_filepath is the complete pathname of the NMDA configuration file. c. The Save Set attribute must specify either the entire Sybase server instance, or one or more Sybase databases for backup: SYBASE:/ASE_server_name[/database_name] To back up all the databases for the Sybase server, type the following in the Save Set attribute: SYBASE:/ASE_server_name To back up selected databases for the Sybase server, type each database name separately in the Save Set attribute: SYBASE:/ASE_server_name/database_name In the Client resource of each physical node, clus_phys1 and clus_phys2: a. The Save Set attribute must specify either the entire Sybase server instance, or one or more Sybase databases for backup: SYBASE:/ASE_server_name[/database_name] To back up all the databases for the Sybase server, type the following in the Save Set attribute: SYBASE:/ASE_server_name To back up selected databases for the Sybase server, type each database name separately in the Save Set attribute: SYBASE:/ASE_server_name/database_name b. The value of the Save Set attribute must be the same as the value of the Save Set string for clus_vir1. The Client resource of the clus_vir1 host must be assigned to the backup group that is configured for the scheduled backup. The required Sybase roles and permissions must be set up according to Set up Sybase roles and permissions on page 113. The Sybase ASE documentation and appropriate cluster vendor documentation provides information on Sybase ASE support in a cluster. Cluster systems 255

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Deduplication setup in cluster environments The NMDA software supports deduplication in cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition environments. NMDA provides this deduplication support to the same extent as the NetWorker software. To configure a deduplication backup in a cluster environment: 1. Perform the cluster backup configuration according to Cluster backup configuration on page 250. 2. For a scheduled deduplication backup, enable deduplication for the Client resource that is part of the NetWorker group for the backup. Note: The Client resource can be for a virtual or physical host. 3. For both scheduled and manual deduplication backups, enable deduplication for the Client resource of the host that is set in the NSR_CLIENT parameter. Configure a scheduled deduplication backup on page 122 provides more information on configuration of a scheduled deduplication backup. Configure a manual deduplication backup on page 123 provides more information on configuration of a manual deduplication backup. Recovery in a cluster For recovery in a cluster, ensure that the following configurations are in place: In the Client resource of the virtual host, the Remote Access attribute is set as described in Procedures for cluster backup configuration on page 251. The NSR_CLIENT parameter is set to the virtual hostname or the same hostname that was set in NSR_CLIENT during the backup. Cluster systems on page 248 provides details. Use the recovery procedures described in Chapter 4, Data Restore and Recovery. 256 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition DB2 DPF systems Note: A DB2 DPF type of cluster is also known as an active-active application cluster. The NMDA software supports backups and restores of DB2 DPF systems for parallelism and high availability. The DB2 Database Partitioning Feature (DPF) offers environments where a single database, divided by logical nodes, may reside on multiple partitions, either on the same host or on multiple hosts. Partitioned databases can manage high volumes of data and provide benefits such as increased performance and high availability. Both manual and scheduled DPF backups must use an NMDA configuration file, for example, nmda_db2.cfg. For deduplication support in a DPF environment, ensure that the required configurations are completed, as described in Deduplication setup in cluster environments on page 256. DPF backups with DB2 version 9.5 and later may be configured differently than with previous versions of DB2. The following figures show examples of supported DPF configurations: Figure 27 on page 257 Figure 28 on page 258 Figure 29 on page 258 Database instance Database partition Logical node 0 Shared memory or fast interconnect Database partition Logical node 1 GEN-001082 Figure 27 Single DPF host with shared memory If all database nodes reside in partitions on a single physical host that runs one copy of the operating system, then a scheduled backup requires the following configuration: Supported DB2 9.1.x versions Configure only one NetWorker Client resource, one Group resource, and one NMDA configuration file. Supported DB2 9.5 and later versions Configure only one NetWorker Client resource, one Group resource, and one NMDA configuration file. DB2 DPF systems 257

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Host 1 Database instance Host 2 Database partition Logical node 0 Interconnect Database partition Logical node 1 GEN-001083 Figure 28 Two DPF hosts with single nodes If the database nodes reside in partitions on separate physical hosts, then a scheduled backup requires the following configuration: Supported DB2 9.1.x versions Configure a separate NetWorker Client resource and NMDA configuration file for each partition. The partition with NODE0000 (the Catalog node) must have its own Group resource and must be backed up first. All other clients must be members of the same Group resource. Supported DB2 9.5 and later versions Configure only one NetWorker Client resource, Group resource, and NMDA configuration file. Host 1 Database instance Host 2 Database partition Nodes 0, 3 Interconnect Database partition Nodes 1, 2 GEN-001084 Figure 29 Two DPF hosts with multiple nodes If multiple DPF nodes reside in partitions on separate hosts, then a scheduled backup requires the following configuration: Supported DB2 9.1.x versions Configure a separate NetWorker Client resource and NMDA configuration file for each partition. The partition with NODE0000 (the Catalog node) must have its own Group resource and must be backed up first. All other clients must be members of the same Group resource. Supported DB2 9.5 and later versions Configure only one NetWorker Client resource, Group resource, and NMDA configuration file. Manual backup in a DPF environment DPF backups with NMDA must use an NMDA configuration file (for example, nmda_db2.cfg), which resides on the DB2 server. The following procedures are for a manual DPF backup with a partitioned database that resides on two host DB2 servers. 258 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Configure a manual DPF backup Configure a manual backup of a DPF database that resides on two host DB2 servers (host1 and host2), as follows: 1. Ensure that the DPF database partitions are properly configured according to the appropriate DB2 documentation. 2. Create an NMDA configuration file (for example, nmda_db2.cfg) in the database instance directory. The following parameters must be set: NSR_SERVER Name of the NetWorker server. NSR_CLIENT Name of the host with the database catalog node partition (NODE0000). Note: Setting NSR_CLIENT enables NetWorker to store all the nodes under the same index. Otherwise, there would be two nodes for host1 and two nodes for host2. 3. Use the NMC program (Configuration > Clients) to create a NetWorker Client resource for both host1 and host2. In each Client resource, set the Remote Access attribute to: *@* Run a manual DPF backup for DB2 9.1.x versions Run a manual DPF backup for supported DB2 9.1.x versions with the following command: db2_all db2 backup db sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg where: sample is the name of the database to be backed up. xx is the platform-specific extension. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. Run a manual DPF backup for DB2 9.5 and later versions Supported DB2 9.5 and later versions enable a manual DPF backup of either all partitions or specific partitions. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the db2 backup command for the backup. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. DB2 DPF systems 259

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition To run a manual DPF backup of all partitions: db2 backup db sample on all dbpartitionnums load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg where: sample is the name of the database to be backed up. xx is the platform-specific extension. pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. To run a manual DPF backup of specific partitions: db2 backup db sample on dbpartitionnums (1,3...) load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg where: sample is the name of the database to be backed up. 1, 3... are numerical values of each partition to back up (for example, 1 and 3 ). xx is the platform-specific extension. pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. Scheduled DPF backup in a DB2 9.1.x environment Supported DB2 9.1.x DPF scheduled backups with NMDA must use an NMDA configuration file (for example, nmda_db2.cfg), which must reside on the host with the database catalog node partition (NODE0000). In the example used in the following procedures, a database partitioned into four nodes resides on two host DB2 servers. Configure a scheduled DPF backup in a DB2 9.1.x environment Configure a scheduled backup of a supported DB2 9.1.x DPF database that resides on two host DB2 servers (for example, host1 and host2), as follows: 1. Ensure that the DPF database partitions are properly configured according to the appropriate DB2 documentation. 2. Create an NMDA configuration file (for example, nmda_db2.cfg) in the database instance directory. The configuration file should contain the following values: NSR_SERVER Name of the NetWorker server. NSR_CLIENT Name of the client with the DPF client partition (NODE0000). INSTHOME Pathname of the DB2 instance home directory. DB2_NODE_NAME Name of the DB2 instance. DB2_USER Name of the DB2 user. DB2_OPTIONS Either DB2BACKUP_ONLINE or DB2BACKUP_OFFLINE. Note: If the DPF partitions are configured as a cluster, DPF backups may be performed offline only and the DB2_OPTIONS parameter must be set to DB2BACKUP_OFFLINE. 3. Encrypt a DB2 user password with the nsrdaadmin -P command. USER_PSWD on page 359 provides details. 4. Use the NMC program to create two NetWorker Group resources, one of which is scheduled to start a backup before the other. 260 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition For example, create the groups dpf_group1 and dpf_group2, where dpf_group1 starts before dpf_group2. 5. Use the NMC program to create a NetWorker Client resource for the database host that has the DPF client partition (NODE0000). For example, the attributes are set as follows: Name: host1 Save Set: DB2:/sample/NODE0000 Group: dpf_group1 Backup Command: nsrdasv -z pathname/nmda_db2.cfg Remote Access: *@* Note: The group for the DPF client partition (NODE0000) must be scheduled to run before the other partitions. 6. Use the NMC program to create a second NetWorker Client resource for the database host that has the database catalog node partition (NODE0000), except with a Save Set for the other nodes on that host. For example, the attributes are set as follows: Name: host1 Save Set: DB2:/sample/NODE0003 Group: dpf_group2 Backup Command: nsrdasv -z pathname/nmda_db2.cfg Remote Access: *@* 7. Use the NMC program to create a NetWorker Client resource for the other database host (host2), which does not have the database catalog node partition. For example, the attributes are set as follows: Name: host2 Save Set: DB2:/sample/NODE0001 DB2:/sample/NODE0002 Group: dpf_group2 Backup Command: nsrdasv -z pathname/nmda_db2.cfg Remote Access: *@* 8. If the DPF partitions are configured as a cluster, set the NetWorker server or device parallelism to 1. Scheduled DPF backup in a DB2 9.5 or later environment With a supported DB2 9.5 or later version, the parameter DB2_PARTITION_LIST enables multiple partitions to be backed up at the same time. DPF scheduled backups must use an NMDA configuration file (for example, nmda_db2.cfg), which resides on the host with the DPF client partition. In the example used in the following procedures, a database partitioned into four nodes resides on two host DB2 servers. DB2 DPF systems 261

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Configure a scheduled DPF backup in a DB2 9.5 or later environment Configure a scheduled backup of a supported DB2 9.5 or later DPF database that resides on two host DB2 servers (for example, host1 and host2), as follows: 1. Ensure that the DPF database partitions are properly configured according to the appropriate DB2 documentation. 2. Create an NMDA configuration file (for example, nmda_db2.cfg) in the database instance directory. The configuration file should contain the following values: NSR_SERVER Name of the NetWorker server. NSR_CLIENT Name of the client with the database catalog node partition (NODE0000). INSTHOME Pathname of the DB2 instance home directory. DB2_NODE_NAME Name of the DB2 instance. DB2_USER Name of the DB2 user. DB2_OPTIONS Either DB2BACKUP_ONLINE or DB2BACKUP_OFFLINE. DB2_PARTITION_LIST is set as follows: To back up all the DPF partitions, specify the value all: DB2_PARTITION_LIST=all To back up specific DPF partitions only, specify the partitions in a comma-separated list, for example: DB2_PARTITION_LIST=0,1,3 Note: If the DPF partitions are configured as a cluster, DPF backups may be performed offline only and the DB2_OPTIONS parameter must be set to DB2BACKUP_OFFLINE. 3. Encrypt a DB2 user password with the nsrdaadmin -P command. USER_PSWD on page 359 provides details. 4. Only one Group resource is required. Use the NMC program to create a Group resource, for example, dpf_group1. 5. Use the NMC program to create a NetWorker Client resource for the database host (host1) that has the DPF client partition (NODE0000). For example, the attributes are set as follows: Name: host1 Save Set: DB2:/sample/NODE0000 Group: dpf_group1 Backup Command: nsrdasv -z pathname/nmda_db2.cfg Remote Access: *@* 6. Use the NMC program to create a NetWorker Client resource for the other database host (host2). For example, the attributes are set as follows: Name: host2 Save Set: DB2:/sample/NODE0001 Group: dpf_group2 Backup Command: nsrdasv -z pathname/nmda_db2.cfg Remote Access: *@* 262 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 7. If the DPF partitions are configured as a cluster, set the NetWorker server or device parallelism to 1. When the scheduled backup runs, the partitions specified in the parameter DB2_PARTITION_LIST are backed up. Restoring a DPF backup To restore a DPF backup, restore the DPF client partition first, then all the other partitions of the database. On one of the database partitions, use the commands for each specified database partition, as shown in the following example: db2_all <<+0< db2 restore database sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg replace existing db2_all <<+1< db2 restore database sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg replace existing db2_all <<+2< db2 restore database sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg replace existing db2_all <<+3< db2 restore database sample load /usr/lib/libnsrdb2.xx options @pathname/nmda_db2.cfg replace existing where: 0, 1, 2, or 3 is the database partition. sample is the name of the database to be restored. xx is the platform-specific extension. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, replace libnsrdb2.dll with libnsrdb232.dll in the command. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file Note: A restore with the db2_all command should always include replace existing or without prompting to prevent the operation hanging while waiting for a prompt. DB2 does not support user prompts for this type of operation. DB2 DPF systems 263

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Oracle RAC systems Note: An Oracle RAC type of cluster is also known as an active-active application cluster. The NMDA software supports backups and restores of Oracle RAC systems for parallelism and high availability. RAC terminology 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. 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. RAC backups and restores After proper configuration of RAC and the associated cluster system, NMDA enables Oracle backups on either a single node or several nodes of the RAC system. A parallel Oracle backup uses Oracle instances that run 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 setting for cluster systems on page 251 provides more information on setting the parameter. NMDA 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 Backup configuration in a RAC system on page 264. Backup configuration in a RAC system To configure database backups with NMDA 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 information. 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 267 provides guidelines. The appropriate Oracle documentation provides more information. 264 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 4. Install NMDA on each node of the cluster to be used for backup and restore operations. The EMC NetWorker Module for Databases and Applications Installation Guide provides more information. 5. Configure a NetWorker Client resource on the NetWorker server for the virtual host and each physical host that will run backups. Customize a Client resource with NMC on page 89 provides details on Client resource configuration. 6. 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 265. 7. Create the appropriate RMAN scripts for the preferred types of Oracle backups and restores on the RAC system. The following sections provide more details: Creating RMAN backup scripts on page 269 Creating RMAN restore scripts on page 270 8. Review the additional issues with Oracle recovery operations in Archived redo logs on page 271. 9. For deduplication support on Oracle RAC, ensure that the required configurations are completed, as described in Deduplication setup in cluster environments on page 256. 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 NMDA backup. 2. On the NetWorker server, create a NetWorker Storage Node resource for each RAC node to be used for the NMDA backup. The EMC 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 NMDA backup. The EMC 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 NMDA 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 NMDA backup and to initiate the backup. 7. For the RAC node that will initiate the NMDA backup, create a NetWorker Client resource with the attribute settings required for the backup, as described in NSR_CLIENT setting for cluster systems on page 251: 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 Oracle RAC systems 265

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 8. For each of the other RAC nodes that will not initiate the NMDA backup, create a basic Client resource. Settings in these other Client resources do not affect the NMDA backup. 9. On the RAC node that will initiate the NMDA backup, create the required NMDA configuration file and RMAN backup script. The RMAN script must include the NSR_CLIENT setting, as described in NSR_CLIENT setting for cluster systems on page 251. Oracle-specific NMDA parameters on page 368 provides details on setting the parameters required for Oracle backups in the NMDA configuration file. Example 35 on page 266 shows how to set up three RAC nodes as storage nodes for NMDA backups. Example 35 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 NMDA 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 NMDA 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 command used for the backup: nsrdasv(.exe) -z configuration_filepath where configuration_filepath is the complete pathname of the configuration file that contains the NMDA parameter settings for the backup. 266 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition The Group attribute is set to the backup group name. The Save Set attribute is set to the RMAN script pathname. Table 9 on page 90 provides more details on the Client resource attributes. 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 ; allocate channel t2 type SBT_TAPE connect sys/oracle@net_service_name_of_instance_b ; allocate channel t3 type SBT_TAPE connect sys/oracle@net_service_name_of_instance_c ; send channel t1 NSR_ENV=(NSR_CLIENT=A) ; send channel t2 NSR_ENV=(NSR_CLIENT=A) ; send channel t3 NSR_ENV=(NSR_CLIENT=A) ; backup database; release channel t1; release channel t2; release channel t3; } 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 { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send channel t1 NSR_ENV=(NSR_CLIENT=A) ; send channel t2 NSR_ENV=(NSR_CLIENT=A) ; restore database; release channel t1; release channel t2; } Connect-time failover Neither Oracle RMAN nor NMDA supports Transparent Application Failover (TAF). As a result, if a failure occurs during an Oracle backup, the backup is not automatically restarted from the point of failure on another node. Only connect-time failover is supported. When multiple listeners support a single service, a connect-time failover reroutes the connection request to another listener if the first listener is either down or cannot connect. 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)) ) Oracle RAC systems 267

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition ) (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 268 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 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. Oracle backup failover 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 NMDA 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) NMDA 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 NMDA backup. Creating RMAN backup scripts A single RMAN backup script can be used to run a parallel Oracle backup with NMDA 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 36 RMAN script for a manual Oracle backup on a RAC system 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 setting for cluster systems on page 251. Two channels are allocated to each of the nodes, node1.emc.com and node2.emc.com: run { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; Oracle RAC systems 269

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition } allocate channel t3 type SBT_TAPE connect user_name/user_passwd@connect_string_of_node2 ; allocate channel t4 type SBT_TAPE 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); release channel t1; release channel t2; release channel t3; release channel t4; Backing up all archived logs from each node on page 271 provides a sample script to back up all the archive log files in a RAC system. Creating RMAN restore scripts A single RMAN restore script can be used to run a parallel Oracle restore with NMDA 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: NMDA 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 37 RMAN script for an Oracle restore on a RAC system Refer to Example 36 on page 269. 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 restore script is to be run on node2.emc.com. The script restores the backup that was created by the backup script in Example 36 on page 269. 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 { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; allocate channel t3 type SBT_TAPE connect user_name/user_passwd@connect_string_of_node1 ; allocate channel t4 type SBT_TAPE connect user_name/user_passwd@connect_string_of_node1 ; send NSR_ENV=(NSR_CLIENT=node1.emc.com, NSR_SERVER=server1.emc.com) ; restore database; release channel t1; release channel t2; release channel t3; release channel t4; } 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 270 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 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 EMC NetWorker Administration Guide provides more information on how to modify the Client resource. Restoring all archived logs from each node on page 271 provides a sample script to restore all the archive log files in a RAC system. Archived redo logs 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 271 Restoring all archived logs from each node on page 271 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, such as a node named ops1.emc.com, by using the following type of RMAN script: run { allocate channel t1 type SBT_TAPE connect user_name/user_passwd@connect_string_of_ops1 ; allocate channel t2 type SBT_TAPE connect user_name/user_passwd@connect_string_of_ops2 ; send NSR_ENV=(NSR_CLIENT=ops1.emc.com) ; backup filesperset 10 (archivelog all delete input format al_%s_%p ); release channel t1; release channel t2; } Restoring all archived logs from each node All the archived log files in a RAC system can be restored from a single node, such as a node named ops1.emc.com, by using the following type of RMAN script: run { allocate channel t1 type SBT_TAPE connect user_name/user_passwd@connect_string_of_ops1 ; allocate channel t2 type SBT_TAPE connect user_name/user_passwd@connect_string_of_ops2 ; send NSR_ENV=(NSR_SERVER=mars.emc.com, NSR_CLIENT=ops1.emc.com) ; restore (archive log all); release t1; release t2; } Oracle RAC systems 271

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Sybase ASE Cluster Edition systems Note: A Sybase ASE Cluster Edition type of cluster is also known as an active-active application cluster. The NMDA software supports backups and restores of Sybase ASE Cluster Edition systems for parallelism and high availability. ASE Cluster Edition terminology An ASE Cluster Edition system consists of multiple ASE servers across multiple nodes that connect to a shared set of disks and run as a shared-disk cluster, including multiple physical hosts. In an ASE Cluster Edition system: Each machine is known as a node. Each ASE server is an instance. Each node contains one instance. All the nodes must be on a storage area network (SAN). The connected instances that form the cluster together manage a set of databases that reside on shared disks. All the databases are accessible from each instance. The multiple instances that make up the cluster appear to clients as a single system. Clients connect logically to the shared-disk cluster while remaining connected physically to individual instances. If one instance fails in the cluster, clients connected to that instance can fail over to any of the remaining active instances. The database devices in the cluster (except for private devices used by local user temporary databases) must be raw devices, not block devices. The quorum device that includes configuration information for the cluster and is shared by all the instances must be on a raw partition that is accessible to all the nodes of the cluster. The ASE Cluster Edition documentation provides details on setting up the required devices and configuring the nodes and instances of an ASE Cluster Edition system. ASE Cluster Edition backups and restores After proper configuration of an ASE Cluster Edition system, NMDA supports Sybase backups on the system. Select one node in the cluster to use for all backups. If the backup node goes down, you can switch to a different node in the cluster for the backups. However, from that point on, you should use the new node as the backup node. Do not constantly switch backup servers.! IMPORTANT NMDA operations do not support failover on ASE cluster databases. 272 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition On the node where backup or recovery is to be performed: NetWorker client software must be installed according to the EMC NetWorker Installation Guide. NetWorker client software must installed before the NMDA software. NMDA software must be installed according to the EMC NetWorker Module for Databases and Applications Installation Guide. NMDA software is not required on a node where backup and recovery is not performed. A Sybase backup server must be configured. NMDA supports two types of Sybase backup server configurations: Single backup server configuration Multiple backup server configuration In a single backup server configuration, the ASE cluster contains only one backup server at any one time. The backup server may be moved from one node to another node by the cluster administration, but only one node at a time contains a running backup server. Single backup server configuration on page 273 provides more information on this type of configuration. In a multiple backup server configuration, the ASE cluster contains two or more backup servers, running simultaneously on separate nodes. Any of the backup servers can perform the backup or restore of the databases. Multiple backup server configuration on page 274 provides more information on this type of configuration. The ASE Cluster Edition documentation provides details on Sybase backup servers in an ASE cluster. Note: For disaster recovery of Sybase ASE Cluster Edition, refer to Sybase documentation or Sybase Technical Support for the disaster recovery steps, and use NMDA to recover the databases and files. Single backup server configuration You must run the nsrdasv and nsrsybrc commands on the same node as the Sybase backup server. You can run the nsrsybcc command on any node in the cluster. You must select one node to act as the index node. All the backups of the ASE cluster are recorded in the client file index of the index node. When you perform backups and restores on the index node, the NMDA configuration and operation is the same as on a nonclustered Sybase server. If the Sybase backup server is moved from the index node to a different node, follow these guidelines during backups and restores: Backups Note: It is recommended that you perform the backups on the index node only. Select one node to act as both the backup node and index node, and use it for all backups. If you must switch to a new index node, continue to use the new node for all subsequent backups. The first backup on a new index node is a full backup. Sybase ASE Cluster Edition systems 273

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Restores Use the nsrsybrc -c option to specify the NetWorker client hostname. Use the nsrsybrc -d option to specify a redirected restore. For example: nsrsybrc -U user_id -P password -s NetWorker_server_name c index_node_name -d SYBASE:/backup_server_node_Sybase_instance_name/database_name SYBASE:/index_node_Sybase_instance_name/database_name Note: In the nsrsybrc command, the instance names and database names are case-sensitive and must be in the same case as recorded in the backup entries in the NetWorker indexes. For deduplication support, ensure that the required configurations are completed, as described in Deduplication setup in cluster environments on page 256. Multiple backup server configuration You must run the nsrdasv and nsrsybrc commands on the same node as the Sybase backup server. You can run the nsrsybcc command on any node in the cluster. You must select one node to act as the index node. All the backups of the ASE cluster are recorded in the client file index of the index node. A Sybase ASE Cluster Edition system supports two types of multiple backup server configurations: Dedicated Each instance in the cluster is assigned a specific backup server. Round-robin An instance is not assigned a specific backup server, but the cluster assigns the least busy backup server from a group according to availability.! IMPORTANT NMDA supports only the dedicated type of multiple backup server configuration, not the round-robin type. When you perform backups and restores on the index node, the NMDA configuration and operation is the same as on a nonclustered Sybase server. If you perform backups or restores on a different node from the index node, you must set the NSR_CLIENT parameter and use the nsrsybrc c and d command options, as described in Single backup server configuration on page 273. Note: It is recommended that you perform the backups on the index node only. Select one node to act as both the backup node and index node, and use it for all backups. If you must switch to a new index node, continue to use the new node for all subsequent backups. The first backup on a new index node is a full backup. 274 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Backup of temporary databases An ASE Cluster Edition system supports the following types of temporary databases: Local system Local user Global user Global system The NMDA software skips the backup of all these types of temporary databases in an ASE Cluster Edition system, just as it skips the backup of tempdb and user-created temp databases on nonclustered Sybase installations. Backup and recovery of the quorum device The NMDA software does not provide backups of the quorum device. You must back up the quorum device by using the Sybase qrmutil utility. The qrmutil utility creates a backup of the quorum device as a file on the file system. The Sybase ASE Cluster Edition documentation provides details on the utility. You can then use the NetWorker save binary to back up the quorum backup file. Note: It is the responsibility of the backup administrator to create the quorum device backup file and to protect that backup file with the NetWorker save binary. To recover the quorum backup file, you must use the NetWorker recover binary. The recover binary restores the quorum backup file as a file on the file system. You must then load the quorum backup file into the database by using the appropriate Sybase ASE Cluster Edition utility. Recovery of the master database on clusters The instructions for recovering the master database on Sybase clusters differ from the instructions for recovering the master database on Sybase single node installations. As of Sybase ASE release 15.0.3, the instructions for recovering the master database on Sybase clusters are not included in the Sybase documentation. You must contact Sybase Technical Support to obtain the instructions. Disregard Sybase instructions that recommend the use of the load command for recovering database backups. You must use the nsrsybrc command to recover the Sybase master database, not the load command. Use the nsrsybrc command for the recovery after starting the instance in single-user mode, which is also known as master-recover mode. Sybase ASE Cluster Edition systems 275

Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition 276 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

7 Multiple Domino Installations and Partitioned Domino Servers This chapter includes the following major sections: Multiple Domino installations on UNIX... 278 Partitioned Domino servers... 280 Multiple Domino Installations and Partitioned Domino Servers 277

Multiple Domino Installations and Partitioned Domino Servers Multiple Domino installations on UNIX To operate the NetWorker Module for Databases and Applications (NMDA) software in an environment that contains multiple Domino installations on a single UNIX host: 1. Install the NMDA software according to the instructions in the EMC NetWorker Module for Databases and Applications Installation Guide. 2. Perform a backup or recovery according to the instructions in this guide. In addition, consider the following important notes: Manual backups with multiple Domino installations on page 278 Scheduled backups with multiple Domino installations on page 278 Recovery with multiple Domino installations on page 279 Manual backups with multiple Domino installations To perform a manual backup with multiple Domino installations: 1. Ensure that the required backup parameters (for example, Notes_ExecDirectory) in the NMDA configuration file are set to the correct values for the specific Domino server only. Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters in the NMDA configuration file. 2. Ensure that the backup is run by the same user that operates the Domino server that is being backed up. 3. On Linux or Solaris, set the environment variable LD_LIBRARY_PATH to the complete pathname of the Lotus program directory that contains the library file libnotes.so belonging to the given installation. Scheduled backups with multiple Domino installations To configure a scheduled backup for multiple Domino installations on the same host by using the wizard, run the wizard separately for each installation. To configure a scheduled backup for multiple Domino installations on the same host without the wizard: 1. Create a separate NMDA configuration file for each Domino installation. Each configuration file must include the required parameters for the specific Domino installation, such as LOTUS_USER, Notes_ExecDirectory, and NSR_LOTUS_DATA_DIR. Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters in the NMDA configuration file. 2. On the NetWorker server, create a separate NetWorker Client resource for each Domino installation. In the Client resource: For the Backup Command attribute, specify the value nsrdasv(.exe) -z config_filepath, where config_filepath is the configuration file pathname for the specific installation. For the Save Set attribute, specify a unique name for the specific installation. 278 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Multiple Domino Installations and Partitioned Domino Servers Recovery with multiple Domino installations To perform a recovery with multiple Domino installations: 1. Ensure that the required restore parameters are set in the NMDA configuration file to the correct values for the specific Domino server only. Appendix A, NMDA Parameters for Backups and Restores, provides details on the parameters in the configuration file. a. Set the PATH parameter to include the directory of the Domino server to be recovered that contains the notes.ini file. b. Ensure that the PATH environment variable does not contain the data directories of any other Domino servers. c. When recovering all the Lotus data for a specific Domino server, set the NSR_BACKUP_PATHS parameter to specify each top-level directory that contains the data for that Domino server. For example: NSR_BACKUP_PATHS = /space1/notesdata1, /space1/linkdata1 Note: Do not specify just NOTES: for the NSR_BACKUP_PATHS parameter because NMDA then attempts to recover all the Lotus data for all the Domino servers on the host. d. When performing a disaster recovery, set the NSR_LOG_DIR parameter to specify the transaction log directory for the specific Domino server, even if it is not a partitioned Domino server. For example: NSR_LOG_DIR = transaction_log_dirpath 2. Ensure that the recovery is run by the same user that operates the Domino server to be recovered. 3. On Linux or UNIX, set the environment variable LD_LIBRARY_PATH or LIBPATH (depending on the type of operating system) to the complete pathname of the Lotus program directory that contains the library file libnotes.so belonging to the given installation. Multiple Domino installations on UNIX 279

Multiple Domino Installations and Partitioned Domino Servers Partitioned Domino servers To perform backups and recovery of partitioned Domino servers, follow the instructions in the preceding chapters of this guide. In addition, consider the following important notes: Manual backups of partitioned Domino servers on page 280 Scheduled backups of partitioned Domino servers on page 280 Recovery of partitioned Domino servers on page 281 Manual backups of partitioned Domino servers To enable manual backups of partitioned Domino servers from either the command line or the NetWorker User for Lotus program (latter on Windows only), set the required parameters in the NMDA configuration file: 1. Set the mandatory Lotus backup parameters for the partition, such as Notes_ExecDirectory and NSR_RESOURCE_DIR (UNIX only). 2. Set the NSR_LOTUS_DATA_DIR parameter to specify which partitioned Domino server to back up. 3. Perform one of the following: For a command line backup through the nsrdasv program, set one of the following to specify the data to back up: NSR_BACKUP_LOTUS_DIR To back up the entire partition. NSR_BACKUP_PATHS To back up one or more specific directories, or files, or both. For backup with the NetWorker User for Lotus GUI, select the files or directories to be backed up in the GUI. For manual backups from the NetWorker User for Lotus program, specify the complete pathname of the NMDA configuration file in the Configuration File field of the Backup Options dialog box. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. Scheduled backups of partitioned Domino servers To configure a scheduled backup of partitioned Domino servers by using the wizard, run the wizard separately for each partition of a Domino server to be backed up. To configure a scheduled backup of partitioned Domino servers without the wizard, create the following for each partition of a Domino server to be backed up: 1. Create a separate NMDA configuration file manually. Ensure that the configuration file includes the mandatory Lotus backup parameters and other required parameters for the partition, same as done for command line manual backups in Manual backups of partitioned Domino servers on page 280. 280 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Multiple Domino Installations and Partitioned Domino Servers 2. Create a NetWorker Client resource for the partition with the required attribute settings: a. For the Name attribute, specify the hostname of the computer, not the name of the Domino server partition. b. For the Backup Command attribute, specify the nsrdasv(.exe) -z config_filepath command, where config_filepath is the complete pathname of the NMDA configuration file for the partition. c. For the Save Set attribute, specify a descriptive name for the backup save set to be stored on the media. The Save Set value must start with the NOTES: prefix. Customize a Client resource with NMC on page 89 provides details on the Save Set attribute. For example, you could specify the following for the Save Set attribute: When you back up the entire data directory for the partition: NOTES:partition1_/disk2/notesdata1 When you back up a database named db.nsf for the partition: NOTES:partition1_/disk2/notesdata1/db.nsf Recovery of partitioned Domino servers To enable recovery of partitioned Domino servers, set the required parameters in the NMDA configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. 1. Set the PATH parameter to include the directory of the partitioned Domino server to be recovered that contains the notes.ini file. 2. Ensure that the PATH environment variable does not include the data directories of any other partitioned Domino servers. 3. When recovering all the Lotus data for a partitioned Domino server, use the NSR_BACKUP_PATHS parameter to specify each top-level directory that contains the data for the partition to be recovered. For example: NSR_BACKUP_PATHS = NOTES:M:\Lotus\p1data Note: Do not specify just NOTES: for the NSR_BACKUP_PATHS parameter because NMDA then attempts to recover all the Lotus data for all the Domino servers on the host. Disaster recovery of partitioned Domino servers on page 237 provides details on performing disaster recovery of partitioned Domino servers. Partitioned Domino servers 281

Multiple Domino Installations and Partitioned Domino Servers 282 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

8 Snapshot Backups and Restores This chapter includes the following major sections: PowerSnap snapshot operations... 284 Oracle PowerSnap operations... 290 DB2 PowerSnap operations... 326 Replication Manager snapshot operations with Oracle ASM... 332 Snapshot Backups and Restores 283

Snapshot Backups and Restores PowerSnap snapshot operations PowerSnap snapshot backups and restores provide continuous snapshot-based protection and availability of data on specific types of primary storage. The NetWorker Module for Databases and Applications (NMDA) software supports PowerSnap snapshot backups and restores of DB2 and Oracle data with the following requirements: The PowerSnap snapshot backups create point-in-time (PIT) copies (snapshots) of the data that resides on primary storage devices supported by the PowerSnap Modules that work with the NMDA software. The EMC Information Protection Software Compatibility Guide on the Powerlink website provides a complete list of supported PowerSnap Modules. Note: NMDA supports the PowerSnap Module for RecoverPoint for the backups and restores of Oracle data only. The EMC Information Protection Software Compatibility Guide details the specific storage arrays that the PowerSnap Module for RecoverPoint supports. The PowerSnap snapshot operations use the particular PowerSnap Module software designed for the primary storage. The following sections provide information on platform and software requirements and the supported types of PowerSnap snapshot backups and restores: Supported environments for PowerSnap snapshot operations on page 284 Required software for PowerSnap snapshot operations on page 285 Types of supported PowerSnap backups on page 286 Types of supported PowerSnap restores on page 287 PowerSnap backup processes on page 288 The following sections provide details on how to configure and perform DB2 and Oracle PowerSnap operations: Oracle PowerSnap operations on page 290 DB2 PowerSnap operations on page 326 Supported environments for PowerSnap snapshot operations NMDA software works with the supported NetWorker PowerSnap Module and NetWorker software to back up snapshots of DB2 or Oracle databases and restore the data. Note: NMDA supports PowerSnap snapshots for scheduled full backups only. The supported types of primary storage platforms for snapshot backups and restores with NMDA include the following: EMC CLARiiON EMC Symmetrix EMC Celerra (NAS Filers) 284 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores The following sources provide details on supported software releases and the installation requirements for PowerSnap snapshot operations: EMC Information Protection Software Compatibility Guide EMC NetWorker Module for Databases and Applications Installation Guide EMC NetWorker PowerSnap Module documentation (Refer to the PowerSnap Module version for the primary storage system.) Required software for PowerSnap snapshot operations Table 21 on page 285 lists the software requirements for a typical network environment that uses the NMDA software for PowerSnap snapshot operations. Table 21 Typical configuration for PowerSnap snapshot operations with NMDA Computer or device Database server host Proxy client host (data mover) NetWorker server host Required software or configuration DB2 or Oracle server, NetWorker client, NMDA, PowerSnap Module NetWorker client, NetWorker storage node (optional), PowerSnap Module NetWorker server Figure 30 on page 286 shows the software components used in the NMDA environment for PowerSnap backups and restores. PowerSnap snapshot operations 285

Snapshot Backups and Restores NetWorker Server NetWorker Storage Node Storage LAN Database Server Host Database Server NetWorker Client NMDA PowerSnap Module SAN Proxy Client NetWorker Client PowerSnap Module Storage Array (Symmetrix, CLARiiON, or Celerra) S4 S5 S3 Primary Storage LUNs/Volumes S1 S2 Snapshots GEN-001089 Figure 30 Software used in the NMDA environment for PowerSnap backups and restores Types of supported PowerSnap backups NMDA supports the following types of PowerSnap snapshot backups, in cooperation with the appropriate PowerSnap Module: Instant backup (snapshot) on page 286 Live backup (snapshot rollover) on page 287 Instant backup (snapshot) An instant backup creates a point-in-time copy (snapshot) of the data on the primary storage system. Instant backups can be scheduled to occur many times in a single day, with little impact to the database server or network. A snapshot policy must be configured to control the lifecycle of the snapshot. The policy specifies the frequency of instant backups and how long snapshots are retained before being recycled. 286 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores The description of the data collection within a snapshot is stored in the NetWorker media database as a snap set. A snap set is a save set record, stored in the media database from a single client, which provides the information required for the application to access a point-in-time copy created on an external disk subsystem. The following sections provide more details: Configuring Oracle PowerSnap backups on page 290 Configuring DB2 PowerSnap backups on page 326 Live backup (snapshot rollover) A live backup creates a point-in-time copy (snapshot) of the data on the primary storage system, and then backs up the snapshot through the proxy client (data mover) to secondary (traditional) storage, such as tape or disk.! IMPORTANT Instant backups protect against logical failures only. To protect against physical failures such as disk array failures, the snapshot must be backed up to secondary storage. NMDA supports the following two types of live backups: Deferred live backup An existing snapshot, previously created during an instant backup, is backed up to secondary storage, such as tape. The snapshot is retained on the primary storage. Note: A deferred live backup runs automatically as part of a scheduled backup, as specified by the Backup Snapshots attribute of the Snapshot Policy resource. Immediate live backup (serverless backup) A snapshot is created and immediately backed up to secondary storage, such as tape. The snapshot is then automatically deleted from the primary storage. A snapshot policy must be configured to enable live backups. The following sections provide more details: Configuring Oracle PowerSnap backups on page 290 Configuring DB2 PowerSnap backups on page 326 A proxy client host that is separate from the database server host can be used to move the snapshot to the secondary storage. Using a proxy client reduces the impact on the database server. Note: The proxy client can be a NetWorker storage node. Types of supported PowerSnap restores NMDA supports three types of PowerSnap snapshot restores, in cooperation with the appropriate PowerSnap Module. Instant restore During an instant restore, the saved data is retrieved from a mounted snapshot that was created through an instant backup. This type of restores requires a minimal amount of time. PowerSnap snapshot operations 287

Snapshot Backups and Restores Rollback restore A rollback restores an entire snapshot back to its source location on the database server by using the hardware capabilities. A rollback is a destructive restore because it overwrites 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. Note: A rollback restore does not support relocation of the database to a different host because it requires the data to be reverse synchronized between the snapshot and its original source. Restore from secondary storage A restore from secondary storage restores a snapshot that was backed up to the storage through a live backup. This type of restore may be redirected to a different host. The PowerSnap Module supports two types of restore from secondary storage, conventional and file-logical image restore (FLIR). The PowerSnap Module documentation provides more details. PowerSnap backup processes Note: A PowerSnap backup can be started only by automatic or manual invocation of the NetWorker scheduled backup group. For example, an Oracle PowerSnap backup cannot be scheduled through Oracle Enterprise Manager or started from Oracle RMAN. The PowerSnap Module documentation provides details on how to manually invoke a scheduled backup. In general terms, a PowerSnap snapshot backup involves the following processes: 1. At the time scheduled for the snapshot backup, the NetWorker server starts processes on the database server host that involve NMDA and the PowerSnap Module. 2. On the database server host, the PowerSnap Module uses a storage platform-specific application programming interface (API) to take a point-in-time (PIT) snapshot of the database data on the primary storage, which then becomes available to the proxy client (data mover). 3. If a live backup is performed, the PowerSnap Module on the proxy client moves the snapshot data on the primary storage to the NetWorker server or storage node, which stores the data on secondary storage, such as tape or disk. If required, the PowerSnap Module deletes the snapshot from the primary storage. 4. At the end of the snapshot backup, the NetWorker server updates the online client and media indexes with information about the backup. The EMC NetWorker Administration Guide provides details on NetWorker server and client programs and services. Figure 31 on page 289 illustrates the data flow of PowerSnap backups and restores in in the NMDA environment. 288 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Database Server Host NetWorker Client PowerSnap Data Mover Host Control NetWorker Server Database Server NMDA NetWorker Client PowerSnap Module PowerSnap Module Data NetWorker Server Database Datafiles Point-in-Time Copy of Datafiles Storage Medium Primary Storage GEN-000868 Figure 31 PowerSnap live backup and restore data flow PowerSnap snapshot operations 289

Snapshot Backups and Restores Oracle PowerSnap operations The following sections provide details on how to configure and perform Oracle PowerSnap operations. Note: Certain Oracle RMAN features, such as checking for corrupt blocks, are not applicable to PowerSnap snapshot operations. NMDA and the PowerSnap Modules do not support PowerSnap snapshot backups and restores of Oracle archived redo logs. Configuring Oracle PowerSnap backups To configure PowerSnap snapshot backups of Oracle databases: 1. Ensure that both the NMDA and required PowerSnap Module software are installed according to the instructions in the following: EMC NetWorker Module for Databases and Applications Installation Guide NetWorker PowerSnap Module documentation Note: The Oracle database layout must be configured to position the datafiles on primary storage that is supported by the specific PowerSnap Module. 2. Review Types of supported PowerSnap backups on page 286 to determine which type of snapshot backup to perform. 3. Ensure that the basic database server and NetWorker configurations are performed according to the Software configuration roadmap on page 70. The required NetWorker Server, Client, Device, and other resources must be configured. For live 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. 4. Cutomize the required scheduled backup configurations for the Oracle PowerSnap backups: Configure internationalization (I18N) support on page 291 Configure the required Oracle settings on page 291 Configure the NWORA resource file on page 291 Create RMAN scripts for Oracle PowerSnap backups on page 292 Configure the NetWorker Pool resources on page 296 Configure the NetWorker Snapshot Policy resource on page 296 Configure the NetWorker Group resource on page 296 Configure the NetWorker Client resource on page 297 Configure deduplication PowerSnap backups on page 298 Test the scheduled backup configurations according to Test a scheduled PowerSnap backup on page 298. 290 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Review the following information on performing Oracle PowerSnap backups and restores: Oracle PowerSnap backup requirements on page 299 Oracle PowerSnap backup information in NetWorker indexes on page 302 Oracle PowerSnap restore requirements on page 305 Configure internationalization (I18N) support In a non-english environment, NMDA supports internationalization (I18N) of PowerSnap backups and restores with a PowerSnap Module, as described in Internationalization (I18N) on page 31. To configure I18N support for PowerSnap backups, follow the instructions in Configuring I18N support on page 78. Additional Oracle-specific instructions are provided in Oracle-specific requirements for I18N support on page 109. Configure the required Oracle settings For Oracle PowerSnap backups, 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 PowerSnap 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: 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. Configure the NWORA resource file To enable PowerSnap backups, the NSR_ORACLECAT_MODE parameter resource must be set to either enabled or disabled in the NWORA resource file, as described in NWORA resource file on page 310. If the resource value is not set, PowerSnap backups fail. To enable catalog synchronization, perform the configuration procedures in Catalog synchronization for Oracle PowerSnap backups on page 309. Catalog synchronization must be configured before any PowerSnap backups of a database are performed. If catalog synchronization is enabled for instant backups, the NWORA resource file must contain a SID resource for each Oracle database to be backed up during instant backups. Use the NSR_ORACLE_SID parameter in NWORA resource file to specify the Oracle SID value. Set the NSR_ORACLE_SID parameter to the same value as the ORACLE_SID parameter in the NMDA configuration file. Oracle PowerSnap operations 291

Snapshot Backups and Restores Create RMAN scripts for Oracle PowerSnap backups The information on RMAN backup scripts in RMAN scripts for manual backups on page 103 also applies to RMAN scripts for Oracle PowerSnap backups. These added requirements apply to RMAN scripts for Oracle PowerSnap backups: The appropriate parameters must be set, as described in Set the parameters for Oracle PowerSnap operations on page 293. 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 PowerSnap 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 PowerSnap backup over more than one channel. Note: PowerSnap backup parallelism is defined by the PowerSnap parameter NSR_PS_SAVE_PARALLELISM. Table 22 on page 294 provides more information. The following sample RMAN script performs a PowerSnap backup of an entire Oracle database that resides on one or more primary storage devices: run { allocate channel t1 type SBT_TAPE ; send NSR_ENV=( NSR_PROXY_PFILE=/oracle/rman/proxy.cfg) ; backup full proxy only format FULL_%d_%U (database); release channel t1; } NSR_PROXY_PFILE is an optional NMDA parameter used for PowerSnap backups. Set the parameters for Oracle PowerSnap operations on page 293 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 PowerSnap backup or restore, unless specific backup options are used. Example 38 RMAN scripts with multiple channels The PowerSnap 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 PowerSnap backup: run { allocate channel c1 type SBT_TAPE ; allocate channel c2 type SBT_TAPE ; send channel c1 NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume1) ; send channel c2 NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume2) ; backup proxy only tablespace tbs1, tbs2, tbs3, tbs4; 292 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores } release channel c1; release channel c2; The following RMAN script uses specific backup options to enforce distribution of the PowerSnap backup over two channels: run { allocate channel c1 type SBT_TAPE ; allocate channel c2 type SBT_TAPE ; send channel c1 NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume1) ; send channel c2 NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume2) ; backup proxy (tablespace tbs1, tbs2 channel c1) (tablespace tbs3, tbs4 channel c2); release channel c1; release channel c2; } Use the following RMAN script to replace both of the preceding two backup scripts: run { allocate channel c1 type SBT_TAPE ; send channel c1 NSR_ENV=(NSR_DATA_VOLUME_POOL=OracleVolume1) ; backup proxy tablespace tbs1, tbs2, tbs3, tbs4; release channel c1; } 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 PowerSnap backups and all the others are used for regular backups. Set the parameters for Oracle PowerSnap operations Two types of parameters can be set for the Oracle PowerSnap backups and restores: NMDA parameters, as described in Appendix A, NMDA Parameters for Backups and Restores. The parameters must be set by using one of the methods in About NMDA parameters on page 346. PowerSnap Module parameters, as described in PowerSnap parameter settings on page 293. 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 379 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 370. Oracle PowerSnap operations 293

Snapshot Backups and Restores 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 PowerSnap 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 39 on page 295 and Example 40 on page 295 provide examples of PowerSnap parameter settings. Table 22 on page 294 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. Table 22 PowerSnap parameters Parameter Description Default and valid values NSR_DATA_MOVER NSR_PS_SAVE_PARALLELISM NSR_MAX_STREAMS RESTORE_TYPE_ORDER Mandatory for a PowerSnap backup that uses a proxy client host. Specifies the hostname of the proxy client host. Optional. Specifies the number of concurrent save streams on the proxy client host. Optional. Specifies the maximum number of restore streams. Optional. Specifies the type of PowerSnap restore to be performed. Note: If multiple values are specified, each type of restore is attempted (in the order specified) until a restore operation is successful. 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. 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 PowerSnap restore from secondary storage media. - rollback Specifies a rollback restore from a point-in-time copy. Oracle PowerSnap restore requirements on page 305 provides more information. 294 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Example 39 PowerSnap parameter settings To set the PowerSnap parameter RESTORE_TYPE_ORDER for a PowerSnap restore, a configuration file named /oracle/rman/proxy.cfg can be created, which consists of the following line: RESTORE_TYPE_ORDER=rollback:pit:conventional In this case, the NMDA 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 40 PowerSnap parameter settings for a Celerra NAS device To enable PowerSnap backup and restore operations with Celerra NAS devices, ensure that the following PowerSnap parameters are set in the user-defined configuration file that was specified with the NMDA 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. The PowerSnap Module documentation provides more details on these PowerSnap parameters. For example, the following PowerSnap parameters are included in the /nsr/apps/res/nas_backup.cfg file (specified with NSR_PROXY_PFILE) for a PowerSnap 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 Oracle PowerSnap operations 295

Snapshot Backups and Restores For example, the following PowerSnap parameters are included in the /nsr/res/nas_restore.cfg file (specified with NSR_PROXY_PFILE) for a PowerSnap 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 Configure the NetWorker Pool resources A separate pool must be configured to support PowerSnap 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 NMDA 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 Configure the NetWorker Group resource on page 296. The NetWorker PowerSnap Module documentation provides more information on configuring this extra pool. Configure the NetWorker Snapshot Policy resource A special NetWorker snapshot policy is required to perform PowerSnap 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. Configure the NetWorker Group resource For PowerSnap backups, configure a NetWorker Group resource by using the instructions in the NetWorker PowerSnap Module documentation. Ensure that the NetWorker Group resource to which the Oracle host belongs is configured with proper snapshot attribute settings. Table 23 on page 296 provides a sample. Table 23 Sample NetWorker Group resource attributes for a snapshot backup Attribute Snapshot Snapshot Policy Snapshot Pool Start Time Interval Setting True. Serverless live backup. Daily or other customized policies may be set later. A Pool resource dedicated to the storage of snapshot metadata is recommended. File-type volume devices are strongly recommended over tape. Must be set in relation to the Number of Snapshots attribute for the snapshot policy: (Interval x Number of Snapshots) must be less than or equal to (24:00 h - Start Time). Must be set in relation to the Number of Snapshots attribute for the snapshot policy. 296 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Configure the NetWorker Client resource Ensure that the basic NetWorker Client resource for the NMDA client is configured according to Customize a Client resource with NMC on page 89. The following Client resource requirements apply to the Oracle PowerSnap backups: 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 (snapshot) is governed by the snapshot policy specified in the Group resource to which the given client belongs. Customize the NetWorker Client resource for PowerSnap backups To customize the NetWorker Client resource for the PowerSnap backups of the NMDA client : 1. For the Save Set attribute, type the following: RMAN:/full_pathname_of_RMAN_backup_script 2. For the Group attribute, specify the name of the NetWorker Group resource created for the PowerSnap backups. Configure the NetWorker Group resource on page 296 provides more information. 3. For the Schedule attribute, select a NetWorker backup schedule. 4. For the Backup Command attribute, type the following: nsrdasv(.exe) -z configuration_filepath where configuration_filepath is the complete pathname of the NMDA configuration file that contains the NMDA parameter settings for the PowerSnap backup. On Windows only, if the configuration file pathname includes any spaces, do one of the following: Change the configuration file pathname so it does not include spaces. Use the Windows short pathname format. For example: nsrdasv(.exe) -z C:\Progra~1\Legato\nsr\apps\config\config.txt Use quotes and double backslashes in the pathname. For example: nsrdasv(.exe) -z C:\\Program Files\\Legato\\nsr\\apps\\config\\config.txt Appendix A, NMDA Parameters for Backups and Restores, provides details on the configuration file and NMDA parameters. 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. Oracle PowerSnap operations 297

Snapshot Backups and Restores For PowerSnap backups that use a proxy client host, the Remote Access attribute must include the proxy client hostname. Configure deduplication PowerSnap backups The following restrictions apply to deduplication PowerSnap backups: NMDA software supports deduplication PowerSnap backups of only the data that is rolled over to secondary storage, not of the data in instant (PIT) backups. NMDA software does not support deduplication PowerSnap backups of raw devices or volumes. If NSR_PS_SAVE_PARALLELISM is set to a value greater than 4, then the PowerSnap Module automatically reduces the parameter setting to 4 during the deduplication PowerSnap backup. To configure the deduplication PowerSnap backups: 1. Perform the required PowerSnap backup configurations according to Configuring Oracle PowerSnap backups on page 290. 2. Perform the required deduplication backup configurations according to Configure a scheduled deduplication backup on page 122, by using the NMC method for a client-side configuration (without the wizard). Note: The proxy client (data mover) host does not need to be enabled for deduplication. Do not set the De-duplication Backup and De-duplication Node attributes in the NetWorker Client resource of the proxy client host. The following sources provide details on any additional requirements and limitations of deduplication PowerSnap backups and restores: EMC NetWorker Module for Databases and Applications Release Notes EMC NetWorker PowerSnap Module documentation (Refer to the PowerSnap Module version for the primary storage system.) Test a scheduled PowerSnap backup! IMPORTANT An Oracle PowerSnap backup can be started only by automatic or manual invocation of the scheduled NetWorker backup group. A PowerSnap 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 156. Since PowerSnap manual (unscheduled) backups are not supported, you cannot test a RMAN script for a PowerSnap backup by using the information in Test RMAN scripts for scheduled backups on page 107. To determine if the script contains any errors, log the RMAN output into a file by setting the parameter NSR_RMAN_ARGUMENTS in the NMDA configuration file used for the backup. 298 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Oracle PowerSnap backup requirements Control file versus recovery catalog Review the following information, specific to Oracle PowerSnap backups: Control file versus recovery catalog on page 299 Checking configuration consistency on page 299 Performing Oracle PowerSnap backups on page 301 PowerSnap backups and restores on cluster systems on page 322 provides information on PowerSnap backups in a cluster environment. Note: For PowerSnap instant backups, use an RMAN recovery catalog instead of a control file. 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 provides more information. 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. Checking configuration consistency During a scheduled backup, NMDA checks for consistency between the NetWorker Group resource configuration and the RMAN backup session. If NMDA 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 PowerSnap backups on page 299 With a group configured for regular backups on page 300 With a group configured for PowerSnap backups If the Snapshot attribute in the NetWorker Group resource is set to True, the resource is configured for PowerSnap backups. However, this configuration does not guarantee that a PowerSnap 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. Oracle PowerSnap operations 299

Snapshot Backups and Restores If RMAN performs only regular Oracle backups due to one of these conditions, NMDA 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 (not PowerSnap) backups, correct the RMAN script or relocate the Oracle datafiles to a supported primary storage device, as required to enable PowerSnap backups. The current EMC compatibility guides provide details on the primary storage devices supported for PowerSnap backups. 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 documentation provides a detailed description of the difference between the proxy and proxy only options. Note: If the PowerSnap Module software involved in a PowerSnap snapshot backup cannot determine if a file is snapshotable, the PowerSnap 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 PowerSnap backup specified in the RMAN script will fail. If there are regular and PowerSnap backups in the same RMAN script, RMAN might complete one or more regular backups before a PowerSnap backup fails. Notes: If RMAN terminates any of the PowerSnap backups in an RMAN script, the savegroup completion report lists failure of the scheduled backup. If any PowerSnap backups in an RMAN script fail, RMAN still performs a regular backup of the corresponding archived redo logs. Example 41 Oracle PowerSnap backup failure 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 PowerSnap database backup fails: run { allocate channel ch1 type SBT_TAPE ; backup proxy database plus archivelog; } Despite the PowerSnap backup failure, RMAN performs a regular backup of the archived redo logs. The savegroup completion report lists failure of the scheduled backup. 300 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Performing Oracle PowerSnap backups An Oracle PowerSnap backup can be started only by automatic or manual invocation of the scheduled NetWorker backup group.! IMPORTANT A PowerSnap backup of Oracle data 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 PowerSnap 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 PowerSnap backups. Directory for temporary files NMDA creates temporary files for processing purposes in the following directory: On UNIX, the directory is /nsr/apps/tmp. On Microsoft Windows, the directory is NetWorker_install_path\apps\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. PowerSnap backup summary line in savegroup report The savegroup completion report for a PowerSnap 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. PowerSnap backup processes on page 288 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 299 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. Oracle PowerSnap operations 301

Snapshot Backups and Restores NWORA resource file backup If a PowerSnap backup completes successfully, NMDA automatically backs up the NWORA resource file, as described in NWORA resource file on page 310. 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 backup debug log file, located in either of the following: Directory specified by NSR_DIAGNOSTIC_DEST Default directory, /nsr/apps/logs (UNIX) or NetWorker_install_path\apps\logs (Windows) 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 304 provides information on how the backup is represented in the NetWorker indexes. The NWORA resource file backup can be restored by using the NetWorker recover command or nwrecover GUI program. The EMC NetWorker Administration Guide provides more information. 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 Oracle PowerSnap backups Oracle PowerSnap backups can be canceled by using the same methods as for regular backups. The following sections provide more details: Monitor a manual backup on page 153 Cancel a scheduled backup on page 157 Oracle PowerSnap backup information in NetWorker indexes The NetWorker server maintains information about each backup in its online indexes. Importance of backups on page 23 provides more information. The index entry for a PowerSnap backup is stored in the NetWorker client file index for the database server host, for example, 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 PowerSnap backup (as is the case for a regular scheduled backup). 302 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores 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 The EMC NetWorker Command Reference Guide and the UNIX man pages provide more information on these NetWorker commands. Entries in the client file index For a backup piece created through an Oracle PowerSnap 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 42 on page 303. The second entry is generated for the point-in-time metadata, such as /brcmeta.1/ in Example 42 on page 303. 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_NMDA10_MVOL3/tbspc4_data1.dbf in Example 42 on page 303. This entry is created for a live backup only. Example 42 Oracle PowerSnap backup entries in the client file index The nsrinfo command provides information on the PowerSnap 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_NMDA10_MVOL3/tbspc4_data1.dbf /JBOD13_NMDA10_MVOL3/tbspc4_data1.dbf, date=1178916453 Fri May 11 13:47:31 2007 Entries in the media database For a backup piece created through a PowerSnap 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. Oracle PowerSnap operations 303

Snapshot Backups and Restores 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 PowerSnap backup, such as /space1/home/oracle/bp1 in Example 43 on page 304. Example 43 Oracle PowerSnap backup entries in the media database The mminfo command provides information on the PowerSnap backup entries in the NetWorker media database: mminfo -v -c marmaris volume client date time size nmda.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 44 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 45 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 volume client date time size nmda.002 marmaris 05/10/07 13:18:39 4 KB ssid fl lvl name 3863367791 cb full /nsr/res/nwora.res The EMC NetWorker Command Reference Guide and the UNIX man pages provide more information on these NetWorker commands. 304 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Oracle PowerSnap restore requirements Chapter 4, Data Restore and Recovery, provides basic information on how to configure and perform data restore and recovery with NMDA. Review the following information specific to Oracle PowerSnap restores: Create RMAN scripts for Oracle PowerSnap restores on page 305 Performing Oracle PowerSnap restores on page 306 Relocating files during an Oracle PowerSnap restore on page 307 Restoring to a different host on page 308 Point-in-time recovery without a Recovery Catalog on page 308 PowerSnap backups and restores on cluster systems on page 322 provides information on PowerSnap restores in a cluster environment. Create RMAN scripts for Oracle PowerSnap restores The same RMAN script used for a regular Oracle restore can also be used for an Oracle PowerSnap restore. Note: The RMAN restore command does not include a proxy option. To create an RMAN script for a PowerSnap restore, follow the instructions in Chapter 4, Data Restore and Recovery. To perform a PowerSnap restore, the appropriate parameters must be set, as described in Set the parameters for Oracle PowerSnap operations on page 293. The RESTORE_TYPE_ORDER parameter The RESTORE_TYPE_ORDER parameter setting determines the type of PowerSnap restore that is performed: 1. RMAN determines which backup needs to be restored and passes the required backup piece name to NMDA. 2. The RESTORE_TYPE_ORDER parameter specifies whether the backup piece is to be restored by using one of the following: Point-in-time copy Copy stored on secondary storage Example 46 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 Oracle PowerSnap restores on page 306 provides more information on setting up a rollback operation.! IMPORTANT For the RESTORE_TYPE_ORDER parameter, NMDA 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. Oracle PowerSnap operations 305

Snapshot Backups and Restores The NSR_CLIENT parameter To restore the data to a different host, the parameter NSR_CLIENT must be set to the required hostname. Restoring to a different host on page 308 provides more information. Performing Oracle PowerSnap restores The following requirements apply to Oracle PowerSnap 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. An Oracle PowerSnap 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 306. For user-specified relocation of files during a PowerSnap restore, the relocation path must be specified as described in Relocating files during an Oracle PowerSnap restore on page 307. 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 PowerSnap 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 22 on page 294 provides more information. Directory created for file system data restore During a PowerSnap 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 PowerSnap 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, NMDA 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. 306 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores 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 NMDA 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 NMDA 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 /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. Relocating files during an Oracle PowerSnap restore This section describes the user-specified relocation of a Oracle PowerSnap restore with NMDA.! 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 an Oracle PowerSnap restore, NMDA 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. To relocate a regular file or raw volume during an Oracle PowerSnap 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. Oracle PowerSnap operations 307

Snapshot Backups and Restores Example 47 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 48 Relocation of a raw volume 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 PowerSnap 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. Restoring to a different host To restore a PowerSnap backup to a different host, both the NMDA and required PowerSnap Module software must be installed and configured on the system where the data is to be restored. Point-in-time recovery without a Recovery Catalog Note: If a point-in-time recovery is performed with an RMAN Recovery Catalog, the information in this section does not apply. During an Oracle PowerSnap backup, Oracle backs up the control file after the PowerSnap 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 PowerSnap database backup session will include information on the new database structure. 308 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Catalog synchronization for Oracle PowerSnap backups During Oracle backups, RMAN stores information about each backup piece in the RMAN repository, also known as the "RMAN catalog". Similarly, NMDA 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 NMDA 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. Extra entries in the catalogs 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 problems, as described in Problems with extra entries in the RMAN catalog on page 310. 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. Removing instant backup entries from the NetWorker indexes Instant backup entries in the NetWorker indexes are removed in one of the following ways: 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 performed with the nsrdasv -c client_name option. The following sections provide more information on using this command: - PowerSnap backups from a virtual cluster client on page 323 - PowerSnap backups from a physical cluster client on page 324 When the expiration policy for an instant backup expires, the NetWorker process nsrim prunes the 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. Oracle PowerSnap operations 309

Snapshot Backups and Restores 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. Automatic catalog synchronization for PowerSnap backups The NMDA software provides automatic catalog synchronization that resolves the issues described in Extra entries in the catalogs on page 309. When you enable catalog synchronization in NMDA, the PowerSnap backup entries in the RMAN catalog and NetWorker indexes are synchronized automatically.! IMPORTANT To enable automatic catalog synchronization for PowerSnap backups: - The parameter ORACLE_SID must be properly set in the NMDA configuration file at the time of the PowerSnap backup. Setting the NMDA parameters for Oracle operations on page 368 provides details. - An NWORA resource file must include the required resources, as described in NWORA resource file on page 310. The NMDA program nsroraclecat uses the NWORA resources in the file to perform automatic synchronization of the RMAN catalog and NetWorker indexes. Note: DBAs can also synchronize the catalogs manually by using RMAN commands. The following sections provide details on how to configure and perform the catalog synchronization: NWORA resource file on page 310 Automatic catalog synchronization with the nsroraclecat program on page 318 NWORA resource file PowerSnap backups require the NWORA resource file to exist in the following location: On UNIX: /nsr/apps/res/nwora.res On Microsoft Windows: NetWorker_install_path\apps\res\nwora.res, where NetWorker_install_path is the root directory of the NetWorker installation path The NWORA resource file is created by the nsroraadmin 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 nsroraadmin 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 nsroraadmin program only. The nsroraadmin program must be run by either the root user on UNIX or a member of the Microsoft Windows Administrators group. 310 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on the nsroraadmin 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 311 NWORA SID resources on page 313 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: NSR_NWPATH on page 311 NSR_ORACLECAT_DEBUG_FILE on page 311 NSR_ORACLECAT_LOG_FILE on page 311 NSR_ORACLECAT_MODE on page 312 NSR_REMOVE_ON_FAILURE on page 312 Note: The parameter resources listed in Table 24 on page 311 are the only ones supported. Do not attempt to add other parameter resources to the NWORA resource file. Table 24 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 NMDA with Sun-branded NetWorker, you must set NSR_NWPATH by using the following nsroraadmin command: nsroraadmin -r update NSR_NWPATH=/usr/sbin/nsr Directory pathname for the location of nsrsnapck (default). Valid directory pathname for the location of the NetWorker binary nsrsnapck. 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. Undefined (default). Valid pathname of the nsroraclecat debug file. Note: If undefined, debug information is not generated. 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. Undefined (default). Valid pathname of the nsroraclecat log file. Note: If undefined, logging information is written to the /nsr/applogs/nsroraclecat.log file by default. Oracle PowerSnap operations 311

Snapshot Backups and Restores Table 24 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 PowerSnap backups. Undetermined (default). Enabled. Disabled. Note: Instant backups require the resource value to be set to either "enabled" or "disabled". If the value is not set, instant backups fail. NSR_ORACLE_NLS_LANG Required to enable 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 78 provides more information. 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, catalog synchronization fails. 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 318 provides more information. FALSE (default). TRUE. Using the nsroraadmin command to set parameter resources When the nsroraadmin command (with any options) is used for the first time after the NMDA installation, the NWORA resource file is automatically populated with five parameter resources from Table 24 on page 311: NSR_NWPATH, NSR_ORACLECAT_DEBUG_FILE, NSR_ORACLECAT_LOG_FILE, NSR_ORACLECAT_MODE, NSR_REMOVE_ON_FAILURE. Depending on the nsroraadmin 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 nsroraadmin -r list command. To modify NWORA parameter resource settings, use the nsroraadmin -r update command. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on how to use the nsroraadmin command. 312 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Example 49 Default NWORA parameter resources After the NMDA installation, if the first nsroraadmin command used is nsroraadmin -r list (to list the NWORA resource file contents), the command adds the following snapshot backup-related 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 nsroraadmin -r update command. This default NWORA resource file does not yet contain any NWORA SID resources, as described in NWORA SID resources on page 313. NWORA SID resources 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 25 on page 313. 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 page 318 provides more information. Note: Each NWORA SID resource must have a unique NSR_ORACLE_SID value. Table 25 NWORA SID resource components (page 1 of 2) Parameter Description Default and valid values NSR_ORACLE_CONNECT_FILE NSR_ORACLE_HOME Mandatory. Specifies the location of the file containing the connection strings required to create an RMAN session. The connection file on page 315 provides more information. Mandatory. Specifies the home directory of the Oracle installation. The RMAN executable must be located in subdirectory bin of this directory. Undefined (default). Valid pathname of the RMAN connection file. Undefined (default). Valid pathname of the Oracle home directory. Note: The value must be equal to the Oracle parameter $ORACLE_HOME value. Oracle PowerSnap operations 313

Snapshot Backups and Restores Table 25 NWORA SID resource components (page 2 of 2) Parameter Description Default and valid values NSR_ORACLE_LIB_PATH Optional. Specifies the pathname of the directory containing the Oracle shared libraries on UNIX, typically $ORACLE_HOME/lib. Undefined (default). Valid pathname of the Oracle shared library directory on UNIX. Note: This parameter is not required on Windows. NSR_ORACLE_SID Mandatory. Specifies the SID value of the Oracle database whose RMAN catalog is to be synchronized. Undefined (default). Valid SID value of the Oracle database. Note: The value must be equal to the ORACLE_SID value in the NMDA configuration file used for the database backup. Setting the NMDA parameters for Oracle operations on page 368 provides more information. NSR_ORACLE_TNS_ADMIN Optional. Specifies the pathname of the directory containing the Oracle Net configuration files. Undefined (default). Valid pathname of Oracle network configuration directory. Note: The value must be equal to the Oracle parameter $TNS_ADMIN value. Using the nsroraadmin command to set SID resources To add an NWORA SID resource to the resource file, use the nsroraadmin -r add command. To modify NWORA SID resource settings, use the nsroraadmin -r update command. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details on how to use the nsroraadmin command. Example 50 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 nsroraadmin -r add command. The SID resource must include the following: NSR_ORACLE_SID set to proddb. 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 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. 314 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores The connection file 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 313 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 51 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 nsroraadmin program All resources in the NWORA resource file must be added, modified, or deleted by using the nsroraadmin program only. To run the program, type the nsroraadmin command at the operating system command line, as the root user on UNIX or as a member of the Microsoft Windows Administrators group. The nsroraadmin command syntax and options related to PowerSnap backups on page 316 provides details on the command syntax and options. Windows Server 2008 and Windows Vista requirements for the nsroraadmin command On Windows Server 2008 and Windows Vista, you must run the nsroraadmin 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 nsroraadmin command in the open Command Prompt window. Oracle PowerSnap operations 315

Snapshot Backups and Restores The nsroraadmin command syntax and options related to PowerSnap backups The nsroraadmin command syntax and options used to configure PowerSnap backup settings are as follows: nsroraadmin [-D debug_level] -r list [ResourceName SidName] nsroraadmin [-D debug_level] -r add ResourceName ResourceValue nsroraadmin [-D debug_level] -r add sid=sidname home=oraclehome connect=connectfilepath [lib=librarypath] [tns=tnspath] nsroraadmin [-D debug_level] -r update ResourceName ResourceValue nsroraadmin [-D debug_level] -r update sid=sidname [home=oraclehome] [connect=connectfilepath] [lib=librarypath] [tns=tnspath] nsroraadmin [-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 NWORA SID resource. TNSPath is the value of the NSR_ORACLE_TNS_ADMIN parameter of the NWORA SID resource. Only the -D and -r options are supported: The -D option causes the nsroraadmin 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. The following sections provide examples of how to use the nsroraadmin command to list, add, update, and delete NWORA resources: List the NWORA resources on page 317 Add the NWORA resources on page 317 Update the NWORA resources on page 317 Delete the NWORA SID resources on page 318 The following sources provide more information on the nsroraadmin command: nsroraadmin man page on a UNIX Oracle Server that contains the NMDA software. nsroraadmin entry in the EMC NetWorker Module for Databases and Applications Command Reference Guide on the Powerlink website. 316 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores List the NWORA resources To display the entire NWORA resource file contents, type the following: nsroraadmin -r list To display the NSR_ORACLECAT_MODE parameter resource only, type the following: nsroraadmin -r list NSR_ORACLECAT_MODE To display an NWORA SID resource with the NSR_ORACLE_SID value of proddb, type the following: nsroraadmin -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: nsroraadmin -r add NSR_ORACLECAT_MODE enabled nsroraadmin -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 50 on page 314, type the following: nsroraadmin -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: nsroraadmin -r update NSR_ORACLECAT_MODE enabled nsroraadmin -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: nsroraadmin -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. Oracle PowerSnap operations 317

Snapshot Backups and Restores Delete the NWORA SID resources To delete an NWORA SID resource with the NSR_ORACLE_SID value of proddb, type the following: nsroraadmin -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 NMDA 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 378. 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 318 Failure of the nsroraclecat program on page 319 NetWorker index entry removals with nsrsnapck on page 320 Catalog synchronization after PowerSnap Oracle backup volume is relabeled manually on page 321 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. 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). 318 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores The nsroraclecat program names each RMAN script as follows: On UNIX: /nsr/apps/tmp/.nworapc/nsroracat_date_pid On Microsoft Windows: NetWorker_install_path\apps\tmp\.nworapc\nsroracat_date_pid where: NetWorker_install_path is the root directory of the NetWorker installation path. 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 311 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 NMDA software. The nsroraclecat entry in the EMC NetWorker Module for Databases and Applications 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 NetWorker indexes. The nsroraclecat program cannot locate the required backup pieces in the NetWorker indexes. 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 320. The following files (if they exist) need to be removed: Files in one of these directories: On UNIX: /nsr/apps/tmp/.nworapc On Microsoft Windows: NetWorker_install_path\apps\tmp\.nworapc, where NetWorker_install_path is the root directory of the NetWorker installation path Oracle PowerSnap operations 319

Snapshot Backups and Restores 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 information. 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. 320 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores 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 NetWorker_install_path is the root directory of the NetWorker installation path The EMC NetWorker Administration Guide provides more information on the daemon.raw log file and how to view its contents. Catalog synchronization after PowerSnap Oracle backup volume is relabeled manually If you relabel a NetWorker volume containing PowerSnap Oracle backups manually, the NMDA program nsroraclecat cannot remove the corresponding entries from the RMAN catalog during automatic catalog synchronization. In this case, you must perform the following procedures to reestablish automatic catalog synchronization for the volume. The procedures to perform depend on the setting of NSR_REMOVE_ON_FAILURE in the NWORA resource file. The EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide provides more details on this parameter resource. To reestablish catalog synchronization for the relabeled volume, use the instructions in the appropriate section, depending on the NSR_REMOVE_ON_FAILURE setting: If NSR_REMOVE_ON_FAILURE is set to TRUE on page 321 If NSR_REMOVE_ON_FAILURE is set to FALSE on page 321 If NSR_REMOVE_ON_FAILURE is set to TRUE If NSR_REMOVE_ON_FAILURE is set to TRUE in the NWORA resource file, synchronize the RMAN catalog entries manually by using the RMAN crosscheck command. This reestablishes the catalog synchronization for the relabeled volume. The appropriate Oracle documentation provides more information on the RMAN crosscheck command. If NSR_REMOVE_ON_FAILURE is set to FALSE If NSR_REMOVE_ON_FAILURE is set to FALSE in the NWORA resource file, you must first detect a catalog synchronization failure before you can reestablish the catalog synchronization. To detect a failure, monitor the backup system for one of the following events: A proxy backup fails due to the catalog synchronization failure and the snapshot resources not being released. One of the following messages appears in both the nsroraclecat log and debug files. (The log and debug files are specified by the NSR_ORACLECAT_LOG_FILE and NSR_ORACLECAT_DEBUG_FILE parameter resources, respectively.) Note: The first message appears when all the RMAN catalog entries fail to be synchronized. The second message appears when only some of the entries fail. Oracle PowerSnap operations 321

Snapshot Backups and Restores ALERT: The save times could not be automatically synchronized because they have already been removed from the NetWorker client file index (possibly through manually relabeling a volume). Please manually synchronize the catalogs using the RMAN crosscheck command. ALERT: Some of the backup pieces may have already been removed from the NetWorker client index (possibly by manually relabeling a volume). Please manually synchronize the catalogs using the RMAN crosscheck command. When you detect this type of failure, reestablish the catalog synchronization for the relabeled volume by performing the following: 1. In the NWORA resource file, set NSR_REMOVE_ON_FAILURE to TRUE by using the nsroraadmin command. 2. To induce catalog synchronization, type the nsrsnapck -y command. Note: This nsrsnapck command also releases any incomplete or invalid snapshots that it detects. 3. In the NWORA resource file, set NSR_REMOVE_ON_FAILURE to FALSE by using the nsroraadmin command. 4. Synchronize the RMAN catalog entries manually by using the RMAN crosscheck command. The appropriate Oracle documentation provides more information on the RMAN crosscheck command. PowerSnap backups and restores on cluster systems NMDA can perform PowerSnap backups and restores of a database configured on a cluster system. This section provides details on the support of cluster and failover for NMDA PowerSnap operations.! IMPORTANT The parameter NSR_CLIENT is not supported for PowerSnap backups on a cluster system. This parameter is used for restores and regular backups on a cluster system, as described in Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems. Review the following information, specific to PowerSnap operations on a cluster system: PowerSnap backup failover on page 322 PowerSnap backups from a virtual cluster client on page 323 PowerSnap backups from a physical cluster client on page 324 Restores from PowerSnap backups on a cluster system on page 325 PowerSnap backup failover During a PowerSnap scheduled backup where the database server software is configured to fail over (for example, by using Oracle Fail Safe with MSCS on Microsoft Windows), the NetWorker server retries the backup on the failover node if 322 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores 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 49 provides more information. PowerSnap backups from a virtual cluster client A PowerSnap backup from a virtual cluster client (virtual host) protects the data on shared cluster disks. To set up a PowerSnap backup from a virtual cluster client: 1. Install the NMDA 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 Configure the NetWorker Client resource on page 297: In the Backup Command attribute, always specify the -c client_name option in nsrdasv -z config_filepath -c client_name if the client is a virtual host. 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 PowerSnap backups, as described in Configuring Oracle PowerSnap backups on page 290: 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 EMC NetWorker Administration Guide. 4. Configure the NWORA resource file on each node of the cluster, as described in Configure the NWORA resource file on page 291. 5. If the PowerSnap backup entries are to be stored in a NetWorker client file index other than the virtual client index (for example, in a physical client index), specify the Oracle user from the virtual host in the Remote Access attribute of the Client resource for client_name. The expiration of instant backups created with the -c client_name option setting differs from the expiration of instant backups created without the setting. Removing instant backup entries from the NetWorker indexes on page 309 provides details on the expiration and removal of backups specified with the -c client_name setting. Notes: The host specified by client_name must have access to instant backups. NMDA and the PowerSnap Module must be installed and configured on the host specified by client_name. Oracle PowerSnap operations 323

Snapshot Backups and Restores 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 52 PowerSnap 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, specify nsrdasv -z config_filepath -c mars.emc.com in the Backup Command attribute of the NetWorker Client resource. PowerSnap backups from a physical cluster client A PowerSnap 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 PowerSnap backup from a physical cluster client: Oracle PowerSnap backup requirements on page 299 EMC 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 PowerSnap backup entries be stored in a NetWorker client file index other than the physical client index, for example, in a virtual client index: Specify nsrdasv -z config_filepath -c client_name in the Backup Command attribute in the Client resource for client_name. Note: When the client is a physical host, the backup is indexed under the hostname of the physical host by default. You need to specify the -c client_name option only when you want the index to be stored under an different hostname. 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 -c client_name option setting differs from the expiration of instant backups created without the setting. Removing instant backup entries from the NetWorker indexes on page 309 provides details on the expiration and removal of backups specified with the -c client_name setting. Notes: The host specified by client_name must have access to instant backups. NMDA and the PowerSnap Module must be installed and configured on the host specified by client_name. Example 53 PowerSnap 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, specify nsrdasv -z config_filepath -c monalisa.emc.com in the Backup Command attribute of the NetWorker Client resource. 324 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Restores from PowerSnap backups on a cluster system To set up a restore from a PowerSnap 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 About NMDA parameters on page 346: 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. Oracle PowerSnap operations 325

Snapshot Backups and Restores DB2 PowerSnap operations For PowerSnap snapshot operations with DB2 data, the IBM DB2 version 9.5 or later software provides a feature called Advanced Copy Services (ACS) that enables snapshots of DB2 data. NMDA software works with ACS, PowerSnap Module, and NetWorker software to back up snapshots of DB2 data. The following sections provide details on how to configure and perform DB2 PowerSnap operations. Configuring DB2 PowerSnap backups! IMPORTANT Snapshots are not produced if any data or log file related to the snapshot resides on a different device than the snapshotable device. NMDA supports only the full snapshot backup and restore of DB2 databases. NMDA does not support snapshot backup and restore of selected DB2 tablespaces, logs, and files. To configure PowerSnap snapshot backups of DB2 databases: 1. Ensure that both the NMDA software and required PowerSnap Module software are installed according to the instructions in the following: EMC NetWorker Module for Databases and Applications Installation Guide NetWorker PowerSnap Module documentation (Refer to the PowerSnap Module version for the primary storage system.) 2. Review Types of supported PowerSnap backups on page 286 to determine which type of snapshot backup to perform. 3. Ensure that the application host (DB2 server) and proxy client (data mover) host are properly configured as NetWorker Client resources. This includes the usual settings for the Backup Command and Save Set attributes, as shown in Customize a Client resource with NMC on page 89. For the application host, set the Application Information attribute for the appropriate primary storage system, as shown in the following examples: CLARiiON: NSR_PS_DEBUG_LEVEL=9 NSR_DATA_MOVER=bu-universe NSR_SNAP_TYPE=emcclar EMCCLAR_SNAP_SUBTYPE=CoW FRAME_IP=10.5.167.17:10.5.167.18 Symmetrix: NSR_PS_DEBUG_LEVEL=9 NSR_DATA_MOVER=bu-lobster NSR_SNAP_TYPE=symm_dmx The PowerSnap Module documentation for the primary storage system provides details on these parameters. 4. Ensure that the NetWorker Group resource to which the DB2 hosts belong is configured with proper snapshot attribute settings. Table 26 on page 327 provides a sample. 326 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Table 26 Sample NetWorker Group resource attributes for a snapshot backup Attribute Snapshot Snapshot Policy Snapshot Pool Start Time Interval Setting True. Serverless live backup. Daily or other customized policies may be set later. A Pool resource dedicated to the storage of snapshot metadata is recommended. File-type volume devices are strongly recommended over tape. Must be set in relation to the Number of Snapshots attribute for the snapshot policy: (Interval x Number of Snapshots) must be less than or equal to (24:00 h - Start Time). Must be set in relation to the Number of Snapshots attribute for the snapshot policy. 5. Ensure that any special parameters specific to the snapshot are set in the NMDA configuration file (for example, nmda_db2.cfg). Typically, no special parameters are required. If the nsrsnapck binary is not in the default installation location, set the NSR_NWPATH parameter. On Linux, the default installation location is /usr/sbin. Appendix A, NMDA Parameters for Backups and Restores, provides details on NMDA parameters in the configuration file. 6. To enable the synchronous removal ( pruning ) of snapshot entries from the DB2 history file when the entries expire and are removed from the NetWorker indexes, ensure that the following parameters are properly set in the DB2 resource file (/nsr/apps/res/nmdb2.res): DB2PATH NSR_DB2CAT_MODE DB2 resource file and parameters on page 327 provides details. 7. If you want to enable deduplication PowerSnap backups, follow the instructions in Deduplication PowerSnap backups on page 329. DB2 resource file and parameters The DB2 resource file (/nsr/apps/res/nmdb2.res) is a user-created file that is used only to enable the pruning function of DB2 snapshot backups. This resource file enables the synchronous removal of snapshot entries from the DB2 history file when they expire in the NetWorker indexes. This process, known as DB2 history pruning, is performed by the nsrdb2cat binary. DB2 resource file parameters on page 328 provides details on parameters that can be set in the DB2 resource file. Syntax rules for the DB2 resource file The DB2 resource file uses the same syntax rules as the NMDA configuration file. Syntax rules for the NMDA configuration file on page 348 provides details. DB2 PowerSnap operations 327

Snapshot Backups and Restores Example DB2 resource file To enable DB2 history pruning, the NSR_DB2CAT_MODE parameter must be enabled and DB2PATH must be set. A typical DB2 resource file without DB2 history pruning may appear as follows: # /nsr/apps/res/nmdb2.res # A sample configuration file used for catalog synchronization # # DB2PATH is set to the DB2 binary directory. Must for nsrdb2cat # binary. # Mandatory # Default: None # # NSR_DB2CAT_MODE specifies if catalog synchronization is 'enabled' # or 'disabled'. It is set to 'disabled' by default. # Optional # Default: disabled NSR_DB2CAT_MODE=disabled # # NSR_REMOVE_ON_FAILURE specifies if the NMDA index entries should be # removed if catalog synchronization fails. It is set to FALSE by # default. # Optional # Default:false #NSR_REMOVE_ON_FAILURE= # # NSR_DEBUG_LEVEL is the debug level file for nsrdb2cat # Optional # Default: 0 NSR_DEBUG_LEVEL=9 DB2 resource file parameters Table 27 on page 328 lists the NMDA parameters supported by the user-created DB2 resource file (for example, /nsr/apps/res/nmdb2.res). Table 27 DB2 resource file parameters (page 1 of 2) DB2 resource file parameter Definition Default and valid values DB2PATH NSR_DB2CAT_MODE NSR_DEBUG_LEVEL Mandatory only if NSR_DB2CAT_MODE is enabled. Specifies the location of the DB2 binary directory. Use for DB2 history pruning with snapshot backups only. Optional. Specifies whether to synchronously remove entries in the DB2 history catalog file when corresponding entries are removed from the NetWorker indexes. Use for snapshot backups created with DB2 Advanced Copy Service. Optional. Appendix A, NMDA Parameters for Backups and Restores, provides details. Undefined (default) Set to the location of the DB2 binary directory. Disabled (default) = Snapshot without catalog synchronization. Enabled = Snapshot with catalog synchronization (DB2 history pruning). 0 (default) = Debug messages are not generated. 1 to 9 = Debug messages are written to the debug log file (name has.log extension). The level of detail in the debug messages increases with the debug level. 328 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Table 27 DB2 resource file parameters (page 2 of 2) DB2 resource file parameter Definition Default and valid values NSR_REMOVE_ON_FAILURE Optional. Specifies whether expired NetWorker index entries should be removed if corresponding backup entries are not successfully removed from the DB2 history. FALSE (default) = Remove expired NetWorker index entries only if they are successfully removed from the DB2 history. TRUE = Remove all expired NetWorker index entries, even if they are not successfully removed from the DB2 history. Deduplication PowerSnap backups The following restrictions apply to deduplication PowerSnap backups: NMDA software supports deduplication PowerSnap backups of only the data that is rolled over to secondary storage, not of the data in instant (PIT) backups. NMDA software does not support deduplication PowerSnap backups of raw devices or volumes. If NSR_PS_SAVE_PARALLELISM is set to a value greater than 4, then the PowerSnap Module automatically reduces the parameter setting to 4 during the deduplication PowerSnap backup. To enable the deduplication PowerSnap backups: 1. Ensure that the required PowerSnap backup configurations are completed according to Configuring DB2 PowerSnap backups on page 326. 2. Ensure that the required deduplication backup configurations are completed according to Configure a scheduled deduplication backup on page 122. The configurations must be performed by using the NMC method for a client-side configuration (without the wizard). Note: The proxy client (data mover) host does not need to be enabled for deduplication. Do not set the De-duplication Backup and De-duplication Node attributes in the NetWorker Client resource of the proxy client host. The following sources provide details on any additional requirements and limitations of deduplication PowerSnap backups and restores: EMC NetWorker Module for Databases and Applications Release Notes EMC NetWorker PowerSnap Module documentation (Refer to the PowerSnap Module version for the primary storage system.) DB2 PowerSnap operations 329

Snapshot Backups and Restores Restoring a DB2 PowerSnap backup To restore a PowerSnap backup of a DB2 database, use the following procedure and referenced documentation: 1. Ensure that all the parameters required for the PowerSnap restore are set in the NMDA configuration file (for example, nmda_db2.cfg), as follows: Set NSR_SERVER to the hostname of the NetWorker server. Set RESTORE_TYPE_ORDER to specify the type of snapshot restore to perform. Set the parameter to one or more of the following values, with each value delimited from the others by a colon(:): pit Specifies an instant restore. conventional Specifies a snapshot restore from secondary storage media. rollback Specifies a rollback restore from a point-in-time snapshot copy. The default value of RESTORE_TYPE_ORDER is pit:conventional. Note: If you specify multiple values for RESTORE_TYPE_ORDER, each type of restore is attempted, in the order specified, until a restore operation is successful. Types of supported PowerSnap restores on page 287 describes the supported restore types. The PowerSnap Module documentation for the appropriate primary storage system provides details on parameters used to restore snapshots. The DB2 Data Recovery and High Availability Guide provides more details. 2. To restore a database, run the db2 restore command. For example, on Linux: db2 restore db SAMPLE use snapshot library /usr/lib/libnsrdb2.so options @pathname/nmda_db2.cfg logtarget include force where pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. DB2 documentation on the db2 restore command syntax provides more details. Managing and deleting DB2 PowerSnap backups DB2 includes a binary named db2acsutil that is used to: List the valid DB2 snapshot backups on the primary storage Delete DB2 snapshot backups and release the associated resources The IBM DB2 documentation provides details on the db2acsutil utility. Query DB2 snapshots Query of DB2 snapshots with the db2acsutil command produces a list of valid snapshots retained in the repository. Note: Monitoring of the status of snapshots made with NMDA is not supported. The following are example snapshot queries on AIX: db2acsutil load /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg query older than 10 days snapshot db SAMPLE 330 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores db2acsutil load /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg query snapshot instance db2inst1 db2acsutil load /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg query snapshot taken at 20081212121212 db2acsutil load /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg query snapshot dbpartitionnum 0 db2acsutil load /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg query older than 5 days ago instance db2inst1 where pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. Delete DB2 snapshots Deletion of DB2 snapshots created with NMDA supports only the taken at yyyymmddhhmmss option of the db2ascutil command. Snapshot entries are deleted from both the DB2 backup history and the NetWorker server indexes. Note: If the nsrsnapck binary, required for deletion operations, is not in the default installation location, set the NSR_NWPATH parameter in the NMDA configuration file. On Linux, the default installation location is /usr/sbin. Appendix A, NMDA Parameters for Backups and Restores, provides details on the NMDA configuration file. The following is an example snapshot deletion on AIX: db2acsutil LOAD /usr/lib/libnsrdb2.o options @pathname/nmda_db2.cfg delete snapshot older than 10 days db SAMPLE taken at 20091212121212 where pathname/nmda_db2.cfg is the full pathname of the NMDA configuration file. The DB2 documentation provides more details. DB2 PowerSnap operations 331

Snapshot Backups and Restores Replication Manager snapshot operations with Oracle ASM Oracle does not support PowerSnap backups of Oracle data that resides on Oracle Automatic Storage Management (ASM). You cannot use the NMDA and PowerSnap Module software to perform a PowerSnap snapshot backup of Oracle ASM data. When ASM is used as the Oracle data storage, if you attempt a PowerSnap backup of the Oracle ASM data by using the methods in PowerSnap snapshot operations on page 284, one of the following occurs: If you did not specify proxy only in the RMAN backup command, then the PowerSnap snapshot backup fails over to a regular RMAN backup. If you specified proxy only, then the PowerSnap snapshot backup fails. By using EMC Replication Manager, the NMDA software can perform snapshot or split-mirror-based backups of Oracle ASM data through disk replication technology. This section describes how to configure the required integration of NMDA with Replication Manager, and then use the integrated solution to perform snapshot backups and restores of Oracle ASM data. Note: Replication Manager cluster support for Oracle is primarily for Oracle RAC. Replication Manager supports RAC, with or without ASM, but converts the RAC database into a single instance database for the replica. While the solution described in this section also applies to Oracle RAC, the scripts must be adjusted accordingly. The Replication Manager documentation provides details on additional settings required for Oracle RAC. About NMDA integration with Replication Manager Replication Manager is an EMC software product that manages the creation and expiration of point-in-time replicas (clones or snapshots) of databases and file systems that reside on supported storage arrays. When NMDA is integrated with Replication Manager, the NMDA software can back up and restore the replicas created by Replication Manager. The data in the replicas can also be used for reporting, analysis, and other repurposing. During the snapshot backups of Oracle ASM data, the replicas of Oracle ASM volumes are created on the production (source) host, mounted to a separate mount host, and backed up from the mount host, to reduce the backup overhead on the production host. A snapshot backup of an Oracle database on ASM storage with Replication Manager involves the following processes: 1. Replication Manager creates and mounts the replica database from the Oracle production database host to the mount host. 2. Oracle RMAN connects to the replica database on the mount host, and backs up the data to NetWorker by using NMDA. Configuration of the snapshot backups of Oracle ASM data includes separate configuration procedures on the four main nodes involved in the backups: Replication Manager server Oracle production database host (contains Replication Manager Agent software) Oracle mount host (contains Replication Manager Agent software) NetWorker server 332 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Backup of Oracle database components The following describes the backup requirements of the individual database components: Datafiles The datafiles in the replica database on the mount host must be backed up through RMAN scripts. Although the datafiles are from the replica database, the backups can be used to restore and recover the original database. Control file When the replica database is mounted, the control file is a current control file, but is a different version from the production current control file. The current control file must be converted to the backup type (backup control file) to obtain a new timestamp for the backup control file. The RMAN and Split Mirror Disk Backups Metalink note (302615.1), which can be obtained from Oracle, provides more details. RMAN does not back up the backup control file on the mount host. Back up the control file through regular NMDA Oracle backup procedures on the production database host by using one of the following options: 1. Set up autobackup of the control file to the NetWorker backup devices, as described in Control file autobackup on page 43. 2. Run the backup current control file command. Parameter files The SPFILE must be backed up through regular NMDA Oracle backup procedures on the production database host. Note: If an SPFILE is not used, RMAN cannot back up the parameter file or PFILE. You must back up a PFILE on the original database host through a file system backup. Archived redo logs Replication Manager can replicate the archived redo log directory. The archived redo logs on the mount host can then be backed up through RMAN scripts. To back up additional archived redo logs generated after the replication, you can use regular NMDA Oracle backups on the original database host. If the archived redo logs do not reside on a supported storage array, then you must use regular NMDA Oracle backups on the production database host to back up the archived redo logs. Flash Recovery Area (FRA) All of the procedures used for the archived redo logs backups also apply to the FRA backups. Requirements for snapshot backups of Oracle ASM data Ensure that you meet the following requirements for snapshot backups of Oracle ASM data: An Oracle RMAN recovery catalog is used for the Oracle database. The use of the Oracle control file as an RMAN catalog is not supported for the snapshot backups. All of the Oracle and ASM configuration and setup requirements are met, as described in the EMC Replication Manager Product Guide and EMC Replication Manager Release Notes. For example, Replication Manager supports only the external redundancy level for Oracle ASM. Confirm that the particular platform is supported with Oracle ASM. Replication Manager snapshot operations with Oracle ASM 333

Snapshot Backups and Restores If you are using Oracle RAC, refer to the Replication Manager documentation for additional Oracle configurations for RAC in ASM environments. Configuring snapshot backups of Oracle ASM data To configure the snapshot backups of Oracle ASM data, perform the required configuration steps on the four different nodes involved in the snapshot backups: Configuration on the Replication Manager server on page 334 Configuration on the Oracle production database host (Replication Manager Agent) on page 338 Configuration on the Oracle mount host (Replication Manager Agent) on page 338 Configuration on the NetWorker server host on page 341 Configuration on the Replication Manager server The EMC Replication Manager Product Guide provides details on the configuration steps on the Replication Manager server. Perform the following configuration steps by using the Replication Manager console on the Replication Manager server: 1. Create an application set for the Oracle production database. Ensure that the application credentials are set properly for the application set. Figure 32 on page 335 shows a sample of the application credentials. 334 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Figure 32 Application Credentials window in the Replication Manager console 2. If required, add storage and create a storage pool. 3. Create a job for the application set that was created in step 1: a. In the Advanced Replication Settings window, specify the proper settings for backup and recovery purposes: To perform an online backup, select Online using hot backup mode. Note: Do not select Online without hot backup mode for backup and recovery purposes. The Use consistent split option is not required for the online hot backup mode, but selecting the option has no impact. To perform an offline backup, select Offline by shutting down the database. Replication Manager shuts down the database before creating a replica, and restarts the database after the replica is created. Ensure that the snapshot backup schedule corresponds to a time when the database can be placed offline. To back up archived redo logs from the replica through RMAN scripts, select Replicate archive log directory. Replication Manager snapshot operations with Oracle ASM 335

Snapshot Backups and Restores To back up the FRA from the replica through RMAN scripts, select Replicate Flash Recovery Area. If required, select the appropriate setting for Copy parameter file to RM Server. Figure 33 on page 336 shows a sample of the advanced replication settings. Figure 33 Advanced Replication Settings in the Replication Manager console b. Specify the following mount options: Select a physical host that is different from the mount host. Under Path options for data residing on file systems, select Original path. Select Recover the database, and specify the following under that option: Select Prepare only for Recovery type. Specify the proper ORACLE_HOME value and user credentials. Under ASM Options, specify the proper value for ORACLE_HOME. You can specify a different ORACLE_HOME for the ASM instance from the one used by the database instance. Replication Manager requires the same operating system user to access both the ASM instance and the database instance. Before you run the job, ensure the instructions are completed for Configuration on the Oracle mount host (Replication Manager Agent) on page 338. Under Other Mount Options, select Fail the replica if the mount fails. 336 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Note: Do not select Unmount the replica on job completion. The replica must remain mounted during the RMAN backup. After the RMAN backup, the replica is unmounted gracefully through the POSTCMD script described in Configuration on the Oracle mount host (Replication Manager Agent) on page 338. Figure 34 on page 337 shows a sample of the required mount options. Figure 34 Mount options in the Replication Manager console 4. In the Starting the Job window of the job wizard, select Manually, or using a third party scheduler. This setting is required to perform a manual or scheduled NetWorker backup. Figure 35 on page 338 shows the required setting in the job wizard. Replication Manager snapshot operations with Oracle ASM 337

Snapshot Backups and Restores Figure 35 Starting the Job window in the job wizard Configuration on the Oracle production database host (Replication Manager Agent) Perform the following configuration steps on the Oracle production database host: 1. Ensure that the Replication Manager Agent software is installed and configured, and the required Oracle configuration steps are completed according to the Oracle procedures in the EMC Replication Manager Product Guide. For example, verify that the tnsnames.ora file contains at least one entry with a dedicated connection to be used by Replication Manager. This dedicated connection should be used when defining an Oracle application set. 2. Install the NetWorker client and NMDA software according to the instructions in the EMC NetWorker Module for Databases and Applications Installation Guide. Configuration on the Oracle mount host (Replication Manager Agent) Perform the following configuration steps on the Oracle mount host: 1. Ensure that the Oracle software is installed properly: The same Oracle software version must be installed on both the production database host and mount host. You can install and use a different ORACLE_HOME for ASM from the one for the database instance host, if this is the setup used on the original database host. 2. If ASM is used, ensure that the Cluster Synch Services (CSS) daemon is running. 3. Ensure that the Replication Manager Agent software and all the other required software (for example, Solutions Enabler) is installed and configured according to the Replication Manager documentation. 4. (Optional) Set up the RMCLI initialization file to identify the following: Replication Manager server host and port Username and password for the connection 338 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores If the initialization file is not set up, the Replication Manager server host, port, and credentials must be provided in a PRECMD and POSTCMD scripts that are used by NMDA. The scripts are described in step 8 and step 9. 5. Install the NetWorker client and NMDA software according to the instructions in the EMC NetWorker Module for Databases and Applications Installation Guide. If you set up the mount host as a NetWorker storage node to avoid network data transfer, the NetWorker client does not need to be installed separately. 6. Configure the local Oracle Net listener and Net service names, to enable you to connect to the Recovery Catalog database and the replica database once the replica database is mounted. The following are samples of the network files used to configure the Net listener and service names. In this case, bu-star1 is the host where the RMAN catalog database is running, and bu-star2.lss.emc.com is the mount host: $ORACLE_HOME/network/admin/listener.ora: LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = bu-star2.lss.emc.com)(port = 1521))) ) $ORACLE_HOME/network/admin/tnsnames.ora: ORCL110REP = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = bu-star2)(port = 1521))) (CONNECT_DATA = (SERVICE_NAME = orcl110)) ) CATALOG = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = bu-star1)(port = 1521))) (CONNECT_DATA = (SERVICE_NAME = catalog)) ) 7. Copy the production database password file to the mount host, under $ORACLE_HOME/dbs. For example: scp bu-star1:/db/app/oracle/product/11.1.0/db/dbs/orapworcl110 bu-star2:/db/app/oracle/product/11.1.0/db/dbs/ 8. Create a PRECMD script, which is a preprocessing script with its full pathname specified by the PRECMD parameter in the NMDA configuration file. Appendix A, NMDA Parameters for Backups and Restores, provides details on NMDA parameters and the configuration file. The PRECMD script must do the following: Create and mount the database replica by starting the Replication Manager job described in Configuration on the Replication Manager server on page 334. Mount the ASM instance. Convert the control file from current mode to the backup mode, and mount the database, according to the instructions in the RMAN and Split Mirror Disk Backups Metalink note (302615.1). Register the replica instance explicitly to the listener by using alter system register, and catalog the archived redo logs generated during hot backup mode if online backups are used. Replication Manager snapshot operations with Oracle ASM 339

Snapshot Backups and Restores A sample PRECMD script is provided in Preprocessing script for Oracle ASM backups on page 342. 9. Create a POSTCMD script, which is a postprocessing script with its full pathname specified by the POSTCMD parameter in the NMDA configuration file. The POSTCMD script must unmount the database replica gracefully by using RMCLI. A sample POSTCMD script is provided in Postprocessing script for Oracle ASM backups on page 344. 10. Create an RMAN script to perform the required snapshot backup. In the script, set the NSR_CLIENT parameter to the hostname of the production database host. This NSR_CLIENT setting enables the production database host to access the backup entries generated by the backup on the mount host, for catalog maintenance operations and restore. The following sample RMAN script is used to run an NMDA Oracle manual backup after the "replica" database is mounted. This script backs up the full database to the NetWorker server, bu-rocky, including all the archived redo logs not backed for a day. The production database host is bu-star1. The script connects to an RMAN Recovery Catalog database named catalog. connect target sys/oracle@orcl110rep; connect catalog rman/rman@catalog; run { allocate channel ch1 type 'SBT_TAPE'; allocate channel ch2 type 'SBT_TAPE'; send device type 'SBT_TAPE' 'NSR_ENV=(NSR_SERVER=bu-rocky, NSR_CLIENT=bu-star1)'; backup full format 'RM_NMDA_DB_%d_%U' database plus archivelog not backed up since time 'sysdate - 1'; release channel ch1; release channel ch2; } 11. If you will perform scheduled backups, create the NMDA configuration file with required parameter settings, as described in Appendix A, NMDA Parameters for Backups and Restores. Ensure that you set the following parameters in the file: PRECMD=full_pathname_of_PRECMD_script POSTCMD=full_pathname_of_POSTCMD_script where: full_pathname_of_precmd_script is the complete pathname of the preprocessing script created in step 8. full_pathname_of_postcmd_script is the complete pathname of the postprocessing script created in step 9. 340 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores Configuration on the NetWorker server host The EMC NetWorker Administration Guide and NMC online help provide details on how to configure NetWorker resources. Perform the required configuration steps on the NetWorker server host: For manual snapshot backups, use NMC to create basic (dummy) Client resources for the production database host and mount host. Ensure that the Remote Access attribute in the Client resource of the production database host contains the following: Oracle_user@mount_host For scheduled backups, perform the following: 1. Configure the required NetWorker Group and Schedule resources. 2. Create a NetWorker Client resource of the mount host that contains the following attribute settings: Backup Command nsrdasv -z NMDA_configuration_filepath, where the NMDA configuration file includes the parameters set in step 11 of Configuration on the Oracle mount host (Replication Manager Agent) on page 338. Group Name of the NetWorker backup group configured in step 1. Save Set RMAN:full_path_of_RMAN_script, where the RMAN script is the script created in step 10 of Configuration on the Oracle mount host (Replication Manager Agent) on page 338. 3. Create another NetWorker Client resource for the production database host to back up the parameter file and control file. Ensure that the Remote Access attribute contains the following: Oracle_user@mount_host Performing backups and restores of Oracle ASM data To perform the snapshot backups and restores of Oracle ASM data, follow the instructions in the appropriate section: Manual snapshot backups of Oracle ASM data on page 341 Scheduled snapshot backups of Oracle ASM data on page 342 Incremental backups on the mount host on page 342 Restore and recovery of Oracle ASM backups on page 342 Manual snapshot backups of Oracle ASM data To perform a manual snapshot backup: 1. Log in to the mount host as an Oracle user. 2. Run the PRECMD script, described in step 8 of Configuration on the Oracle mount host (Replication Manager Agent) on page 338. 3. Run the following command to perform the backup: rman @RMAN_script_name 4. Run the POSTCMD script, described in step 9 of Configuration on the Oracle mount host (Replication Manager Agent) on page 338. Replication Manager snapshot operations with Oracle ASM 341

Snapshot Backups and Restores Scheduled snapshot backups of Oracle ASM data The NetWorker server automatically starts scheduled backups based on the specified backup schedule. Scheduled backup procedures on page 156 provides more information on scheduled backups. To manually start and test a scheduled backup group, you can use the NMC NetWorker Administration GUI, or the savegrp command with the appropriate options. The EMC NetWorker Administration Guide and NMC online help provide details on using the NMC GUI program. The EMC NetWorker Command Reference Guide provides details on the savegrp command. Incremental backups on the mount host You can perform regular RMAN incremental backups on the mount host. You can also use additional scripting to perform the new incremental backup with change tracking, available in Oracle 10g and known as Block Change Tracking (BCT). The EMC whitepaper titled Reducing Backup Window and Recovery Time with Oracle Database 11g RMAN and EMC TimeFinder/Clone provides details. Restore and recovery of Oracle ASM backups To restore and recover a snapshot backup of Oracle ASM data, you must perform an RMAN restore with NMDA, as described in Chapter 4, Data Restore and Recovery. Replication Manager is not involved in the restore and recovery of the Oracle ASM backups. Sample preprocessing and postprocessing scripts The following sections provide sample preprocessing and postprocessing scripts for the snapshot backups of Oracle ASM data on UNIX or Linux. Preprocessing script for Oracle ASM backups The following shows a sample script used to perform preprocessing tasks on UNIX or Linux, prior to a snapshot backup of Oracle ASM data. The main preprocessing script, precmd, calls each of the following scripts in turn: create_replica.sh mountasm.sql convertcf.sql catalog.sql You must specify the complete pathname of the main preprocessing script with the PRECMD parameter in the NMDA configuration file. $ more precmd #!/bin/ksh echo on # This script creates and mounts the replica database # by starting the job configured on the RM server. # If the replica cannot be mounted, the script fails. DATE=$(date +%Y%m%d) LOGFILE=/db/home/ora110/rman/rm_rman_backup_$DATE.log RM_HOME=/opt/emc/rm/gui ORACLE_SID=orcl110 echo "*** Starting the Oracle database replica for $ORACLE_SID ****" >> $LOGFILE 342 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Snapshot Backups and Restores RM_COMMAND_LINE="$RM_HOME/rmcli host=bu-caspian.lss.emc.com port=65432 login user=administrator password=password file=/db/home/ora110/rman/create_replica.sh >> $LOGFILE " eval ${RM_COMMAND_LINE} & Pid=$! wait $Pid rm_status=$? if [ $rm_status!= 0 ] ; then echo "The RM job returned status of "$rm_status echo $0 "exiting." exit 1 fi # Switch to the Oracle user su - ora110 # Mount the ASM instance export ORACLE_SID=+RM0001 eval "sqlplus /nolog < /db/home/ora110/rman/mountasm.sql >>$LOGFILE" & # Change the CONTROL FILE type to backup type and mount the "replica" database export ORACLE_SID=orcl110 eval "sqlplus /nolog < /db/home/ora110/rman/convertcf.sql >>$LOGFILE" & # Catalog the archived redo logs generated during hot backup mode eval "rman @/db/home/ora110/rman/catalog.sql >>$LOGFILE" & exit 0 $ more /db/home/ora110/rman/create_replica.sh if run-job name=orcl110_replica appset=orcl110_appset then exit 0 else exit 1 $ more /db/home/ora110/rman/mountasm.sql connect sys/oracle as sysdba; startup mount; exit $ more /db/home/ora110/rman/convertcf.sql connect erm/oracle as sysdba; startup mount; recover database using backup controlfile until cancel; CANCEL shutdown immediate; startup mount; alter system register; $ more /db/home/ora110/rman/catalog.sql connect target erm/oracle@orcl110rep; # catalog the archived redo log generated during hot backup mode catalog start with '/tmp/orcl110/arch/'; Replication Manager snapshot operations with Oracle ASM 343

Snapshot Backups and Restores Postprocessing script for Oracle ASM backups The following shows a sample script used to perform postprocessing tasks on UNIX or Linux, after a snapshot backup of Oracle ASM data has finished. The main postprocessing script, postcmd, calls the unmount_replica.sh script. You must specify the complete pathname of the main postprocessing script with the POSTCMD parameter in the NMDA configuration file. $ more postcmd #!/bin/ksh echo on # This script unmounts the replica database # If the replica cannot be unmounted, the script fails. DATE=$(date +%Y%m%d) LOGFILE=/db/home/ora110/rman/rm_rman_backup_$DATE.log RM_HOME=/opt/emc/rm/gui ORACLE_SID=orcl110 echo "*** Unmounting the Oracle database replica for $ORACLE_SID ****" >> $LOGFILE RM_COMMAND_LINE="$RM_HOME/rmcli host=bu-caspian.lss.emc.com port=65432 login user=administrator password=password file=/db/home/ora110/rman/unmount_replica.sh >> $LOGFILE " eval ${RM_COMMAND_LINE} & Pid=$! wait $Pid rm_status=$? if [ $rm_status!= 0 ] ; then echo "The RM job returned status of "$rm_status echo $0 "exiting." exit 1 fi exit 0 $ more /db/home/ora110/rman/unmount_replica.sh if unmount-replica position=last appset=orcl110_appset then exit 0 else exit 1 344 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

A NMDA Parameters for Backups and Restores This appendix includes the following major sections: About NMDA parameters... 346 NMDA configuration file... 347 Common NMDA parameters... 350 DB2-specific NMDA parameters... 355 Informix-specific NMDA parameters... 360 Lotus-specific NMDA parameters... 362 Oracle-specific NMDA parameters... 368 Sybase-specific NMDA parameters... 373 NMDA Parameters for Backups and Restores 345

NMDA Parameters for Backups and Restores About NMDA parameters This appendix describes the parameters that you can set for NetWorker Module for Databases and Applications (NMDA) backups and restores. Note: Unless noted otherwise, the parameters are supported for both regular backups and restores and PowerSnap snapshot backups and restores. The PowerSnap snapshot operations are supported for DB2 and Oracle only. Set the parameters for Oracle PowerSnap operations on page 293 provides details for the snapshot operations. If you perform client-side configuration by using the NMC method (without the configuration wizard), then you must set specific parameters for an NMDA scheduled or manual backup or an NMDA restore. The following chapters provide details on backup and restore configuration procedures: Chapter 2, Software Configuration Chapter 4, Data Restore and Recovery In a client-side configuration, you must typically set the NMDA backup or restore parameters in the NMDA configuration file. NMDA configuration file on page 347 provides details on the NMDA configuration file and the exceptions to setting the parameters in the file. Common NMDA parameters on page 350 describes the parameters that NMDA uses for backups and restores of all the supported databases and applications. The following sections describe the parameters that NMDA uses for backups and restores of specific databases and applications only: DB2-specific NMDA parameters on page 355 Informix-specific NMDA parameters on page 360 Lotus-specific NMDA parameters on page 362 Oracle-specific NMDA parameters on page 368 Sybase-specific NMDA parameters on page 373 346 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores NMDA configuration file As part of a client-side configuration for backup or restore operations, you must typically set the required NMDA parameters in the NMDA configuration file. The only exceptions to setting NMDA parameters in the configuration file are as follows: For Informix manual backups and restores, parameters must be set in the environment. For Oracle backups and restores, certain parameters must be set in the RMAN script, as described in Oracle-specific NMDA parameters on page 368. For Sybase restores, parameters must be set in the environment or as nsrsybrc command options. You can use the same configuration file for both backup and restore operations. If you configure a scheduled backup or Oracle restore with the configuration wizard (a server-side configuration, set up with the wizard), you must not set any parameters directly in the configuration file on the client host. Instead, you must specify all the configuration settings in the wizard only. Five templates for the NMDA configuration file are installed with the NMDA software: nmda_db2.cfg Template for DB2 parameters nmda_informix.cfg Template for Informix parameters nmda_lotus.cfg Template for Lotus parameters nmda_oracle.cfg Template for Oracle parameters nmda_sybase.cfg Template for Sybase parameters The configuration file templates are installed in the following directory: On UNIX: /nsr/apps/config On Windows: NetWorker_install_path\apps\config, where NetWorker_install_path is the root directory of the NetWorker installation path You should make a copy of the required configuration file templates (for example, in the original directory or an alternate location) because the original templates are removed when the NMDA software is uninstalled. To create the NMDA configuration file for backups and restores of a particular database or application, copy the appropriate template file to any location on the client host, and customize the parameter settings in the file. You must set the appropriate parameters properly in the NMDA configuration file. For example, to create the NMDA configuration file for DB2 backups and restores, copy the nmda_db2.cfg template file to any required directory, and customize the parameters in the file according to the information in these sections: Common NMDA parameters on page 350 DB2-specific NMDA parameters on page 355 NMDA configuration file 347

NMDA Parameters for Backups and Restores! IMPORTANT Ensure that the NMDA configuration file is stored in a secure location, and is accessible by privileged users only. If possible, make this file readable and writeable by the administrative user that performs the operation. For manual backups, the file must also be accessible to the application user. For Lotus data recovery, the NMDA configuration file must be located on the destination client where the database files are to be recovered. You can name the configuration file with any suitable name. You must specify the configuration file pathname with the -z option in the appropriate backup or restore command. Syntax rules for the NMDA configuration file The contents of the NMDA configuration file must conform to the following syntax rules: Each parameter setting must be in one of the following formats: NAME = value NAME = value1, value2, value3 where: NAME is the parameter name. value, value1, value2, value3 are values assigned to the parameter. Parameter names and values are case-sensitive, unless specified otherwise in this appendix. Parameter settings can optionally be grouped within braces as follows: keyword {...parameter_settings... } where keyword is one of the following case-insensitive keywords, to signify that the parameter settings apply to a particular type of database or application: DB2 INFORMIX LOTUS LOTUS_DAOS ORACLE SYBASE For example, the keyword DB2 starts a group of DB2-specific NMDA parameters in the configuration file. Note: The LOTUS_DAOS keyword is used only to set parameters for a Lotus DAOS backup. The LOTUS_DAOS{} section must appear after the LOTUS{} section in the same configuration file. Configure a Lotus DAOS backup on page 101 provides details on setting parameters in the LOTUS_DAOS{} section. A group of parameters enclosed by braces cannot be nested inside another group of parameters. Multiple values for a parameter must be separated by commas. 348 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores The values of a parameter can be specified over multiple lines if each line ends in a comma. For example: NAME = value1, value2, value3 If the line specifying a parameter does not end in a comma, the next line must contain a new parameter setting. White space is ignored. Text on a line after the # symbol (where # is not enclosed in quotes) is considered a comment, and is ignored. A comment may appear after a parameter setting on the same line. A space, comma, or # symbol in a parameter value must be surrounded by single quotes ( ), double quotes(" "), or backwards quotes ( ). NMDA configuration file 349

NMDA Parameters for Backups and Restores Common NMDA parameters Table 28 on page 350 lists the common NMDA parameters, which are parameters that NMDA uses for backups and restores of all the supported databases and applications. For each common NMDA parameter, the following table includes: A description of the parameter. The default value of the parameter. The valid values that you can assign to the parameter.! IMPORTANT For Oracle operations, you must set: - Certain parameters for Oracle scheduled backups in the configuration file only. - Other parameters for Oracle backups and restores in the RMAN script only. Oracle-specific NMDA parameters on page 368 provides details on exactly where to set all the parameters for Oracle operations. Table 28 Common NMDA parameters (page 1 of 5) Parameter Description Default and valid values NSR_AES_ENCRYPTION Specifies whether the NetWorker server encrypts the backup data through 256-bit AES encryption, which uses the key or pass phrase that is set in the Datazone pass phrase attribute of the NetWorker Server resource. Optional for a backup. 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 NMDA backup, the encrypted data cannot be recovered. The EMC NetWorker Administration Guide provides more information on pass phrases. Note: Record each key (pass phrase) used for 256-bit AES encryption. The key is required to restore the backup later. FALSE (default) = Data is not encrypted through 256-bit AES encryption during the backup. TRUE = Data is encrypted through 256-bit AES encryption during the backup. NSR_CHECKSUM NSR_CLIENT NSR_COMPRESSION Specifies whether the NetWorker software performs checksumming on the backup data. Optional for a backup. Specifies the NetWorker Client resource to use for a backup or restore. Recommended for a backup or restore in a cluster, DB2 DPF, Oracle RAC, or Sybase ASE Cluster Edition system, and for a redirected restore (to a different host). Chapter 6, Cluster, DB2 DPF, Oracle RAC, and Sybase ASE Cluster Edition Systems provides more information. Specifies whether the NetWorker software performs compression on the backup data. Optional for a backup. FALSE (default) = NetWorker software does not perform checksumming. TRUE = NetWorker software performs checksumming. Hostname of the physical host on which the session runs (default). Valid NetWorker client hostname. FALSE (default) = The NetWorker software performs no compression. TRUE = The NetWorker software performs compression. 350 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 28 Common NMDA parameters (page 2 of 5) Parameter Description Default and valid values NSR_DATA_VOLUME_POOL Specifies the name of the NetWorker volume pool to use for the backup. For PowerSnap snapshot backups (DB2 and Oracle only), specifies the volume pool for live backups only (backups to secondary storage only). Optional for a DB2, Informix, Lotus, or Sybase manual backup. Mandatory for an Oracle manual backup that uses the set duplex command (with duplex set to 1, 2, 3, or 4) or other RMAN commands to generate backup copies. For an Oracle manual backup that generates backup copies, set this parameter with the parms option in the RMAN script (not with the send command or option). Note: For a scheduled backup, this parameter overrides any pool associated with the scheduled backup group. Most appropriate pool, selected by the NetWorker server (default). Valid name of a NetWorker volume pool. For a manual Oracle backup, 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. NSR_DEBUG_LEVEL NSR_DEDUP_BACKUP Specifies the level of debug messages that NMDA writes to the debug log file, located in the directory specified by NSR_DIAGNOSTIC_DEST or in the default directory, /nsr/apps/logs (UNIX) or NetWorker_install_path\apps\logs (Windows). Note: Use this parameter for debugging purposes with assistance from EMC Customer Support only. Optional for a backup or restore. For an Oracle operation, set this parameter either in the configuration file or with the parms option in the RMAN script (not with the send command or option). Specifies whether deduplication is performed during a manual NMDA backup. Mandatory for a manual deduplication backup. Do not set this parameter for a scheduled deduplication backup. Note: For a scheduled deduplication backup, set the De-duplication Backup attribute in the NetWorker Client resource, instead of setting this parameter. 0 (default) = Debug messages are not generated. 1 to 9 = Debug messages are written to the debug log file (name has.log extension). The level of detail in the generated debug messages increases with the debug level. FALSE (default) = Deduplication is not performed during an NMDA backup. Other NSR_DEDUP* parameters are ignored. TRUE = Deduplication is performed during an NMDA backup. If NSR_DEDUP_NODE is not set, the backup fails. NSR_DEDUP_CACHE_ENABLED Specifies whether a hash cache is used during a deduplication backup. Optional for a deduplication backup. The nsravtar process creates the cache in the /nsr/dedup/cache directory (or the equivalent directory on Windows). Use of the cache increases both the deduplication backup performance and disk usage in the cache directory. Note: Setting this parameter requires knowledge of the potential effects on Avamar server operations. 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. Common NMDA parameters 351

NMDA Parameters for Backups and Restores Table 28 Common NMDA parameters (page 3 of 5) Parameter Description Default and valid values NSR_DEDUP_CACHE_TAG Specifies the tag to be used to generate the hash cache name for a deduplication backup. Mandatory for Informix parallel deduplication backups when caching is enabled. Mandatory for an Oracle deduplication backup configured without the wizard. Optional for a DB2, Lotus, or Sybase deduplication backup. For an Oracle deduplication backup: If multiple channels are used on Windows, set this parameter with the send command (no the parms option) in the RMAN script. If automatic channel allocation is used (and multiple channels are not used on Windows), set this parameter with the parms option (no the send command) in the RMAN script. Set this parameter to a different value for each channel; if the same tag value is used for more than one channel, the deduplication backup fails. Application-specific default value: - For DB2 (non-powersnap backup): <DB2_node_name>_<backup_session_number>, where the backup session number is supplied by the DB2 server. - For DB2 (PowerSnap backup): / (forward slash). - For Informix: <XBSA objectname.pathname>, supplied by the IDS server. - For Lotus: Same value as the save set name. - For Oracle: / (forward slash); all RMAN channels (concurrent backup processes will have the same cache tag, which will cause the backup to fail). - For Sybase: <database>_<stripe_number> if a database is provided for backup; otherwise, <instance>_<stripe_number>. Default value is the recommended value for all application backups except Informix parallel backups and Oracle backups. String value of the tag that will generate a deduplication cache name. Do not include the client name in the value. Set the parameter to a different value for each concurrent NMDA process. Recommended value for an Oracle backup is: <ORACLE_SID or Net_service_name>_<channel_ID> For example: ORCL102_t1 Note: The software uses the tag value to generate the cache name through hashing. The actual cache name does not contain this parameter value. NSR_DEDUP_CHUNK_SIZE 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 deduplication backup. Optional for a deduplication backup. Note: Setting this parameter requires knowledge of the potential effects on Avamar server operations. 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. NSR_DEDUP_NODE Specifies the hostname of the Avamar server that will store the deduplicated client data. The hostname must be the same as the Avamar server hostname set in the NetWorker De-duplication Node resource. Mandatory for a manual deduplication backup. Do not set this parameter for a scheduled deduplication backup. Note: For a scheduled deduplication backup, set the De-duplication Node attribute in the NetWorker Client resource, instead of setting this parameter. Undefined (default). Avamar server hostname set in the NetWorker De-duplication Node resource. NSR_DIAGNOSTIC_DEST Specifies the directory location of all the NMDA log files, including the debug, operational, and error logs. Optional for a backup or restore. For an Oracle operation, set this parameter either in the configuration file or with the parms option in the RMAN script (not with the send command or option). Undefined (default). By default, NMDA log files are generated in the directory /nsr/apps/logs or NetWorker_install_path\apps\logs. Valid directory pathname for the location where all the NMDA log files are generated. 352 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 28 Common NMDA parameters (page 4 of 5) Parameter Description Default and valid values NSR_DPRINTF NSR_ENCRYPTION_PHRASES NSR_NO_BUSY_ERRORS Specifies whether NetWorker core debug messages are written to the NMDA debug log files, as described for NSR_DEBUG_LEVEL on page 351. Optional for a backup or restore. Use for debugging purposes with assistance from EMC Customer Support only. For an Oracle operation, set this parameter either in the configuration file or with the parms option in the RMAN script (not with the send command or option). Specifies one or more encryption phrases for decrypting data during an NMDA restore. If this parameter is not set, the NMDA restore obtains the encryption phrase from the NetWorker server. Optional for a restore. If both of the following are true, set this parameter to the phrase used to originally back up the data: The data that is being restored was backed up with 256-bit AES encryption. The encryption phrase on the NetWorker server has changed since the data was backed up. For an Oracle restore, set this parameter with the send command in the RMAN script. Specifies whether a backup or restore fails immediately when the NetWorker server is busy or waits for the NetWorker server to accept the connection. Optional for a backup or restore. Note: This parameter has no effect for PowerSnap snapshot backups or restores. FALSE (default) = NetWorker core debug messages are not written to the NMDA debug log files. TRUE = NetWorker core debug messages are written to the NMDA debug log files. Undefined (default). By default, an NMDA restore obtains the encryption phrase from the Datazone pass phrase attribute of the NetWorker Server resource, as described in Datazone pass phrase on page 72. One or more encryption phrases to use during an NMDA restore. Each phrase must be a string enclosed in quotes. Multiple phrases must be separated by commas. For Oracle restores only, the entire group of phrases must be surrounded by outer quotes that are different from the inner quotes. For example, the parameter is set for an Oracle restore: NSR_ENCRYPTION_PHRASES=" key1, key2 " - NMDA itself supports double ("), single ( ), and backward ( ) quotes. - Certain shells, databases, or applications might not support certain types of quotes. FALSE (default) = The backup or restore waits for the NetWorker server to accept the connection. TRUE = The backup or restore fails immediately when the NetWorker server is busy. NSR_NWPATH Specifies the pathname of the directory that contains the NetWorker binaries. Recommended for a PowerSnap snapshot or deduplication backup or restore if any of the following is true: NetWorker PowerSnap software (nsrsnapck binary) is installed in a nondefault location. NetWorker client software is installed in a nondefault location. Sun-branded NetWorker software is used. Note: NSR_NWPATH is not supported for deduplication PowerSnap backups or restores. Platform-specific default location of the NetWorker client binaries (default). If NetWorker PowerSnap software (nsrsnapck binary) is installed in a nondefault location, valid directory pathname of the PowerSnap binary. If NetWorker client software (nsravtar binary) is installed in a nondefault location, valid directory pathname of the nsravtar binary. If Sun-branded NetWorker software is used, /usr/sbin/nsr. NSR_SAVESET_BROWSE Specifies the browse policy of a backup, as the date when the entry for the backup is to be removed from the NetWorker client index. Optional for a manual backup. Note: This parameter overrides the browse policy specified in the NetWorker Client resource. Browse policy specified in the NetWorker Client resource for the client (default). Valid date in nsr_getdate(3) format. Common NMDA parameters 353

NMDA Parameters for Backups and Restores Table 28 Common NMDA parameters (page 5 of 5) Parameter Description Default and valid values NSR_SAVESET_RETENTION Specifies the retention policy of a backup, as the date when the save set becomes recyclable. Optional for a manual backup. Note: This parameter overrides the retention policy specified in the NetWorker Client resource. Retention policy specified in the NetWorker Client resource for the client (default). Valid date in nsr_getdate(3) format. NSR_SERVER POSTCMD Specifies the hostname of the NetWorker server to perform the backup or restore. Recommended for a manual backup or restore if the NetWorker server host is different from the client host. For an Oracle operation: If backup copies will be generated, set this parameter with the parms option in the RMAN script (not with the send command or option). If backup copies will not be generated, set this parameter with the send command or option in the RMAN script. Specifies a postprocessing script to be run after a scheduled backup. The postprocessing script file must have permissions that allow execution by the root user, as a scheduled backup is launched by root. The script should return a zero value when it succeeds, and a nonzero value when it fails. Optional for a scheduled backup. Do not set this parameter for a manual backup. Note: If the scheduled backup fails, the postprocessing script is still run. If the postprocessing script fails, an error message is generated. Hostname of the NetWorker server detected on the client host (default). Valid hostname of a NetWorker server. Undefined (default). Valid complete pathname of a postprocessing script file. The pathname 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 value is undefined or invalid, a postprocessing script is not run after the scheduled backup. PRECMD Specifies a preprocessing script to be run before a scheduled backup. The preprocessing script file must have permissions that allow execution by the root user, as a scheduled backup is 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 causes the scheduled backup to fail. Optional for a scheduled backup. Do not set this parameter for a manual backup. Note: If the preprocessing script fails, the scheduled backup fails, an error message is generated, and any postprocessing script is not run. Undefined (default). Valid complete pathname of a preprocessing script file. The pathname 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 value is undefined or invalid, a preprocessing script is not run before the scheduled backup. 354 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores DB2-specific NMDA parameters Common NMDA parameters on page 350 describes the common NMDA parameters, which are NMDA parameters used for backups and restores of all the supported databases and applications. The following sections describe DB2-specific information and the parameters that NMDA uses for specific purposes during DB2 backups and restores only. The parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347. Settings not to use for DB2 operations! IMPORTANT The DB2_VENDOR_INI registry variable must not be set. Also, if the $INSTHOME/sqllib/cfg/vendor.cfg file exists, do not use it for DB2 backup settings. Otherwise, conflicts can cause DB2 backups to fail. The DB2_VENDOR_INI registry variable was used with NetWorker Module for DB2 release 1.6 and earlier to set environment variables for DB2 operations. It is no longer used for DB2 operations, and should not be sset. If the $INSTHOME/sqllib/cfg/vendor.cfg file exists and contains settings of parameters listed in this appendix (such as NSR_DATA_VOLUME_POOL), remove the file. Otherwise, delete all parameter settings from the file. To implement these removals, recycle the DB2 database instance with the appropriate stop and start commands. For example: $ db2stop $ db2set DB2_VENDOR_INI= (Edit the $INSTHOME/sqllib/cfg/vendor.cfg file, removing any parameter settings) $ db2start DB2-specific NMDA parameter definitions Table 29 on page 356 lists the DB2-specific NMDA parameters, which NMDA uses for specific purposes during DB2 backups and restores only. The parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347.! IMPORTANT The parameters used for DB2 transaction log backups or restores should be in a special configuration file, for example, nmda_db2_tlogs.cfg, which is specified in the LOGARCHOPT1 setting. Configure DB2 transaction log backups for rollforward recovery on page 93 provides details. DB2-specific NMDA parameters 355

NMDA Parameters for Backups and Restores Table 29 DB2-specific NMDA parameters (page 1 of 4) Parameter Description Default and valid values DB2_ALIAS DB2_APPLY_NW_LEVELS DB2INSTANCE (UNIX) Specifies the database alias of the DB2 database to be backed up. This alias is typically the same as the database name. If not set, this parameter and the partition number are derived from the DB2 save set name. The DB2 save set will retain its current form of DB2:/DB_NAME/NODEXXXX, where XXXX is the partition number. Optional for a DB2 scheduled backup only. Specifies whether backups are performed at the levels specified in either the NMDA configuration file (for example, nmda_db2.cfg) or in the NetWorker Schedule resource. Optional for a DB2 scheduled backup only. Specifies the name (no the alias) of the DB2 instance that contains the database to be backed up. Mandatory for a DB2 scheduled backup on UNIX only. Note: Ensure that this parameter is set correctly. The appropriate IBM DB2 documentation provides details. Undefined (default). Valid DB2 Alias Name. FALSE (default) = Backup level set in the configuration file is used and mapped to the NetWorker schedule as follows: - DB2BACKUP_FULL is mapped to the full level in the schedule. - DB2BACKUP_INCREMENTAL is mapped to the incr level in the schedule. - DDB2BACKUP_DELTA is mapped to whatever level is set in the NetWorker schedule. If the schedule does not specify a level from 1 to 9, then level 9 is applied. TRUE = Backup is performed with the level defined in the NetWorker schedule. Backup level set in the configuration file is ignored. Levels in the NetWorker schedule are mapped to DB2 levels as follows: - The full level is mapped to DB2BACKUP_FULL.. - The incr level is mapped to DB2BACKUP_INCREMENTAL.. - The levels from 1 to 9 are mapped to DDB2BACKUP_DELTA. Undefined (default). Valid name of the DB2 instance that contains the database. DB2_NODE_NAME Specifies the alias of the DB2 instance to which the user must connect for the backup. Mandatory for a DB2 scheduled backup only. Undefined (default). Valid alias of the DB2 instance. If the node you are usiing is through a local connection, specify the instance name. 356 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 29 DB2-specific NMDA parameters (page 2 of 4) Parameter Description Default and valid values DB2_OPTIONS DB2_PARTITION_LIST DB2PATH (Windows) DB2_QUIESCE Specifies the DB2 backup options. Optional for a DB2 scheduled backup only. Note: At a minimum, specify either DB2BACKUP_DB or DB2BACKUP_TABLESPACE, not both. Specifies which nodes to back up for a DPF backup. Optional for a DB2 DPF backup only. Set this parameter only for DB2 release 9.5 or later. Specifies the path where the DB2 binaries are located. Mandatory for a DB2 scheduled backup on Windows only. Specifies whether to quiesce the DB2 database during a backup. Optional for a DB2 scheduled backup only. Undefined (default). One or more of the following values (case-sensitive), where multiple values must be separated by commas: - DB2BACKUP_COMPRESS - DB2BACKUP_DB - DB2BACKUP_DELTA - DB2BACKUP_EXCLUDE_LOGS - DB2BACKUP_FULL - DB2BACKUP_INCLUDE_LOGS - DB2BACKUP_INCREMENTAL - DB2BACKUP_OFFLINE - DB2BACKUP_ONLINE - DB2BACKUP_TABLESPACE Undefined (default). If not specified, the backup will back up a single node only. Value all or any integer that specifies an individual node to back up. Use commas to separate multiple integers. Undefined (default). Valid path where the DB2 binaries to be used for the backup are located. FALSE (default) = DB2 database is not quiesced during a backup. TRUE = DB2 database is quiesced during a backup. Note: DB2_ALIAS parameter must also be set. DB2_SESSIONS DB2_TBS_LIST DB2_USER Specifies the number of parallel NMDA sessions to be run with the NetWorker server for the DB2 backup. Optional for a DB2 scheduled backup only. Specifies a list of tablespaces to be backed up. Mandatory for a DB2 scheduled backup only. Set this parameter for a tablespace backup only, not for a database backup. Specifies the name of the DB2 user that connects to the DB2 instance for the backup. The password of the user is specified by the USER_PSWD parameter. Mandatory for a DB2 scheduled backup only. 1 (default). Integer number of parallel NMDA sessions. Undefined (default). List of tablespace names, with multiple names separated by commas. For example: DB2_TBS_LIST = SYSCATSPACE, USERSPACE1 Undefined (default). Valid DB2 username. DB2-specific NMDA parameters 357

NMDA Parameters for Backups and Restores Table 29 DB2-specific NMDA parameters (page 3 of 4) Parameter Description Default and valid values DB2_VENDOR_LIB_PATH Specifies the complete pathname of the NMDA shared library on the DB2 host. Path can point to various library versions to test and evaluate hot fixes. Optional for a DB2 scheduled backup only. On UNIX systems, the default location is assumed if not specified. For example, on Solaris systems: /usr/lib/libnsrdb2.so On Windows systems, the default path is obtained automatically from the registry. Note: If 32-bit NMDA is installed for 32-bit and 64-bit application coexistence on 64-bit Windows, set DB2_VENDOR_LIB_PATH to NetWorker_install_path\bin\libnsrdb232.dll. Multiple database support on the same host on page 33 provides more information on the NMDA installation for 32-bit and 64-bit application co-existence. INSTHOME (UNIX) NSR_DB2_RESTORE_ TABLESPACE_BKUP NSR_DR_BACKUP_INFO Specifies the path where the DB2 binaries are located. Mandatory for a DB2 scheduled backup on UNIX only. Specifies the full timestamp for a tablespace to be restored. Set this parameter if restoring a tablespace with no timestamp or only a partial timestamp. Optional for a DB2 restore only. Specifies whether additional disaster recovery and support information is backed up along with a scheduled backup. If the additional information fails to be backed up, an error message is generated. Optional for a DB2 scheduled backup only. Undefined (default). Valid path where the DB2 binaries to be used for the backup are located. Undefined (default). Full timestamp that includes the year, month, day, hour, minute, and second, in that order. For example: 20081113142149 (A partial timestamp would be 20081113.) TRUE (default) = Additional disaster recovery and support information is backed up. FALSE = Additional disaster recovery and support information is not backed up. Note: The following parameters must also be set: - DB2_ALIAS - DB2PATH (Windows) - INSTHOME (UNIX) NSR_DR_FILE_LIST NSR_LOG_VOLUME_POOL NSR_MAX_START_RETRIES Specifies a file that contains a list of files to be backed up in addition to the database backup. These files will be backed up as part of the scheduled backup, before any postprocessing script (defined with POSTCMD) runs. If the extra files fail to be backed up, an error message is generated. Optional for a DB2 scheduled backup only. Specifies the volume pool to use for a backup of the transaction logs. Optional for a DB2 backup. Specifies how many times the NMDA software attempts to start the DB2 backup before it fails. For example, the NetWorker server is not ready because the devices are not mounted. Optional for a DB2 backup. Undefined (default). Valid complete pathname of the file (containing the list of extra files to be backed up). For example, NSR_DR_FILE_LIST is set to nmda_savelist.txt, which is a file that contains: /space12/vendor.cfg /space12/db2inst1/sqllib/db2nodes.cfg Predefined NetWorker volume pool named Default (default). Valid name of a NetWorker volume pool for the transaction logs. 4 (default). Integer number of DB2 backup retries. 358 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 29 DB2-specific NMDA parameters (page 4 of 4) Parameter Description Default and valid values USER_PSWD Specifies the encrypted password for the DB2 user that connects to the DB2 instance, as specified by the DB2_USER parameter. Mandatory for a DB2 scheduled backup only. Undefined (default). Encrypted DB2 user password, which must be set with the nsrdaadmin -P command, for example: nsrdaadmin -P -z configuration_file The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrdaadmin command. DB2-specific NMDA parameters 359

NMDA Parameters for Backups and Restores Informix-specific NMDA parameters Common NMDA parameters on page 350 describes the common NMDA parameters, which NMDA uses for backups and restores of all the supported databases and applications. Table 30 on page 360 lists the Informix-specific NMDA parameters, which NMDA uses for specific purposes during Informix IDS backups and restores only. For Informix scheduled backups, the NMDA parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347. For Informix manual backups and restores, parameters must be set in the environment. Table 30 Informix-specific NMDA parameters (page 1 of 2) Parameter Description Default and valid values DO_LOGFILE_BACKUPS Specifies whether to perform the logical log file backup after the dbspace backup. Optional for an Informix scheduled backup only. Note: If DO_WHOLE_SYSTEM_BACKUP is set to TRUE, DO_LOGFILE_BACKUPS is ignored. TRUE (default) = Logical log file backup is performed after the dbspace backup. FALSE = Logical log file backup is not performed after the dbspace backup. DO_WHOLE_SYSTEM_BACKUP INFORMIXDIR INFORMIXSQLHOSTS NSR_DR_BACKUP_INFO NSR_DR_FILE_LIST Specifies whether to back up the logical log files during a scheduled backup. Optional for an Informix scheduled backup only. Specifies the pathname of the directory where the Informix RDBMS is installed. Mandatory for an Informix scheduled backup only. Specifies the name of the Informix SQL hosts file. Mandatory for an Informix scheduled backup on UNIX only. Optional for an Informix scheduled backup on Windows only. Specifies whether an additional set of files is backed up along with a scheduled backup, as additional disaster recovery and support information. Optional for an Informix scheduled backup only. Note: If deduplication is enabled, the boot file is not deduplicated. Specifies a file that contains a list of files to be backed up in addition to the database backup. These files will be backed up as part of the scheduled backup, before any postprocessing script (defined with POSTCMD) runs. If the extra files fail to be backed up, an error message is generated. Optional for an Informix scheduled backup only. TRUE (default) = Logical log files are backed up during a scheduled backup. This is equivalent to running onbar with the -w option. FALSE = Logical log files are not backed up during a scheduled backup. Undefined (default). Valid directory pathname of the Informix RDBMS installation. Undefined (default). Valid name of the Informix SQL hosts file. TRUE (default) = The following additional set of files is backed up along with a scheduled backup: - Informix ONCONFIG file - ixbar file - onconfig boot file - sqlhosts file - sm_versions file FALSE = The additional set of files is not backed up along with a scheduled backup. Undefined (default). Valid complete pathname of the file that contains the list of extra files to be backed up. For example, NSR_DR_FILE_LIST is set to nmda_savelist.txt, which is a file that contains a list of the extra file pathnames. 360 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 30 Informix-specific NMDA parameters (page 2 of 2) Parameter Description Default and valid values NSR_LOG_VOLUME_POOL ONCONFIG Specifies the volume pool to use for a backup of the logical logs. Optional for an Informix scheduled backup only. Specifies the name of the Informix RDBMS configuration file. Mandatory for an Informix scheduled backup only. Predefined NetWorker volume pool named Default (default). Valid name of a NetWorker volume pool for the logical logs. Undefined (default). Valid name of the Informix RDBMS configuration file. Informix-specific NMDA parameters 361

NMDA Parameters for Backups and Restores Lotus-specific NMDA parameters Common NMDA parameters on page 350 describes the common NMDA parameters, which NMDA uses for backups and restores of all the supported databases and applications. The following sections describe Lotus-specific information and the parameters that NMDA uses for specific purposes during Lotus backups and restores only. The parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347. Wildcard restrictions for Lotus operations For a client-side configuration of a Lotus scheduled or manual backup (configured with the NMC method, not with the wizard), you can use wildcards to specify the pathnames of Lotus directories or files (or both) to be backed up or restored with the NSR_BACKUP_PATHS parameter in the NMDA configuration file. The following restrictions apply to using wildcards that are expanded by NMDA: Wildcard expansion supports only asterisks (*) and question marks (?) in a regular expression: An asterisk (*) stands for any number of characters, including zero. A question mark (?) stands for only one character. For example: *.nsf matches abc.nsf and a.nsf, but not data.ntf. *.n?f matches abc.nsf, a.nsf, and data.ntf, but not test.nf. * matches all filenames.?.nsf matches a.nsf, b.nsf, and c.nsf, but not ab.nsf. A wildcard can be used in the last component only of a pathname. For example, the following includes an invalid pathname that the NMDA software cannot expand: NSR_BACKUP_PATHS = '/local/*/*.nsf' Lotus comfort span NMDA supports the NSR_COMFORT_SPAN parameter for incremental backups only when the Domino server is enabled for transaction logging in archive mode. The parameter specifies the acceptable amount of logs in kilobytes that can be applied to a database during the recovery. If that amount is exceeded at backup time, NMDA backs up the database file as a full backup in addition to backing up the logs. Note: The default NMDA behavior is to back up the archived logs only. A full backup reduces future recovery time. Fewer transaction logs are required to recover the logged database. For example, the NMDA configuration contains the following parameter settings for a Lotus incremental database backup with the comfort span option: NSR_BACKUP_LEVEL = incr NSR_COMFORT_SPAN = 196608 362 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores If NMDA determines that more than 196608 KB of logs need to be applied to recover the specified database, NMDA performs a full backup of the database in addition to backing up the logs. Lotus-specific NMDA parameter definitions Table 31 on page 363 lists the Lotus-specific NMDA parameters, which NMDA uses for specific purposes during Lotus Domino and Notes backups and restores only. Table 31 Lotus-specific NMDA parameters (page 1 of 5) Parameter Description Default and valid values LOTUS_USER Notes_ExecDirectory NSR_APPLY_LOGS NSR_AUTO_RESTORE NSR_BACKUP_ALL_EXTENSIONS NSR_BACKUP_LEVEL NSR_BACKUP_LOGS_MODE Specifies the name of the Lotus Domino or Notes user. Mandatory for a Lotus scheduled backup on UNIX and Linux. Specifies the complete pathname of the Lotus Domino or Notes directory that contains the application library. Mandatory for a Lotus backup or restore. Specifies whether to apply the transaction logs after a Lotus backup is restored. Optional for a Lotus restore. Specifies whether the Lotus database or file restore occurs automatically without user interaction. Optional for a Lotus restore. Specifies whether all Lotus files or only the default set of Lotus files (with specific filename extensions) are backed up. Optional for a Lotus backup. Specifies the level of Lotus backup to perform. Optional for a Lotus manual backup. Do not set this parameter for a scheduled backup. Specifies the level of transaction log backup to perform during a full backup. Optional for a Lotus full backup only. Do not set this parameter for an incremental backup. Note: Transaction logs are always backed up during a Lotus incremental backup. Undefined (default). Valid name of the Lotus Domino or Notes user. Undefined (default). Valid pathname of the Lotus Domino or Notes directory that contains the libnotes.xx or nnotes.dll library file. TRUE (default) = Transaction logs are applied after the backup is restored. FALSE = Transaction logs are not applied after the backup is restored. FALSE (default) = Lotus database or file restore occurs with user interaction. TRUE = Lotus database or file restore occurs automatically without user interaction. FALSE (default) = Only Lotus files with names ending in.box,.dic,.dsk,.id,.ncf,.njf,.nsf, and.ntf and the notes.ini file in the specific directory are backed up. TRUE = All Lotus files (with names ending in all extensions) are backed up. full (default) = Perform a full backup. incr = Perform an incremental backup. 0 (default) = Transaction logs are not processed. 1 = Transaction logs are backed up and marked as reusable. 2 = Transaction logs are marked as reusable, but are not backed up. Note: Use the NSR_BACKUP_LOGS_MODE = 2 setting with extreme caution. With this setting, the transaction logs are not backed up and will be recycled by the Domino server. Lotus-specific NMDA parameters 363

NMDA Parameters for Backups and Restores Table 31 Lotus-specific NMDA parameters (page 2 of 5) Parameter Description Default and valid values NSR_BACKUP_LOTUS_DIR Specifies whether files in the Lotus Domino or Notes data directory are backed up. On UNIX systems, the data directory is defined as the first Lotus data directory that NMDA finds in the parameter PATH. On Windows systems, the data directory is defined as the first Lotus data directory that NMDA finds in the Windows registry. Optional for a Lotus backup. Note: You cannot use this parameter with the NSR_BACKUP_PATHS parameter. FALSE (default) = Lotus directories and files specified with NSR_BACKUP_PATHS are backed up. TRUE = Lotus data directory is backed up. On Windows systems, the notes.ini file is included in the backup, whether or not it resides in the default data directory. Note: The NSR_BACKUP_ALL_EXTENSIONS setting determines whether all Lotus files or only the default set of Lotus files (with specific filename extensions) in the Lotus data directory are backed up. NSR_BACKUP_PATHS For a backup or restore, specifies the complete pathnames of one or more directories or files or both. Wildcard restrictions for Lotus operations on page 362 provides details on using wildcards in the pathnames. Optional for a Lotus backup or restore. Note: For a backup, you cannot use this parameter with the NSR_BACKUP_LOTUS_DIR parameter. For a restore, you cannot use this parameter with the NSR_RECOV_LIST_FILE parameter. Undefined (default). For a backup or restore, valid pathnames of one or more directories or files or both, with multiple names being separated by commas. The pathnames must not include the NOTES: prefix. For a restore only, NOTES: keyword by itself, specifying to restore all the Lotus data backed up from the given client. Do not use the keyword for a partitioned Domino server or multiple Domino installations on a single UNIX host. NSR_CATALOGFILE NSR_COMFORT_SPAN NSR_CROSS_MOUNT_POINTS NSR_DBIID Specifies the complete pathname of the backup catalog file, which contains detailed information about each file that is backed up. The information is appended to the file after each backup. If the specified catalog file cannot be accessed, the backup still proceeds as usual. At the end of the backup, an error message appears for the failed catalog file operation. Optional for a Lotus backup. Specifies the comfort span value to use for an incremental backup. Lotus comfort span on page 362 provides details on the comfort span. Optional for a Lotus incremental backup. Specifies whether the NMDA software crosses mount points during a Lotus backup. Optional for a Lotus backup. Specifies that NMDA assigns either a new DBIID, or both a new DBIID and new replica ID, to a restored database. Optional for a Lotus restore. Undefined (default). Valid complete pathname of a backup catalog file. The directory path to the file must exist. The file is created during the backup if it does not exist. Undefined (default). Integer value between 65536 and 65536000, inclusive. FALSE (default) = Lotus backup does not cross mount points. TRUE = Lotus backup crosses mount points. Undefined (default). 1 = A new DBIID is assigned to the restored database. 2 = A new DBIID and a new replica ID are assigned to the restored database. 364 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 31 Lotus-specific NMDA parameters (page 3 of 5) Parameter Description Default and valid values NSR_EXCLUDE_FILE Specifies the complete pathname of a file that lists file pathnames to exclude from the Lotus backup. Optional for a Lotus backup. Note: If both NSR_EXCLUDE_FILE and NSR_EXCLUDE_LIST are set, then all the files and objects specified through both parameters are excluded from the Lotus backup. Undefined (default). Valid complete pathname of a file that lists filepaths to exclude from the Lotus backup. NSR_EXCLUDE_LIST Specifies the complete pathnames of database files or directories to exclude from the Lotus backup. If a directory is specified, then all its data (including all subdirectories) is excluded from the backup. Optional for a Lotus backup. Note: If both NSR_EXCLUDE_LIST and NSR_EXCLUDE_FILE are set, then all the files and objects specified through both parameters are excluded from the Lotus backup. Undefined (default). Valid complete pathnames of one or more database objects to exclude from the Lotus backup, with multiple names being separated by commas. NSR_FOLLOW_LINKS NSR_LOG_DIR NSR_LOTUS_DATA_DIR Specifies which of the following actions occur when Lotus link files are to be backed up or restored: Both the Lotus link files and the data files or directories that the link files point to are backed up or restored. Only the Lotus link files are backed up or restored. Optional for a Lotus backup or restore. Specifies the complete pathname of the log directory of a partitioned Domino server for disaster recovery only. Optional for a Lotus restore. Specifies the complete pathname of the directory that contains the Lotus Notes data. Optional for a Lotus backup. Required for a partitioned Domino server or multiple Domino installations. Note: This parameter does not specify that the data will be backed up. TRUE (default) = Both the Lotus link files and the data files or directories that the links point to are backed up or restored. FALSE = Only the Lotus link files are backed up or restored. Undefined (default). Valid complete pathname of the log directory. Undefined (default). Valid complete pathname of the directory that contains the Lotus Notes data. NSR_MAX_TXN_LOGS NSR_NO_NOTES_INIT Specifies the number of transaction logs that are stored in a single save set during a Lotus backup. The logs are marked reusable after the successful backup of all the logs in the save set. If a backup fails, then none of the logs from the incomplete save set are marked reusable. Optional for a Lotus backup of transaction logs. Specifies whether the Notes API is initialized during a disaster recovery. Optional for a Lotus restore. 10 (default) logs per save set. Integer number of logs per save set. FALSE (default) = Notes API is initialized during the disaster recovery. TRUE = Notes API is not initialized during the disaster recovery. Lotus-specific NMDA parameters 365

NMDA Parameters for Backups and Restores Table 31 Lotus-specific NMDA parameters (page 4 of 5) Parameter Description Default and valid values NSR_NOTES_CONNECT_TIMEOUT NSR_NOTES_INI_PATH NSR_NUMBER_LOGS NSR_PARALLELISM NSR_PREFETCH_LOGS NSR_RECOV_INTERACT Specifies a timeout value in seconds during which NMDA retries a Lotus backup in either of the following cases: A Lotus database is offline while the Domino server runs a fixup command against the database. In-place compaction of a Lotus database is in progress on the Domino server. NMDA cannot back up a database in either of these cases. NMDA retries the database backup after every five seconds, until either the database becomes accessible or the timeout is reached. If the timeout is reached first: If NSR_SKIPDBERRORS = TRUE, NMDA skips the database and proceeds to back up the next database. If NSR_SKIPDBERRORS = FALSE, NMDA fails the backup with an error. Optional for a Lotus backup. Specifies the complete pathname of the notes.ini file, including the filename. Recommended for a Lotus backup or restore. Specifies the number of transaction logs to recover during a disaster recovery only. Optional for a Lotus restore. Specifies the maximum number of concurrent backup or restore streams that can be sent to or from the NetWorker server during a backup or restore. Optional for a Lotus backup or restore. Specifies the number of transaction log files that the NMDA software retrieves in advance when it is applying logs to a restored Lotus database. Optional for a Lotus restore. Specifies the default overwrite response when the name of a file being restored conflicts with an existing filename. The value of the parameter must be a single letter: If the letter is lowercase, it applies to the current file only, and the overwrite prompt continues to appear for subsequent files. If the letter is uppercase, it applies to all the files being restored and no prompts appear unless as specified for the R value. Optional for a Lotus restore. 30 (default); signifies a timeout of 30 seconds. Integer value of timeout in seconds. Undefined (default). Valid complete pathname of the notes.ini file. Undefined (default). Integer number of transaction logs to recover during a disaster recovery. Value determined by the NetWorker server, based on the NetWorker client and server parallelisms (default). Integer number of the maximum concurrent backup or restore streams. 0 (default) = NMDA does not prefetch extra logs. NMDA restores only a log that is requested by Domino. Integer number of transaction logs retrieved in advance, typically in the range of 2 to 5. Undefined (default). n = Do not restore the current file. N = Do not restore any files with conflicting names. No prompts appear. y = Overwrite the existing file with the restored file. Y = Overwrite all existing files with conflicting names. No prompts appear. r = If restoring a logged database, do not rename the existing file, and restore the backed-up file with a name that begins with a tilde (~). If restoring a database that is not logged, rename the existing file by adding a tilde to the start of the filename, and restore the backed-up file with its original name. R = Apply the actions of the r option to all existing files with conflicting names. No prompts appear. 366 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 31 Lotus-specific NMDA parameters (page 5 of 5) Parameter Description Default and valid values NSR_RECOV_LIST_FILE Specifies the complete pathname of a file that lists the files to restore. Optional for a Lotus restore. Note: You cannot use this parameter with the NSR_BACKUP_PATHS parameter. Undefined (default). Valid complete pathname of a file that lists Lotus Notes files or directories to restore. The file must contain one filepath per line, without any commas or other punctuation. NSR_RECOVER_TIME NSR_RELOCATION_DEST NSR_RESOURCE_DIR NSR_SAVESET_NAME NSR_SKIPDBERRORS PATH Specifies the point in time to which a database will be recovered. Optional for a Lotus restore. Specifies the complete pathname of a directory to which the Lotus database files are restored. Optional for a Lotus restore. Specifies the location of the directory that contains the Lotus resource files. Mandatory for a Lotus backup on UNIX only. Specifies the base name for the save sets of a Lotus DAOS backup. If more than one save set is created, NMDA appends a numeric extension to the name to create the additional save set names. Optional for a Lotus DAOS backup only. Specifies whether NMDA continues a Notes database backup if a noncritical error is encountered while backing up Notes database files (not flat files). A noncritical error is one that allows NMDA to recover from the problem, and to continue operations without compromising the backup data integrity. A noncritical error occurs when NMDA cannot access a Notes database while generating a list of files to back up. In this case, the file is skipped and the backup continues. A critical error occurs later if NMDA cannot access the file while trying to read the data to be saved. This error is critical because NMDA cannot safely skip the file and continue. During the backup of multiple databases, NSR_SKIPDBERRORS enables NMDA to skip the backup of problematic databases while continuing to back up good databases. Optional for a Lotus backup. Specifies the pathnames of the Domino data directory and Lotus software directory. Mandatory for the following Lotus backups: Lotus scheduled backup Any type of Lotus backup on a UNIX system By default, NMDA recovers the following: - Recovers a database in archived log mode to the current time. - Recovers a database not in archived log mode to the most recent available backup. Valid backup time in nsr_getdate(3) format. Undefined (default). Valid complete pathname of the directory to which the database files are restored. Undefined (default). Valid complete pathname of the Lotus directory that contains the resource files. Undefined (default). Base name to use for DAOS backup save sets, for example, notes_daos. FALSE (default) = NMDA does not continue a Notes database backup if a noncritical error is encountered. TRUE = NMDA continues a Notes database backup if a noncritical error is encountered. Note: If NSR_SKIPDBERRORS is set to TRUE, check the output log after a backup to see if any databases were skipped due to errors. Undefined (default). Valid directory pathnames of the Domino data directory and the directory where the Lotus binaries are installed. Lotus-specific NMDA parameters 367

NMDA Parameters for Backups and Restores Oracle-specific NMDA parameters Common NMDA parameters on page 350 describes the common NMDA parameters, which are NMDA parameters used for backups and restores of all the supported databases and applications. Oracle-specific NMDA parameter definitions on page 369 describes the Oracle-specific NMDA parameters, which NMDA uses for specific purposes during Oracle backups and restores only. Note: Unless noted otherwise, the parameters are supported for both regular backups and restores and PowerSnap snapshot backups and restores. Set the parameters for Oracle PowerSnap operations on page 293 provides details for the snapshot operations. Setting the NMDA parameters for Oracle operations on page 368 describes how to set the NMDA parameters for Oracle backup and restore operations. Setting the NMDA parameters for Oracle operations You must set the following NMDA parameters for Oracle scheduled backups in the NMDA configuration file: NSR_DEBUG_LEVEL (enables debug messages for scheduled backups) NSR_DIAGNOSTIC_DEST (changes the diagnostic file locations for scheduled backups) NSR_DPRINTF (enables DPRINTF debug messages for scheduled backups) NSR_RMAN_ARGUMENTS ORACLE_HOME ORACLE_SID ORACLE_USER PRECMD POSTCMD TNS_ADMIN To set an NMDA parameter in the configuration file, follow the guidelines in the section NMDA configuration file on page 347. You must set all the other NMDA parameters for Oracle operations in the RMAN script only. When you set an NMDA parameter in the RMAN script, use one of the following methods unless specified otherwise in Table 28 on page 350 (common parameters) or Table 32 on page 369 (Oracle-specific parameters): If you use automatic channels, set the parameter with the parms option in the configure channel command. Automatic channel allocation on page 43 provides more information on automatic channels. If you do not use automatic channels, set the parameter 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. 368 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Do not mix these different ways of setting Oracle-specific NMDA 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 parameters has no effect. On Windows systems, when a parameter is set through the parms option, the value of that 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 parameter is unset for the channel by using the parms option, as in the following example: run { allocate channel t1 type SBT_TAPE parms ENV=(NSR_SERVER=,NSR_DATA_VOLUME_POOL=) ; : : release channel t1; } Note: On Windows systems, this does not occur if the parameters are set with the send command in all RMAN sessions. Oracle-specific NMDA parameter definitions Table 32 on page 369 lists the Oracle-specific NMDA parameters. Table 32 Oracle-specific NMDA parameters (page 1 of 4) Parameter Description Default and valid values NSR_DATA_VOLUME_POOL1 NSR_DATA_VOLUME_POOL2 NSR_DATA_VOLUME_POOL3 Specifies the name of the volume pool to use for a duplexed Oracle backup. Mandatory for an Oracle manual backup that uses the set duplex command (with duplex set to 2, 3, or 4) or other RMAN commands to generate two or more backup copies. Set this parameter with the parms option in the RMAN script (not with the send command or option). Specifies the name of the volume pool to use for a duplexed Oracle backup. Mandatory for an Oracle manual backup that uses the set duplex command (with duplex set to 3 or 4) or other RMAN commands to generate three or more backup copies. Set this parameter with the parms option in the RMAN script (not with the send command or option). Specifies the name of the volume pool to use for a duplexed Oracle backup. Mandatory for an Oracle manual backup that uses the set duplex command (with duplex set to 4) or other RMAN commands to generate four backup copies. Set this parameter with the parms option in the RMAN script (not with the send command or option). Undefined (default). Valid NetWorker pool name that is different from the name used by the parameter NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL2, or NSR_DATA_VOLUME_POOL3. Undefined (default). Valid NetWorker pool name that is different from the name used by the parameter NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, or NSR_DATA_VOLUME_POOL3. Undefined (default). Valid NetWorker pool name that is different from the name used by the parameter NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, or NSR_DATA_VOLUME_POOL2. Oracle-specific NMDA parameters 369

NMDA Parameters for Backups and Restores Table 32 Oracle-specific NMDA parameters (page 2 of 4) Parameter Description Default and valid values NSR_MMDB_RETRY_TIME NSR_NO_MULTIPLEX NSR_PROXY_PFILE NSR_RECOVER_POOL NSR_RETENTION_DISABLED NSR_RMAN_ARGUMENTS Specifies the number of minutes that NMDA 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, NMDA tries to reconnect after sleeping for five seconds between attempts. Optional for an Oracle backup or retore. 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. Optional for an Oracle backup. To optimize restore operations, RMAN requires Oracle backups no to 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. Specifies the complete pathname of a configuration file that contains PowerSnap parameter settings for a snapshot backup or restore. Mandatory for an Oracle backup or restore if PowerSnap parameters are set in a configuration file. Supported for a PowerSnap snapshot backup or restore only. Specifies the name of the NetWorker volume pool to use for an Oracle 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. Optional for an Oracle restore. Supported for a regular Oracle restore only, not a PowerSnap snapshot restore. Specifies whether the NetWorker browse and retention policies are disabled. Optional for an Oracle backup. Set this parameter 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. Specifies any valid combination of options for the RMAN executable, rman(.exe). The appropriate Oracle Recovery Manager documentation provides details on the valid options. Optional for an Oracle scheduled backup. Set this parameter in the configuration file only. 0 (default) = NMDA does no try to reconnect to the media database if the first attempt fails. Valid integer = Number of minutes that NMDA tries to connect to the media database. 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: Do not set this parameter to TRUE if you use a random access NetWorker device, such as an advanced file device. Undefined (default). Valid pathname of the configuration file. Note: If undefined or an invalid pathname, parameter settings in the preferred configuration file are ignored. Undefined (default). 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 NMDA backup data. TRUE = NetWorker browse and retention policies are disabled. Only Oracle policies are used to manage the lifecycle of the NMDA backup data. Undefined (default). Double-quoted string that contains any valid combination of options for the RMAN executable, rman(.exe). For example, set the parameter to append RMAN output to message log file /nsr/applogs/msglog.log if a Recovery Catalog is not used: NSR_RMAN_ARGUMENTS= nocatalog msglog /nsr/applogs/msglog.log append" 370 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 32 Oracle-specific NMDA parameters (page 3 of 4) Parameter Description Default and valid values NSR_SERVER_NIC Specifies the name of a network interface card (NIC) on a NetWorker server. Optional for an Oracle backup or restore. When this parameter is set with the RMAN send command for an allocated channel, its value overrides the NSR_SERVER setting for that channel only. Note: You must explicitly set this parameter 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. Undefined (default). Valid name of a NetWorker server NIC. ORACLE_HOME ORACLE_SID ORACLE_USER (UNIX) Specifies the home directory pathname of the Oracle Server installation. Mandatory for an Oracle scheduled backup. Set this parameter in the configuration file only. Specifies the system identifier (SID) value of the Oracle database to be backed up. Mandatory for an Oracle 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 PowerSnap snapshot backup is performed with catalog synchronization enabled. Chapter 8, Snapshot Backups and Restores, provides details on PowerSnap snapshot backups. Oracle operating system authentication is used on UNIX or Linux. ORACLE_USER must also be set, as described in ORACLE_USER (UNIX) on page 371. Set this parameter in the configuration file only. To enable a scheduled backup for operating system authentication, specifies the username of the Oracle operating system user that is set up to connect to the Oracle database through operating system authentication. ORACLE_SID must also be set, as described in ORACLE_SID on page 371. Optional for an Oracle scheduled backup in a client-side configuration (configured with the NMC method, not the wizard) on UNIX systems only. Set this parameter in the configuration file only. Note: Using ORACLE_USER to perform an Oracle backup through operating system authentication is not supported for the following: - Scheduled backup that is configured through the configuration wizard. - Scheduled backup on Microsoft Windows. - Probe-based backup. - PowerSnap snapshot backup. Undefined (default). Valid pathname of the home directory of the Oracle Server installation. Undefined (default). Valid SID value of the Oracle database to be backed up. For example, if catalog synchronization is enabled for PowerSnap snapshot backups, and orcl10 is the SID of the Oracle database to be backed up: ORACLE_SID=orcl10 Undefined (default). Valid username of the Oracle operating system user that is set up to connect to the Oracle database through operating system authentication. Oracle-specific NMDA parameters 371

NMDA Parameters for Backups and Restores Table 32 Oracle-specific NMDA parameters (page 4 of 4) Parameter Description Default and valid values TNS_ADMIN Specifies the directory pathname of the Oracle Net configuration files. Mandatory for an Oracle scheduled backup if Oracle Net configuration files are located in a directory other than the default $ORACLE_HOME/network/admin directory. Set this parameter in the configuration file only. Undefined (default). Valid pathname of the directory that contains the Oracle Net configuration files. 372 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Sybase-specific NMDA parameters Common NMDA parameters on page 350 describes the common NMDA parameters, which NMDA uses for backups and restores of all the supported databases and applications. Table 33 on page 373 lists the Sybase-specific NMDA parameters, which NMDA uses for specific purposes during Sybase ASE backups only. For Sybase backups, the NMDA parameters must be set in the NMDA configuration file, as described in NMDA configuration file on page 347. For Sybase restores, parameters must be set in the environment or as nsrsybrc command options. Table 33 Sybase-specific NMDA parameters (page 1 of 4) Parameter Description Default and valid values DBCCOPT LD_LIBRARY_PATH LD_LIBRARY_PATH_64 LIBPATH Specifies one or more -o options to be passed to the nsrsybcc command, which performs a database consistency check for the Sybase backup. Optional for a Sybase backup. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybcc command and its options. Note: If USE_CONSISTENCY_CHECK is set to TRUE and DBCCOPT is undefined, nsrsybcc performs all the possible checks prior to a backup. Specifies the directory pathname of the Open Client Server (OCS) library. Mandatory for a Sybase scheduled backup on the following platforms: HP-UX Itanium Linux AMD64/EM64T Solaris SPARC Optional for a Sybase manual backup on these platforms. For a Sybase manual backup, this parameter can alternately be set as an environment variable. Specifies the directory pathname of the Open Client Server (OCS) library. Mandatory for a Sybase scheduled backup on Solaris AMD64/EM64T. Optional for a Sybase manual backup on Solaris AMD64/EM64T. For a Sybase manual backup, this parameter can alternately be set as an environment variable. Specifies the directory pathname of the Open Client Server (OCS) library. Mandatory for a Sybase scheduled backup on AIX. Optional for a Sybase manual backup on AIX. For a Sybase manual backup, this parameter can alternately be set as an environment variable. Undefined (default). One or more of the following options of the nsrsybcc command, with a single option or multiple space-separated options enclosed in double quotes: -o ckdb -o ckal -o ckcat -o ckdbnoidx -o ckstor For example: DBCCOPT= -o ckcat -o ckal -o ckdb Undefined (default). Directory pathname of the OCS library, which must be the same value as set in the SYBASE.sh or SYBASE.csh script. Undefined (default). Directory pathname of the OCS library, which must be the same value as set in the SYBASE.sh or SYBASE.csh script Undefined (default). Directory pathname of the OCS library, which must be the same value as set in the SYBASE.sh or SYBASE.csh script. Sybase-specific NMDA parameters 373

NMDA Parameters for Backups and Restores Table 33 Sybase-specific NMDA parameters (page 2 of 4) Parameter Description Default and valid values NSR_ASE_PASSWORD Specifies an unencrypted password to add to the Sybase dump command, as a method of password-protecting the Sybase backup data. Optional for a Sybase backup only. Note: This unencrypted password value is stored in the NMDA configuration file. Undefined (default). Unencrypted password, from 6 to 30 characters in length, which is added with the passwd= clause to the Sybase dump command. NSR_ASE_VERIFY NSR_BACKUP_LEVEL NSR_BACKUP_PATHS NSR_DUMP_LOG_OPT Specifies one of the following options for backup verification: full header Optional for a Sybase backup only. Specifies the level of Sybase manual backup to perform. Optional for a Sybase manual backup. Do not set this parameter for a scheduled backup. Specifies the backup of either the entire Sybase server instance, or one or more Sybase databases. Optional for a Sybase manual backup only. Note: Do not specify both an instance name and a list of databases. Specifies one of the following options for the transaction log backup: no_log no_truncate truncate_only Optional for a Sybase backup only. Sybase transaction log backups on page 113 provides more details on using the options for transaction log backups. Undefined (default). One of the following values: - full = Verify both the header information and rows structure (full verification of the backup). - header = Verify the page header information only. For example, the following specifies a full verification of the backup: NSR_ASE_VERIFY=full full (default) = A full level backup is performed, which backs up the database. incr = An incremental level backup is performed, which backs up the transaction logs. Undefined (default). Valid pathnames in either of the following forms, with multiple database names being separated by a comma: SYBASE:/ASE_server_name (backs up the entire server instance) SYBASE:/ASE_server_name/database_name [,SYBASE:/ASE_server_name/database_name...] Undefined (default). One of the following values: - no_log = Back up the transaction log without recording the backup operation. (The no_log clause is added to the Sybase dump command.) - no_truncate = Back up the transaction log withou truncating it. - truncate_only =Truncate the transaction log without backing it up. For example, the following specifies to back up the transaction log withou truncating it: NSR_DUMP_LOG_OPT= no_truncate Note: Use the no_log clause with caution. The Sybase documentation provides details on using the dump command with the no_log clause. NSR_EXCLUDE_FILE Specifies the complete pathname of a file that lists databases to exclude from a backup of a Sybase server instance. Optional for a Sybase backup of a server instance. Note: Do not specify this parameter for a Sybase backup of one or more databases. Undefined (default). Valid complete pathname of an ASCII file that lists the databases to exclude from the backup of the server instance. The file lists each database on a separate line in the following format: SYBASE:/ASE_server_name/database_name 374 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

NMDA Parameters for Backups and Restores Table 33 Sybase-specific NMDA parameters (page 3 of 4) Parameter Description Default and valid values NSR_LOG_VOLUME_POOL Specifies the volume pool to use for a backup of the transaction logs. Optional for a Sybase backup. Note: The metadata from a transaction log backup is backed up to a regular (non-log) volume pool. Using NSR_LOG_VOLUME_POOL for incremental Sybase backups on page 76 provides details. Predefined NetWorker volume pool named Default (default). Valid name of a NetWorker volume pool for the transaction logs. NSR_PARALLELISM Specifies the number of stripes to use to back up each database during the backup. During a multistripe backup, multiple data streams are extracted in parallel from a database and written in parallel to one or more media devices. Optional for a Sybase backup only. Note: NMDA does not support multistripe backups for the backup of transaction logs. 1 (default). Integer value of 1 or greater for the number of multistripe sessions. NSR_PROMOTE_FULL PATH SHLIB_PATH SYBASE Specifies whether to promote an incremental backup to a full backup when an incremental backup cannot be performed. Optional for a Sybase backup only. Specifies the following: On UNIX, the pathname of the directory where the NetWorker binaries are installed. On Windows, the pathnames of the directories where the Open Client Server (OCS) library and the NetWorker binaries are installed. Mandatory for a Sybase scheduled backup on Windows only if the paths of the NetWorker client binaries and OCS library are not in the system path. Set on UNIX only if the NetWorker client binaries are relocated. Specifies the directory pathname of the Open Client Server (OCS) library. Mandatory for a Sybase scheduled backup on HP-UX PA-RISC. Optional for a Sybase manual backup on HP-UX PA-RISC. For a Sybase manual backup, this parameter can alternately be set as an environment variable. Specifies the pathname of the directory where the Sybase ASE software is installed. Mandatory for a Sybase backup or restore. Set the parameter through the required method: For a scheduled backup, set it in the configuration file. For a manual backup, set it in either the configuration file or the environment. For a restore, set it in the environment. TRUE (default) = Promote an incremental backup to a full backup if an incremental backup cannot be performed. FALSE = Do not promote an incremental backup to a full backup if an incremental backup cannot be performed. Undefined (default). Valid directory pathnames as follows: - On UNIX, the directory pathname of the NetWorker binaries. - On Windows, the directory pathnames of the OCS library and the NetWorker binaries, with a semicolon separating the pathnames. For example, set the parameter as follows to add the OCS library pathnames on Windows: PATH=%PATH%;%SYBASE%\%SYBASE_OCS % \bin;%sybase%\%sybase_ocs%\dll Undefined (default). Directory pathname of the OCS library, which must be the same value as set in the SYBASE.sh or SYBASE.csh script. Undefined (default). Valid directory pathname for the Sybase ASE software installation. Sybase-specific NMDA parameters 375

NMDA Parameters for Backups and Restores Table 33 Sybase-specific NMDA parameters (page 4 of 4) Parameter Description Default and valid values SYBASE_USER USE_CONSISTENCY_CHECK USER_PSWD Specifies the name of the Sybase user that connects to the Sybase server instance for the backup. The password of the user is specified by the USER_PSWD parameter. Mandatory for a Sybase backup. Specifies whether the nsrsybcc command performs a database consistency check before a backup occurs. Optional for a Sybase scheduled backup only. Specifies the encrypted password for the Sybase user that connects to the Sybase server instance, as specified by the SYBASE_USER parameter. Mandatory for a Sybase backup only if the Sybase instance has a password. Undefined (default). Valid Sybase username. FALSE (default) = Database consistency check command, nsrsybcc, is not run before a backup. TRUE = Database consistency check command, nsrsybcc, is run before a backup. The specific checks performed depend on the DBCCOPT setting. Undefined (default). Encrypted Sybase user password, which must be set through the nsrdaadmin -P command, for example: nsrdaadmin -P -z configuration_file The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrdaadmin command. 376 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

B Oracle RMAN Commands This appendix includes the following major sections, which describe Oracle RMAN commands that you can use in the RMAN scripts for Oracle backups and restores: The delete expired backup command... 378 The change...crosscheck and crosscheck commands... 378 The pool option of the backup command... 378 The send command... 379 The set duplex command... 383 The trace option of the backup command... 385 Oracle RMAN Commands 377

Oracle RMAN Commands The delete expired backup command To use the delete expired backup command with a NetWorker server, the user must have the required NetWorker privileges, as described in NetWorker user group privileges on page 72. 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 Databases and Applications (NMDA) 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, use the appropriate NetWorker media management command to manually remove the required save set entries from the NetWorker indexes. The EMC 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 NMDA installation, you may need to set the NSR_NWPATH parameter in the NWORA resource file or in the RMAN script. NSR_NWPATH on page 353 provides more information. The change...crosscheck and crosscheck commands For all NetWorker client file index entries that are not browsable, running 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 NMDA 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 NMDA returns the following error message: sbtbackup: Oracle pools are not supported NMDA error messages on page 398 provides more information on this error message. To specify the NetWorker volume pool that NMDA will use, set the parameter NSR_DATA_VOLUME_POOL in the RMAN script. Appendix A, NMDA Parameters for Backups and Restores, provides more information. 378 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Oracle RMAN Commands The send command The NMDA implementation of the send command enables you to set the Oracle-specific parameters, as described in Oracle-specific NMDA parameters on page 368. Set the Oracle-specific parameter values by using the methods described in Setting the NMDA parameters for Oracle operations on page 368. 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 379 Two ways to run the send command on page 381 Precedence rules on page 383 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. Syntax rules 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 379 The send command options on page 380 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: Oracle restricts the maximum length of the command string 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, you must include one or more Oracle-specific 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. The send command 379

Oracle RMAN Commands Commas separating the name=value entries are mandatory. Comments are not allowed inside the quotes. In the following example, # NSR_SERVER is considered the first parameter s name: run { allocate channel t1 type SBT_TAPE ; send NSR_ENV=( # NSR_SERVER=server1, NSR_CLIENT=oracle) ; : A send command in an RMAN script can span multiple lines. For example: send NSR_ENV=( 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 You can use the device_type or the channel option in the send command in an RMAN script only. You cannot use either option in the send command on the operating system command line. The send command on the operating system command line on page 381 provides more information. Example 54 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 { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send channel t1 NSR_ENV=(NSR_SERVER=server1, NSR_DATA_VOLUME_POOL=MondayFulls) ; : } This sample RMAN script is referenced in Table 34 on page 381. 380 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Oracle RMAN Commands Table 34 on page 381 lists the values for options used with the send command. The example referred to is Example 54 on page 380. Table 34 Option values in the send command Option value device_specifier channel_id name1 value1 name2 value2 Describes The device type as specified in an allocate channel command in the RMAN script. For a backup tape device, use SBT_TAPE. The channel identifier as specified in an allocate channel command in the RMAN script. In the example, the identifier is t1. The first NMDA parameter name. In the example, the first parameter name is NSR_SERVER. The value assigned to the first parameter. In the example, the first value is server1. The second NMDA parameter name. In the example, the second parameter name is NSR_DATA_VOLUME_POOL. The value assigned to the second parameter. In the example, the second value is MondayFulls. Two ways to run the send command 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 381. In the run job of the RMAN script, as described in The send command in the RMAN script on page 382. 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 379, 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 380 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 381

Oracle RMAN Commands 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 383 provides more information. Example 55 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 { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; allocate channel t3 type SBT_TAPE ; : } 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 379. 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 380. Specify the correct option values in the send command, as described in The send command options on page 380. 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 appears. 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 { allocate channel t1 type SBT_TAPE ; allocate channel t2 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); release channel t1; release channel t2; } This script is the same as the sample script on page 104. The single send command sets the parameters for both channels. 382 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Oracle RMAN Commands Precedence rules! 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, Oracle executes only the send option in the configure channel command. 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 56 Order of parameters set according to the precedence rules 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 { allocate channel t1 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=server2, NSR_CLIENT=client2) ; send channel t1 NSR_ENV=(NSR_SERVER=server3, NSR_CLIENT=client3) ; : } The set duplex command For an Oracle 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: NMDA supports the generation of backup copies for Oracle manual backups only, not for Oracle scheduled backups. The set duplex command 383

Oracle RMAN Commands Table 35 on page 384 describes the results of setting duplex to each of the valid values. Table 35 Set duplex command values Set duplex command set duplex=1 set duplex=2 or set duplex=on set duplex=3 set duplex=4 Oracle backup results The backup set is directed to NSR_DATA_VOLUME_POOL. 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. Three copies of the backup set are directed to the separate pools specified by NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, and NSR_DATA_VOLUME_POOL2. These three pools must be different. 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. No default values exist 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 in the RMAN script, not with the send command or option. Appendix A, NMDA Parameters for Backups and Restores, provides more information on how to set the parameters. Each pool that one of these NSR_DATA_VOLUME_POOL* parameters specifies 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 backup includes the current control file, 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 44 provides information on additional Oracle commands that you can use for backup set duplexing during Oracle 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 NMDA, 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 384 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Oracle RMAN Commands piece as expired ( Retention policies on page 49 provides a definition of expired) and to use the duplexed copy for the restore operation. The appropriate Oracle backup and recovery documentation provides more information. The trace option of the backup command 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 of trace is also written to the log file nmda_oracle.messages.raw, located in the directory specified by the NSR_DIAGNOSTIC_DEST parameter (if set) or in the default directory: On UNIX: /nsr/apps/logs On Windows: NetWorker_install_path\apps\logs, where NetWorker_install_path is the root directory of the NetWorker installation path These log files do not contain Oracle Server or RMAN errors. NMDA generates Oracle error messages in the nmda_oracle.messages.raw file in a language-independent binary form, readable by the nsr_render_log program only. The EMC NetWorker Administration Guide provides information on how to use the nsr_render_log program to read any language-independent binary file, such as nmda_oracle.messages.raw. Table 36 on page 385 outlines the conditions that are traced when the trace option is set to each of the three valid values. Table 36 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 NMDA implementation of the Oracle SBT interface). 2 All error conditions. Entry and exit for each SBT function (the NMDA 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 385

Oracle RMAN Commands 386 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

C Sybase isql Commands This appendix includes the following major sections: Syntax for isql commands... 388 Loading and dumping a database... 388 Loading and dumping a transaction log... 389 Recovering a database and transaction logs... 390 Sybase isql Commands 387

Sybase isql Commands Syntax for isql commands This section provides information about the conventions that must be used with Sybase isql commands. Follow these conventions for command options on the Sybase isql command line: Command options not enclosed in brackets or braces must always be present in the command. Command options enclosed in square brackets ([ ]) are optional. If command options are enclosed in braces ({ }), one of the options must be included with the command. Loading and dumping a database This section describes how to dump and load a Sybase database from the Sybase isql command line. It includes the following procedures: Dump a database on page 388 Load a database on page 388! IMPORTANT To back up or restore a Sybase database, use the information in the preceding chapters of this guide; do not manually invoke the Sybase dump or load command. When you use NMDA to perform a Sybase backup or restore, the nsrdasv or nsrsybrc command (respectively) invokes the Sybase dump or load command. Dump a database To dump a database from the Sybase isql command line, use the following syntax for each database to be dumped: dump database database_name to nsrsyb:: To specify the hostname and server name, or that a notification should be sent to the operator console, use the following syntax: dump database database_name to nsrsyb::[[host_name][.[sybase_server][.[database_name]]]] [with notify = {client operator_console}] Load a database To load the most recent database backup from the Sybase isql command line, use the following syntax: load database database_name from nsrsyb:: To specify the hostname, server name, and timestamp, or that a notification should be sent to the operator console, use the following syntax: load database database_name from nsrsyb::[[host_name][.[sybase_server][.[database_name] [.[timestamp]]]]] [with {[headeronly,][notify = {client operator_console}]}] 388 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Sybase isql Commands Example 57 Loading the master database To load the master database from a backup performed on October 22, 2009 at 11:52:30 AM, the syntax is as follows:! load database master from nsrsyb::...2009102211523000 IMPORTANT After loading the database, bring it back online. Loading and dumping a transaction log This section describes how to dump and load transaction logs from the isql command line. It includes the following procedures: Dump a transaction log on page 389 Load a transaction log on page 389 Find the timestamp for a save set on page 390! IMPORTANT To back up or restore Sybase transaction logs, use the information in the preceding chapters of this guide; do not manually invoke the Sybase dump or load command. Dump a transaction log To dump a transaction log from the isql command line, use the following syntax for each transaction log to be dumped: dump transaction database_name to nsrsyb:: To specify the hostname and server name, or that a notification should be sent to the operator console, use the following syntax: dump transaction database_name to nsrsyb::[[host_name][.[sybase_server][.[database_name]]]]] [with {[{truncate_only no_log no_truncate},] [notify = {client operator_console}]}] Load a transaction log To load the most recent transaction log backup from the isql command line, use the following syntax: load transaction database_name from nsrsyb:: To specify the hostname and server name, or that a notification should be sent to the operator console, use the following syntax: load transaction database_name from nsrsyb::[[host_name][.[sybase_server][.[database_name] [.[timestamp]]]]] [with {[headeronly,][notify = {client operator_console}]}] Loading and dumping a transaction log 389

Sybase isql Commands Find the timestamp for a save set! IMPORTANT Do not use the Save Set Recover window to recover Sybase data. Use the nsrsybrc command to recover databases and transaction logs. The EMC NetWorker Module for Databases and Applications Command Reference Guide provides details on the nsrsybrc command and its options. To use a specific timestamp when loading a database or transaction log: 1. Find the timestamp for a save set by using either of the following methods: Run the following command to obtain a list of all the Sybase save sets for the NetWorker client. nsrinfo -X all -n sybase client_name Use the Save Set Recover window in NMC to select the save set to be recovered. The date and time are displayed in the Instances window. Type the load command at the isql command line. 2. Specify a timestamp in the following format: YYYYMMDDhhmmsslll where: YYYY indicates the year. MM indicates the month. DD indicates the day. hh indicates the hour. mm indicates the minutes. ss indicates the seconds. lll indicates the milliseconds. The millisecond position is optional; alternatively, 000 can be entered for the milliseconds. Note: If you do not specify a timestamp, the most recent backup is recovered. Recovering a database and transaction logs Use the Sybase load command from the isql command line to recover a database or transaction logs. To recover database and transaction logs: 1. Ensure that one of the following environment variables is set for the Sybase backup server: NSR_SERVER NSR_CLIENT Note: The load command uses the environment variables that are set for the Sybase backup server. 390 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Sybase isql Commands 2. Load a database from the isql command line: load database database_name from nsrsyb:: Note: To load a database or transaction log from the isql command line, the timestamp for each database or transaction log may be required. If a timestamp is not included, the NetWorker software uses the most recent backup. If there are multiple transaction logs, then it is useful to indicate the timestamp when a transaction log is loaded. If required, find the timestamp for a save set by using either of the following methods: Type the following command to obtain a list of all the Sybase save sets for the NetWorker client: nsrinfo -X all -n sybase NetWorker_client Select the save set to be recovered: Use the Save Set Recover window in NMC to select the save set. The date and time appear in the Instances window. At the isql command line, type the load command.! IMPORTANT Use the nsrsybrc command to recover databases and transaction logs. Do not use the Save Set Recover window to recover Sybase data. Chapter 4, Data Restore and Recovery, provides details. 3. Apply the transaction logs to the database: load transaction database_name from nsrsyb:: 4. Bring the database back online: online database database_name Recovering a database and transaction logs 391

Sybase isql Commands 392 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

D Troubleshooting and Error Messages This appendix includes the following major sections: General troubleshooting tips... 394 NMDA error messages... 398 DB2-specific troubleshooting tips and error messages... 399 Informix-specific troubleshooting tips and error messages... 403 Lotus-specific troubleshooting tips and error messages... 407 Oracle-specific troubleshooting tips and error messages... 412 Sybase-specific troubleshooting tips and error messages... 427 Troubleshooting and Error Messages 393

Troubleshooting and Error Messages General troubleshooting tips The following list of troubleshooting tips refers to sections of this guide and the EMC NetWorker Module for Databases and Applications Installation Guide. Use the following list to troubleshoot basic problems in running backup and restore operations with NetWorker Module for Databases and Applications (NMDA). To properly set up an NMDA backup and restore system: 1. Verify that the combination of the operating system, database or application server, NetWorker server, and NetWorker client is supported. The following provide information on installation requirements: EMC NetWorker Module for Databases and Applications Installation Guide EMC Information Protection Software Compatibility Guide 2. Ensure that the database or application server system and any network services (if used) are configured according to the instructions in the appropriate documentation. Verifying the database or application server configuration on page 72 provides more information. 3. Ensure that the NetWorker server and client software is installed and configured according to the instructions in the following: EMC NetWorker Installation Guide EMC NetWorker Administration Guide Chapter 2, Software Configuration 4. Ensure that the NMDA software is installed and enabled according to the instructions in the EMC NetWorker Module for Databases and Applications Installation Guide. To verify the version of NMDA installed, check the version of the nsrdasv program file by using one of the following commands, where filename is the complete pathname of the nsrdasv binary: On UNIX: what filename On Linux: strings filename grep "@(#)" On Windows: 1. Open Windows Explorer, and locate the nsrdasv.exe file. 2. Right-click the file icon, and select Properties. 3. In the Properties dialog box, select the Version tab to display the version information. For example, the following command displays version information for the nsrdasv binary on Solaris: what /usr/sbin/nsrdasv 394 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages To display the NMDA version number, enter the appropriate command for the operating system: On AIX: lslpp -L all grep -i lgtonmda On HP-UX: swlist -l product NMDA On Linux: rpm -qa grep -i lgtonmda On Solaris: pkginfo -l LGTOnmda 5. Ensure that you can perform a manual backup with NMDA according to the instructions in Manual backup procedures on page 134. 6. Ensure that you can perform a scheduled backup with NMDA according to the instructions in Scheduled backup procedures on page 156. Viewing group backup details and messages on page 395 provides details on monitoring messages and logs in the NMC program. The following sections provide details on common issues and how to resolve them: Wizard creation of backup fails, authentication denied on page 395 The backup hangs on page 396 If the manual or scheduled backup fails, check the debug log files for NMDA and the NetWorker server. Debug log files on page 396 provides more details. Viewing group backup details and messages The NetWorker Management Console (NMC) enables messages and logs to be monitored for performance, troubleshooting, and diagnostic purposes. For example, the NMC 7.5 interface provides these monitoring features: To view detailed information about a group backup: Start the NMC 7.5 program. In the Monitoring view, select the Groups tab and view the backup group. Click the Show Messages button to view any messages generated during the backup. To view the most recent general notification logs: Start the NMC 7.5 program. In the Monitoring view, select the Log tab. The priority, time, source, category, and message for each log appears. If a particular log file is no longer available, inspect the log file on the NetWorker server. Wizard creation of backup fails, authentication denied If the configuration wizard fails to create a scheduled backup, an error message might indicate that authentication is denied, or denied for username. The lockbox with the database connection credentials was not accessible by the superuser on the client where the backup failed and the message appeared. As a solution, use the NMC program to ensure that the Lockbox resource is created for the given client and the Users attribute contains the superuser of the client. General troubleshooting tips 395

Troubleshooting and Error Messages The EMC NetWorker Administration Guide provides details on lockbox password management. The backup hangs If the backup hangs, the NetWorker server might be temporarily unavailable at the start of the backup. The backup waits until the NetWorker server becomes available. As a solution, edit the NMDA configuration file or (for Oracle backups only) the RMAN backup scripts, and set this parameter to TRUE: NSR_NO_BUSY_ERRORS=TRUE NSR_NO_BUSY_ERRORS on page 353 describes this parameter. If the NSR_NO_BUSY_ERRORS parameter is set to TRUE and the backup still hangs, determine if the nsrexecd program is running as follows: # ps -ef grep nsrexecd If nsrexecd is not running, start the program with the following command: # nsrexecd Debug log files You can set the following parameters in the configuration file (if not using the wizard) or in the wizard to specify settings for the NMDA debug logs: NSR_DEBUG_LEVEL on page 351 NSR_DIAGNOSTIC_DEST on page 352 The NSR_DEBUG_LEVEL parameter specifies the level of debug messages that the NMDA software generates. The valid parameter values are 0 to 9: If the parameter is not set or if it is set to 0, NMDA does not generate debug messages. If the parameter is set to a value between 1 and 9, NMDA generates debug messages in the debug log file on the database or application server host. The level of detail in the debug messages increases with the debug level. The debug log file has the following filename: binaryname[_app].date.time.pid[_threadid.log where app indicates the type of application: db2 informix lotus oracle sybase Note: _app is included in the filename only if the binaryname binary supports different applications. For example: nsrdasv_app.date.time.pid.log 396 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages The NSR_DIAGNOSTIC_DEST parameter specifies the directory location of all the NMDA log files, including debug, operations, and error logs. If the parameter is not set, the debug logs are located in the following default directory: On UNIX: /nsr/apps/logs On Windows: NetWorker_install_path\apps\logs The NetWorker server also writes diagnostic information from a manual or scheduled backup to specific log files on the NetWorker server. The EMC NetWorker Administration Guide provides more information on these log files. The following sections provide additional information for application-specific troubleshooting: DB2-specific troubleshooting tips on page 399 Informix-specific troubleshooting tips on page 403 Lotus-specific troubleshooting tips on page 407 Oracle-specific troubleshooting tips on page 412 Sybase-specific troubleshooting tips on page 427 General troubleshooting tips 397

Troubleshooting and Error Messages NMDA error messages During a backup or restore, the NMDA software records the NMDA error messages in an error log file in binary format on the database or application server host. You can set the NSR_DIAGNOSTIC_DEST parameter to specify the directory location of all the NMDA log files, including debug, operations, and error logs. NSR_DIAGNOSTIC_DEST on page 352 provides details. If the NSR_DIAGNOSTIC_DEST parameter is not set, the error log file is located in the following default directory: On UNIX: /nsr/apps/logs On Windows: NetWorker_install_path\apps\logs A separate error log is generated for each different application involved in the NMDA backups and restores. The error log file has the following filename: nmda_app.messages.raw where app indicates the type of application: db2 informix lotus oracle sybase NMDA generates error messages in the nmda_app.messages.raw file in a language-independent binary form, readable by the nsr_render_log program only. The EMC NetWorker Administration Guide provides information on how to use the nsr_render_log program to read any language-independent binary file, such as nmda_app.messages.raw. The debug log file does not contain the database or application server errors. To obtain more debug information for a backup or restore, set the parameter NSR_DEBUG_LEVEL to an appropriate value to generate the required level of debugging information in the debug log. General troubleshooting tips on page 394 provides more information. The following sections provide details on application-specific error messages that NMDA generates: DB2-specific error messages on page 400 Lotus-specific error messages on page 409 Lotus-specific error messages on page 409 Oracle-specific error messages on page 413 Sybase-specific error messages on page 427 398 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages DB2-specific troubleshooting tips and error messages These sections provide general information on NMDA troubleshooting tips and error messages: General troubleshooting tips on page 394 NMDA error messages on page 398 Refer to the following sections for additional DB2-specific troubleshooting information and error messages. DB2-specific troubleshooting tips Review the following subsections for DB2-specific troubleshooting tips. DB2-specific log files Log files that can be useful for troubleshooting and diagnostic purposes are recorded on the DB2 server host (NetWorker client). Debug log files on page 396 provides information on the NMDA debug logs. The following files are used as additional DB2 logs for specific purposes: Wizard log: nsrdb2ra.log PowerSnap catalog pruning logs (Linux and AIX operating systems only): nsrdb2cat.log nsrdb2acs.log DB2-specific example problems The following subsections provide DB2-specific troubleshooting examples. Note: The NetWorker man pages, the EMC NetWorker Command Reference Guide, and the EMC NetWorker Administration Guide provide details on NetWorker commands. The backup fails The backup fails. A faulty record is written in the NetWorker media database and corrupt data is saved. Reason: The backup failed and did not roll back. Solution: The faulty record should be manually removed from the NetWorker database so the failed backup cannot be restored. To remove a failed backup: 1. On the NetWorker server, type the following command to view backup records for the DB2 server in the media database: $ mminfo -v -c client_name.mydomain.com where client_name.mydomain.com is the hostname of the DB2 server where the database resides. Note: In a cluster environment, use the virtual hostname. DB2-specific troubleshooting tips and error messages 399

Troubleshooting and Error Messages 2. Inspect the output of the mminfo command to determine if a save set was created for a failed backup and was not automatically removed by the server. Note the save set id (ssid). 3. Use the following command to remove the faulty save set from the media database: $ nsrmm -S ssid -d DB2-specific error messages The following subsections describe DB2 SQL error messages that are specific to DB2 operations with the NMDA software. The IBM DB2 reference documentation provides more information about SQL messages. The load libnsrdb2 command Table 37 on page 400 provides the path and suffix information for the load libnsrdb2 command. Use the path and suffix information in Table 37 on page 400 to determine the correct shared library for the operating system. Table 37 Path and suffix for the load libnsrdb2 command Operating system Path with suffix AIX /usr/lib/libnsrdb2.o HP-UX Linux, Solaris, HP-UX Itanium Microsoft Windows /usr/lib/libnsrdb2.sl /usr/lib/libnsrdb2.so NetWorker_install_path\bin\libnsrdb2.dll DB2 SQL messages! Table 38 on page 400 lists DB2 SQL error messages that are specific to DB2 operations with the NMDA software. IMPORTANT Identical messages are listed in the table for different causes. For these multiple listings, examine each cause. Table 38 DB2 SQL error messages (page 1 of 3) DB2 SQL message Explanation Cause Resolution SQL1268N A rollforward recovery stopped due to error "SQL1042" while retrieving log file <logfile> for database <db> on node "0". The NSR_ENCRYPTION_PHRASES parameter does not contain the datazone pass phrase that was used to back up the transaction logs. Change the parameter NSR_ENCRYPTION_PHRASES to include the datazone pass phrase that was used to back up the transaction logs. SQL2025N An I/O error "3" occurred on media "VENDOR". The client is not registered on the NetWorker server to which the NMDA software is backing up. Create a valid client on the NetWorker server. Test to ensure that the connection between the client and server is valid: save -s servername/testfile 400 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 38 DB2 SQL error messages (page 2 of 3) DB2 SQL message Explanation Cause Resolution SQL2025N An I/O error "3" occurred on media "VENDOR". The NSR_CLIENT parameter is set to an invalid client name while running a backup. Set the NSR_CLIENT parameter to the name of the client from which the backup is running. SQL2025N An I/O error "3" occurred on media "VENDOR". In the vendor configuration file, the NSR_DATA_VOLUME_POOL parameter is set to a pool name that does not exist, while attempting to run a backup If possible, remove the DB2 vendor.cfg file. Settings not to use for DB2 operations on page 355 provides details. Otherwise, do as follows: Create a pool to the same name that the NSR_DATA_VOLUME_POOL is set. Change the value of NSR_DATA_VOLUME_POOL to a valid pool. SQL2025N An I/O error "3" occurred on media "VENDOR". There is no NMDA license on the server. A separate client license is required for each client. Obtain a valid NMDA license. SQL2025N An I/O error "3" occurred on media "VENDOR". For a manual deduplication backup, the deduplication backup attribute is not enabled in the corresponding NetWorker Client resource. Ensure that the corresponding NetWorker Client resource is defined on the NetWorker server and the deduplication backup attribute is enabled. SQL2025N An I/O error "3" occurred on media "VENDOR". For a manual or scheduled deduplication backup, the Avamar server is already in maintenance mode before the backup starts. Ensure that the Avamar server is available for the backup operation. SQL2025N An I/O error "25" occurred on media "VENDOR". The NSR_ENCRYPTION_PHRASES parameter does not contain the datazone pass phrase that was used to back up the database. Change the parameter NSR_ENCRYPTION_PHRASES to include the datazone pass phrase that was used to back up the database. SQL2025N An I/O error "25" occurred on media "VENDOR". The user does not have the restore privilege on the NetWorker server. Add the "recover local data" privilege for the user. SQL2025N An I/O error 25 occurred on media VENDOR. For the restore of a deduplication backup, the Avamar server is already in maintenance mode before the restore starts. Ensure that the Avamar server is available for the restore operation SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.so". Reason code: "0". Permissions or ownership of debug files are incorrect for the database instance. Ensure that each database instance has a unique debug filename. SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.so". Reason code: "4". Table 37 on page 400 provides the correct libnsrdb2 path and suffix information. The NSR_CLIENT parameter was set to an incorrect client name while running a restore. Set the NSR_CLIENT parameter to the name of the client from which the restore is running. SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.so". Reason code: "4". Table 37 on page 400 provides the correct libnsrdb2 path and suffix information. The client is not registered on the NetWorker server to which the module is restoring. 1. Create a valid client on the NetWorker server. 2. Test to make sure the connection between the client and server is valid: save -s servername/testfile DB2-specific troubleshooting tips and error messages 401

Troubleshooting and Error Messages Table 38 DB2 SQL error messages (page 3 of 3) DB2 SQL message Explanation Cause Resolution SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.o". Reason code: "11" No matching backups found. Restore of the deduplicated save set failed because the save set on the Avamar server was deleted. Restore the save set to the Avamar server prior to restoring the deduplicated save set. SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.so". Reason code: "11". A valid timestamp for the object being restored was not specified. Or: Failed to restore a database from one instance to another. The Applications Information attribute in the Client resource is missing instance information. Specify a valid timestamp. Or: Specify Applications Information: DB2_R=database_name: db2inst1:db2inst2: Recover DB2 data to the same instance on page 170 provides details. SQL2062N An error occurred while accessing media "/usr/lib/libnsrdb2.so". Reason code: "11". Table 37 on page 400 provides the correct libnsrdb2 path and suffix information. The NSR_SERVER parameter is set to an invalid server name. For example, the server might not exist and you cannot ping it. Set the NSR_SERVER parameter to a valid NetWorker server that has the DB2 server defined as a client. SQL2062N An error occurred while accessing media "libnsrdb2.o". Reason code: "25" Unable to back up the database_name database due to backup request failure. The BRC API call pb_open failed. Deduplication backup is supported only for serverless backups. Perform a serverless type of backup for the PowerSnap deduplication backup of the database. SQL2071N An error occurred while accessing the shared library. "c:\progra~1\legato\nsr\bin\libnsrdb2.dll". Reason code: "1". Missing NMDA DB2 library, libnsrdb2.dll, is not in the correct place as indicated. Reinstall NMDA, or place the libnsrdb2.dll library into the correct location as indicated. SQL2071N An error occurred while accessing the shared library "/usr/lib/libnsrdb2.so". Reason code: "2". Table 37 on page 400 provides the correct libnsrdb2 path and suffix information. An error message occurs when you use: 32-bit NMDA software to back up a 64-bit database. 64-bit NMDA software to back up a 32-bit database. Use the correct version of NMDA for the database. For example, a 64-bit version of NMDA is required to back up a 64-bit database. SQL2079N On Windows, the backup fails for DB2 v9.5: An error was reported by the shared library: "c:\progra~1\legato\nsr\bin\libnsrdb2.dll". Return code: "30". The stack size is insufficient for the db2syscs.exe file. Increase the stack size as follows: 1. Stop the database engine with the db2stop command. 2. Use the db2hdr.exe utility to increase the stack size to a minimum of 512, for example: C:\Program Files\IBM\SQLLIB\BIN>..\misc\db2hdr db2syscs.exe /s 512,32 3. Start the database engine with the db2start command. SQL2079N An error was reported by the shared library during an attempted recovery: /usr/lib/libnsrdb2.so. Return code 30. The VENDOROPT parameter is null. Assign the VENDOROPT parameter a value that points to the nmda_db2.cfg file, for example: db2 update db cfg using vendoropt @/db/nmda_db2.cfg SQL2079N An error was reported by the shared library "/usr/lib/libnsrdb2.so". Return code: "30". The configuration file is not found for either backup or recovery. Specify the correct pathname for the NMDA DB2 configuration file (nmda_db2.cfg). 402 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Informix-specific troubleshooting tips and error messages These sections provide general information on NMDA troubleshooting tips and error messages: General troubleshooting tips on page 394 NMDA error messages on page 398 Refer to the following sections for additional Informix-specific troubleshooting information and error messages. Informix-specific troubleshooting tips Review the following subsections for Informix-specific troubleshooting tips. Informix-specific log files Log files that can be useful for troubleshooting and diagnostic purposes are recorded on the Informix server host (NetWorker client). Debug log files on page 396 provides information on the NMDA debug logs. Note: For Informix scheduled backups, the parameters NSR_DEBUG_LEVEL and NSR_DIAGNOSTIC_DEST must be set in the NMDA configuration file. For Informix manual backups, the parameters must be set as environment variables in the system environment. Multiple servers configured for backing up an Informix server instance An Informix Dynamic Server instance cannot be configured for backups by multiple NetWorker servers. Configuring more than one NetWorker server to back up the same Dynamic Server instance produces unexpected results: Logical log backups spread across multiple NetWorker servers might render one or more dbspaces unrecoverable. Scheduled backups started by multiple NetWorker servers that attempt to access the same Dynamic Server instance at the same time will fail. For example, suppose you configure one NetWorker server to perform a scheduled backup of selected dbspaces from a Dynamic Server instance named venus on the system mars at 2 A.M. Then you configure a different NetWorker server to back up the remaining venus dbspaces at 4 A.M. The first NetWorker server runs out of tapes at 2:15 A.M., stalling the backup and leaving the ON-Bar backup processes waiting. At 4 A.M., the second NetWorker server s scheduled backup begins. Because the Dynamic Server instance venus is still locked by the first NetWorker server s savegroup, the second NetWorker server s savegroup fails, generating an ON-Bar error code 131. NetWorker Savegroup: (notice) DBMI completed, 1 client (mars Failed) Start time: Tue Nov 24 04:00:01 2009 End time: Tue Nov 24 04:07:47 2009 --- Unsuccessful Save Sets --- * mars:informix:/venus onbar returned status of 131 * mars:informix:/venus /usr/sbin/nsrdasv exiting. The ON-Bar error code 131 indicates that a problem occurred during the exchange of backup or restore data for dbspaces, blobspaces, or logical logs between ON-Bar and the Informix Dynamic Server database server. The ON-Bar activity log (BAR_ACT_LOG file) might contain more information about the error. Informix-specific troubleshooting tips and error messages 403

Troubleshooting and Error Messages To resolve the problem, restart the failed backup and reconfigure future backups so that all objects for an Informix Dynamic Server instance are backed up to only one NetWorker server. No dbspaces/blobspaces found to back up or restore If you attempt to back up a dbspace or blobspace that does not exist, the savegroup completion message indicates an ON-Bar error: * mars:informix:/venus/bogus_space onbar returned status of 147 The ON-Bar BAR_ACT_LOG file displays a related list of messages: 2009-11-27 12:56:24 15612 15606 WARNING: DB/BLOBspace bogus_space does not exist. 2009-11-27 12:56:24 15612 15606 ERROR: There are no DB/BLOBspaces to backup/restore You might also see these error messages if you attempt a point-in-time restore to a time period before the first dbspace backup for the instance occurred. To resolve the problem, ensure that you have the correct spelling, pathname, or point in time, then retry the backup or restore operation. Unable to open connection to server If you attempt to back up an Informix Dynamic Server instance that does not exist or is in offline mode during the backup, the savegroup completion message indicates an ON-Bar error: * mars:informix:/venus onbar returned status of 151 The ON-Bar BAR_ACT_LOG file displays a related list of messages: 2009-11-27 13:07:29 15671 15665 onbar -b -L 0 2009-11-27 13:07:29 15671 15665 ERROR: Unable to open connection to server. To resolve the problem, ensure that you have the correct spelling and pathname for the instance, check that the instance is in online mode, and then retry the backup. Default value assigned to LTAPEDEV causes failure Setting the LTAPEDEV configuration parameter in the ONCONFIG file to /dev/null causes logical logs to be erroneously marked as backed up (U-B----). This error occurs when the Dynamic Server switches to the next log before ON-Bar has a chance to send the logical log data to the NetWorker server. With the LTAPEDEV parameter assigned the value /dev/null, you can perform only whole system restores. If LTAPEDEV is undefined or set to /dev/null in the ONCONFIG file, an ON-Bar logical log backup returns the error code 131 and a message is sent to BAR_ACT_LOG: 2009-11-25 10:50:00 12441 12404 ERROR: Unable to start the logical log backup: Log backup to device /dev/null not allowed The NetWorker savegroup completion message also returns an error message: --- Unsuccessful Save Sets --- * mars:informix:/venus/rootdbs onbar returned status of 131 * mars:informix:/venus/rootdbs /usr/sbin/nsrdasv exiting. To ensure that your logical logs are successfully backed up, set the LTAPEDEV parameter in the ONCONFIG file to anything other than /dev/null. 404 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Media required for restore is missing or damaged If the media required for an ON-Bar restore is missing or damaged, you can still recover data. The method available depends on whether you have the NetWorker cloning option enabled for the backup group: If cloning is enabled in the NetWorker Group resource for the backup group configured for the Dynamic Server, NetWorker automatically retrieves the cloned media to complete the restore operation. If cloning is disabled, you can perform an ON-Bar point-in-time restore to a time close to the one you need. The following sources provide detailed instructions on how to perform a point-in-time restore: Chapter 4, Data Restore and Recovery Informix Dynamic Server Backup and Restore Guide ON-Bar status code 3 When NMDA is not properly enabled and a scheduled savegroup of Informix data attempts to run, the backup fails and the following message is returned in the savegroup completion notice: NetWorker Savegroup: (notice) DBMI1 completed, 1 client (mars Failed) Start time: Wed Nov 25 00:00:00 2009 End time: Wed Nov 25 00:01:20 2009 --- Unsuccessful Save Sets --- * mars:informix:/venus 1 retry attempted * mars:informix:/venus onbar returned status of 3 * mars:informix:/venus /usr/sbin/nsrdasv exiting. A message from the messages log file verifies the error: XBSA-1.0.1 dbmi-1.0 13158 Tue Nov 24 20:00:32 2009 _nwbsa_open_saveset_session: received a network error (Severity 5 Number 13): NetWorker Module has not been properly enabled. These messages indicate a licensing problem with the NetWorker server software and must be resolved on the NetWorker server before the database data can be backed up. There are three possible causes for the error messages: The NetWorker server does not have TurboPak functionality. NMDA is not enabled. The wrong server operating system enabler code was used for the NMDA enabler. Enabling the NetWorker module The NetWorker module enabler comes in both Microsoft Windows and UNIX versions. In the Registration Window, both appear as follows: NetWorker Module for Databases and Applications If you are evaluating the NetWorker server software, you do not need any enabler codes. If you have entered an enabler code on the NetWorker server, you must also enter an enabler code for the NetWorker module. If you have purchased the NetWorker module, follow the instructions on the Enabler Certificate. If you do not have an Enabler Certificate for the NetWorker module, you may use the temporary enabler code listed in the media kit roadmap to evaluate the software for 45 days. After this evaluation period, or after you have decided to purchase the module, contact the EMC Sales Representative to purchase a permanent enabler code. Informix-specific troubleshooting tips and error messages 405

Troubleshooting and Error Messages! IMPORTANT Enter the correct temporary enabler code for the NetWorker server operating system. Ensuring the NetWorker module is enabled for the correct server operating system If you enter the Windows version of the NetWorker module enabler code on a UNIX NetWorker server or the UNIX version of the enabler code on a Windows NetWorker server, neither will function. Although the name attribute of the License resource is identical for both Windows and UNIX servers, the license type attribute is different. To view the license type attribute associated with the enabler code you are attempting to use, issue the following command and replace enabler_code with the actual enabler code: nsrcap -vn -c enabler_code The nsrcap command must be executed from the directory where it is physically located or it must be in the user search path. The default location of the nsrcap command for Windows systems is NetWorker_install_path\bin. For UNIX systems, the default location is /usr/bin or /usr/sbin. The Windows enabler code generates output similar to the following: Read an enabler: name: Application Interface for Informix enabler code: f06b72-bb0c35-76d3ba license type: Z11 expires: 45 days nsrcap: License enabler code is valid. The UNIX enabler code generates output similar to the following: Read an enabler: name: Application Interface for Informix enabler code: cc494e-872811-52f796 license type: D11 expires: 45 days nsrcap: License enabler code is valid. For Windows, the license type attribute is Z11, while for UNIX the license type attribute is D11. If you have an enabler code that is not for the operating system that the NetWorker server is running, contact EMC Customer Service. Informix-specific error messages The following describes error messages that you might encounter while using the NMDA software for Informix operations, and the possible resolutions for the errors. ON-Bar messages When ON-Bar encounters an error or condition that requires a warning, it writes a message to the assigned message file. The default message file for ON-Bar is $INFORMIXDIR/bar_act.log. The ON-Bar documentation provides more details on ON-Bar messages. 406 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Lotus-specific troubleshooting tips and error messages These sections provide general information on NMDA troubleshooting tips and error messages: General troubleshooting tips on page 394 NMDA error messages on page 398 Refer to the following sections for additional Lotus-specific troubleshooting information and error messages. Lotus-specific troubleshooting tips Review the following subsections for Lotus-specific troubleshooting tips. Lotus-specific log files Log files that can be useful for troubleshooting and diagnostic purposes are recorded on the Lotus server host (NetWorker client). Debug log files on page 396 provides information on the NMDA debug logs. The NMDA Lotus wizard generates messages in the nsrlotusra.log file. In the backup catalog file on the Domino or Notes host, NMDA records information about each file backed up. The NSR_CATALOGFILE parameter specifies the complete pathname of the backup catalog file. If the specified file cannot be accessed, NMDA attempts to write the information to the NetWorker applog file on the client. If the NetWorker applog file cannot be accessed, NMDA writes the information to /tmp/applog (UNIX and Linux) or C:\Temp\applog (Windows), by default. "Invalid Time Specified" error If you attempt to restore files by using the European date format (dd/mm/yy), an Invalid Time Specified error appears. The nsrnotesrc command is unable to interpret European date formats. When restoring files with the nsrnotesrc command, the date specified for the NSR_RECOVER_TIME parameter must be in the American format (mm/dd/yy). For example, to restore files from a save set that is timestamped 11/26/09 15:08:34, ensure that the NMDA configuration file contains the following parameter settings: NSR_BACKUP_PATHS = /notes/names.nsf NSR_RECOVER_TIME = "11/26/09 15:08:34" NSR_SERVER = spain Backup failure caused by time conversion An NMDA Lotus backup fails when there is a problem with the time conversion or when opening the file to obtain the modification times. On Windows, the date and time formats (including DateOrder and DateSeparator) are read from the country settings specified on the operating system level. On UNIX and Linux, the Domino server ignores these settings in the locale that would affect the format used to display a date or time or both, and instead uses defaults that are coded in the appropriate.res files. Lotus-specific troubleshooting tips and error messages 407

Troubleshooting and Error Messages The following notes.ini settings on the Domino server can be used to overwrite these defaults: DateOrder May be set to DMY, YMD, MDY ClockType May be set to 24_HOUR DateSeparator May be set to an arbitrary string and may be longer than one character, if required. TimeSeparator May be set to an arbitrary string and may be longer than one character, if required. The Domino Administrator Help provides additional information. Restore problem due to NSR_BACKUP_PATHS on a partitioned Domino server If the restore parameter NSR_BACKUP_PATHS is set to the value NOTES: for a partitioned Domino server or multiple Domino installations on a single UNIX host, the NMDA software attempts to restore the data for all the partitions or Domino installations, which can cause data corruption. Do not set the NSR_BACKUP_PATHS parameter to the keyword NOTES:. Instead, set the parameter to a specific pathname. NSR_BACKUP_PATHS on page 364 provides more details on the restore parameter. Failure of a document-level recovery on a remote Domino server The NMDA software does not support document-level recovery on a remote Domino server through the nsrdocrc command. On Windows only, the NMDA software supports document-level recovery of selected (modified) and deleted Notes documents on a remote Domino server through the Notes client program. If a remote document-level recovery through the Notes client program fails with an "Authentication failure" error, ensure the following: The user that runs the Notes client on the local host is: Listed in the Remote Access attribute in the NetWorker Client resource of the remote Domino server. Granted administrative privileges on the remote Domino server. A NetWorker Client resource is configured on the same NetWorker server for the host where the Notes client program runs. 408 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Lotus-specific error messages This section describe error messages that you might encounter while using the NMDA software for Lotus operations, and the possible resolutions for the errors. The NMDA programs for Lotus backups and restores generate error messages in the following format: error_message_text (function_name error_type error_code error_number) where: error_message_text is the text of the NMDA error message, as shown in the following tables: Table 39 on page 409 Table 40 on page 410 function_name is the name of the NMDA function that generated the error message. error_type, error_code, error_number are internal numbers representing an error type or code to report to technical support, reached through EMC Customer Service at the EMC Powerlink website. Certain fields might be null or 0 if the information was not available at the time when the error message was generated. Error messages from Lotus backups Table 39 on page 409 lists errors messages generated by the NMDA software during a Lotus backup, in alphabetical order. Note: The following error messages are those that require additional explanation. Table 39 Error messages from Lotus backups (page 1 of 2) Error message A NW server with a NSR client resource for hostname could not be located on the network. Could not open file: filename. Directory link points to its own directory. Duplicate entry: file_pathname. Ignoring. Either nothing was specified to backup or system is down. Error finding last backup instance for filename; error = error_description. Description The NMDA software cannot access the NetWorker server for the backup. To resolve the error, ensure that the NetWorker server name is spelled correctly and the server contains a Client resource for the NMDA client. The NMDA software cannot open the file to back it up. To resolve the error, ensure that the file has the correct permissions. The NMDA software has detected a circular link. To resolve the error, delete the directory link file or correct the path set in the file. The NMDA software is not adding another entry for the file to the backup list because the file is already on the list. This is an informational message only, and does not require a resolution. The NMDA software cannot derive a list of files to back up. To resolve the error, ensure that the ad hoc or scheduled backup is configured and performed correctly, according to the instructions in this administration guide. The NMDA software cannot find an existing backup for the file, and performs a full backup of the file. This error typically occurs during an incremental backup. To resolve the error, ensure that the NetWorker server is up and accessible to the Lotus user on the client computer. Lotus-specific troubleshooting tips and error messages 409

Troubleshooting and Error Messages Table 39 Error messages from Lotus backups (page 2 of 2) Error message Failed to build exclude list, ignoring exclude list entries. Failed to open directory link file: filename, errno = error_number. Failed to open exclude list file, errno = error_number. pathname is not a directory. The call to NotesInitExtended failed: Notes_API_error_number. The LoadLibrary() call failed. The password file lookup for the user Notes_user failed. The user name may be invalid. The ReadFile() call failed. Description The NMDA software cannot correctly process the values specified with the NSR_EXCLUDE_FILE or NSR_EXCLUDE_LIST parameter, so nothing is excluded from the backup. To resolve the error, ensure that the parameters specify the correct values. The NMDA software cannot open the file. To resolve the error, ensure that the file has the correct pathname or permissions or both. The exclude list file does not exist or does not have the correct access permissions. To resolve the error, ensure the following: The correct pathname is specified for the exclude list file with the NSR_EXCLUDE file parameter. The exclude list file has the correct permissions. The pathname contained in the Domino directory link (.dir) file is not a directory. To correct the error, delete the.dir file from the directory if it is not used. The NMDA software cannot initialize the Notes session. To resolve the error, locate the error message for the given Notes_API_error_number and perform the appropriate corrective action. If the error number is 421, set the NSR_NOTES_INI_PATH parameter. The NMDA software cannot find or load the libnotes.xx or nnotes.dll library file. To resolve the error, ensure that the Notes_ExecDirectory parameter is set to the directory path containing the Lotus library. An invalid Notes user is specified with the LOTUS_USER parameter. To resolve the error, ensure that the LOTUS_USER parameter specifies the name of a Lotus Notes user that is running the server to be backed up. The NMDA software cannot read the contents of a file to be backed up. To resolve the error, ensure that the file is a readable file. Error messages from Lotus recoveries Table 40 on page 410 lists errors messages generated by the NMDA software during a Lotus recovery, in alphabetical order. Table 40 Error messages from Lotus recoveries (page 1 of 2) Error message Full backup not found, cannot recover without full backup filename. No objects found for recover. The list of items to recover includes Notes databases. NSR_NO_NOTES_INIT parameter cannot be used when recovering Notes databases. Description The NMDA software cannot find a full backup for the file in the NetWorker index. To resolve the error, ensure that the path for the filename matches the case-sensitive path in the NetWorker index. Either nothing is specified for recovery or the specified items have been removed from the recovery list. To resolve the error, perform one of the following: Specify the required items for recovery. Set the parameter NSR_RELOCATION_DEST to enable relocated recovery, or set NSR_RECOV_INTERACT to y or r to enable renaming of the file. The NSR_NO_NOTES_INIT parameter is specified during a database recovery. To resolve the error, specify either the NSR_NO_NOTES_INIT parameter or a list of databases (not both) for the recovery. The NSR_NO_NOTES_INIT parameter is used for a disaster recovery only. 410 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 40 Error messages from Lotus recoveries (page 2 of 2) Error message The log directory may only be number characters in length. The recover time '-t' was either not specified or contained an invalid value. Description The log directory pathname specified with the NSR_LOG_DIR parameter is too long. To resolve the error, specify a different (shorter) pathname with the NSR_LOG_DIR parameter. During a document-level recovery, the mandatory -t option is not correctly specified with nsrdocrc command. To resolve the error, specify the -t time option correctly by using the nsr_getdate() format for the time. To recover the backup to the current time, use the -t now option. Lotus-specific troubleshooting tips and error messages 411

Troubleshooting and Error Messages Oracle-specific troubleshooting tips and error messages These sections provide general information on NMDA troubleshooting tips and error messages: General troubleshooting tips on page 394 NMDA error messages on page 398 Refer to the following sections for additional Oracle-specific troubleshooting information and error messages. Oracle-specific troubleshooting tips Review the following subsections for Oracle-specific troubleshooting tips. Diagnosing Oracle-specific problems In addition to General troubleshooting tips on page 394, use the following list to troubleshoot problems in running NMDA Oracle backup and restore operations: Without NMDA 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. On UNIX or Linux, ensure that the correct libnsrora.* library file is linked according to the linking commands in the EMC NetWorker Module for Databases and Applications Installation Guide. Compare the library file with the libnsrora.* file in the NMDA software package; the two files should be identical. Ensure that Oracle is not linked to the wrong libnsrora.* or other library file. Perform a manual Oracle backup by using NMDA and the proper RMAN script. Set the required NMDA parameters in either the RMAN backup script or the rman send command on the operating system command line. Appendix A, NMDA Parameters for Backups and Restores, provides details on how to set the parameters. RMAN scripts for manual backups on page 103 provides a simple startup RMAN script. If the manual backup fails, check the debug files for NMDA and the NetWorker server. Oracle-specific log files on page 413 provides more details. If the backup fails with the following error, ensure that both NMDA 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 Perform a scheduled Oracle backup by using NMDA and the proper RMAN 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 105. 412 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Oracle-specific log files Log files that can be useful for troubleshooting and diagnostic purposes are recorded on the Oracle server host (NetWorker client). Debug log files on page 396 provides information on the NMDA debug logs. The following files are used as additional Oracle logs for specific purposes: Wizard log nsrorara.log PowerSnap log nsroraclecat.log Oracle-specific error messages The following sections provide details on error messages that you might encounter during NMDA backups or restores of Oracle data. RMAN error messages Note: If the scheduling portion of an Oracle scheduled backup succeeds but the actual backup fails, error messages and debug information might be generated in the locations described in this section. 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 NMDA configuration file. Setting the NMDA parameters for Oracle operations on page 368 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 NMDA 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. NMDA Oracle error messages The NMDA Oracle error messages can be grouped into categories, according to the program that generates the message and the message format: Error messages from the libnsrora library on page 414 Error messages from the nsroraadmin program on page 422 Error messages from the nsrorainfo program on page 424 Oracle error messages from the nsrdaprobe program on page 425 Error messages from the nsrdasv program on page 426 Oracle-specific troubleshooting tips and error messages 413

Troubleshooting and Error Messages Error messages from the libnsrora library Table 41 on page 414 lists error messages generated by the libnsrora library, in alphabetical order. Note: The library name libnsrora 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 NMDA 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 41 Error messages from the libnsrora library (page 1 of 8) 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) 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 Could not find the nsrsnapck binary. Could not locate the LNM save file 'backup_piece_name' on server 'server'. NMDA 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. NMDA failed to create the lock file required for an index deletion operation. This is an internal XDR error caused by a network read or write operation. This is an internal XDR error caused by a network read or write operation. This is an internal XDR error caused by a network read or write operation. During an index removal for a proxy backup, NMDA could not locate the nsrsnapck binary, which is probably in a nondefault location. NMDA could not locate an index record for the backup piece. The index record is probably missing. 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. Report the error to Technical Support. Report the error to Technical Support. 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. 414 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 2 of 8) Error message Description Resolution Could not locate the LNM save time 'save_time' on server 'server'. Could not lock 'filename' for index deletion. There were number attempts. (errno) Could not lstat - filename Could not lstat secondary link - filename Could not obtain NSR_ORACLECAT_MODE from NWORA resource file. Could not read link - pathname Direct saves are not enabled. Error creating staging directory 'directory'. Error in mmdb lookup by time: reason 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. NMDA could not locate an index record for the save time in the client file index. The index record is probably missing. NMDA 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. The lstat() system call failed. The file filename either did not exist or had invalid permissions. 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. 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. A proxy backup failed due to the pathname that was an invalid symbolic link. NMDA attempted to connect to an old release of NetWorker server software that is no longer supported. During a proxy restore of a regular file, the permissions of the destination directory were possibly invalid. NMDA was not able to create the required staging subdirectory,.nworapc. A lookup in the media database failed for the given reason. NMDA could not contact the NetWorker index service nsrindexd. This was probably caused by the NetWorker services being shutdown. After a maximum of five attempts, NMDA 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, NMDA failed to call the NetWorker core function, nsr_start(). This was probably caused by the NetWorker services being shut down. 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. NWORA resource file on page 310 provides 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 NMDA. 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. Restart the NetWorker services on the server, as required. Restart the NetWorker services on the server, as required. Restart the NetWorker services on the server, as required. Oracle-specific troubleshooting tips and error messages 415

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 3 of 8) Error message Description Resolution Invalid browse and retention policies. Values Ignored. Invalid browse policy browse_time. Value Ignored. Invalid KEY word Invalid retention policy: retention_time. Value Ignored. Invalid source path argument NSR_DATA_VOLUME_POOLn is not set. 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) Oracle pools are not supported Path pathname is too long. pb_init() failed with (reason): invalid BRCAPI version Proxy copy is not supported. 'string' should be in format: KEY=(xxxxx) The ASDF body could not be unwrapped. 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. The syntax of the string in the RMAN send command was incorrect. The NSR_SAVESET_RETENTION parameter had an invalid time value, retention_time. A proxy backup failed due to an invalid source pathname. 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. 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 NMDA backup failed because a valid NWORA resource file does not exist or is not available. NMDA does not support Oracle pools. NMDA supports NetWorker pools only. A proxy backup failed because the given pathname exceeded the limit of 1,024 bytes. The version number of the BRC API that was reported by the PowerSnap Module was corrupted. A proxy operation was attempted on a platform that NMDA does not support for proxy operations. The syntax of the string in the RMAN send command was incorrect. The incoming recover stream of data could not be decoded due to a possible network error or data corruption. 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 379 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 351 provides more information. Report the error to Technical Support. If you do not use the wizard to configure a scheduled backup with save set bundling, use the nsroraadmin command to create a valid NWORA resource file, according to instructions in Chapter 2 or 8 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 page 378 provides more information. Ensure that any pathname involved in a proxy backup does not exceed 1,024 bytes. Report the error to Technical Support. Do not attempt a proxy operation on an unsupported platform. The EMC Information Protection Software Compatibility Guide on the Powerlink website provides details on supported platforms. The send command on page 379 provides the correct send command syntax. Report the error to Technical Support. 416 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 4 of 8) Error message Description Resolution 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 The current time could not be obtained (errno). The data could not be XDR'd from the stream. 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'. NMDA 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(), failed due to the given reason. 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 call failed due to the given reason. During a proxy operation, a pb_status() function call failed due to the given reason. During a proxy operation, a pb_status() function call failed due to the given reason. The operating system filename specified for a proxy operation was not a valid pathname. NMDA could not obtain the current time due to an operating system error. The incoming recover stream of data could not be decoded due to a possible network error or data corruption. The file filename involved in a proxy backup was not recognized as a regular file or raw volume. For proxy backups, NMDA 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. 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. Report the error to Technical Support. Report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical 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. 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. Oracle-specific troubleshooting tips and error messages 417

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 5 of 8) Error message Description Resolution 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 NMDA 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. 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. During a restore, a call of the NetWorker core function, nsr_bind_recov_mm(), failed due to the given reason. A call of the NetWorker core function, nsr_end(), failed due to the given reason. During a restore, a call of the NetWorker core 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. NMDA 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. NMDA release 1.0 does not support the PowerSnap Module release that was used for a proxy operation. The name of the NetWorker client could not be determined. The name of the NetWorker server could not be determined. 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. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Report the error to Technical Support. Report the error to Technical 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. Ensure that a supported release of the PowerSnap Module is installed. The EMC Information Protection Software Compatibility Guide on the Powerlink website provides details on supported releases. 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. 418 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 6 of 8) Error message Description Resolution The NSR_CLIENT parameter was not set. The NSR_DMO_BENCHMARK_1 parameter is no longer supported. The NSR_SERVER parameter was not set. The NW authentication for client 'client' was refused by server 'server' because 'reason'. The NW client has not been set. The NW server does not have a valid NMDA proxy copy license. The NW server has not been set. 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 nsroraadmin. The NWORA resource lock file does not exist. Please create it by running 'nsroraadmin -r list' The NWORA resource NSR_ORACLECAT_MODE is in the 'undetermined' state. The name of the NetWorker client could not be determined. The undocumented parameter NSR_DMO_BENCHMARK_1 was specified, but it is no longer supported. The name of the NetWorker server could not be determined. NMDA 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 name of the NetWorker client could not be determined. The NetWorker server attempted a proxy operation without the required license. The name of the NetWorker server could not be determined. This is an internal XDR error caused by a network read or write operation. 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. Set the parameter NSR_CLIENT to the NetWorker client name by using the send command. Do not set the unsupported parameter NSR_DMO_BENCHMARK_1. Set the parameter NSR_SERVER to the NetWorker server name by using the send command. Take the corrective action suggested by the error message. Set the parameter NSR_CLIENT to the NetWorker client name by using the send command. Ensure that the NetWorker server has the required license for the proxy operation. Set the parameter NSR_SERVER to the NetWorker server name by using the send command. Report the error to Technical Support. Create the NWORA resource file by using the nsroraadmin command, and restart the proxy backup. NWORA resource file on page 310 provides details. Create the NWORA resource lock file by using the nsroraadmin -r list command, and restart the proxy backup. NWORA resource file on page 310 provides details. Set the value of NSR_ORACLECAT_MODE to either enabled or disabled (as required) by using the nsroraadmin command. 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. 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 The parameter file cannot be open: filename During a scheduled proxy backup, the parameter ORACLE_SID was not set in the configuration file. This is an internal Oracle error caused by Oracle specifying the same filename twice during a proxy operation. 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. In the configuration file, set the parameter ORACLE_SID to the SID value of the Oracle database. Report the error to Technical Support. Ensure that the value specified by the parameter NSR_PROXY_PFILE is a valid pathname of the configuration file. Oracle-specific troubleshooting tips and error messages 419

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 7 of 8) Error message Description Resolution 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 savefile_fini() call failed. reason 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 pb_cancel() function call failed during a proxy operation. The pb_inquiry() function call failed during a proxy operation. The pb_inquiry() function call failed during a proxy operation. The pb_inquiry() function call failed during a proxy operation. The pb_restore() function call failed during a proxy operation. The pb_save() function call failed during a proxy operation. The pb_snapshot() function call failed during a proxy operation. NMDA 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, NMDA 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. During a restore, a call of the NetWorker core function, savefile_fini(), failed due to the given reason. During a proxy restore operation, NMDA was unable to determine where to restore the file. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Restart the NetWorker services, and run the nsrck program to resolve any corruption of the indexes. Use the mminfo and nsrinfo commands to verify 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. Take the corrective action suggested by the error message. If required, report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. 420 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 41 Error messages from the libnsrora library (page 8 of 8) Error message Description Resolution 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 SBTPC object 'object_name' is entering the SBTPCSTART restore state but its BRC type is: type The SBTPC object 'object_name' is entering 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 SBTPC object 'object_name' is leaving the BRC save state but its status is: status The proxy backup or restore of a file failed during a PowerSnap Module operation, for the given reason. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. The SBTPC object 'object_name' is leaving the BRC snapshot state but its status is: status During a proxy operation, NMDA and the PowerSnap Module became unsynchronized as to the status of the object object_name. Report the error to Technical Support. 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. The sfhead could not be XDR'd. 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 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 The PowerSnap Module terminated the proxy operation. This is an internal Oracle error that occurred during a proxy restore. This is an internal XDR error caused by a network write operation. 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, NMDA was unable to write to the staging directory, directory. The errno is the error number from the function call that failed. This is an internal XDR error caused by a network read or write operation. This is an internal error during a proxy operation caused by Oracle expecting more files to be processed whereas NMDA has completed its file processing. This is an Oracle error caused by Oracle specifying the same backup piece name twice during a proxy operation. Examine the PowerSnap Module logs for a possible reason for the termination. Report the error to Technical Support. Report the error to Technical Support. 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. Report the error to Technical Support. Report the error to Technical Support. Report the error to Technical Support. Oracle-specific troubleshooting tips and error messages 421

Troubleshooting and Error Messages Error messages from the nsroraadmin program Table 42 on page 422 lists error messages generated by the nsroraadmin program, in alphabetical order. The error messages appear in the following format: nsroraadmin: error_message where error_message is the text of the error message, as shown in the table. Table 42 Error messages from the nsroraadmin program (page 1 of 3) Error message Description Resolution Command line arguments are not understood. Could not create the NWORA resource file (errno) Could not create the NWORA resource lock file (errno) Could not open resource file 'filename' (errno). No command line parameters are set. NSR_ORACLECAT_MODE can only be set to 'enabled', 'disabled' or 'undetermined'. 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. The '-r' flag cannot be set multiple times. The '-r' option requires an NWORA resource specification. The nsroraadmin command included one or more invalid options. The nsroraadmin command could not create the NWORA resource file, possibly due invalid permissions. The nsroraadmin 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 resource file. The nsroraadmin command could not open the NWORA resource file, possibly due invalid permissions. The nsroraadmin command options were missing. In the nsroraadmin command, the NSR_ORACLE_CAT_MODE parameter resource was set to a value other than enabled, disabled, or undetermined. In the nsroraadmin command, the NSR_REMOVE_ON_FAILURE parameter resource was set to a value other than TRUE or FALSE. In the nsroraadmin command, an NWORA parameter resource name and value were not specified in the correct format. In the nsroraadmin command with the -r delete option, the SID value of an Oracle database was not specified. The nsroraadmin command contained more than one -r option. The nsroraadmin command with the -r option did not include the required resource specification. Use the nsroraadmin command with the correct options. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. Ensure that valid permissions exist to allow the nsroraadmin command to create the NWORA resource file. NWORA resource file on page 310 provides details. Report the error to Technical Support. Verify that the NWORA resource file exists and has valid permissions. If required, create or repair the file by using the nsroraadmin command, or modify the file permissions. Use the nsroraadmin command with the correct options. In the nsroraadmin command, set the NSR_ORACLE_CAT_MODE parameter resource to enabled or disabled for instant backups. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. In the nsroraadmin command, set the NSR_REMOVE_ON_FAILURE parameter resource to either TRUE or FALSE only. In the nsroraadmin command, specify the NWORA parameter resource name and value in the correct format. In the nsroraadmin command with the -r delete option, specify the correct SID value. Use the nsroraadmin command with only one -r option. In the nsroraadmin command with the -r option, specify the required resource name and value. 422 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 42 Error messages from the nsroraadmin program (page 2 of 3) Error message Description Resolution 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. In the nsroraadmin command, the -r option did not include one of the required keywords: add, update, list, or delete. The NWORA resource file is probably corrupted. The NWORA resource file does not contain the mandatory NSR_NWPATH parameter resource. The file might be corrupted. In the nsroraadmin command, include one of the required keywords with the -r option. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. Verify the contents of the NWORA resource file. If required, repair the resource file by using the nsroraadmin command. Verify the contents of the NWORA resource file. If required, repair the resource file by using the nsroraadmin command. The NWORA resource file does not exist. The NWORA resource file does not yet exist. Create the NWORA resource file by using the nsroraadmin command. 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 information. The NWORA resource 'resource_name' is not a SID resource. The NWORA resource specified is not supported: resource_name = resource_value The NWORA SID resource for 'sid_value' already exists. The SID token 'connect' is an empty string. The SID token 'home' is an empty string. The SID token 'ORACLE_SID' is invalid. The SID token 'sid' is an empty string. The nsroraadmin command specified the name of a resource that does not exist in the NWORA resource file. 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 nsroraadmin command for creating or updating an NWORA SID resource was missing the required items. The nsroraadmin command with the -r delete option did not include a valid name of an NWORA SID resource. In the nsroraadmin command, an invalid name or value were specified for an NWORA parameter resource. The nsroraadmin command attempted to add an NWORA SID resource that already existed. The nsroraadmin command did not include the required pathname of the RMAN connection file with the connect keyword. The nsroraadmin command did not include the required pathname of the Oracle home directory with the home keyword. In the nsroraadmin command with the sid keyword, the specified SID value of the Oracle database was invalid. The nsroraadmin command did not include the required SID value of the Oracle database with the sid keyword. In the nsroraadmin command, specify a valid resource name from the NWORA resource file. Repair the NWORA resource file by using the nsroraadmin command. Repair the NWORA resource file by using the nsroraadmin command. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. In the nsroraadmin command for creating or updating an NWORA SID resource, include the required items. In the nsroraadmin command with the -r delete option, specify a valid name of an NWORA SID resource. In the nsroraadmin command, specify a valid name and value for an NWORA parameter resource. NWORA parameter resources on page 311 provides details. In the nsroraadmin command, specify the values for a new NWORA SID resource. In the nsroraadmin command, specify a valid pathname of the RMAN connection file with the connect keyword. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. In the nsroraadmin command, specify a valid pathname of the Oracle home directory with the home keyword. In the nsroraadmin command, specify a valid SID value with the sid keyword. In the nsroraadmin command, specify a valid SID value with the sid keyword. Oracle-specific troubleshooting tips and error messages 423

Troubleshooting and Error Messages Table 42 Error messages from the nsroraadmin program (page 3 of 3) Error message Description Resolution The tokens 'sid', 'home' and 'connect' must be set when adding a SID. The value of the NWORA resource is missing. Unrecognized argument 'option'. You must be the super-user to update the NWORA resource file. The nsroraadmin command to add an NWORA SID resource did not include the settings of the mandatory sid, home, and connect keywords. In the nsroraadmin command with the -r update option, the NWORA resource value was not specified with the resource name. The nsroraadmin command included the unrecognized option option. The nsroraadmin command was typed by the wrong user. In the nsroraadmin command to add an NWORA SID resource, include the settings of the sid, home, and connect keywords. In the nsroraadmin command with the -r update option, specify the NWORA resource value with the resource name. Use the nsroraadmin command with the correct options. Configuring the NWORA resource file with the nsroraadmin program on page 315 provides details. Type the nsroraadmin command as the root user on UNIX, or as a member of the Microsoft Windows Administrators group. Error messages from the nsrorainfo program Table 43 on page 424 lists error messages generated by the nsrorainfo program, in alphabetical order. The error messages appear in the following format: The NW volume information lookup failed: error_message where error_message is the text of the error message, as shown in the table. Table 43 Error messages from the nsrorainfo program (page 1 of 2) Error message Description Resolution 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'. Error in mmdb lookup by time: reason Exceeded the number of retries. The NetWorker server may be down or unreachable. The file 'filename' could not be opened. The file name provided is NULL. NMDA 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. NMDA could not locate an index record for the backup piece. The index record is probably missing. NMDA could not locate an index record for the save time in the client file index. The index record is probably missing. A lookup in the media database failed for the given reason. NMDA could not contact the NetWorker index service nsrindexd. This was probably caused by the NetWorker services being shutdown. The file specified with the -f option of the nsrorainfo command could not be accessed. In the nsrorainfo command, the -f option did not include the required filename. Take the corrective action suggested by the error message. Use the mminfo and nsrinfo commands to verify the status of the index record. Use the mminfo and nsrinfo commands to verify the status of the index record. Use the mminfo command to verify the status of the media database record. Take the corrective action suggested by the error message. Restart the NetWorker services on the server, as required. Ensure that the specified file exists, and then type the nsrorainfo command again with the -f option. In the nsrorainfo command, include the required filename with the -f option. 424 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 43 Error messages from the nsrorainfo program (page 2 of 2) Error message Description Resolution 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. NMDA could not locate backup_piece_name in the indexes due to the reason. The indexes might be corrupted. NMDA 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. NMDA located an index record in the client file index, but it had an unexpected save time. The indexes might be corrupted. 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. Take the corrective action suggested by the error message. Restart the NetWorker services, and run the nsrck program to resolve any corruption of the indexes. Oracle error messages from the nsrdaprobe program Table 44 on page 425 lists error messages generated by the nsrdaprobe program during Oracle operations, in alphabetical order. Table 44 Error messages from the nsrdaprobe program (page 1 of 2) Error message Description Resolution 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 nsrdaprobe command does not support databases with more than one sthread. The nsrdaprobe 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 NMDA probe did not contain the username or password. The nsrdaprobe program does not support a RAC database, where the database has multiple threads (instances). Ensure the following: The connection strings (database username and password), Oracle Net service name, and ORACLE_HOME value that nsrdaprobe 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 126 provides more information. Correct the Command Options attribute setting in the NetWorker Probe resource, according to Configure a probe-based backup on page 126. Edit the connection file to correct the problem. Do not use the nsrdaprobe program with a RAC database. Oracle-specific troubleshooting tips and error messages 425

Troubleshooting and Error Messages Table 44 Error messages from the nsrdaprobe program (page 2 of 2) Error message Description Resolution The nwora.res file has not been created. The v$database_incarnation SQL statement could not be run because: reason. ORACLE_SERVICE was set in the Command Options attribute in the NetWorker Probe resource, but the NWORA resource file did not exist. The nsrdaprobe program could not determine the database incarnation information due to the reason given in the error message. Create the NWORA resource file according to the information in Configure a probe-based backup on page 126. 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. Error messages from the nsrdasv program Table 45 on page 426 lists error messages generated by the nsrdasv program during Oracle operations, in alphabetical order. Table 45 Error messages from the nsrdasv program Error message Description Resolution 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 backup config did not contain a string. 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 NWORA resource file could not be backed up after a successful RMAN backup. ORACLE_HOME was not set properly in the configuration file. The nsrdasv program was run with the -C option, but the Backup Config attribute was not set properly in the Client resource. The nsrdasv program was run with the -C option, but the Backup Config attribute was not set properly in the Client resource. The scheduled backup binary, nsrdasv, could not create the file rman_script_path to write the RMAN script generated by the backup configuration wizard. 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 configuration file. 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. 426 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Sybase-specific troubleshooting tips and error messages These sections provide general information on NMDA troubleshooting tips and error messages: General troubleshooting tips on page 394 NMDA error messages on page 398 Refer to the following sections for additional Sybase-specific troubleshooting information and error messages. Sybase-specific troubleshooting tips Review the following for Sybase-specific troubleshooting tips. Sybase-specific log files Log files that can be useful for troubleshooting and diagnostic purposes are recorded on the Sybase server host (NetWorker client). Debug log files on page 396 provides information on the NMDA debug logs. Note: For Sybase backups, the NSR_DEBUG_LEVEL and NSR_DIAGNOSTIC_DEST parameters must be set in the NMDA configuration file. For Sybase restores, these parameters must be set in the environment or as nsrsybrc command options. NMDA uses an additional log file, xbsa.messages, on the Sybase host to record messages generated by the NetWorker X/Open Backup Services Application (XBSA) library, as described in NetWorker XBSA and libnsrsyb error messages on page 435. Diagnostic messages specific to Sybase software are recorded in following log files: ASE log file Sybase Backup server log file The Sybase documentation provides more details on these log files. Sybase-specific error messages The NetWorker error messages are displayed in the NetWorker administration program window. The display lists the messages encountered during the previous 24 hours. The messages are also written to NetWorker log file, daemon.raw. The EMC NetWorker Administration Guide provides more information on the daemon.raw log file and how to view its contents. The NetWorker error messages appear in the format: day hh:mm:ss daemon_or_program_name: message The NetWorker XBSA and libnsrsyb error messages are written to the xbsa.messages file. The libnsrsyb error messages are also reported to the Sybase Backup server, which prints them to the stdout file and logs them in the Sybase Backup server error log. Sybase-specific error messages can be grouped into the following categories, according to the type of message generated: Error messages from the nsrsybcc program on page 428 Error messages from the nsrsybrc program on page 429 Sybase-specific troubleshooting tips and error messages 427

Troubleshooting and Error Messages Error messages from the nsrdasv program on page 431 Sybase backup server and libnsrsyb error messages on page 433 NetWorker XBSA and libnsrsyb error messages on page 435 Error messages from the nsrsybcc program Table 46 on page 428 lists errors messages generated during Sybase consistency checking operations with the nsrsybcc program, in alphabetical order. Table 46 Error messages from the nsrsybcc program Error message CS-LIBRARY or CT-LIBRARY error: error_message. Operating system error number(n): error_message. error from server Sybase_server: Msg number, Level number, State number invalid check option -o value was supplied No database names were specified. no NetWorker server was specified non fatal internal error from server server_name: Msg number, Level number, State number path needs to begin with SYBASE:. The command line has the form SYBASE:/instance_name[/database_name] SQL Server server_name version is too old. It must be 11.0 or later, and it is version_number. the command line may specify the entire instance or a list of individual databases, but not both The command line specifies more than one Sybase instance. Only a single instance may be supplied with each command line. the database name database_name has a length greater than the maximum of 30 The instance name was not provided in the command line command_line_value. The command line has the form SYBASE:/instance_name[/database_name]. user name is required and was not supplied Description An error occurred in the Sybase Open Client library layer. The operating system part of the error message appears only if an operating system error occurred. These error messages normally appear when the master database is recovered because this operation shuts down the Sybase server, but they are not normal during other operations. The error message text describes the specific problem. The Sybase server returned an error. Check the error message that follows this message to determine the reason for the error. The database consistency check option that was supplied is not valid. Refer to the EMC NetWorker Module for Databases and Applications Command Reference Guide or to the nsrsybcc man page for a list of supported options. The nsrdasv, nsrsybrc, and nsrsybcc commands each operate on a database (or, for nsrsybrc and nsrsybcc, a list of databases). No database names were specified on the command line. The NetWorker server was not specified or could not be found. The NetWorker server to which the command is to be issued can be specified with the -s NetWorker_server option. The Sybase server returned a nonfatal error. This error does not stop the operation. Examine the message to ensure that the error does not lead to future problems. The database name option for the nsrsybcc program did not begin with the characters SYBASE:. All Sybase server save sets must begin with this name. NMDA is supported on SQL Server 11.x or later and Adaptive Server Enterprise 11.5 or later. Either the entire instance (SYBASE:/ASE_server_name) or a list of databases (SYBASE:/ASE_server_name/database_name1 SYBASE:/ASE_server_name/database_name2) can be specified at the command line. An instance name and a list of databases cannot be specified at the same time. Each invocation of the nsrdasv, nsrsybcc, or nsrsybrc program can operate on a single Sybase server because the user ID and password supplied are unlikely to be the same over multiple servers. Retry the command and run it once for each Sybase server. The database name supplied at the command line was longer than 30 characters. The maximum database name length is 30 characters. The database to be processed was specified as SYBASE:, but the instance name was not supplied. A username must be supplied for Sybase log in. This username can be queried from the Client resource in the NetWorker server, entered on the command line, or obtained from the environment variable, $USER. 428 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Error messages from the nsrsybrc program Table 47 on page 429 lists errors messages generated during Sybase restore operations with the nsrsybrc program, in alphabetical order. Table 47 Error messages from the nsrsybrc program (page 1 of 3) Error message cannot restore database database_name because it does not exist in instance_name cannot restore to the destination database database_name because it does not exist in the instance server_name CS-LIBRARY or CT-LIBRARY error: error_message. Operating system error number(n): error_message. error from server server_name: Msg number, Level number, State number Error from server server_name: Msg number, Level number, State number Login failed. CT-LIBRARY error: ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed. If master is being restored, no others can be restored in the same session. The database must be in master recover mode to recover master, and this precludes restoring any other database. if the destination is an instance, the source must be an instance, too Description The nsrsybrc command could not find a backup of the database specified for recovery. Run the nsrinfo command to see if a backup exists, and ensure that the user ID used for the nsrsybrc command matches the object owner that is displayed. Run the Sybase Backup server and the nsrsybrc and nsrdasv commands from the same user ID to avoid this problem. The database to which the nsrsybrc command is recovering does not exist. Create the database and try the nsrsybrc command again. An error occurred in the Sybase Open Client library layer. The operating system part of the error message is displayed only if an operating system error occurred. These error messages might appear when the master database is recovered because this operation shuts down the Sybase server, but they are not normal during other operations. The error message text describes the specific problem. The Sybase server returned an error. Check the error message that follows this message to determine the reason for the error. The Sybase server returned the login failure error due a connection problem. A list of databases to recover was specified, and the master database was listed along with others. Recovering the master database shuts down the Sybase server, which makes recovering other databases impossible. The -d destination option was used to specify a server instance, but the item to be recovered is a single database. Retry the command and specify the destination database. For example: nsrsybrc -U sa -P xxx -d SYBASE:/destination_server/destination_database SYBASE:/source_server/source_database Note: The Sybase server and database names are case-sensitive and must be in the same case as recorded in the NetWorker backup indexes. if the source is an instance, the destination must be an instance, too The object to be recovered is an entire Sybase server instance, but the destination specified to recover the instance to is a database name. Retry the command and specify the destination as an instance. For example: nsrsybrc -U sa -P xxx -d SYBASE:/destination_server SYBASE:/source_server Note: The Sybase server names are case-sensitive and must be in the same case as recorded in the NetWorker backup indexes. internal error. Full backup expected but not found. A full backup was found, but was then no longer available before the nsrsybrc command recovered the database. For example, this error occurs when the volume containing the full backup is manually relabeled at the same time the incremental backup that depends on that full backup is being recovered. Sybase-specific troubleshooting tips and error messages 429

Troubleshooting and Error Messages Table 47 Error messages from the nsrsybrc program (page 2 of 3) Error message invalid time specification: time value no NetWorker server was specified Non fatal internal error from server server_name: Msg number, Level number, State number path needs to begin with SYBASE:. The command line has the form SYBASE:/instance_name[/database_name] Recover option validation error. Recover option validation error. Recover option validation error. SQL Server server_name version is too old. It must be 11.0 or later, and it is version_number. Sybase server version version_number does not support the checkstorage option. Versions 11.5 and later support it the command line did not specify a database or an instance to restore The instance name was not provided in the command line command_line_value. The command line has the form SYBASE:/instance_name[/database_name]. there are no databases to restore in instance server_name there is no backup of the instance for the time supplied there is no full backup of database database_name in instance server_name for the time supplied Unable to close temporary file that has environment variables. Check for disk full or privilege errors in /nsr/tmpdir. Description The -t time option supplied with the nsrsybrc command was not valid. This option should be supplied in the nsr_getdate form. The nsr_getdate man page provides details. The NetWorker server was not specified or could not be found. Specify the NetWorker server to which the command is to be issued with the -s server_name option. The Sybase server returned a nonfatal error. This error does not stop the operation. Examine the message to ensure that the error does not lead to future problems. The -d destination option or the database name option for the nsrsybrc command did not begin with the characters SYBASE:. All Sybase server save sets must begin with this name. Either the entire instance (SYBASE:/ASE_server_name) or a list of databases (SYBASE:/ASE_server_name/database_name1 SYBASE:/ASE_server_name/database_name2) must be specified at the command line. Both an instance name and a list of databases cannot be specified at the same time. Each invocation of the nsrdasv, nsrsybcc, or nsrsybrc commands can operate on a single Sybase server because the user ID and password supplied are unlikely to be the same over multiple servers. Retry the command and run it once for each Sybase server. The maximum database name length is 30 characters. The database name supplied at the command line was longer than 30 characters. The NMDA software is supported on SQL Server 11.x or later and Adaptive Server Enterprise 11.5 or later. The database consistency check checkstorage option works only with Adaptive Server Enterprise 11.5 and later. SQL Server 11.x does not support this option. The name of the database or Sybase server instance to be recovered must be supplied when using the nsrsybrc command. The database to be processed was specified as SYBASE:, but the instance name was not supplied. There were no databases found in the directory entry for the Sybase server database. No backup could be found for the Sybase server name supplied. Make sure that the nsrsybrc command is run with the same user ID that was used to run the nsrdasv command. Otherwise, ensure that the time used is correct. If a time is not entered, the current time is used. Backups of this database exist, but there was not a full backup available for the time requested. Try an earlier time, or run the nsrinfo command to determine when the last full backup occurred. For example, if the full backup has passed its browse policy, the full backup might be listed in the media database but not in the client index. In this situation, re-create the entry in the client index with the scanner -i command, and then recover the database with the nsrsybrc command. The temporary file used to pass environment variables between nsrdasv and libnsrsyb could not be closed. The permissions might be incorrect, or the disk might have insufficient space to write the file. Redirect the nsrdasv command to create a temporary directory in a different place by setting the NSR_TEMPDIR variable. 430 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 47 Error messages from the nsrsybrc program (page 3 of 3) Error message unable to create directory /nsr/tmpdir unable to open temporary file to pass environment variables unable to query backup unable to write environment variables to the temporary file Description The access privileges for the user running the nsrdasv command are insufficient to create the /nsr/tmpdir directory. Re-create the directory manually or change the permissions so that this directory can be created by this user. Redirect the nsrdasv command to create a temporary directory in a different place by setting the NSR_TEMPDIR variable. The temporary file that is used to pass environment variables between nsrsdasv, nsrsybrc, and libnsrsyb could not be opened. Check for file access or disk problems. Redirect the nsrdasv command to create a temporary directory in a different place by setting the NSR_TEMPDIR variable. There was an error querying the backup from the server. Check the xbsa.messages file for the specific error text. The system could not write to the temporary file used to pass environment variables between nsrdasv and libnsrsyb. Check for file access or disk problems. Error messages from the nsrdasv program Table 48 on page 431 lists errors messages generated during Sybase backup operations with the nsrdasv program, in alphabetical order. Table 48 Error messages from the nsrdasv program (page 1 of 3) Error message a full database backup is required and will be done before the transaction log backup An invalid backup level was supplied. Valid backup levels are full, incremental, and skip cannot find database database_name in instance server_name CS-LIBRARY or CT-LIBRARY error: error_message. Operating system error number(n): error_message. error from server server_name: Msg number, Level number, State number no NetWorker server was specified Non fatal internal error from server server_name: Msg number, Level number, State number only one database or instance may be specified path needs to begin with SYBASE:. The command line has the form SYBASE:/instance_name[/database_name] PRECMD or POSTCMD did not return a result. It needs to return zero on success and nonzero on failure. Description The incremental backup failed because a full backup must first be performed. Perform a full backup, then retry the transaction log backup. The backup level supplied to the nsrdasv command is not permitted. The database to be backed up does not exist in the Sybase server. An error occurred in the Sybase Open Client library layer. The operating system part of the error message is displayed only if an operating system error occurred. These error messages appear when the master database is recovered because this operation shuts down the Sybase server, but they are not normal during other operations. The error message text describes the specific problem. The Sybase server returned an error. Check the error message that follows this error message to determine the reason for the error. A NetWorker server was not specified or could not be found. Specify the NetWorker server to which the command is to be issued. The Sybase server returned a nonfatal error. This error does not stop the operation. Examine the message to ensure that the error does not lead to future problems. More than one database or instance was supplied to the nsrdasv command. The nsrdasv command only supports a single instance (SYBASE:/ASE_server_name) or database (SYBASE:/ASE_server_name/database_name) per invocation. The -N save_set_name option or the database name option for the nsrdasv command did not begin with the characters SYBASE:. All Sybase server save sets must begin with this name. The PRECMD or POSTCMD did not return a status value. Sybase-specific troubleshooting tips and error messages 431

Troubleshooting and Error Messages Table 48 Error messages from the nsrdasv program (page 2 of 3) Error message process process_number running command PRECMD or POSTCMD completed with a result of n SQL Server server_name version is too old. It must be 11.0 or later, and it is version_number. Sybase server version version_number does not support the checkstorage option. Versions 11.5 and later support it the command line may specify the entire instance or a list of individual databases, but not both The command line specifies more than one Sybase instance. Only a single instance may be supplied with each command line. the database name database_name has a length greater than the maximum of 30 the exit status of process process_number could not be determined The instance name was not provided in the command line command_line_value. The command line has the form SYBASE:/instance_name[/database_name]. The LNM level parameter value must be between 'FULL' and '9' the NSR_BACKUP_PATHS parameter was not set in the configuration file The Sybase user name was not set. Please specify the Sybase user in the configuration by setting the SYBASE_USER parameter Unable to close temporary file that has environment variables. Check for disk full or privilege errors in /nsr/tmpdir. unable to create directory /nsr/tmp unable to create directory entries unable to determine whether database and log are on separate segments unable to dump database database_name in instance server_name Description The PRECMD or POSTCMD exited with a nonzero result code. Check the PRECMD or POSTCMD exit code for details. Also verify that the settings of PRECMD or POSTCMD are valid. The following provide details: PRECMD on page 354 POSTCMD on page 354 The NMDA software is supported on SQL Server version 11.x or later and Adaptive Server version 11.5 or later. The database consistency check checkstorage option only works with Adaptive Server version 11.5 and later. SQL Server version 11.x does not support this option. Specify either the entire instance (SYBASE:/ASE_server_name) or a list of databases (SYBASE:/ASE_server_name/database_name1 SYBASE:/ASE_server_name/database_name2). An instance name and a list of databases cannot be specified at the same time. Each invocation of the nsrdasv, nsrsybcc, or nsrsybrc command can operate on a single Sybase server because the user ID and password supplied are unlikely to be the same over multiple servers. Retry the command and run it once for each Sybase server. The maximum database name length is 30 characters. The database name supplied was longer than 30 characters. The PRECMD or POSTCMD that was run did not exit, but the process no longer exists. The database to be processed was specified as SYBASE:, but the instance name was not supplied. The environment variable NSR_BACKUP_LEVEL specified a level other than full, incremental, or skip. The required setting of the NSR_BACKUP_PATHS parameter could not be found in the configuration file. Supply a username for Sybase login through the SYBASE_USER parameter setting in the configuration file. The temporary file used to pass environment variables between nsrdasv and libnsrsyb could not be closed. The permissions might be incorrect, or the disk might have insufficient space to write the file. The access privileges for the user running the nsrdasv command are insufficient to create the /nsr/tmp directory. Re-create the directory manually or change the permissions so that this directory can be created by this user. The directory entries could not be created. Check the xbsa.messages file for the specific reason that the entries could not be created. The database to be backed up is not in a state in which it can be queried to determine whether incremental backups are allowed. The error message from the Sybase server that was displayed prior to this message indicates the reason the database cannot be queried. The dump database command failed. The error message from the Sybase server that was displayed prior to this message indicates the reason the database was not dumped. 432 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 48 Error messages from the nsrdasv program (page 3 of 3) Error message unable to dump the transaction log for database database_name in instance server_name unable to dump the transaction log without truncating it for database database_name unable to execute the command PRECMD or POSTCMD contents unable to open temporary file to pass environment variables unable to print savegrp completion message Unable to print summary. One or more parameters are not set unable to spawn process to issue the PRECMD or POSTCMD command unable to truncate the transaction log for database database_name unable to truncate the transaction log for database database_name with the no_log option unable to write environment variables to the temporary file Description The command to dump the transaction log failed. The error message from the Sybase server that was displayed prior to this message indicates the reason the transaction log was not dumped. The command to dump the transaction log with the no_truncate option failed. The error message from the Sybase server that was displayed prior to this message indicated the reason the transaction log was not truncated. The PRECMD or POSTCMD could not be found. Ensure the command exists in one of the directories specified in $PATH. The temporary file used to pass environment variables between nsrdasv, nsrsybrc, and libnsrsyb could not be opened. Check for file access or disk problems. After the backup occurred, the NetWorker software could not find the save sets in the media database. The parameters that NetWorker software expected to find for the function that prints the savegrp summary were not supplied. The PRECMD or POSTCMD could not be run because a process needed to run them was not available. The command to truncate the transaction log failed. The error message from the Sybase server that was displayed prior to this message indicated the reason the transaction log was not truncated. The command to truncate the transaction log failed. The error message from the Sybase server that was displayed prior to this message indicates the reason the transaction log was not truncated. The system could not write to the temporary file that was used to pass environment variables between nsrdasv and libnsrsyb. Check for file access or disk problems. Sybase backup server and libnsrsyb error messages When the Sybase Backup server encounters an error or condition requiring a warning, it writes a message to the Sybase Backup server error log. The default error log location differs for Sybase Server versions 11.x and 12.x: For Sybase Server 11.x: $SYBASE/install For Sybase Server 12.x: $SYBASE/$SYBASE_ASE/install If an error with the libnsrsyb shared library occurs, a libnsrsyb message is written to the xbsa.messages file and is reported to the Sybase Backup server. The Sybase Backup server logs the libnsrsyb error messages in the Sybase Backup server error log. Table 49 on page 433 lists libnsrsyb error messages that are logged in the Sybase Backup server error log. The Sybase documentation provides details on other Sybase Backup server errors. Table 49 Sybase backup server and libnsrsyb error messages (page 1 of 2) Error message libnsrsyb opened with an unknown mode: internal error there is insufficient memory to continue Description The libnsrsyb shared library was opened with a mode other than read or write. There is not enough memory to complete the operation. Sybase-specific troubleshooting tips and error messages 433

Troubleshooting and Error Messages Table 49 Sybase backup server and libnsrsyb error messages (page 2 of 2) Error message The time stamp dddddddd has non digits in it. Timestamps are composed of digits in the form YYYYMMDDhhmmsslll. time stamps are not valid for dump command unable to close and create save set unable to close save set unable to create environment variables Unable to create save set. There is likely a configuration or enabler problem. Set the debug level to at least 2, retry the operation, and check the /nsr/applogs/xbsa.messages file for the underlying reason. unable to create the save set on the server unable to end the current read session Unable to find backup of the (database or transaction log) SYBASE:/server_name/database_name. Check the command line for errors in the instance or database name or use nsrinfo to see which save sets are available. Unable to find full backup of the database database_name for the time supplied. Unable to find incremental backup of the database database_name for the time supplied. Unable to find backup of the database database_name for the time supplied. unable to parse stripe specifier unable to read the requested number of bytes from the save set unable to send data to save set unknown backup type supplied Description The timestamp supplied for the load command from the isql command line has a timestamp with an incorrect format. The timestamp must have the format YYYYMMDDhhmmsslll, where: YYYY indicates the year. MM indicates the month. DD indicates the day. hh indicates the hour. mm indicates the minutes. ss indicates the seconds. lll indicates the milliseconds. The l millisecond position is optional. Alternatively, 000 can be entered for the milliseconds. The isql command line specified a timestamp for a dump command. Timestamps are not valid with the dump command. The BSA call to create and close the save set for a database or transaction dump failed. Check the xbsa.messages file for specific details. The call to close the save set failed during a load of a database or a transaction log. Check the xbsa.messages file for specific details. The resources required to create the internal environment variable array were not available. This might be due to access problems in the /nsr/tmp directory. The save set could not be created on the NetWorker server. If the debug level is at least 2 (the default), check the xbsa.messages file for the error text. If the debug level is not set at 2, change the setting to 2 and retry the operation. Check the xbsa.messages file for specific details. The call to create the save set on the NetWorker server failed. Check the xbsa.messages file for specific details. During a load database or load transaction log operation, the read session of the data from the NetWorker software could not be closed. Check the xbsa.messages file for specific details. The item to be loaded could not be found. Use the nsrinfo command to check that the object-owner for the backup is the same as the process that launched the Sybase Backup server and that backups exist for this database. No backup could be found in the NetWorker server. If no time was supplied, the time used is the current time, which means that no backup exists. Use the nsrinfo command to check which backups are available and make sure that the object owner shown there is the same as the user ID that launched the Sybase Backup server. The isql command line had a poorly formatted stripe specifier. During a load database or load transaction log operation, the save set could not be read. Check the xbsa.messages file for specific details. During a database or transaction log dump, the data could not be written to the save set. Check the xbsa.messages file for specific details. The backup type supplied from the NetWorker server was not a database or a transaction log. 434 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages NetWorker XBSA and libnsrsyb error messages During a backup or recovery, NetWorker software records error messages generated by the NetWorker X/Open Backup Services Application (XBSA) library in the xbsa.messages file, located in the same directory as the NMDA debug logs. General troubleshooting tips on page 394 provides details on the NMDA debug logs. If the assigned location is invalid or unreachable, the message file is written to the NMDA temporary directory. NetWorker XBSA error messages appear in the following format: XBSA-1.0 bms-1. process_id day month date hh:mm:ss year function_name: BSA_RC_message_code: message The libnsrsyb error messages are also written to the xbsa.messages file and reported to the Sybase Backup server. The Sybase Backup server prints the messages in the stdout file and logs them in the Sybase Backup server error log. Table 50 on page 435 lists the relevant NetWorker XBSA and libnsrsyb error messages. Table 50 NetWorker XBSA and libnsrsyb error messages (page 1 of 4) Error message BSA_RC_ABORT_ACTIVE_NOT_FOUND No active object matched the name that was specified for a BSAMarkObjectInactive BSA_RC_ABORT_SYSTEM_ERROR System detected error due to explanation. Operation aborted BSA_RC_APP_OBJECTOWNER_TOO_LONG The appobjectowner field contained too many characters (n >= n BSA_RC_AUTHENTICATION_ERROR There was an authentication failure for ObjectOwner ownername BSA_RC_BAD_CALL_SEQUENCE The sequence of API calls is incorrect. Must call item1 before item2 BSA_RC_BAD_HANDLE The handle used to associate this call with a previous BSAInit() call is invalid because explanation BSA_RC_BAD_PARAMETER received parameter parm with value value, which is invalid BSA_RC_BSA_OBJECTOWNER_TOO_LONG The bsaobjectowner field contained too many characters (n >= n) BSA_RC_BUFFER_TOO_SMALL Buffer is too small to hold the object entry to be returned. n bytes required for the object entry Description No active object matching the given search parameters was found in the NetWorker server that is being used by the NetWorker XBSA session. A general system error occurred within a NetWorker XBSA function call. This error is returned for all NetWorker errors that do not map cleanly to XBSA errors. The appobjectowner field of an ObjectOwner parameter contains too many characters and might be corrupt. The routine failed to authenticate a BSAObjectOwner with NetWorker server used by the NetWorker XBSA session. The code is returned by the routine BSASetEnvironment to allow for the possibility of changing NetWorker servers during a single session by changing the value of the NSR_SERVER environment option. Appendix A, NMDA Parameters for Backups and Restores, provides more details about available settings. The NetWorker software permits all users to back up data and recover their files without passwords, so this should not occur. An API call sequence was made that does not conform to the XBSA Data Movement API State Diagram document. The value passed into the function for bsahandle contained a NULL pointer. An invalid parameter was received. The appobjectowner field of an ObjectOwner parameter contains too many characters and might be corrupt. The buffer is too small to hold the object entry to be returned. Sybase-specific troubleshooting tips and error messages 435

Troubleshooting and Error Messages Table 50 NetWorker XBSA and libnsrsyb error messages (page 2 of 4) Error message BSA_RC_COPYGPNAME_TOO_LONG The copygpname field contained too many characters (n >= n) BSA_RC_DESCRIPTION_TOO_LONG The description field contained too many characters (n >= n) BSA_RC_INVALID_COPYTYPE the copytype field contained an unrecognized value of n BSA_RC_INVALID_DATABLOCK the datablock parameter contained inconsistent values: bufferlength: n, bufferptr: n, numbytes: n BSA_RC_INVALID_KEYWORD an entry in the environment structure is invalid (variable=value) BSA_RC_INVALID_OBJECTSTATUS the objectstatus field contained an unrecognized value of n BSA_RC_INVALID_OBJECTTYPE the objecttype is invalid (n) BSA_RC_INVALID_TIME a time field contained an unrecognized value of n BSA_RC_INVALID_VERSION the version field contained an unrecognized value of n BSA_RC_LGNAME_TOO_LONG The LGName field contained too many characters (n >= n) BSA_RC_MATCH_EXISTS object matching the specified predicate already exists Description The copygpname field in one of the supplied structures contained more BSA_MAX_COPYGPNAME characters, and the structure could not be used for the requested operation. The Description field in one of the supplied structures contained more than BSA_MAX_DESC characters, and the structure could not be used for the requested operation. The copytype field in one of the supplied structures has a value that is not in the NetWorker XBSA libraries implementation of this enumerated type. The fields of a supplied DataBlock parameter are not internally consistent. This can occur under one of the following conditions: When the bufferlen field is less than the numbytes field while data is being sent. When the bufferlen field is nonzero and the bufferptr field is NULL. One of the environment strings passed into the function did not have a valid structure. The value structure of an environment keyword is KEYWORD = VALUE, where KEYWORD is a white space delimited string and VALUE is a white space delimited string followed by a null terminator. This can indicate a number of possible errors: The KEYWORD was not in the reserved word list. This error is not returned by the NetWorker XBSA libraries because other environment variables might be passed into the library along with valid keywords. The KEYWORD and VALUE strings were not separated by a '=' character. This type of error is also used to detect environment vectors that are not properly terminated with a (char *)NULL entry, as well as invalid KEYWORD VALUE pair formats. The VALUE string was invalid. The VALUE string could not be validated, as in the case of a hostname string that could not be found by the gethostbyname() function. The objectstatus field in one of the supplied structures has a value that is not in the NetWorker XBSA libraries implementation of this enumerated type. One of the object type parameters was either passed in directly or contained in one of the following structures: ObjectDescriptor QueryDescriptor was not in the range of BSAObjectType_ANY to BSAObjectType_DIRECTORY. An invalid time value was received. The version for a parameter passed into the function is not supported by this version of NetWorker XBSA. For routines that receive multiple parameters containing a version field, it does not indicate which parameter is not supported. An LGName, passed in to the function, contained more than BSA_MAX_LGNAME_SIZE characters and might be corrupt. For routines that require multiple LGName parameters, it does not indicate which token was invalid. The object already exists in the NetWorker server being used by the NetWorker XBSA session and that the requested operation cannot be completed. 436 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Troubleshooting and Error Messages Table 50 NetWorker XBSA and libnsrsyb error messages (page 3 of 4) Error message BSA_RC_MORE_DATA more data is available. Data can be obtained through BSAGetData() or BSAGetNextQueryObject() BSA_RC_NO_MATCH The ResourceType predicate value of D does not match the reference value of L BSA_RC_NO_MATCH The variable predicate value of value does not match the reference value of variable BSA_RC_NO_MORE_DATA there is no more data for the current object BSA_RC_NULL_APIVERSION an ApiVersion pointer is required BSA_RC_NULL_BUFFER an buffer pointer is required BSA_RC_NULL_DATABLOCK a data block pointer is required BSA_RC_NULL_ENVIRONMENT an environment pointer is required BSA_RC_NULL_NEWTOKEN a value must be entered for the new token. The old token has expired BSA_RC_NULL_OBJECTDESCRIPTOR an ObjectDescriptor pointer is required BSA_RC_NULL_OBJECTNAME an object name is required BSA_RC_NULL_OBJECTOWNER an ObjectOwner pointer is required Description This has two meanings in the XBSA Data Movement API: Object Data Retrieval There is more data available for an object being read from the NetWorker server than is being used by the NetWorker XBSA session. Use BSAGetData to retrieve the next DataBlock from the NetWorker server (see also BSA_RC_BUFFER_TOO_SMALL on page 435 and BSA_RC_NO_MORE_DATA on page 437). This message is not returned by the BSAGetObjectF function because all data for an object is written to a file descriptor by this function. Query Result Retrieval There are more objects matching the requested query descriptor from the NetWorker server than is being used by the NetWorker XBSA session. Use BSAGetNextQueryObject to retrieve the next object descriptor from Backup Services (see also BSA_RC_NO_MORE_DATA on page 437). The client index and media database are out of synch. To resynchronize the client index and media database, run the nsrck -X command. Alternatively, wait for NetWorker to run nsrck automatically. No objects matching the specified QueryDescriptor were found in the NetWorker server that is being used by the NetWorker XBSA session. This has two meanings in the XBSA Data Movement API: Object Data Retrieval This is used when all the data for an object being retrieved from a NetWorker server was placed into the given DataBlock parameter for a function call (see also BSA_RC_NO_MORE_DATA on page 437). Query Result Retrieval This is used when the last (or only) object matching a query is returned to the caller (see also BSA_RC_NO_MORE_DATA on page 437). A pointer to an ApiVersion structure, passed into the function, was NULL and is required as input. This is not used by NetWorker XBSA. A NULL buffer when reading an object s data (BSAGetData, BSAGetObject) results in no bytes being read and a BSA_RC_MORE_DATA code being returned. The DataBlock pointer parameter for the called function was NULL. The caller is responsible for allocating and passing in the DataBlock structure to the NetWorker XBSA library (see also BSA_RC_NULL_BUFFER on page 437 and BSA_RC_INVALID_DATABLOCK on page 436). This is not used by NetWorker XBSA. An environment vector parameter that is NULL is not processed. The SecurityToken parameter, newtoken, was found to be NULL and is required as input. See also BSA_RC_NULL_SECURITYTOKEN on page 438. The SecurityToken parameter, newtoken, was found to be NULL and is required as input. See also BSA_RC_NULL_SECURITYTOKEN on page 438. The ObjectName parameter passed into the called function was NULL. A pointer to an object-owner structure was NULL and is required as input. Sybase-specific troubleshooting tips and error messages 437

Troubleshooting and Error Messages Table 50 NetWorker XBSA and libnsrsyb error messages (page 4 of 4) Error message BSA_RC_NULL_POINTER a required pointer parameter is NULL BSA_RC_NULL_SECURITYTOKEN an SecurityToken pointer is required BSA_RC_OBJECTINFO_TOO_LONG The objectinfo field contained too many characters (n >= n) BSA_RC_OBJECTSPACENAME_TOO_LONG The objectspacename field contained too many characters (n >= n) BSA_RC_PATHNAME_TOO_LONG The pathname field contained too many characters (n >= n) BSA_RC_RESOURCETYPE_TOO_LONG The resourcetype field contained too many characters (n >= n) BSA_RC_SECURITYTOKEN_TOO_LONG The securitytoken field contained too many characters (n >= n) BSA_RC_SUCCESS the function was successful BSA_RC_TRANSACTION_ABORTED the transaction was aborted Description The NetWorker XBSA library does not return this code. Instead, specific codes indicating that a required parameter was NULL are returned: BSA_RC_NULL_APIVERSION BSA_RC_NULL_BUFFER BSA_RC_NULL_COPYGPNAME BSA_RC_NULL_COPYID BSA_RC_NULL_DATABLOCK (BSA_RC_NULL_DATABLKPTR) BSA_RC_NULL_ENVIRONMENT BSA_RC_NULL_LGNAME BSA_RC_NULL_NEWTOKEN BSA_RC_NULL_OBJECTDESCRIPTOR BSA_RC_NULL_OBJECTNAME BSA_RC_NULL_OBJECTOWNER BSA_RC_NULL_OLDTOKEN BSA_RC_NULL_QUERYDESCRIPTOR BSA_RC_NULL_RULEID BSA_RC_NULL_SECURITYTOKEN BSA_RC_NULL_STREAM A pointer to a SecurityToken parameter is NULL and is required as input. The NetWorker XBSA library uses this internally and should not be seen in normal use. The more specific codes BSA_RC_NULL_NEWTOKEN and BSA_RC_NULL_OLDTOKEN are used, as appropriate. The ObjectInfo parameter passed into the function, either directly or in one of the following data structures, was found to have more than BSA_MAX_OBJINFO characters: ObjectDescriptor The string objectspacename contains more than BSA_MAX_OBJECTSPACENAME characters in an ObjectName structure. The string pathname contains more than BSA_MAX_PATHNAME characters in an ObjectName structure. The string resourcetype contains more than BSA_MAX_RESOURCETYPE characters and might be corrupt. A SecurityToken, passed in to the function, contained more than BSA_MAX_SECURITYTOKEN characters and might be corrupt. For routines that require multiple tokens, it does not indicate which token was invalid. The called function did not fail and is returned by all NetWorker XBSA function calls. The current transaction was aborted by the BSAEndTxn function call. A transaction can either be aborted by an internal error, or by user request through the Vote parameter to this function. 438 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary This glossary contains the definitions of terms found in this manual. Most of the terms are specific to the NetWorker Module for Databases and Applications (NMDA) software. For terms specific to the NetWorker software, refer to the latest EMC NetWorker Administration Guide. A? Oracle placeholder for the main directory of the Oracle database instance identified as $ORACLE_HOME. ad hoc backup administrator Administrators group API (application programming interface) ASM (application specific module) archived redo log attribute auto media management autochanger Legacy term for a manual backup. This term is now obsolete. See manual backup. Person who normally installs, configures, and maintains software on network computers, and who adds users and defines user privileges. 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. 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 copy of a filled online Oracle redo log that preserves older redo log data for recovery operations. See also redo log. Feature of a NetWorker resource. It is a service or information that the resource provides. 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. See library. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 439

Glossary B backup backup cycle backup group backup host backup level Backup Operators group backup piece backup set backup volume bootstrap browse policy Operation that saves data to a volume. An Oracle backup of several datafiles may include several backup sets. See scheduled backup cycle. See group. See proxy client host. See level. 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. Binary file created during an NMDA 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. Group of one or more backup pieces, created through the RMAN backup command during an NMDA backup. See volume. 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. 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. C catalog synchronization client client file index client-side configuration cluster cold Oracle backup 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. Computer, workstation, or fileserver whose data can be backed up and restored. 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. NetWorker Module backup configuration that is performed through the NetWorker Management Console (without the configuration wizard), as compared to server-side configuration. 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. See offline backup. 440 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary command line connection port Line on a display screen, also known as a command prompt or shell prompt, where you type software commands. Port that NetWorker processes use to perform backup and restore sessions through a firewall. D daemon database DBA DBMS deduplication backup deferred live backup Process on UNIX systems that runs in the background and performs a specified operation at predefined times or in response to certain events. Database instance of a third-party DBMS vendor. NMDA backs up and restores Oracle database files. Abbreviation for database administrator, the person that is typically responsible for installing, configuring, and maintaining Oracle database systems. Abbreviation for database management system, which refers to the primary architecture of an Oracle database. 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. 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 drive 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. Hardware device through which media can be read or written to. See also device. E enabler code event-based backup exit code expiration date 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. See probe-based backup. 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. Date when the status of a volume changes from read/write to read-only. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 441

Glossary 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. F failover file index 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. 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 firewall full backup Computer with disks that provides services to other computers on the network. 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. See level. G group Client or group of client computers that are configured to back up files at a designated time of day. H high-availability system host hot Oracle backup 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. Computer on a network. See online backup. I I18N (internationalization) immediate live backup incremental backup Capability of the NMDA software to operate in a non-english environment or locale without itself generating non-ascii data. After I18N is set up, NMDA can process and display non-ascii data that is passed to it by the operating system, NetWorker software, and Oracle software. 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. See level. 442 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary index policy instance instant backup instant restore Policy that specifies how long file and data index entries should remain valid. Clients specify which index policies they wish to use. Combination of processes that runs each time a database starts up. 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. 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. J jukebox See library. L level library license enabler live backup Backup configuration option that specifies how much data is saved during a scheduled or manual backup. An NMDA backup level is specified by an RMAN command in the RMAN backup script only: A full NMDA backup backs up all of the data blocks in the database, regardless of when they last changed. An incremental NMDA backup backs up only data blocks that have changed since the last backup. 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. Enabler code that is required to run a feature or product. One of the following two types of proxy Oracle backup: deferred live backup immediate live backup M manual backup media media database media index media manager media pool 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. Informix term for a manual backup is an on-demand backup. Physical storage, such as magnetic tape, optical disk, or file system, to which backup data is written. See also volume. 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. See media database. NetWorker database that tracks save sets stored on backup volumes. Feature to sort backup data to selected storage volumes. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 443

Glossary MML (media management library) mount MTTR (mean time to recover) multiplexing Library of media management routines provided by the NMDA software and linked with the Oracle kernel software during the installation of NMDA on the Oracle Server host. 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. NetWorker feature that permits data from more than one save set to be simultaneously written to the same storage device. N NetWorker NetWorker client NetWorker Module for Databases and Applications NetWorker Module for DB2 NetWorker Module for Informix NetWorker Module for Lotus NetWorker Module for Oracle NetWorker Module for Sybase NetWorker resource NetWorker server NetWorker storage node NMDA NMDB2 NMI NML NMO NMS Network-based EMC software product that backs up and restores file systems. See client. NetWorker add-on module for the NetWorker server software that enables backups and restores of IBM DB2, Informix Dynamic Server (IDS), Lotus Domino and Notes, Oracle Server, and Sybase Adaptive Server (ASE) data. See also NMDA. NetWorker add-on module for the NetWorker server software that enables backups and restores of DB2 data. See also NMDB2. NetWorker add-on module for the NetWorker server software that enables backups and restores of Informix IDS data. See also NMI. NetWorker add-on module for the NetWorker server software that enables backups and restores of Lotus Domino/Notes data. See also NML. NetWorker add-on module for the NetWorker server software that enables backups and restores of Oracle Server data. See also NMO. NetWorker add-on module for the NetWorker server software that enables backups and restores of Sybase ASE data. See also NMS. See resource. See server. See storage node. Abbreviation for NetWorker Module for Databases and Applications. Abbreviation for NetWorker Module for DB2. Abbreviation for NetWorker Module for Informix. Abbreviation for NetWorker Module for Lotus. Abbreviation for NetWorker Module for Oracle. Abbreviation for NetWorker Module for Sybase. 444 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary notification nsrhost NWORA resource file Message generated and sent to the NetWorker administrator about important NetWorker events. Logical hostname of the computer that is the NetWorker server. Resource file installed during the NMDA installation, which must be extended to include specific additional resources to enable proxy Oracle backups and (optionally) catalog synchronization. O offline backup on-demand backup online backup online indexes operator Oracle Enterprise Manager Oracle10g Server Oracle11g Server override Offline Oracle backup performed while the Oracle instance is shut down and unavailable to users. Informix term for a manual backup. See manual backup. Online Oracle backup performed while the Oracle instance is running and available to users. Databases located on the NetWorker server that contain all the information pertaining to the client backups ( client file index ) and backup volumes ( media database ). Person who monitors the server status, loads backup volumes into storage devices, and executes the day-to-day NetWorker tasks. Oracle Enterprise Manager Backup Management Tools, which include an optional graphical user interface to the RMAN utility. Computer running an Oracle10g release 10.x DBMS. See DBMS. Computer running an Oracle11g release 11.x DBMS. See DBMS. Different backup level that is used in place of the regularly scheduled backup level. P parallelism pathname physical host point-in-time copy Method that backs up or restores data for multiple clients, or multiple save sets for one client, at the same time. 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. Node or host that forms part of a cluster. 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. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 445

Glossary policy policy uniformity pool PowerSnap PowerSnap Module preconfigured primary storage probe probe-based backup proxy client proxy client host proxy backup proxy restore purging 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 EMC 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. 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 NMDA to ensure that incremental backups do not persist after other backups they depend on have expired. Feature to sort backup data to selected storage volumes. 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. 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. NMDA operates with a PowerSnap Module to perform proxy Oracle backups. Initial default selections or configurations for software features. 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. Query operation to determine if a specified condition is met on a client. 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. 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. 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. 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. 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. 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. 446 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary R RDBMS (relational database management system) recover Recovery Catalog recyclable save set recyclable volume redo log remote device resource resource database restore restore from secondary storage retention policy RMAN (Recovery Manager) RMAN catalog RMAN script Type of DBMS that stores data in the form of related tables. To apply archived redo logs and online redo logs to an Oracle database to make the database consistent with a given point in time. 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. Save set whose browse and retention policies have expired. Recyclable save sets are removed from the media database. Volume whose data has exceeded both its browse and retention policies and is now available to be relabeled and reused. 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. Storage device that is attached to a NetWorker storage node. 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. Database of information about each of the configured NetWorker resources. 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. 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. Oracle utility that acts as an intelligent interface to Oracle databases and works with third-party media management products, such as NMDA, to back up and restore Oracle database objects. RMAN repository that stores information about each Oracle backup piece in either a control file of the target database or an RMAN Recovery Catalog. Script of RMAN commands used to perform an NMDA Oracle backup or restore or an Oracle database duplication. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 447

Glossary rollback restore rollover save set 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. 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. root On UNIX, the superuser account. On Microsoft Windows and UNIX, the highest level of the system directory structure. RPC (remote procedure call) save save set save set bundle save set bundle join save set bundling save set ID save set status save stream scanner scheduled backup scheduled backup cycle secondary storage Protocol that the NetWorker server uses to perform client requests over a network. S NetWorker command that backs up client files to backup volumes and makes data entries in the online index. Group of files or a file system from a single client computer, which is backed up on storage media. Group of co-dependent save sets from the same scheduled backup cycle of an Oracle database object, assembled by NMDA into a bundle according to configuration settings. Creation, during an incremental scheduled NMDA backup, of a combined save set bundle from co-dependent save sets in different save set bundles. Process whereby NMDA 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. Internal identification number that NetWorker software assigns to a save set. 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. Data and save set information that is written to a storage volume during a backup. A save stream originates from a single save set. NetWorker command used to read a backup volume when the online indexes are not available. 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. 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. Storage library attached to the NetWorker server or storage node, used to store traditional or snapshot backups. 448 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Glossary server server index service port server-side configuration shared disk shell prompt SID (system identifier) silo skip snap set snapshot snapshot policy ssid staging stand-alone device storage device storage node system administrator 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. File that lists all the server files backed up during a scheduled backup. Port used by a server or storage node to listen for backup and restore requests from clients through a firewall. NetWorker Module backup configuration that is performed through the configuration wizard, as compared to client-side configuration. Storage disk that is connected to multiple nodes in a cluster. Cue for input in a shell window where you type a command. Unique name for an Oracle database instance. This value is typically set in an ORACLE_SID parameter. Repository for holding hundreds or thousands of volumes. Silo volumes are identified by barcodes, not by slot numbers. Backup level in which designated files are skipped and not backed up. See also level. 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. Point-in-time copy of Oracle data created on a supported type of primary storage during an instant backup. 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. See save set ID. Moving data from one storage medium to a less costly medium, and later removing the data from its original location. Type of storage device that contains a single drive for backing up data. Stand-alone devices cannot store or automatically load backup volumes. Hardware that reads and writes data during backup, restore, or other NetWorker operations. Storage device physically attached to a computer other than the NetWorker server, whose backup operations are administered from the controlling NetWorker server. Person normally responsible for installing, configuring, and maintaining NetWorker software. T tablespace Oracle database structure that consists of one or more datafiles. EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 449

Glossary target database temporary enabler TNS (Transparent Network Substrate) traditional restore traditional storage Database that the NetWorker server backs up as a safeguard against data loss. Code that enables operation of the NMDA software for an additional 45 days beyond the evaluation period. Oracle networking technology that provides a single interface to all standard network protocols. 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. See secondary storage. U unscheduled backup user See manual backup. Person who uses NetWorker software from a computer to back up and restore files. V versions volume volume ID volume name volume pool Date-stamped collection of available backups for any single file. Backup volume used to store backup data. Backup data cannot be stored on an archive volume or a clone volume. Internal identification that the NetWorker software assigns to a backup volume. Name assigned to a backup volume when it is labeled. See pool. 450 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Index A ADDRESS_LIST parameter 268 Administrator program, NetWorker Stop button 158 Administrator, NetWorker Client resource 297 Device resource 75 Group resource 88, 296 Label Template resource 75 Pool resource 75, 296 Schedule resource 88 Server resource 72 Snapshot Policy resource 286, 296 User Group resource 72 Advanced Copy Services (ACS) 326 AES encryption 141, 350 Aliases attribute in Client resource 90 allocate channel command parms option 383 Application Information attribute in Client resource 90 archive logging 35 archived redo log backup 228, 271 restore 271 sharing across RAC nodes 271 attributes for resources Client resource 74 Server resource 72 autochanger 75, 202 automatic catalog synchronization for proxy backups 318 automatic channel allocation 43, 104, 105 B backup Client resource 297 command 292, 382 command (pool option) 378 command (trace option) 385 copies 45 delete 135 error messages 398, 413 from NetWorker User for Lotus 140, 142, 148 change server 142, 150 from NetWorker User for Sybase performing 150 Group resource 88, 296 levels supported 38 multiple session 95 required Sybase roles 113 Schedule resource 88 transaction logs 93 Backup Command attribute in Client resource 91, 297 backup copies during manual backups 45 backup current control file command 229 backup failover 250 backup fails, troubleshooting 399 backup hangs, troubleshooting 396 Backup Snapshots attribute in Snapshot Policy resource 287 backup spfile command 229 backup types archived redo log 228, 271 control file 227, 229 deduplication 26, 119 deferred live 287, 301 immediate live 287 instant 286, 301, 309 manual 24, 25, 134 NetWorker bootstrap 66, 152 NWORA resource file 302, 304 password file 227 probe-based 26, 125 proxy 28, 284, 299 registry files 227 scheduled 24, 25, 156 BACKUP_TAPE_IO_SLAVES parameter 384 bootstrap records 23, 225, 227, 230 bootstrap, NetWorker 66, 152 Browse Policy attribute in Client resource 91, 297 browse policy uniformity 48 browse time 193, 219 bundling, save set 50 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 451

Index C canceling manual backup 151 nonresponding backup 152 proxy backup 302 scheduled backup 106, 157, 158 catalog synchronization for proxy backups 318 change backuppiece...unavailable command 384 change DBIID 194 change replica ID 194 change...crosscheck command 378, 384 change...delete command 318 channel option, send command 380 circular logging 35 client file index 23, 303, 304 Client resource 297 Client resource attributes Aliases 90 Application Information 90 Backup Command 91 Browse Policy 91 Group 91 Name 91 Parallelism 91 Remote Access 91 Retention Policy 91 Save Set 92 Schedule 92 Client Retries attribute in Group resource 323 cluster configuration 248 cluster systems 29, 322 command allocate channel, parms option 383 backup 292, 382 backup (pool option) 378 backup (trace option) 385 backup current control file 229 backup spfile 229 change backuppiece...unavailable 384 change...crosscheck 378, 384 change...delete 318 configure channel, parms option 294, 368 crosscheck 378, 384 delete expired backup 378 nsrorainfo 202 nsrsybcc 144 nsrsybrc 113 restore 382 rman 144, 208 rman send 368, 381, 383 rman.exe 144, 208 savefs 65 savegrp 65, 153 send 293, 368, 379 send (channel option) 380 send (device_type option) 380 send (NSR_ENV keyword) 379 send (precedence rules) 383 set 369 set duplex 383, 384 setenv 369 Command attribute in Probe resource 126 Command Options attribute in Probe resource 127, 128 configuration Client resource 297 Device resource 75 Group resource 88, 296 Label Template resource 75 manual backup 134 Pool resource 75, 296 roadmap 70 Schedule resource 88 scheduled backup 156 Server resource 72 Snapshot Policy resource 286, 296 User Group resource 72 configuration file transaction logs 93 configuration template nmda_db2.cfg 347 nmda_informix.cfg 347 nmda_lotus.cfg 347 nmda_oracle.cfg 347 nmda_sybase.cfg 347 configuration wizard 70 configure channel command parms option 294, 368 connection file, for catalog synchronization 311, 313, 315 control file backup 227, 229 control files, mirrored 228 crosscheck command 378, 384 D database instance name 90 manual backup 24, 134 scheduled backup 24, 156 Database Partitioning Feature (DPF) 34, 257 Datazone pass phrase attribute in Server resource 72 DB2 DPF systems 257 history file 136 prune command 135 resource file 327 restore and recovery 168 DB2 DPF partitions 34 DB2 history file 35 DB2 history pruning 327 DB2 multinode configurations 34 DB2 transaction logs 35 DB2_ALIAS parameter 356 DB2_APPLY_NW_LEVELS parameter 356 DB2_NODE_NAME 260, 262 DB2_NODE_NAME parameter 356 DB2_OPTIONS 260, 262 452 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Index DB2_OPTIONS parameter 357 DB2_PARTITION_LIST 262 DB2_PARTITION_LIST parameter 357 DB2_QUIESCE parameter 357 DB2_SESSIONS parameter 357 DB2_TBS_LIST parameter 357 DB2_USER 260, 262 DB2_USER parameter 357 DB2_VENDOR_INI 355 DB2_VENDOR_LIB_PATH parameter 358 DB2INSTANCE parameter 356 DB2PATH parameter 327, 357 DBCCOPT parameter 373 DBID 227, 228 DBIID, changing 194 deduplication backup 26, 119 restore 26 deferred live backup 287, 301 delete backup 135 snapshots 331 delete expired backup command 378 destructive restores overview 288 Device resource 75 device_type option, send command 380 disaster recovery 224 partitioned Domino server 237 preparation 227 types 231 DO_LOGFILE_BACKUPS parameter 360 DO_WHOLE_SYSTEM_BACKUP parameter 360 DPF partitions 34, 92, 257 dump command 388, 389 E EMCCLAR_SNAP_SUBTYPE 326 enabling policy uniformity 111 save set bundling 110 encryption AES encryption 141, 350 environment variable LC_ALL 78 NLS_LANG 109 erorr messages ON-Bar 406 error messages 398, 400 RMAN 413 Sybase Backup Server and libnsrsyb 433 F failover backup 250, 269 connect-time 267 proxy backup 322 FAILOVER parameter 268 fetched logs method of rollforward recovery 175 force_rollback option, not supported 305 full backups load from isql 390 G Group attribute in Client resource 91, 297 Group resource 88, 296 GUI, NetWorker Stop button 158 H high availability 248 history pruning 35, 327 I I18N (internationalization) 32, 78 immediate live backup 287 incremental backups load from isql 390 threshold procedure 117 Informix restore and recovery 179 Informix restore through onbar combined restore 181 logical restore 181 physical restore 181 point-in-time restore 181 Informix restore types 180 INFORMIXDIR parameter 360 INFORMIXSQLHOSTS parameter 360 initialization parameter file initoracle_sid.ora 268 PFILE 227, 228, 229 SPFILE 227, 229 INSTANCE_NAME parameter 268 instant backup 286, 301, 309 instant restore 287, 305 INSTHOME 260, 262 INSTHOME parameter 358 internationalization (I18N) 32, 78 isql commands dump command 388 load command 390 threshold procedure 118 L Label Template resource 75 LC_ALL environment variable 78 LD_LIBRARY_PATH parameter 373 LD_LIBRARY_PATH_64 parameter 373 LIBPATH parameter 373 live backup deferred 287, 301 immediate 287 load command 388, 389 from isql 390 LOCAL_LISTENER parameter 268 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 453

Index LOG_THRESHOLD parameter 127 logs, transaction backup levels 38 Lotus recovery 182 restore types 39 LOTUS_NSF_FILE parameter 127 LOTUS_USER parameter 363 M mandatory parameters 127, 351, 352, 356, 357, 358, 359, 360, 361, 363, 367, 369, 370, 371, 372, 373, 375, 376 manual backup 24, 134 canceling 151 from NetWorker User for Lotus 140, 142, 148 change server 142, 150 from NetWorker User for Sybase 150 levels supported 38 monitoring 153 multiple Domino installations 278 partitioned Domino server 280 roadmap 134 manual catalog synchronization for proxy backups 318 master database, recovering 243 media database 23, 303, 304 media management storage devices 75 volume pools 75 mirrored control files 228 online redo logs 228 MML catalog 309 monitoring manual backup 153 scheduled backup 159 multiple devices and sessions 169 session backups 95, 168 multiple applications on same host 33 multiple Domino installations manual backup 278 recovery 279 scheduled backup 278 multistripe session configuring a backup 116 N Name attribute in Client resource 91 in Probe resource 126 in Server resource 72 network files listener.ora 227, 228, 268 sqlnet.ora 227, 228 tnsnames.ora 227, 228, 267 NetWorker bootstrap backup 66, 152 client file index 23, 303, 304 configuration Client resource 297 media database 23, 303, 304 processes restore 290 staging 50 NetWorker Administrator program Stop button 158 NetWorker configuration Client resource 74 Device resource 75 Group resource 88, 296 Label Template resource 75 Pool resource 75, 296 roadmap 70 Schedule resource 88 Server resource 72 Snapshot Policy resource 286, 296 NetWorker PowerSnap Modules 28, 73, 284 NetWorker User for Lotus backup 140, 142, 148 change server 142, 150, 195, 222 recovery 190 NetWorker User for Sybase backup 150 NLS_LANG environment variable 109 nmda_app.messages.raw file 398 nmda_db2.cfg template file 347 nmda_db2_tlogs.cfg configuration file 93 nmda_informix.cfg template file 347 nmda_lotus.cfg template file 347 nmda_oracle.cfg template file 347 nmda_oracle.messages.raw file 385 nmda_sybase.cfg template file 347 NOCATALOG mode 269 node partition 92 nonresponding Oracle backup, canceling 152 Notes_ExecDirectory parameter 363 NSR_AES_ENCRYPTION parameter 350 NSR_APPLY_LOGS parameter 363 NSR_ASE_PASSWORD parameter 374 NSR_ASE_VERIFY parameter 374 NSR_AUTO_RESTORE parameter 363 NSR_BACKUP_ALL_EXTENSIONS parameter 363 NSR_BACKUP_LEVEL parameter 363, 374 NSR_BACKUP_LOGS_MODE parameter 363 NSR_BACKUP_LOTUS_DIR parameter 364 NSR_BACKUP_PATHS parameter 364, 374 NSR_BUNDLING parameter 110 NSR_CATALOGFILE parameter 364 NSR_CHECKSUM parameter 350 NSR_CLIENT 260, 262 NSR_CLIENT parameter 306, 350 NSR_COMFORT_SPAN parameter 364 NSR_COMPRESSION parameter 350 NSR_CROSS_MOUNT_POINTS parameter 364 NSR_DATA_MOVER parameter 294 NSR_DATA_VOLUME_POOL 355 NSR_DATA_VOLUME_POOL* parameters 76, 108, 351, 369, 384 454 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Index NSR_DB2_RESTORE_TABLESPACE_BKUP parameter 358 NSR_DB2CAT_MODE parameter 327 NSR_DBIID parameter 364 NSR_DEBUG_LEVEL parameter 127, 351 NSR_DEDUP_BACKUP parameter 351 NSR_DEDUP_CACHE_ENABLED parameter 351 NSR_DEDUP_CACHE_TAG parameter 352 NSR_DEDUP_CHUNK_SIZE parameter 352 NSR_DEDUP_NODE parameter 352 NSR_DIAGNOSTIC_DEST parameter 127, 352 NSR_DPRINTF parameter 353 NSR_DR_BACKUP_INFO parameter 358, 360 NSR_DR_FILE_LIST parameter 358, 360 NSR_DUMP_LOG_OPT parameter 374 NSR_ENCRYPTION_PHRASES parameter 353 NSR_ENV keyword in send command 379 NSR_EXCLUDE_FILE parameter 365, 374 NSR_EXCLUDE_LIST parameter 365 NSR_FOLLOW_LINKS parameter 365 NSR_GROUP parameter 106 NSR_INCR_EXPIRATION parameter 111 NSR_LOG_DIR parameter 365 NSR_LOG_VOLUME_POOL parameter 76, 358, 361, 375 NSR_LOTUS_DATA_DIR parameter 365 NSR_MAX_START_RETRIES parameter 358 NSR_MAX_STREAMS parameter 294 NSR_MAX_TXN_LOGS parameter 365 NSR_MMDB_RETRY_TIME parameter 370 NSR_NO_BUSY_ERRORS parameter 353 NSR_NO_MULTIPLEX parameter 370 NSR_NO_NOTES_INIT parameter 365 NSR_NOTES_CONNECT_TIMEOUT parameter 366 NSR_NOTES_INI_PATH parameter 366 NSR_NUMBER_LOGS parameter 366 NSR_NWPATH parameter 311, 327, 353 NSR_ORACLE_CONNECT_FILE parameter 127, 313 NSR_ORACLE_HOME parameter 313 NSR_ORACLE_LIB_PATH parameter 314 NSR_ORACLE_NLS_LANG parameter 109 NSR_ORACLE_NLS_LANG parameter resource 312 NSR_ORACLE_SID parameter 314 NSR_ORACLE_TNS_ADMIN parameter 314 NSR_ORACLECAT_DEBUG_FILE parameter resource 311 NSR_ORACLECAT_LOG_FILE parameter resource 311 NSR_ORACLECAT_MODE parameter resource 312, 320 NSR_PARALLELISM parameter 366, 375 NSR_PREFETCH_LOGS parameter 366 NSR_PROMOTE_FULL parameter 375 NSR_PROXY_PFILE parameter 370 NSR_PS_SAVE_PARALLELISM parameter 294 NSR_RECOV_INTERACT parameter 366 NSR_RECOV_LIST_FILE parameter 367 NSR_RECOVER_POOL parameter 370 NSR_RECOVER_TIME parameter 367 NSR_RELOCATION_DEST parameter 367 NSR_REMOVE_ON_FAILURE parameter resource 312 NSR_RESOURCE_DIR parameter 367 NSR_RETENTION parameter 91 NSR_RETENTION_DISABLED parameter 370 NSR_RMAN_ARGUMENTS parameter 370 NSR_SAVESET_BROWSE parameter 91, 353 NSR_SAVESET_NAME parameter 367 NSR_SAVESET_RETENTION parameter 354 NSR_SERVER 260, 262 NSR_SERVER parameter 106, 354 NSR_SERVER_NIC parameter 371 NSR_SKIPDBERRORS parameter 367 NSR_SNAP_TYPE 326 nsrd service 65 nsrdaprobe program 27, 126, 129 nsrdasv program 65 nsrexecd service 65 nsrindexd service 67 nsrnotesrc options skip Notes API 235, 236 nsrnotesv options number of transaction logs 236 nsroraadmin program 312, 314, 315, 316, 317 nsroraclecat program 310, 318, 321 nsrorainfo command 202 nsrsnapck program 318, 319, 321 nsrsybcc command syntax 144 Sybase roles command nsrsybcc 113 nsrsybrc Sybase roles 113 nsrsybsv Sybase roles 113 NWORA parameter resources NSR_ORACLE_NLS_LANG 312 NSR_ORACLECAT_DEBUG_FILE 311 NSR_ORACLECAT_LOG_FILE 311 NSR_ORACLECAT_MODE 312, 320 NSR_REMOVE_ON_FAILURE 312 NWORA resource file 310, 311, 312, 313, 314 backup 302, 304 NWORA SID resources 313, 314 nworapc directory 306 O ONCONFIG parameter 361 online NetWorker indexes 23 online redo logs, mirrored 228 Oracle DBID 227, 228 manual backup script 104, 292, 382 mirrored control files 228 online redo logs 228 password file 106 recover 22, 166, 209 Recovery Catalog database connection to 106 restore 22, 24, 166, 202, 205, 271 sbtio.log file 385 scheduled backup script 105 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 455

Index Oracle ASM 55 See also Oracle Automated Storage Oracle Automated Storage 55 Oracle Enterprise Manager Backup Management Tools 144, 209 Oracle Net 264, 268 Oracle RAC systems 264 ORACLE_HOME parameter 371 ORACLE_SERVICE parameter 128 ORACLE_SID parameter 371 ORACLE_USER parameter 371 ORACLER_USER parameter 371 P Parallelism attribute in Client resource 91, 297 in Server resource 72 parameter ADDRESS_LIST 268 FAILOVER 268 INSTANCE_NAME 268 LOCAL_LISTENER 268 SERVICE_NAME 268 SID_LIST_LISTENER 268 parameter resources NSR_ORACLE_NLS_LANG 312 NSR_ORACLECAT_DEBUG_FILE 311 NSR_ORACLECAT_LOG_FILE 311 NSR_ORACLECAT_MODE 312, 320 NSR_REMOVE_ON_FAILURE 312 parameters BACKUP_TAPE_IO_SLAVES 384 DB2_ALIAS 356 DB2_APPLY_NW_LEVELS 356 DB2_NODE_NAME 356 DB2_OPTIONS 357 DB2_PARTITION_LIST 357 DB2_QUIESCE 357 DB2_SESSIONS 357 DB2_TBS_LIST 357 DB2_USER 357 DB2_VENDOR_LIB_PATH 358 DB2INSTANCE 356 DB2PATH 327, 357 DBCCOPT 373 DO_LOGFILE_BACKUPS 360 DO_WHOLE_SYSTEM_BACKUP 360 INFORMIXDIR 360 INFORMIXSQLHOSTS 360 INSTHOME 358 LD_LIBRARY_PATH 373 LD_LIBRARY_PATH_64 373 LIBPATH 373 LOG_THRESHOLD 127 LOTUS_NSF_FILE 127 LOTUS_USER 363 mandatory 127, 351, 352, 356, 357, 358, 359, 360, 361, 363, 367, 369, 370, 371, 372, 373, 375, 376 Notes_ExecDirectory 363 NSR_AES_ENCRYPTION 350 NSR_APPLY_LOGS 363 NSR_ASE_PASSWORD 374 NSR_ASE_VERIFY 374 NSR_AUTO_RESTORE 363 NSR_BACKUP_ALL_EXTENSIONS 363 NSR_BACKUP_LEVEL 363, 374 NSR_BACKUP_LOGS_MODE 363 NSR_BACKUP_LOTUS_DIR 364 NSR_BACKUP_PATHS 364, 374 NSR_BUNDLING 110 NSR_CATALOGFILE 364 NSR_CHECKSUM 350 NSR_CLIENT 306, 350 NSR_COMFORT_SPAN 364 NSR_COMPRESSION 350 NSR_CROSS_MOUNT_POINTS 364 NSR_DATA_MOVER 294 NSR_DATA_VOLUME_POOL* 76, 108, 351, 369, 384 NSR_DB2_RESTORE_TABLESPACE_BKUP 358 NSR_DB2CAT_MODE 327 NSR_DBIID 364 NSR_DEBUG_LEVEL 127, 351 NSR_DEDUP_BACKUP 351 NSR_DEDUP_CACHE_ENABLED 351 NSR_DEDUP_CACHE_TAG 352 NSR_DEDUP_CHUNK_SIZE 352 NSR_DEDUP_NODE 352 NSR_DIAGNOSTIC_DEST 127, 352 NSR_DPRINTF 353 NSR_DR_BACKUP_INFO 358, 360 NSR_DR_FILE_LIST 358, 360 NSR_DUMP_LOG_OPT 374 NSR_ENCRYPTION_PHRASES 353 NSR_EXCLUDE_FILE 365, 374 NSR_EXCLUDE_LIST 365 NSR_FOLLOW_LINKS 365 NSR_GROUP 106 NSR_INCR_EXPIRATION 111 NSR_LOG_DIR 365 NSR_LOG_VOLUME_POOL 76, 358, 361, 375 NSR_LOTUS_DATA_DIR 365 NSR_MAX_START_RETRIES 358 NSR_MAX_STREAMS 294 NSR_MAX_TXN_LOGS 365 NSR_MMDB_RETRY_TIME 370 NSR_NO_BUSY_ERRORS 353 NSR_NO_MULTIPLEX 370 NSR_NO_NOTES_INIT 365 NSR_NOTES_CONNECT_TIMEOUT 366 NSR_NOTES_INI_PATH 366 NSR_NUMBER_LOGS 366 NSR_NWPATH 311, 327, 353 NSR_ORACLE_CONNECT_FILE 127, 313 NSR_ORACLE_HOME 313 NSR_ORACLE_LIB_PATH 314 NSR_ORACLE_NLS_LANG 109 NSR_ORACLE_SID 314 NSR_ORACLE_TNS_ADMIN 314 NSR_PARALLELISM 366, 375 NSR_PREFETCH_LOGS 366 456 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Index NSR_PROMOTE_FULL 375 NSR_PROXY_PFILE 370 NSR_PS_SAVE_PARALLELISM 294 NSR_RECOV_INTERACT 366 NSR_RECOV_LIST_FILE 367 NSR_RECOVER_POOL 370 NSR_RECOVER_TIME 367 NSR_RELOCATION_DEST 367 NSR_RESOURCE_DIR 367 NSR_RETENTION 91 NSR_RETENTION_DISABLED 370 NSR_RMAN_ARGUMENTS 370 NSR_SAVESET_BROWSE 91, 353 NSR_SAVESET_NAME 367 NSR_SAVESET_RETENTION 354 NSR_SERVER 106, 354 NSR_SERVER_NIC 371 NSR_SKIPDBERRORS 367 ONCONFIG 361 ORACLE_HOME 371 ORACLE_SERVICE 128 ORACLE_SID 371 ORACLE_USER 371 PATH 367, 375 PowerSnap 292, 293, 294 resource file 328 RESTORE_TYPE_ORDER 294, 305, 307 SHLIB_PATH 375 SYBASE 375 SYBASE_USER 376 TNS_ADMIN 372 USE_CONSISTENCY_CHECK 376 USER_PSWD 359, 376 parms option allocate channel command 383 configure channel command 294, 368 partioned databases (DPF) 92 partioned DB2 databases (DPF) 34 partitioned Domino server disaster recovery 237 manual backup 280 recovery 281 scheduled backup 280 password file 106 backup 227 PATH parameter 367, 375 permissions, Sybase 113 persistent settings 43, 105 PFILE 227, 228, 229 physical cluster client, proxy backups from 324 point-in-time (PIT) copies 284 point-in-time copy 28, 286, 296, 297, 303 policy browse 91 retention 91 policy uniformity 48 pool option, backup command 378 Pool resource 75, 296 pool, volume defined 75 label template for 75 pool types 75 postcommand script 228, 240 PowerSnap Modules 28, 73, 284 PowerSnap parameters 292, 293, 294 PowerSnap snapshot serverless backup 287 precedence rules for send command 383 primary storage 28, 284, 287, 290, 299, 300 primary storage platforms for snapshot 284 Probe resource attributes Command 126 Command Options 127, 128 Name 126 probe-based backup 26, 125 processes restore 290 program nsrd 65 nsrdaprobe 27, 126, 129 nsrdasv 65 nsrexecd 65 nsrindexd 67 nsroraadmin 312, 314, 315, 316, 317 nsroraclecat 310, 318, 321 nsrsnapck 318, 319, 321 savefs 65 savegrp 65 scanner 167 proxy backup 28, 284, 299 restore 287, 305 prune unwanted backups 136 pruning of DB2 snapshots 327 pruning of snapshots 35 psrollback.res file 306 R RAC nodes as storage nodes 266 RAC systems 47, 61 recover 22, 166, 209 rollforward 174 to a different instance 171 to the same instance 170 recoveries, types of multistripe 215 redirected restore 212 recovering databases not on the master device 244 master database 243 recovery from NetWorker User for Lotus browse time 192, 219 change server 195, 222 database version 192 options 194, 220 performing 190 stopping 198, 222 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 457

Index Lotus data 182 multiple Domino installations 279 partitioned Domino server 281 Recovery Catalog database connection to 106 Recovery Catalog, backup 228, 229 Recovery Manager (RMAN) backup scripts 103 commands 377 error messages 413 proxy backup scripts 292 proxy restore scripts 305 restore scripts 205 scheduled backup scripts 105, 106 recovery options number of transaction logs 236 skip Notes API 235, 236 redirected restore to different host, different instance 174 to different host, same instance 170 redo logs, mirrored 228 registry files backup 227 relocating files during proxy restores 307, 308 Remote Access attribute in Client resource 91, 297, 323 replica ID, changing 194 resource types of Client 297 Device 75 Group 88, 296 Label Template 75 Pool 75, 296 Schedule 88 Server 72 Snapshot Policy 286, 296 User Group 72 restore archived redo log 271 command 382 DB2 data 168 deduplication 26 determining required volumes 202 from secondary storage 288 Informix data 179 Informix restore types 180 instant 287, 305 multstripe 215 Oracle data 22, 24, 166, 202, 205 physical restore 181 processes 290 proxy 287, 305 redirected restore 212 rollback 288, 305, 306 Sybase data 210 RESTORE_TYPE_ORDER 330 RESTORE_TYPE_ORDER parameter 294, 305, 307 Retain Snapshots attribute in Snapshot Policy resource 309 Retention Policy attribute in Client resource 91, 297 retention policy uniformity 48 RMAN catalog 309 rman command 144, 208 RMAN repository 309 rman send command 368, 381, 383 rman.exe command 144, 208 roadmap manual backup 134 scheduled backup 156 rollback restore 288, 305, 306 rollforward recovery 174, 175 rollforward recovery with DB2 transaction logs 35 S Save Set attribute in Client resource 92, 297, 323 save set bundling 50 save sets finding timestamp 390 savefs command 65 savegroup completion report for proxy backup 301 savegrp command 65, 153 sbtio.log file 385 scanner program 167 Schedule attribute in Client resource 92, 297 Schedule resource 88 scheduled backup 24, 156 canceling 106, 157, 158 configuring Group resource 88 configuring Schedule resource 88 monitoring 159 multiple Domino installations 278 partitioned Domino server 280 roadmap 156 secondary storage 287, 288 send command 293, 368, 379 channel option 380 device_type option 380 NSR_ENV keyword 379 precedence rules 383 Server resource attributes Datazone pass phrase 72 Name 72 Parallelism 72 service nsrd 65 nsrexecd 65 nsrindexd 67 SERVICE_NAME parameter 268 set command 369 set duplex command 383, 384 setenv command 369 SHLIB_PATH parameter 375 SID_LIST_LISTENER parameter 268 silo 75 snapshot 28, 286, 296, 297, 303 458 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide

Index backup and restore operations 284 backup processes 288 deletion 331 restore 330 Snapshot attribute in Group resource 299, 300 Snapshot Policy resource 286, 296 Snapshot Pool attribute in Group resource 296 SPFILE 227, 229 SQL error messages 400 staging 50 Stop button in NetWorker Administrator program 158 stopping manual backup 151 nonresponding backup 152 scheduled backup 106, 158 stopping recovery from NetWorker User for Lotus 198, 222 storage devices Device resource 75 volume pool 75 Storage Nodes attribute in Client resource 297 Sybase restore and recovery 210 Sybase ASE Cluster Edition systems 272 Sybase Backup Server error message file 433 Sybase isql commands dump command 388, 389 load command 388, 389 SYBASE parameter 375 SYBASE_USER parameter 376 synchronization automatic catalog 318 manual catalog 318 manual backup 395 scheduled backup 107, 395 types of backup archived redo log 228, 271 manual 24, 134 NetWorker bootstrap 66, 152 scheduled 24, 156 U uniformity, policy 48 USE_CONSISTENCY_CHECK parameter 376 User Group resource 72 USER_PSWD parameter 359, 376 V vendor.cfg file 355 VENDOROPT 136 virtual cluster client, proxy backups from 323 volume pool Default pool 76 defined 75 resource 75, 296 specifying 76 types 75 volumes required for recovery 195, 221 volumes, determining for restore 202 W wizard fails to create backup, troubleshooting 395 wizard, configuration 70 Z zap DBIID 194 zap replica ID 194 T tablespace manual backup 24, 134 scheduled backup 24, 156 target database connection to 106 template file nmda_db2.cfg 347 nmda_informix.cfg 347 nmda_lotus.cfg 347 nmda_oracle.cfg 347 nmda_sybase.cfg 347 threshold procedure, sample 117 timestamp 390 TNS_ADMIN parameter 372 trace option, backup command 385 transaction logs backup 93 backup levels 38 configuration file 93 recovery with 174 rollforward recovery 93 troubleshooting 394 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide 459

Index 460 EMC NetWorker Module for Databases and Applications Release 1.0 Administration Guide