NSR-DBM-ORA V5.0. Administrator s Guide

Transcription

1 NSR-DBM-ORA V5.0 Administrator s Guide Edition August 2009

2 Comments Suggestions Corrections The User Documentation Department would like to know your opinion on this manual. Your feedback helps us to optimize our documentation to suit your individual needs. Feel free to send us your comments by to: Certified documentation according to DIN EN ISO 9001:2000 To ensure a consistently high quality standard and user-friendliness, this documentation was created to meet the regulations of a quality management system which complies with the requirements of the standard DIN EN ISO 9001:2000. cognitas. Gesellschaft für Technik-Dokumentation mbh Copyright and Trademarks Base of NSR-DBM-ORA V5.0 / this manual: EMC NetWorker, Release 7.5, Multiplatform Version, Administrator s Guide, Copyright by EMC Corporation. Copyright Fujitsu Technology Solutions All rights reserved. Delivery subject to availability; right of technical modifications reserved. All hardware and software names used are trademarks of their respective manufacturers. Microsoft, Microsoft Windows, and Windows Server are U.S. registered trademarks of Microsoft Corporation. HP-UX Release and later and HP-UX Release and later (in both 32 and 64-bit configurations) on all HP 9000 computers are Open Group UNIX 95 branded products. AMD Opteron(TM) is the trademark owned by Advanced Micro Devices, Inc. Intel, Intel Itanium, Intel Pentium, and Intel Xeon are trademarks or registered trademarks of IntelCorporation or its subsidiaries in the United States and other countries. EMC and NetWorker are trademarks of EMC Corporation. Oracle is a registered US trademark of Oracle Corporation, Redwood City, California. NetApp, Data ONTAP, SnapDrive, SnapManager, SnapMirror, SnapRestore, and WAFL are registered trademarks and Network Appliance Inc. in the U.S. and other countries. Fujitsu and the Fujitsu Logo are trademarks of Fujitsu Limited. Product Number: This manual is printed on paper treated with chlorine-free bleach.

3 Contents Preface Chapter 1 Introduction About this guide Naming conventions used in this guide New features and changes Improved monitoring of manual operations in NMC Improved reporting of proxy operations in NMC Improved security measures for sensitive data IPv6 support (regular backups and restores) NetWorker core debug messages New platform support for proxy operations NSR-DBM-ORA parameter changes NWORA resource file requirements Oracle operating system authentication Restore from a specific volume pool Importance of backups Product features Scheduled compared to manual backups Deduplication backups and restores Probe-based backups Proxy backups and restores VMware support Archived redo log backups Control file autobackup Automatic channel allocation Backup and restore optimization Backup copies Backup of backup sets Cluster and RAC backups and restores Configuration wizards Internationalization (I18N) Oracle Data Guard support Parallelism Policy uniformity Restartable backups Retention policies Save set bundling Other Oracle features NSR-DBM-ORA V5.0 Administrator s Guide 3

4 Software used in the NSR-DBM-ORA environment...44 NetWorker software NSR-DBM-ORA software NetWorker PowerSnap Module software Oracle backup and recovery system NSR-DBM-ORA components...48 NSR-DBM-ORA backup and restore processes...49 Regular scheduled backup processes Regular manual backup processes Deduplication backup processes Regular restore processes Deduplication restore processes Chapter 2 Software Configuration Configuration roadmap Verify the Oracle Server configuration Verify the NetWorker resources NetWorker Server resource NetWorker user group privileges NetWorker Schedule resource NetWorker Device resources NetWorker volume pools Firewall support Configuring I18N support Requirements for I18N support Configure I18N support Migrating a legacy configuration with the nsrnmoadmin command...65 Requirements for using the nsrnmoadmin command for migration Migration command syntax and options Configuring a backup with the NMC wizard...68 About the backup configuration wizard Requirements for using the backup configuration wizard Configure a backup with the wizard Configuring a backup with the NMC legacy method...70 About backup configuration with the legacy method Create RMAN scripts for backups Customize the nsrnmo script Configure a Group resource with NMC Configure a Schedule resource with NMC Configure a Client resource with NMC Configure save set bundling Configure policy uniformity Configuring a deduplication backup Requirements for a deduplication backup Best practices for a deduplication backup Configure a deduplication backup Configuring a probe-based backup Requirements for a probe-based backup Configure a probe-based backup NSR-DBM-ORA V5.0 Administrator s Guide

5 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Backup Procedures Manual backup procedures Requirements for a manual backup Manual backup through the RMAN command line interface Manual backup through Oracle Enterprise Manager Backup Management Tools NetWorker server bootstrap backup Cancel a manual backup Monitor a manual backup Scheduled backup procedures Test a scheduled backup Cancel a scheduled backup Monitor a scheduled backup Automation of NSR_SERVER and NSR_GROUP parameter settings Regular backup information in NetWorker indexes Deduplication backup information in NetWorker indexes Data Restore and Recovery About restore and recovery NetWorker indexes and policies used for restores Recovery configuration wizard RMAN scripts for restore and recovery Performing an Oracle data restore and recovery Requirements for an Oracle data restore Restore through the RMAN command line interface Restore with Oracle Enterprise Manager Backup Management Tools Perform an Oracle data recovery Disaster Recovery About disaster recovery Preparing an Oracle database for disaster recovery Create the DBID text file Set up a postcommand script for backup of Oracle-related files Set up RMAN backups of the database and related files Set up RMAN backups of Recovery Catalog Performing a disaster recovery NetWorker server recovery Oracle disaster recovery to a new host Sample postcommand script Cluster and RAC Systems Considerations for cluster and RAC systems Parameters in the RMAN script or session NetWorker software configuration Backup failover Cluster systems Roadmap for backup/restore configuration in a cluster system Backup failover RAC systems RAC terminology RAC backups and restores Roadmap for backup/restore configuration in a RAC system NSR-DBM-ORA V5.0 Administrator s Guide 5

6 Setting up RAC nodes to back up to a local storage node Connect-time failover Creating RMAN backup scripts Creating RMAN restore scripts Archived redo logs Chapter 7 Appendix A Appendix B Proxy Backups and Restores Overview of proxy backups and restores Types of proxy backups Types of proxy restores Proxy backup and restore system Proxy backup processes Scheduled proxy backup Proxy restore processes Instant restore or rollback Restore from secondary storage Software configuration roadmap Basic configurations Additional configurations for proxy operations Proxy backup requirements Checking configuration consistency Performing proxy backups Proxy backup information in the NetWorker indexes Entries in the client file index Entries in the media database NWORA resource file backup in the NetWorker indexes Proxy restore requirements Creating RMAN scripts for proxy restores Performing proxy restores Relocating files during proxy restores Restoring to a different host Point-in-time recoveries without a Recovery Catalog Catalog synchronization for proxy backups Extra entries in the catalogs Control file versus recovery catalog The NWORA resource file Automatic catalog synchronization with the nsroraclecat program Proxy backups and restores on cluster systems Proxy backup failover Proxy backups from a virtual cluster client Proxy backups from a physical cluster client Restores from proxy backups on a cluster system Parameters in an RMAN Session Setting the NSR* parameters NSR* parameter definitions RMAN Commands The delete expired backup command The change...crosscheck and crosscheck commands The pool option of the backup command NSR-DBM-ORA V5.0 Administrator s Guide

7 The send command Syntax rules Two ways to run the send command Precedence rules The set duplex command The trace option of the backup command Appendix C Appendix D Troubleshooting and Error Messages Troubleshooting tips RMAN error messages NSR-DBM-ORA error messages Error messages from the libnwora library Error messages from the nsrnmoadmin program Error messages from the nsrnmoinfo program Error messages from the nsrnmoprobe program Error messages from the nsrnmostart program Command Reference Glossary Index NSR-DBM-ORA V5.0 Administrator s Guide 7

8 8 NSR-DBM-ORA V5.0 Administrator s Guide

9 Preface This guide provides information on how to install, configure and manage the Fujitsu NSR-DBM-ORA release 5.0 software for Oracle data storage management on Linux or Solaris operating systems. Audience Related documentation This document is intended for use by system administrators and Oracle database administrators (DBAs) who are responsible for installing software and maintaining the Oracle Server backup and recovery systems. Operators who monitor Oracle database backups may also find this document useful. Readers of this document are expected to be familiar with the following topics: Oracle terminology and concepts, especially those related to Oracle database backup and recovery. Backup and recovery procedures on an Oracle Server. Disaster recovery procedures on an Oracle Server. The complete set of the Fujitsu NetWorker documentation can be found at Follow the link NetWorker backup solution. Most of the documents are in Adobe Portable Document Format (PDF), and can be viewed by downloading and installing the Adobe (Acrobat) Reader as of V5.0. The Reader is available from Adobe at To install and use the Reader on the platform of your choice, refer to the instructions at the Adobe website. The information in this guide is best used in conjunction with information from the following sources: NetWorker PowerSnap Module Installation and Administrator s Guide (for the appropriate PowerSnap Module) NetWorker Administrator s Guide (for the NetWorker server version) NetWorker Administrator program Online Help NetWorker Command Reference Guide (for NetWorker commands) Man pages on UNIX systems (for NetWorker and NetWorker Module commands) Oracle Server documentation Oracle database backup and recovery documentation Preface 9

10 Preface Conventions used in this document This document 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 The following type style conventions are used in this document: Normal Used in running (nonprocedural) text for: Names of interface elements (such as names of windows, dialog boxes, buttons, fields, and menus) Names of resources, attributes, pools, Boolean expressions, buttons, DQL statements, keywords, clauses, environment variables, functions, utilities URLs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, notifications Bold Used in running (nonprocedural) text for: Names of commands, daemons, options, programs, processes, services, applications, utilities, kernels, notifications, system calls, man pages Used in procedures for: Names of interface elements (such as names of windows, dialog boxes, buttons, fields, and menus) What the user specifically selects, clicks, presses, or types Italic Used in all text (including procedures) for: Full titles of publications referenced in text Emphasis (for example, a new term) Variables Courier Used for: System output, such as an error message or script URLs, complete paths, filenames, prompts, and syntax when shown outside of running text Courier bold Used for: Specific user input (such as commands) Courier italic Used in procedures for: Variables on the command line User input variables < > Angle brackets enclose parameter or variable values supplied by the user [ ] Square brackets enclose optional values Vertical bar indicates alternate selections - the bar means or { } Braces indicate content that you must specify (that is, x or y or z)... Ellipses indicate nonessential information omitted from the example 10 NSR-DBM-ORA V5.0 Administrator s Guide

11 Preface Where to get help Company, product, and technical information can be obtained as follows. Information and services Information and documentation on Fujitsu NetWorker products can be obtained as follows: Resource Product information, documentation and downloads NetWorker manuals Release notices Software patches Address Follow the links Storage solutions - Storage software. Follow the links Storage solutions - Storage software. Follow the links NetWorker - Networker patches. Customer service Resource NetWorker training Address technical-training@ts.fujitsu.com Support phone Support fax Technical support The Support section of the Fujitsu Technology Solutions web site at provides links with contact information and information about available support programs. If you have an active support agreement, you may contact your service provider. If you do not have an active support agreement, contact your Fujitsu Technology Solutions sales representative to purchase a service contract or updates. 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: manuals@ts.fujtsu.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. NSR-DBM-ORA V5.0 Administrator s Guide 11

12 Preface 12 NSR-DBM-ORA V5.0 Administrator s Guide

13 1 Introduction This chapter includes the following major sections: About this guide Naming conventions used in this guide New features and changes Importance of backups Product features Software used in the NSR-DBM-ORA environment NSR-DBM-ORA components NSR-DBM-ORA backup and restore processes Introduction 13

14 Introduction About this guide This guide is organized as follows: Chapter 1, Introduction (this chapter) provides an overview of the main features of NSR-DBM-ORA release 5.0. Chapter 2, Software Configuration describes the procedures for configuring NSR-DBM-ORA backups and restores. Chapter 3, Backup Procedures describes the procedures for running manual NSR-DBM-ORA backups. Chapter 4, Data Restore and Recovery describes the procedures for configuring and running scheduled NSR-DBM-ORA backups. Chapter 5, Disaster Recovery describes the procedures for restoring and recovering from NSR-DBM-ORA backups. Chapter 6, Cluster and RAC Systems describes the procedures for configuring and running NSR-DBM-ORA backups and restores on cluster, OPS, and RAC systems. Chapter 7, Proxy Backups and Restores describes the procedures for proxy backups and restores of Oracle data on specific primary storage devices, performed by using NSR-DBM-ORA and the required PowerSnap Module software. Appendix A, Parameters in an RMAN Session describes the parameters that can be set for NSR-DBM-ORA backups and restores. Appendix B, RMAN Commands describes RMAN commands that concern the NSR-DBM-ORA software. Appendix C, Troubleshooting and Error Messages describes troubleshooting guidelines, RMAN error messages, and NSR-DBM-ORA error messages. Appendix D, Command Reference includes the text from the man pages that accompany NSR-DBM-ORA. 14 NSR-DBM-ORA V5.0 Administrator s Guide

15 Introduction Naming conventions used in this guide Consider the naming conventions used throughout this guide: Oracle Server host refers to the host where both the Oracle Server and NSR-DBM-ORA software are installed. Proxy backup or restore refers to an Oracle RMAN proxy copy backup or restore that is implemented by using snapshot technologies through the PowerSnap Module software. Unlike the NetWorker software, which uses the term recover for all data retrieval activities, Oracle distinguishes between restoring and recovering a database: Restore refers to retrieving individual datafiles from backup and storing the files on disk. Recover refers to applying the redo logs to make the database consistent. This guide follows the Oracle terminology. Regular backup or restore refers to an NSR-DBM-ORA backup or restore of Oracle data that does not use snapshot technologies through the PowerSnap Module software. "UNIX" refers to both UNIX and Linux operating systems, unless specified otherwise. New features and changes NSR-DBM-ORA release 5.0 supports the following new features: Deduplication backups and restores, performed by the NSR-DBM-ORA, NetWorker server, and Avamar server software. Deduplication backups and restores on page 20 provides more information. Probe-based backups (also known as event-based backups) that are triggered when specified conditions are met. Probe-based backups on page 21 provides more information. Regular Oracle backups and restores on a VMware Virtual Machine on an ESX server, including support of the following advanced features: Distributed Resource Scheduler (DRS) VMotion VMware support on page 23 provides more information. Backup and recovery configuration wizards that are integrated with the NetWorker Management Console (NMC) release 7.5 or later. Configuration wizards on page 28 provides more information. Use of the nsrnmoadmin command to migrate a legacy backup configuration to the configuration framework supported by the NMC-based backup configuration wizard. Migration of configurations for the wizard on page 30 provides more information. Internationalization support for both regular and proxy backups and restores, with specified limitations. NSR-DBM-ORA release 4.5 supported I18N for regular backups and restores. NSR-DBM-ORA release 5.0 extends the I18N support for proxy backups and restores with a supported PowerSnap Module release. Internationalization (I18N) on page 31 provides more information. Naming conventions used in this guide 15

16 Introduction Improved monitoring of manual operations in NMC NSR-DBM-ORA release 5.0 supports the improved monitoring of manual backups and restores in NMC. Detailed displays of information about manual NSR-DBM-ORA backups and restores are available under the Sessions tab of the NMC Monitor window. Improved reporting of proxy operations in NMC The Group Details window in NMC reports detailed information for proxy backups. The information includes a complete listing of all the save set sessions run, the total size of the backups, and the sizes of the bootstrap and index save sets. The Sessions tab of the Monitor window in NMC reports detailed information for proxy restore sessions. Improved security measures for sensitive data NSR-DBM-ORA release 5.0 uses NetWorker 7.5 or later lockbox services and encryption to ensure the secure storage and transfer of sensitive data and passwords: When you configure NSR-DBM-ORA backups through the NMC-based configuration wizard, the wizard uses the lockbox services to store sensitive data. When you migrate a legacy backup configuration to the configuration framework supported by the NMC-based wizard, the migration operation uses the lockbox services to store sensitive data. Sensitive data and passwords are encrypted before being transferred by the configuration wizards and NSR-DBM-ORA programs such as nsrnmoadmin, nsrnmoprobe, and nsrnmostart. Lockbox password management is implemented through the NetWorker server. IPv6 support (regular backups and restores) NSR-DBM-ORA release 5.0 provides new support of Internet Protocol version 6 (IPv6) for regular (nonproxy) backups and restores. The NetWorker Release Notice provides details on the use of NetWorker software in an IPv6 environment. NetWorker core debug messages NSR-DBM-ORA release 5.0 includes a new parameter, NSR_DPRINTF, for use with Tech Support only. You can set the parameter to specify that NetWorker core debug messages are printed to the file specified by NSR_DEBUG_FILE. (If NSR_DEBUG_FILE is not set, the debug messages are printed to the default location.) Note: The NSR_DPRINTF parameter must be set through the parms options, not through the send command. The NSR_DEBUG_LEVEL parameter must also be set. 16 NSR-DBM-ORA V5.0 Administrator s Guide

17 Introduction New platform support for proxy operations NSR-DBM-ORA release 5.0 provides new support of the Linux AMD64/EM64T platform for proxy backups and restores. NSR-DBM-ORA parameter changes NSR-DBM-ORA release 5.0 supports the following new parameters: NSR_DEDUP_BACKUP NSR_DEDUP_CACHE_ENABLED NSR_DEDUP_CACHE_TAG NSR_DEDUP_CHUNK_SIZE NSR_DEDUP_NODE NSR_DPRINTF NSR_RECOVER_POOL ORACLE_USER The NSR_ORACLE_NLS_LANG parameter is no longer required to enable use of the configuration wizard with internationalized NSR-DBM-ORA in a non-english user locale. NSR-DBM-ORA release 5.0 no longer supports the following parameters: NSR_RMAN_OUTPUT NSR_TMPDIR NWORA resource file requirements In NSR-DBM-ORA release 5.0, the NWORA resource file requirements are changed from previous NSR-DBM-ORA releases: The NWORA resource file is no longer mandatory for performing any type of NSR-DBM-ORA backup. The NWORA resource file is only required to enable the following NSR-DBM-ORA features: Catalog synchronization for proxy backups Policy uniformity Save set bundling Oracle operating system authentication NSR-DBM-ORA release 5.0 supports Oracle operating system authentication to connect to RMAN. You can enable a scheduled NSR-DBM-ORA backup for operating system authentication by setting the ORACLE_USER parameter to the username of the Oracle operating system user, which is set up to connect to the Oracle database through operating system authentication. New features and changes 17

18 Introduction Operating system authentication is supported for a scheduled backup configured through the legacy method (without the wizard). The operating system authentication is not supported for the following: A scheduled backup configured through the new configuration wizard. A probe-based backup. A scheduled proxy backup. Restore from a specific volume pool By default, NSR-DBM-ORA and NetWorker use configuration settings and information in the media database to determine the backup volume to use for an NSR-DBM-ORA restore. NSR-DBM-ORA release 5.0 supports the alternative restore method whereby you set the NSR_RECOVER_POOL parameter in the RMAN restore script to specify data restore from a specified volume pool if there are multiple copies (clones) of the backup on different volume pools. The NSR_RECOVER_POOL parameter is not supported for proxy restores. 18 NSR-DBM-ORA V5.0 Administrator s Guide

19 Introduction 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 necessitate database restores from backup storage media. A viable backup strategy can help in the recovery from disastrous situations. Database administrators must recognize the importance of performing regular backups of database files and frequent backups of archived redo logs. If all archived redo logs are lost, a database can be recovered only to the time of the last consistent backup. Without backups and archived redo logs, the database cannot be recovered at all. Product features The following sections describe major features of NSR-DBM-ORA, Oracle Recovery Manager (RMAN), and Oracle Server software. Certain sections refer to the send command, which is used to set parameters in the RMAN script for an NSR-DBM-ORA backup, as described in The send command on page 201. The Oracle backup and recovery documentation provides more details on RMAN backups and restores and Oracle product features. Scheduled compared to manual backups An NSR-DBM-ORA backup can be either a scheduled or manual (unscheduled) backup: A scheduled NSR-DBM-ORA backup includes the following features: The backup is initiated by the NetWorker server. The backup start time depends on the settings in the NetWorker resources. A regular scheduled backup starts at a time specified in the NetWorker Group resource. A probe-based backup (or event-based backup) is a type of scheduled backup that starts when specified conditions are met, as described in Probe-based backups on page 21. A proxy backup is only supported by using a scheduled backup, as described in Proxy backups and restores on page 22. A manual NSR-DBM-ORA backup includes the following features: The backup is initiated by a user on the NSR-DBM-ORA host through an Oracle backup utility, which can be RMAN or Oracle Enterprise Manager. The backup is performed by running the Oracle utility from the operating system command line. For example, a user starts a manual NSR-DBM-ORA backup by running an RMAN backup script from the command line. Chapter 2, Software Configuration, provides details on the configuration of both scheduled and manual backups. Importance of backups 19

20 Introduction Chapter 3, Backup Procedures, provides details on scheduled and manual backup procedures. Deduplication backups and restores NSR-DBM-ORA 5.0 software provides new support for deduplication backups and restores. The NSR-DBM-ORA Release Notice provides details on the NetWorker requirements for the support of deduplication operations. Main features of deduplication operations An EMC Avamar server (on Linux) interacts with the NetWorker server and NSR-DBM-ORA 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 NSR-DBM-ORA clients. (The Avamar server must also be available when a deduplication client resource is created.) The initial backup to a deduplication node (Avamar server) will be a full backup. During subsequent deduplication backups, the Avamar server identifies redundant data blocks on the NSR-DBM-ORA client host and backs up only the unique blocks (not entire files) that contain changes. Only a single instance of any unique (atomic in Avamar terminology) data block is maintained on the Avamar server. Since data deduplication is performed on the client host, deduplication backups typically require less time, network bandwidth, and storage space than regular NSR-DBM-ORA backups. The Avamar client-side binary, nsravtar, is installed on the NSR-DBM-ORA client with the NetWorker client software. During a deduplication backup, the nsravtar process sends the deduplicated client data to the Avamar server. A deduplication NSR-DBM-ORA backup uses a hash cache on the client side. The Avamar and NetWorker documentation provides more details about caches in deduplication backups. The following sections describe the processes involved in deduplication backups and restores: Deduplication backup processes on page 52 Deduplication restore processes on page 55 A deduplication backup can be a manual or scheduled backup, including a probe-based backup. The application of browse and retention policies and the selection of media pools is the same for a deduplication backup as for a regular NSR-DBM-ORA backup. Since only the backup metadata (hash ID) is stored on the NetWorker backup device (generating a very small save set), the device should be configured as an advanced file type device (AFTD). The NetWorker Administrator s Guide provides more information. You must configure a scheduled or manual deduplication backup according to Configuring a deduplication backup on page 86. Deduplication backup information in NetWorker indexes on page 109 describes the backup information stored in the NetWorker indexes, and how to delete the backups. 20 NSR-DBM-ORA V5.0 Administrator s Guide

21 Introduction Features not supported with deduplication operations Deduplication operations do not support the following: Oracle proxy backups or restores. Cluster or RAC backups or restores. Internet Protocol version 6 (IPv6). AES encryption of deduplicated data through the NSR_AES_ENCRYPTION parameter. Checksumming of deduplicated data through the NSR_CHECKSUM parameter. Compression of deduplicated data through the NSR_COMPRESSION parameter. If NSR_AES_ENCRYPTION, NSR_CHECKSUM, or NSR_COMPRESSION is set for a deduplication backup, NSR-DBM-ORA applies the AES encryption, checksumming, or compression, respectively, to only the metadata that is stored on the NetWorker storage node. Cloning or staging of deduplicated data on the Avamar server. Only the metadata stored on the NetWorker storage node can be cloned or staged. However, deduplicated save sets on the Avamar server can be replicated to another Avamar server that has been configured as a replication node by Fujitsu Technology Solutions Technical Support representatives. Avamar documentation and the NetWorker Administrator s Guide provide details on replication of deduplication backups. Probe-based backups NSR-DBM-ORA 5.0 software provides new support for probe-based backups (also known as event-based backups). A probe-based backup is a type of scheduled backup: The NetWorker server starts a regular scheduled backup based on a time interval. The NetWorker server starts a probe-based backup when specified conditions are met. Probe-based backups are not supported for proxy backups or cluster/rac environments. Workflow of probe-based backups A probe-based NSR-DBM-ORA 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. Product features 21

22 Introduction 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 There are two different types of probes: An NSR-DBM-ORA probe. The NSR-DBM-ORA probe is implemented through the NSR-DBM-ORA program nsrnmoprobe. The nsrnmoprobe program returns a successful result (signifying that the condition being checked has been met) when it detects either of the following: The number of Oracle redo logs generated since the previous probe-based backup exceeds a number known as the change threshold. A new database incarnation (reset log) has occurred since the previous probe-based backup. User-defined probes. A user-defined probe checks if any other user-defined condition (other than the number of generated Oracle redo logs) has been met since the previous probe-based backup. (This option requires more advanced configuration.) To implement a user-defined probe, you must create a new script or program that checks for the condition, as described in Configuring a probe-based backup on page 90. You must configure the required parameters and NetWorker resources to specify the probe interval, backup window, and any other settings for a probe-based backup. Configuring a probe-based backup on page 90 provides details on how to configure a probe-based backup. Proxy backups and restores Proxy backups and restores provide continuous snapshot-based protection and availability of Oracle data on specific types of primary storage. A proxy operation involves both the NSR-DBM-ORA software and a specific PowerSnap Module. Proxy backups create point-in-time copies or snapshots of Oracle data, store the snapshots on primary storage devices supported by the PowerSnap Modules (for Symmetrix, CLARiiON, and so on), and optionally back up the data to secondary storage (such as tape) from the point-in-time copies. Proxy restores are used to restore the Oracle data that is backed up during the proxy backups. 22 NSR-DBM-ORA V5.0 Administrator s Guide

23 Introduction Chapter 7, Proxy Backups and Restores, provides more information on proxy backup and restore operations. VMware support NSR-DBM-ORA 4.5 provided support for regular backups and restores of an Oracle database installed on a VMware Virtual Machine (VM) on an ESX server. NSR-DBM-ORA 5.0 extends this support with the support for the following advanced features of a VMware ESX server: VMotion The VMotion feature enables migration of virtual machines from one ESX server to another while the servers are on. The migration is seamless to the applications running on the virtual machines, and NSR-DBM-ORAa user does not experience any disconnection. If a migration occurs during an NSR-DBM-ORA 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 NSR-DBM-ORA backup or restore, the backup or restore is not interrupted. The NSR-DBM-ORA Release Notice provides details on the NetWorker requirements for the support of VMware features. 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. Ensure that the NSR-DBM-ORA backups of archived redo logs are enabled. Backing up all archived logs from each node on page 142 provides a sample script to back up the archived redo log files in a RAC system. The appropriate Oracle backup and recovery documentation provides more information on setting up and running archived redo log backups. Control file autobackup RMAN performs a control file autobackup after each RMAN backup command if the control file autobackup has been enabled with the configure controlfile autobackup on command. Use this feature to restore the backup entries contained in the control file when the control file is lost and the Recovery Catalog is not available. Specify persistent settings for the control file autobackups with the configure controlfile autobackup command. For example, enable control file autobackup and specify the persistent setting for the format of the control file autobackup name with the following commands: Product features 23

24 Introduction configure controlfile autobackup on configure controlfile autobackup format for device type sbt_tape to /NMO_%f/ If the control file autobackup is set to on and the RMAN backup is performed with NSR-DBM-ORA, the control file autobackup will also be performed with NSR-DBM-ORA. As a result, one or more channels of device type sbt_tape must be allocated for the restore. Note: Oracle also supports autobackup of the current server parameter file together with control file autobackup. 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 NSR-DBM-ORA 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 NSR-DBM-ORA. 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 NSR-DBM-ORA backup. Do not use the send command or option to set the NSR* parameters for automatic channels if you plan to use scheduled backups. Table 10 on page 191 lists all the NSR* parameters and their requirements. Example 1 Using the configure channel command with parms option for automatic channels Automatic channels are configured for NSR-DBM-ORA backups with the NetWorker server server1.fujitsu.com by typing the following configure channel...parms... command: configure channel device type sbt_tape parms ENV=(NSR_SERVER=server1.fujitsu.com ) This command sets the default parameters for all the automatic channels. 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_GROUP for each channel) by typing the configure channel n device type...parms... command, where n represents a channel number. An NSR-DBM-ORA debug file is specified for the second automatic channel by typing the following configure channel command: configure channel 2 device type sbt_tape parms ENV=(NSR_DEBUG_FILE=/db/logs/backup.log) 24 NSR-DBM-ORA V5.0 Administrator s Guide

25 Introduction 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 NSR-DBM-ORA backups and restores, run the crosscheck command regularly to synchronize the Recovery Catalog and NetWorker indexes. This ensures that backups expired by the NetWorker server are also marked as expired in the Recovery Catalog and RMAN does not skip a backup when a referenced backup has already expired in NetWorker. The restore optimization function prevents RMAN from restoring a file if the original file is already in the correct location and contains the expected information. Note: To force a restore that would otherwise be skipped due to restore optimization, use the force option in the restore command. Backup copies! IMPORTANT If more than one RMAN channel is used for backup copies of an NSR-DBM-ORA 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, NSR-DBM-ORA does not support the use of RMAN backup copies commands during scheduled backups. NSR-DBM-ORA supports backup copies with manual backups only. Use the RMAN commands for backup copies only during manual backups when the parameters NSR_SERVER, NSR_DATA_VOLUME_POOL, NSR_DATA_VOLUME_POOL1, NSR_DATA_VOLUME_POOL2, and NSR_DATA_VOLUME_POOL3 are set with the parms option, not with the send command or option. The set duplex command is deprecated (no longer supported by Oracle, but still functional in some Oracle releases). The Oracle documentation provides more details. Despite the fact that RMAN provides different commands for duplexing backups, the rules for duplexing through NSR-DBM-ORA 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 205 provides more information on the set duplex command and setting up NetWorker pools for each copy. Product features 25

26 Introduction 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 NSR-DBM-ORA. For example, specify persistent settings for duplex copies of datafiles and archived redo logs (respectively) in NSR-DBM-ORA backups with the following types of configure commands: configure datafile backup copies for device type sbt_tape to 2 configure archivelog backup copies for device type sbt_tape to 2 The backup command with the copies option applies to objects within the backup command. The backup...copies setting takes precedence over the persistent settings in the configure...backup copies command. The set backup copies command applies to all backup objects in the same run job. In the following examples, the parms option is used to configure the channel and set the required parameters. These sample scripts must be invoked manually with RMAN, for example, by using the following command: rman cmdfile script_name Example 3 Using the set backup copies command in the RMAN script The following RMAN script uses the set backup copies command to generate the backup copies. The parameters are set with the parms option, as required. The RMAN script must be invoked for a manual backup, not a scheduled backup: run { set backup copies 4; allocate channel ch1 parms ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmo1, NSR_DATA_VOLUME_POOL1=nmo2, NSR_DATA_VOLUME_POOL2=nmo3, NSR_DATA_VOLUME_POOL3=nmo4) ; backup format '%d_%u' tag tag_name (tablespace 'SYSTEM' ); release channel ch1; } Example 4 Using automatic channels for backup copies The following configure commands are used to configure RMAN automatic channels. (The configure commands could also be included in the RMAN script.) The configure...backup copies command generates the backup copies. The parameters are set with the parms option, as required. The RMAN script must be invoked for a manual backup, not a scheduled backup: configure default device type to sbt_tape ; configure datafile backup copies for device type sbt_tape to 4; configure channel device type sbt_tape parms ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmo1, NSR_DATA_VOLUME_POOL1=nmo2, NSR_DATA_VOLUME_POOL2=nmo3, NSR_DATA_VOLUME_POOL3=nmo4) ; 26 NSR-DBM-ORA V5.0 Administrator s Guide

27 Introduction The RMAN script invoked for the manual backup is as follows: connect target 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, NSR-DBM-ORA 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 Cluster and RAC backups and restores The NSR-DBM-ORA software supports backups and restores of cluster and Real Application Cluster (RAC) systems for high availability and parallelism. A cluster system typically includes multiple nodes connected by a shared SCSI bus to which common storage is attached. Cluster services such as disk services can be defined and assigned their own IP addresses and names (virtual hosts). The services and their associated storage can migrate for failover between the physical nodes in the cluster. After a cluster service is configured as a NetWorker client, NSR-DBM-ORA can be used with NetWorker server software to back up and restore an Oracle database associated with the service, independent of the actual node that provides the service. A RAC system enables multiple Oracle instances across multiples nodes to access the same Oracle database at the same time. Oracle RAC is based on a cluster software infrastructure that provides concurrent access to the same storage and the same set of datafiles from all nodes in the cluster. All the database files reside on cluster-aware shared disks. After RAC and the associated cluster system are properly configured, NSR-DBM-ORA enables Oracle backups on either a single node or several nodes of the RAC system. A parallel Oracle backup uses Oracle instances running in parallel on multiple nodes of the cluster. NSR-DBM-ORA software supports restores of the Oracle data to any physical node in the cluster, regardless of which physical node originally performed the backup. Chapter 6, Cluster and RAC Systems, provides more information on cluster and RAC systems and how to configure the systems for Oracle backup and restore operations that use the NSR-DBM-ORA software. Product features 27

28 Introduction Configuration wizards NSR-DBM-ORA 5.0 software supports new backup and recovery configuration wizards that are integrated with the NetWorker Management Console (NMC). The configuration wizards used in NSR-DBM-ORA release 4.5 or earlier are replaced by the NMC-based wizards in NSR-DBM-ORA release 5.0. Configuration wizard plug-in components are installed with the NSR-DBM-ORA software on the NSR-DBM-ORA client host. NMC loads the NSR-DBM-ORA wizard plug-in at run time. You can run the NSR-DBM-ORA 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. Main features of the wizards The configuration wizards can be used to configure the following for an NSR-DBM-ORA client: Scheduled Oracle backups (either typical or customized). Configuring a backup with the NMC wizard on page 68 provides details on using the backup configuration wizard. RMAN scripts for Oracle data restores to the original host. RMAN scripts for Oracle database duplication to either a local or remote host. Recovery configuration wizard on page 112 provides details on the recovery configuration wizard. The configuration wizards support NetWorker servers and clients in a stand-alone or cluster environment. The new wizards provide improved security and ease of management for backup and recovery configurations, compared to the wizards from NSR-DBM-ORA release 4.5 or earlier. Features of the backup configuration wizard The backup configuration wizard can perform the following: Configure a new NetWorker Client resource for an NSR-DBM-ORA backup. Configure a new or use an existing NetWorker Group resource for the backup Client resource. Configure new or use existing browse and retention policies for the backup Client resource. Optionally save a copy of the configuration settings from the Client resource to a nsrnmo script or RMAN script. Modify a backup configuration that was created with the NMC-based NSR-DBM-ORA configuration wizard. Modify a backup configuration that was created either with the wizard from NSR-DBM-ORA release 4.5 or earlier, or with the legacy method, but only after the configuration has been migrated according to Migration of configurations for the wizard on page NSR-DBM-ORA V5.0 Administrator s Guide

29 Introduction Note: NSR-DBM-ORA 5.0 still supports the legacy method of backup configuration whereby you manually create a nsrnmo script and RMAN script, set any required parameters in the NWORA resource file, and configure the NetWorker resources with NMC (without the wizard). Configuring a backup with the NMC legacy method on page 70 describes the legacy configuration method. Configuring a backup with the NMC wizard on page 68 provides information on using the wizard to create or modify a backup configuration. Features of the recovery configuration wizard Features of the recovery configuration wizard on page 113 provides information on the features of the recovery configuration wizard. Backup configuration storage with the wizard The backup configuration wizard stores the configuration information in a new hidden attribute named Backup Config in the NetWorker Client resource. Do not modify the new attribute manually. If you use the wizard to create a backup configuration, you must use the wizard to modify the configuration. In a backup configuration created with the wizard, the Client resource stores the parameters and RMAN commands (except for sensitive data, such as passwords) that would have been stored in the nsrnmo and RMAN scripts and NWORA resource file in NSR-DBM-ORA release 4.5 or earlier. Note: The backup configuration wizard stores sensitive data securely by using NetWorker lockbox services. The wizard does not automatically generate a nsrnmo script and RMAN script, but provides an option to save configuration settings to a nsrnmo script or RMAN script on disk. These scripts are meant for reference use only. When you run a backup that was configured through the wizard, the backup does not access any nsrnmo or RMAN script file that the wizard saved to disk. Instead, the backup accesses the configuration information that the wizard stored in the Client resource. The wizards do not store any database connection passwords in any RMAN scripts that are saved to disk. The backup configuration wizard also sets the following values in the Client resource: Backup Command attribute is set to: nsrnmostart -C [-c virtual_client] Save Set attribute is set to: RMAN:/<database_Net_service_name>_level[/<name_of_first_tablespace _or_datafile>] where: database_net_service_name is the the name of the Oracle database to be backed up. level is the Oracle backup level (full, incr_differential, or incr_cumulative). name_of_first_tablespace_or_datafile is the name of the first tablespace or datafile in the backup list. This name is included in Save Set attribute only if a partial database (subset of the entire database) is selected for backup. Product features 29

30 Introduction Features not supported with the wizards The configuration wizards cannot perform the following: Configure backups or restores in a RAC environment. Configure proxy backups or restores that require a PowerSnap Module. Proxy backups and restores must be configured without the wizard, as described in Chapter 7, Proxy Backups and Restores. Configure two different database backups in the same Client resource. A separate Client resource must be created for each database to be backed up on the same client host. Modify a backup configuration that was created either with the wizard from NSR-DBM-ORA 4.5 or earlier, or with the legacy method, unless the configuration has been migrated according to Migration of configurations for the wizard on page 30. Migration of configurations for the wizard The backup configuration wizard stores the scheduled backup configuration in the Client resource by using a configuration storage framework that is incompatible with the configurations created either through the wizard from NSR-DBM-ORA release 4.5 or earlier, or through a legacy method (without a wizard). The backup configuration wizard can modify only the following types of backup configurations: Configurations created with the new wizard. Configurations migrated to the configuration storage framework that is supported by the new wizard. If you have a backup configuration that was created with the wizard from NSR-DBM-ORA release 4.5 or earlier, or with a legacy configuration method, you must migrate the configuration before you can use the new wizard to modify it. The recommended migration method is to use the nsrnmoadmin command, as described in Migrating a legacy configuration with the nsrnmoadmin command on page 65. Note: Migration of a proxy backup configuration is not supported. Requirements for using the nsrnmoadmin command for migration on page 66 describes the requirements and limitations of migration with the nsrnmoadmin command. Migration converts legacy configuration files and resources (the nsrnmo script, RMAN script, NWORA resource file, and Client resource) to the configuration storage framework used by the new wizard. Migration with the nsrnmoadmin command does not create a new Client resource; the migration modifies an existing Client resource, such that you can then use the wizard to modify it. The migration process stores the following in a hidden attribute in the Client resource: Environment variable settings extracted from the nsrnmo script. (Any scripting commands in the nsrnmo script are ignored.) RMAN commands and options extracted from the RMAN script. NSR_BUNDLING, NSR_INCR_EXPIRATION, and NSR_ORACLE_NLS_LANG settings extracted from the NWORA resource file. 30 NSR-DBM-ORA V5.0 Administrator s Guide

31 Introduction The migration process also sets the following values in the Client resource: Backup Command attribute is set to: nsrnmostart -C [-c virtual_client] Save Set attribute is set to: RMAN:database_Net_service_name Internationalization (I18N) NSR-DBM-ORA I18N is the capability of the NSR-DBM-ORA software to operate in a non-english environment or locale without itself generating non-ascii data. After you set up NSR-DBM-ORA I18N as described in Configuring I18N support on page 64, NSR-DBM-ORA can process and display non-ascii data that is passed to it by the operating system, NetWorker software, and Oracle software. The non-ascii data can include text messages, dates, times, numbers, and so on. The NetWorker Administrator s Guide provides details on the different supported languages and operating system. NSR-DBM-ORA I18N is supported for the following: Regular (nonproxy) backups and restores Proxy backups and restores with a supported PowerSnap Module release, as described in the NSR-DBM-ORA Release Notice. The term internalization is used differently in the NetWorker documentation (as opposed to this NSR-DBM-ORA 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. When NSR-DBM-ORA I18N support is set up as described in Configuring I18N support on page 64, NSR-DBM-ORA supports non-ascii data in the following: Pathnames of nsrnmo scripts Pathnames of preprocessing and postprocessing scripts Pathnames of RMAN scripts Strings passed as command line options to the nsrnmosh, nsrnmoadmin, nsrnmoinfo, and nsroraclecat commands Tablespace names and datafile paths The tag string of the RMAN backup command Usernames in the connection strings to the target database and recovery catalog Note: Oracle does not recommend the use of non-ascii text in the Oracle database usernames. Due to Oracle limitations, ASCII text must be used for the password of the target database. Values of the following parameters: NSR_DEBUG_FILE NSR_ORACLECAT_LOG_FILE NSR_RMAN_ARGUMENTS NSR_SB_DEBUG_FILE Product features 31

32 Introduction Note: Support of non-ascii values for ORACLE_SID and TNS_ADMIN is dependent on the Oracle software. Support of non-ascii values for LD_LIBRARY_PATH, LIBPATH, and SHLIB_PATH is dependent on the operating system. Additional values input in the NSR-DBM-ORA wizard, including the following: New or existing names of NetWorker Group resources Time data based on the time zone of the user Information displayed on the following screens of the NSR-DBM-ORA wizard: Review and Edit the RMAN Script screen Review and Accept the Client Configuration screen Content of output files created by the NSR-DBM-ORA wizard, such as nsrnmo scripts and RMAN scripts Due to Oracle limitations, ASCII text must be input in the wizard for the following: ORACLE_HOME path Net service name of the Oracle target database, recovery catalog, or duplicate database The deduplication backup process, nsravtar, on the NSR-DBM-ORA client generates messages in English only. When NSR-DBM-ORA I18N support is set up, NSR-DBM-ORA generates debug messages in English only. NSR-DBM-ORA generates error messages in the nmo.messages.raw file in a language-independent binary form, readable by the nsr_render_log program only. The nmo.messages.raw file replaces the nmo.messages file used in previous NSR-DBM-ORA releases. (The log file does not contain Oracle Server or RMAN errors.) The NetWorker Administrator s Guide provides information on how to use the nsr_render_log program to read any language-independent binary file, such as nmo.messages.raw. The PowerSnap Module documentation provides details on the PowerSnap options that support non-ascii values. Configuring I18N support on page 64 describes how to set up NSR-DBM-ORA I18N support. Oracle Data Guard support NSR-DBM-ORA software supports Oracle Data Guard, an Oracle data availability and protection solution that involves the primary database and one or more standby databases over an IP network. As transactions occur in the primary database and redo data is written to the local redo logs, Data Guard automatically transfers this redo data to the standby sites and applies it to the standby databases, synchronizing them with the primary database. RMAN backups of datafiles, archived redo logs, and possibly other files can be offloaded to a physical standby database, and the backups used to recover the primary database or a standby database. RMAN and Data Guard documentation provides information on how to configure and back up a physical standby database, and use the backups to recover the primary or standby database. 32 NSR-DBM-ORA V5.0 Administrator s Guide

33 Introduction To configure NSR-DBM-ORA 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 NSR-DBM-ORA and NetWorker client software on the primary database host, and on each physical standby database host involved in the backups and restores. 3. Configure a Client resource on the NetWorker server for the primary database host and each physical standby database host involved in the backups and restores. In the Client resource of the primary database host, specify the hostname of the physical standby host in the Remote Access attribute if you set NSR_CLIENT to the primary database hostname in the following step. 4. Create an RMAN script for the primary database and the standby database, setting the same NSR_CLIENT parameter value in both. The NSR_CLIENT value used for a backup should be the same as the NSR_CLIENT value used for the restore of that backup. Setting NSR_CLIENT to the primary hostname might be preferable. Parallelism Parallelism is a feature that enables NSR-DBM-ORA backup or restore streams of Oracle data from several clients, or many Oracle data streams from one client, at the same time. Different types of configuration settings enable different types of parallelism during NSR-DBM-ORA operations: The Parallelism attribute in the NetWorker Server resource specifies the maximum number of backup save streams that the NetWorker software allows to arrive in parallel at the server. The Parallelism attribute (a hidden attribute) in the NetWorker Client resource specifies the maximum number of data streams that the Oracle Server sends in parallel to the NetWorker server or storage node during an NSR-DBM-ORA backup. For proxy operations, the PowerSnap parameter settings specify the maximum number of parallel save streams on the proxy client host. Note: The degree of proxy backup or restore parallelism is not controlled by the allocation of multiple channels in the RMAN script. Oracle uses only one of the allocated channels for the proxy backup or restore, unless specific backup options are used. Configurations on a RAC system enable parallel Oracle backups and restores with the NSR-DBM-ORA software on multiple nodes of a cluster. Chapter 6, Cluster and RAC Systems, provides more details. Policy uniformity If policy uniformity is enabled, NSR-DBM-ORA automatically enforces the uniformity of the browse and retention policies between all the dependent save sets in a scheduled backup cycle (whether or not save set bundling is enabled). When save set bundling is also enabled, all the save sets in a bundle receive the same browse and retention policies. Product features 33

34 Introduction After NSR-DBM-ORA performs an incremental scheduled backup, if the browse and retention policies of the save sets in the backup are longer than the policies of preceding dependent save sets in the same backup cycle, the NSR-DBM-ORA program nsrnmostart changes the policies of all save sets in the cycle to match the longest policy of the new incremental save sets. NSR-DBM-ORA 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 NSR-DBM-ORA software does not enforce policy uniformity for a manual backup, except when a subsequent scheduled backup is dependent on the manual backup, and then the policies of the manual backup are modified accordingly. Policy uniformity does not depend on whether save sets are stored on separate volumes. For example, if parts of a save set bundle are split onto separate volumes, all the save sets in the bundle still receive the same browse and retention policies. Configure policy uniformity on page 85 provides information on how to configure policy uniformity for NSR-DBM-ORA backups. 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 2 days ago, use the following command: backup device type sbt database not backed up since time sysdate-2 RMAN compares the given time in this command with the completion time of the most recent backup of a datafile to determine if the datafile requires backup. The appropriate Oracle backup and recovery documentation provides more information. The following sections provide more information on how to cancel NSR-DBM-ORA backups: Cancel a manual backup on page 101 Cancel a scheduled backup on page 105 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. NSR-DBM-ORA supports the Oracle retention policy with some restrictions, since the NetWorker server has its own browse and retention policies to specify how long data is available for recovery. NetWorker browse and retention policies are based on a user-defined time period. Since the Oracle retention policy is independent from that of the NetWorker server, and there is no mechanism to synchronize these policies, the NetWorker and Oracle policies could conflict. 34 NSR-DBM-ORA V5.0 Administrator s Guide

35 Introduction Example 5 Expiring a backup A NetWorker server might expire an NSR-DBM-ORA backup that is not yet obsolete in RMAN, depending on the NetWorker browse and retention policies. Use of NSR-DBM-ORA cannot guarantee that the NetWorker server will not expire a backup volume until all the RMAN backups on that volume have been removed from the RMAN catalog. To avoid conflicts, perform either of the following: Disable the Oracle retention policy (and then use only the NetWorker server policy) with the following command: configure retention policy to none If the Recovery Catalog is used, exempt a backup from the retention policy with one of the following commands: change backupset...keep until/forever... backup...keep until/forever... (If you want to use the Oracle retention policy) Set the NetWorker browse and retention policies to be long enough that backups are kept on the backup volumes until the Oracle retention policy makes them obsolete. Set the NetWorker policies in the NetWorker Client resource for scheduled backups or through the NSR_SAVESET_BROWSE and NSR_SAVESET_RETENTION parameters. Configure a Client resource with NMC on page 81 provides more information on how to set NetWorker policies for NSR-DBM-ORA backups.! IMPORTANT Run the crosscheck command on the NSR-DBM-ORA backups before running report obsolete or delete obsolete backups of the device type sbt_tape. This ensures that backups expired by the NetWorker server are flagged as expired in the RMAN catalog. As a result, RMAN can correctly identify which backups are not needed according to the Oracle retention policy. For example: 1. Run the following command to synchronize the RMAN Catalog and NetWorker indexes: crosscheck backup; 2. Run the following command to delete all obsolete backups defined by the current Oracle retention policy: delete obsolete; Save set bundling If NSR-DBM-ORA save set bundling is configured, NSR-DBM-ORA automatically creates a save set bundle for each scheduled backup cycle of an Oracle database object, by grouping all the dependent save sets from the same backup cycle into the save set bundle. A backup cycle includes a full backup of the database object and all subsequent incremental backups that are dependent on the full backup. Note: NSR-DBM-ORA does not support save set bundling for proxy backups. NSR-DBM-ORA performs save set bundling for regular Oracle backups only. Product features 35

36 Introduction During staging operations with NetWorker server release 7.4 and later, if the staging criteria determine that a particular NSR-DBM-ORA save set should be staged (migrated) and the save set is part of a save set bundle, the NetWorker server stages the entire save set bundle. If the nsrstage command is used to manually stage one or more save sets from a save set bundle, all the save sets in the bundle are staged. Note: After a staging operation during which all the save sets in a bundle are staged, the resulting available space on the staging device might exceed the lower-water mark specified in the staging policy. The NetWorker Administrator s Guide provides details on how to work with staging policies and perform automatic and manual staging operations through the NetWorker server. NSR-DBM-ORA scheduled backups and save set bundling on page 36 describes NSR-DBM-ORA save set bundling during regular scheduled backups, and how to configure save set bundling. If policy uniformity is configured, NSR-DBM-ORA automatically enforces the uniformity of browse and retention policies for all the dependent save sets of the same scheduled backup cycle or same save set bundle, which ensures that incremental backups do not persist after the backups they depend on have expired. Other Oracle features on page 41 provides more information on how policy uniformity relates to save set bundling. Save set bundling and policy uniformity can be enabled and disabled independently. NSR-DBM-ORA 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 NSR-DBM-ORA scheduled backups. Both are performed to prepare for staging operations with NetWorker server 7.4 and later. Configure save set bundling on page 84 provides information on how to configure save set bundling for NSR-DBM-ORA scheduled backups. RMAN backup levels and dependencies An RMAN backup can be either full or incremental: A full (or stand-alone full) backup includes every used block of the database objects listed in the RMAN backup script (unused blocks might be skipped). This type of backup is created when you do not specify a backup level with the RMAN backup command. A full backup cannot be the parent of a subsequent incremental backup. (Incremental backups cannot be dependent on a stand-alone full backup.) An incremental backup is either level 0 or level 1. Incremental backups are created when you specify either incremental level=0 or incremental level=1 with the RMAN backup command. Incremental backups are dependent on preceding incremental backups in the same scheduled backup cycle: A level 0 incremental is physically identical to a full backup, but is recorded as incremental in the RMAN repository. (A level 0 backup may also be referred to as "full" in other sections of this guide.) A level 1 incremental can be either of the following: A differential backup, which contains only the data blocks changed since the most recent incremental backup, whether level 0 or 1. The differential backup is dependent on the preceding level 0 or 1 backup. Incremental backups are differential by default. 36 NSR-DBM-ORA V5.0 Administrator s Guide

37 Introduction A cumulative backup, which contains only the data blocks changed since the most recent level 0 incremental backup. The cumulative backup is dependent on the preceding level 0 backup. RMAN backup sets and NSR-DBM-ORA save sets NSR-DBM-ORA save set bundling is performed at the backup set level. An NSR-DBM-ORA 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 NSR-DBM-ORA 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 NSR-DBM-ORA 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 NSR-DBM-ORA 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 NSR-DBM-ORA 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, NSR-DBM-ORA 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. Product features 37

38 Introduction 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 NSR-DBM-ORA cannot find a preceding dependent backup in any existing bundles, NSR-DBM-ORA 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 NSR-DBM-ORA scheduled backups. Backup copies created during a manual backup are independent of each other, and each copy goes to a different NetWorker volume. If an error occurs during save set bundling, the bundling operation fails but the scheduled backup can finish successfully. Information about the bundling failure is printed to the savegrp output and to the debug file specified by NSR_DEBUG_FILE. How the nsrnmostart program performs save set bundling The NSR-DBM-ORA program nsrnmostart automatically places save sets into a save set bundle at the end of a scheduled backup, before the nwora.res file is backed up. Configure save set bundling on page 84 provides information on the nwora.res file. To perform save set bundling, the nsrnmostart program connects to the Oracle database by attempting to use the login and password from the RMAN script. If a login and password are not available from the script, the program uses the ORACLE_SID value from the nsrnmo script to search the nwora.res file for the NSR_ORACLE_CONNECT_FILE parameter, and uses the connection strings from the specified connection file. Configure save set bundling on page 84 provides more details on the requirements of save set bundling. After connecting to the Oracle database, the nsrnmostart program obtains all the required information about the backups from the Oracle control file (by querying the v$backup_set, v$backup_piece, and v$backup_datafile tables). The control file can store only a limited number of backup entries. When the maximum number of entries is exceeded, old entries in the control file are overwritten by new ones. Save set bundling is successful only if information in the control file about backed-up save sets has not been overwritten. The Oracle documentation provides information about proper maintenance of the control file and how much backup information the control file can store. 38 NSR-DBM-ORA V5.0 Administrator s Guide

39 Introduction The nsrnmostart program creates a save set bundle for each full or incremental level 0 backup. The program adds the save sets from subsequent incremental backups to the bundles of the full or level 0 backups they are dependent on. The name that the nsrnmostart program assigns to a save set bundle is a number corresponding to the save time of the oldest save set in the bundle. NSR-DBM-ORA 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 39. Example 6 Save set bundling for a one-week scheduled backup cycle of a tablespace A one-week scheduled backup cycle of a tablespace includes a level 0 backup of the tablespace on Sunday and a level 1 backup every other day of the week. The save set bundle for the cycle is created during the Sunday backup, and save sets from each level 1 backup are added into the same bundle. The complete bundle contains the save sets from the seven daily backups of the tablespace. A new bundle is created for the next backup cycle during the following week. NetWorker staging restrictions When planning the strategy for NSR-DBM-ORA save set bundling, consider the following NetWorker staging restrictions: NetWorker cannot simultaneously stage all the save sets from a save set bundle if some of the save sets were backed up to separate volumes. NetWorker simultaneously stages save sets only if they are located on the same staging volume. Example 8 on page 40 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 NSR-DBM-ORA backup cycle to be staged before the cycle is complete. For example, if a one-week NSR-DBM-ORA 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 NSR-DBM-ORA backup cycle, adjust the NetWorker staging policy accordingly. For example, adjust the policy so that older save sets are staged before new ones, or adjust the high-water and low-water marks. The NetWorker Administrator s 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 NSR-DBM-ORA software stores information about each save set bundle in the NetWorker media database. NetWorker software on page 44 provides more information about the media database. Product features 39

40 Introduction Query the media database by using the NetWorker command, mminfo, with the appropriate options: The mminfo -r command can display the name of the bundle associated with a save set. For example, the following command displays a list of all save sets and their bundles: mminfo -a -r "ssid,ssbundle" The mminfo -q command can display all the save sets in a specific bundle. For example, the following command displays all the save sets in the bundle named : mminfo -a -q "ssbundle= " The NetWorker Command Reference Guide and the UNIX man pages provide more information on the mminfo command and its available options. Examples of save set bundles and staging The following examples illustrate different aspects of save set bundling, and how splitting the save set bundles across volumes can affect staging operations. Example 7 Save set bundle join Two save set bundles are created by separate level 0 backups of files A and B. Then a new backup set is created by a level 1 backup of both files A and B. Since the new backup set is dependent on both of the preceding level 0 backups, NSR-DBM-ORA combines all three backups into the same save set bundle. If the original file A backup has the oldest backup time, NSR-DBM-ORA places the new backup set (from the level 1 backup) into the save set bundle of the (level 0) file A backup. NSR-DBM-ORA then moves the original (level 0) file B backup into the save set bundle with the other two backups. This method of combining existing bundles into a new save set bundle is known as a save set bundle join. Example 8 Splitting a save set bundle across volumes In both of the following cases, a save set bundle is split across multiple volumes. The parts of the save set bundle on different volumes must be staged separately by the NetWorker server: A backup uses multiple channels so the backup set spans multiple volumes. All the save sets belong to the same backup set and save set bundle, but parts of the bundle are stored on different volumes. During staging, only the save sets on the same volume can be staged together. A level 0 backup of file A is performed to volume A. An incremental backup of file A is then performed to volume B. Although both backups are recorded as belonging to the same save set bundle, the save set bundle is split across volumes. During staging, only the save sets on the same volume can be staged together. Example 9 Using save set consolidation to re-unite a save set bundle A level 0 backup of file A is performed to volume A. A level 1 backup of file A is then performed to volume B. Save set consolidation is used to merge the save sets from these two backups onto the same volume. Bundle names are preserved when save sets are moved from volume to volume by save set consolidation. The consolidated backup is staged as a single save set bundle. 40 NSR-DBM-ORA V5.0 Administrator s Guide

41 Introduction Other Oracle features This section describes supported features of the Oracle Server software. The NSR-DBM-ORA software supports the Oracle releases on specific platforms, as outlined in the NSR-DBM-ORA Release Notice. Examples of the Oracle RMAN features that NSR-DBM-ORA supports are as follows: Fast incremental backups that use change tracking files. Proxy backups and restores of archived redo logs. Note: Oracle does not support proxy backups of datafiles or archived redo logs that reside on Oracle Automated Storage. Oracle Automated Storage is also known by the term Oracle Automated Storage Management (ASM). Channel backup failover and backup piece restore failover. Management of backup duration and throttling. Backups and restores of data residing on Oracle Automated Storage. Flash recovery area and flashback database. The Oracle Recovery Manager documentation provides a complete list of the RMAN features. When using Oracle RMAN features with NSR-DBM-ORA, 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 NSR-DBM-ORA 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; If multiple channels are used for an RMAN backup command and one of the channels fails, Oracle fails over to another channel to continue the backup job. For example, if two channels are configured with different NetWorker volume pools and one of the channels fails over to the other channel during a backup, the entire backup goes to the volumes in the pool of that remaining channel. Before using the backup command with the duration...minimize load option, consider: Product features 41

42 Introduction 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 NSR-DBM-ORA scheduled backup to be timed out if RMAN does not send data to the NetWorker Module within the time frame specified in the Inactivity Timeout field of the corresponding NetWorker Group resource. Starting with release 10.1, RMAN does not print database connection strings (user/password@netservicename) to the session output. As a result, the parameter NSR_RMAN_OUTPUT is not required (to suppress the connection strings in the log files) for an RMAN scheduled backup. Oracle11g specific features NSR-DBM-ORA 5.0 supports the following major Oracle11g features: Data Recovery Advisor Improved integration with Data Guard Archival backup through the RMAN backup...keep command Improved archived redo log management through the configure archivelog deletion policy command Recovery catalog enhancements, such as virtual private catalogs and the import and merging of recovery catalogs Multisection or intrafile backup and validation, with the backup of a single large datafile over multiple channels Improved block media recovery, with the blockrecover command being replaced by the recover...block command Configurable backup compression through the configure compression algorithm to command Block change tracking support in Data Guard Backup of read-only transportable tablespaces Oracle Enterprise Manager enhancements, with new interfaces for the Data Recovery Advisor Oracle Globalization Support enhancements To enable NSR-DBM-ORA 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 42 and Archival backup feature on page 43. The appropriate Oracle documentation provides more information on the Oracle11g features. Data Recovery Advisor The Oracle Data Recovery Advisor is a new tool in Oracle11g. Integrated with RMAN and Oracle Enterprise Manager (OEM), the tool enables a DBA to diagnose and repair database failures. 42 NSR-DBM-ORA V5.0 Administrator s Guide

43 Introduction Before you can use the Data Recovery Advisor to invoke an RMAN restore script that involves NSR-DBM-ORA 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 NSR-DBM-ORA parameters may also be specified for the automatic channel configuration. To enable the use of Data Recovery Advisor with Oracle11g and NSR-DBM-ORA: If automatic channels have not been configured for NSR-DBM-ORA backups, 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=NSR-DBM-ORA_client_name) ; configure channel device type 'sbt_tape' parallelism number_of_restore_channels; If automatic channels are already configured for NSR-DBM-ORA backups, no additional configuration steps are required. Archival backup feature With Oracle11g, the RMAN backup...keep forever command enables the creation of an archival backup that is exempt from Oracle backup retention policies (but not automatically exempt from NetWorker retention policies). The archival backup is all-inclusive because every file required to restore a database is backed up to a single disk or tape location. To enable the use of the RMAN backup...keep forever command with NSR-DBM-ORA: 1. Configure an Archive type Pool resource through the NetWorker server. 2. Specify that the backup data must go to the Archive pool by performing one of the following: Set the pool selection criteria accordingly on the NetWorker server. Set the NSR_DATA_VOLUME_POOL parameter in the RMAN backup script. 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 NSR-DBM-ORA. The NetWorker Administrator s Guide provides more information on how to configure resources and specify pool selection criteria through the NetWorker server. Product features 43

44 Introduction Software used in the NSR-DBM-ORA environment The following sections describe the different software components involved in the NSR-DBM-ORA environment. NetWorker software The NetWorker software comprises a high-capacity, easy-to-use data storage management solution that protects and helps manage data across an entire network. The NetWorker software simplifies the storage management process and reduces the administrative burden by automating and centralizing data storage operations. The NetWorker software enables a user to: Perform automated backups during nonpeak hours Administer, configure, monitor, and control NetWorker functions from any computer on a network Centralize and automate data management operations Increase backup performance by simultaneously sending more than one save stream to a single device Optimize performance by using parallel save streams to multiple backup devices or storage nodes NetWorker client/server technology uses the network remote procedure call (RPC) protocol to back up data. The NetWorker client software consists of client-side services and user interface programs. The NetWorker server software consists of several server-side services and programs that: Oversee backup and restore processes Maintain client configuration files Maintain an online client file index and online media database, which together comprise the online indexes on the NetWorker server During a backup, the NetWorker server makes an entry in the online client file index and records the location of the data in the online media database. These entries provide recovery information required for all backed-up data. After a scheduled backup, the NetWorker server sends a record of the bootstrap file to the default printer. This is a printed record of the dates, locations, and save set ID numbers for the server s online indexes that are required for restoring data. Keep the bootstrap printout on file as a quick reference in the event of a disaster, such as a disk crash or server failure: The NetWorker Release Notice provides information on how to install NetWorker software. The NetWorker Administrator s Guide provides information on how to configure and use NetWorker software. 44 NSR-DBM-ORA V5.0 Administrator s Guide

45 Introduction NSR-DBM-ORA software NSR-DBM-ORA software is an add-on module for the NetWorker server that enables you to perform the following tasks: Manual Oracle backups Scheduled Oracle backups Restores of Oracle backup data Automated media management NSR-DBM-ORA software provides the following features: Capability to integrate database and file system backups, to relieve the burden of backup from the database administrator while allowing the administrator to retain control of the restore process. Automatic database storage management through automated scheduling, autochanger support, electronic tape labeling, and tracking. Support for backup to a centralized backup server. High performance through support for multiple, concurrent high-speed devices such as digital linear tape (DLT) drives. Together with the NetWorker server, NSR-DBM-ORA augments the backup and recovery system provided by the Oracle Server and provides a storage management solution that addresses the need for cross-platform support of enterprise applications. Proxy backups and restores of Oracle database files residing on specific types of primary storage devices are supported. These proxy operations are performed by NSR-DBM-ORA, with the NetWorker server and the appropriate NetWorker PowerSnap Module software. The NSR-DBM-ORA Release Notice provides information on how to install the NSR-DBM-ORA software. NetWorker PowerSnap Module software The NetWorker PowerSnap Module software works with the NetWorker server and NSR-DBM-ORA software to perform RMAN proxy backups and restores of Oracle data that resides on specific types of primary storage. Each type of primary storage requires a different type of PowerSnap Module. A proxy backup performed with the PowerSnap Module involves taking a snapshot of the Oracle data. The snapshot resides on the primary storage to ensure high availability of the database and eliminate downtime latency on the Oracle Server host. During a proxy backup, the Oracle data can optionally be copied from the snapshot to a NetWorker storage device. The data is copied to the secondary storage by either the Oracle Server host or a proxy client host that is separate from the Oracle Server host. The following sources provide information on how to configure and run proxy backups and restores with the NSR-DBM-ORA and PowerSnap Module software: Chapter 7, Proxy Backups and Restores NetWorker PowerSnap Module documentation Software used in the NSR-DBM-ORA environment 45

46 Introduction Oracle backup and recovery system This section describes the system used for regular Oracle backup and recovery. The NSR-DBM-ORA and NetWorker server and client software function with the standard Oracle backup and recovery system to produce an efficient Oracle data storage management system. The implementation of an Oracle backup and recovery strategy requires a knowledge of how the NetWorker software works together with the Oracle components. The regular Oracle backup and recovery system consists of the following: Oracle Server Oracle Recovery Manager (RMAN) Recovery Catalog (optional) Backup Management Tools for Oracle Enterprise Manager (optional) The NetWorker software consists of the following components: NetWorker server NetWorker client NSR-DBM-ORA Figure 1 on page 47 illustrates the architecture of the regular Oracle backup and recovery system, and shows the functional relationship between the NetWorker and Oracle software components. The NSR-DBM-ORA media management library (MML) is integrated with the Oracle Server during the NSR-DBM-ORA installation on the Oracle Server host. The NetWorker Management Console program (used to configure the NetWorker resources) and the Oracle Enterprise Manager (OEM) Backup Manager can be optionally located on a separate platform, referred to as the GUI console. 46 NSR-DBM-ORA V5.0 Administrator s Guide

47 Introduction GUI Console OEM Backup Manager Oracle Server System Oracle Database FIles RMAN NetWorker Server Recovery Catalog Oracle Server NSR- DBM-ORA MML Storage Medium NetWorker Client NetWorker Management Console NetWorker Server GEN Figure 1 Regular Oracle backup and recovery system Oracle Recovery Manager During the Oracle backup and restore operations, NSR-DBM-ORA acts as an intermediary between the NetWorker server and Oracle Recovery Manager (RMAN). RMAN is the main Oracle utility for backing up, restoring, and recovering Oracle datafiles, control files, and archived redo log files. It stores information about its operations in the control file of the backed-up database (target database) and, optionally, in the Recovery Catalog on the Oracle Server host. RMAN provides the following features: Online and offline Oracle database backups High performance through parallel backups and restores An intelligent interface to Oracle databases Well-defined backup strategies Checks for corrupt blocks during backups and restores Block-level incremental backups and restores The Oracle Recovery Manager documentation provides more information on RMAN. Oracle Recovery Catalog The Recovery Catalog is a collection of Oracle database tables that contain structural information about Oracle database backups and restores. The collection includes information about the following types of objects: Backup sets and backup pieces Image copies Proxy copies Software used in the NSR-DBM-ORA environment 47

48 Introduction Archived redo logs Target database schema Stored scripts (user-created sequences of RMAN commands) The Recovery Catalog is maintained by the RMAN utility. This utility uses the catalog information or the database control file to determine how to perform requested backup and restore operations. Store the Recovery Catalog in the dedicated Recovery Catalog database. The Oracle Recovery Manager documentation provides more information on the Recovery Catalog, including the implications of not using it for backups and restores. NSR-DBM-ORA components Table 1 on page 48 lists the NSR-DBM-ORA components that are installed on the NSR-DBM-ORA client host during the NSR-DBM-ORA and NetWorker software installation. Unless specified otherwise, the files are located in the same directory as the NetWorker client software. Table 1 NSR-DBM-ORA components Name on UNIX fdiff.jar nwora.jar nwora_res.jar libcommonssl.7.5.so libnwora.xx nsrnmo nsrnmo.sh nsrnmoadmin nsrnmodrpostcmd nsrnmoinfo nsrnmoprobe nsrnmostart nsroraclecat nsrorara Description Plug-in jar files for the NSR-DBM-ORA backup and recovery configuration wizards. In a subdirectory under /opt/nsr/lib. An NSR-DBM-ORA library that is required for communication with NetWorker. In a subdirectory under /opt/nsr/lib. The main NSR-DBM-ORA library (known as Media Management Library in Oracle documentation) that is loaded by the Oracle backup or restore process. The nsrnmo script that contains parameter settings for a particular scheduled backup. The script is only used for a scheduled backup that has been configured through NMC (the legacy configuration method without the wizard). In /opt/nsr. A sample template for the nsrnmo script. You should copy and customize this template, and save the original file in /etc. The program that is used either to create resource settings in the NWORA resource file, or to migrate legacy backup configurations to the new format supported by the configuration wizard. A sample postcommand script that can be customized to back up specific files at the end of a scheduled backup, in preparation for disaster recovery. The program that determines the NetWorker volumes required to restore specified Oracle backup pieces from NSR-DBM-ORA backups. The program that probes for the number of generated Oracle logs as a condition that triggers probe-based backups. The program that invokes a scheduled backup on the Oracle Server, launching RMAN by passing arguments to the Oracle utility. The program optionally runs precommand and postcommand scripts. Not available on Linux Itanium or Solaris AMD64/EM64T (platforms that do not support proxy backups). The program that is used to remove RMAN catalog entries during automatic catalog synchronization for proxy backups. The program that performs operations on behalf of the NSR-DBM-ORA configuration wizard on the local or remote NSR-DBM-ORA host. 48 NSR-DBM-ORA V5.0 Administrator s Guide

49 Introduction NSR-DBM-ORA backup and restore processes This section describes the processes involved in regular backups and restores. To provide storage management services for Oracle Server data, NSR-DBM-ORA implements the media management interface, also known as the Oracle System Backup to Tape (SBT). This interface comprises a media management library (MML) that is integrated with the Oracle Server during the NSR-DBM-ORA installation on the Oracle Server host. Oracle loads the NSR-DBM-ORA MML at run time, and the Oracle Server backup sessions call the NSR-DBM-ORA MML software routines to back up and restore Oracle data to and from the media controlled by the NetWorker server. A regular Oracle backup can be performed in either of two ways: By issuing the appropriate commands through the RMAN command line interface. By using the Oracle Enterprise Manager Backup Management Tools, which include an optional graphical user interface to the RMAN utility. RMAN establishes connections with the target database. Each RMAN channel starts an Oracle Server backup session that performs the backup. During the backup, the following occurs: 1. The Oracle Server backup sessions read the datafile, control file, or archived redo log being backed up, and then write it to the NetWorker server through the MML. 2. The NetWorker server stores the Oracle data to the appropriate backup storage device. At the end of the Oracle backup, the NetWorker server updates the online client and media indexes with information about the backup media used and the Oracle data it contains. Regular scheduled backup processes Note: Deduplication backup processes on page 52 provides information specifically for a deduplication backup. A scheduled NSR-DBM-ORA backup is a backup of Oracle data initiated by the NetWorker server. A regular scheduled backup includes the following interactions: 1. At the scheduled backup start time, the main NetWorker service, nsrd, starts the configured group s backup by invoking the savegrp program. 2. The savegrp program requests that the NetWorker client-side service, nsrexecd, run the savefs program (mainly used for file system backups; it has no usage for Oracle backups). 3. The savefs program sends back information to the savegrp program. 4. The savegrp program contacts the nsrexecd service to start the backup. 5. For each client in the backup group and each of the client s save sets, the following sequence of events occurs: a. The nsrexecd service starts a specific process, depending on how the backup was configured: NSR-DBM-ORA backup and restore processes 49

50 Introduction If the backup was configured through the legacy method (without the wizard), nsexecd starts the nsrnmo script, which then sets the required parameters and invokes the NSR-DBM-ORA program, nsrnmostart. If the backup was configured through the new configuration wizard, nsexecd starts the nsrnmostart program directly. b. The nsrnmostart program starts the RMAN utility to run the required RMAN backup script. c. From this point on, the scheduled Oracle backup sessions follow the same steps as described in Regular manual backup processes on page 51. Note: At the end of a scheduled Oracle backup, the savegrp program also automatically backs up the NetWorker server bootstrap and the Oracle client file indexes. The bootstrap and client indexes are not automatically backed up at the end of a manual NSR-DBM-ORA backup. Figure 2 on page 50 shows how the Oracle Server, NetWorker server, and NSR-DBM-ORA processes interact during a regular scheduled NSR-DBM-ORA backup that was configured through the legacy method (without the wizard). In a scheduled backup configured through the wizard, the nsrnmo process is removed from the picture, and the nsrexecd and nsrnmostart processes interact directly with each other. Oracle Server (NetWorker Client) Backup Pieces NetWorker Server Client File Index Media Database Storage Medium Oracle process (channel) nsrindexd tracking information nsrmmdbd NSR- DBM-ORA MML NetWorker Module elements data savefs rman nsrnmostart interprocess communication nsrmmd nsrnmo savegrp nsrd nsrexecd GEN Figure 2 Regular scheduled NSR-DBM-ORA backup 50 NSR-DBM-ORA V5.0 Administrator s Guide

51 Introduction Regular manual backup processes Note: Deduplication backup processes on page 52 provides information specifically for a deduplication backup. A manual NSR-DBM-ORA backup is a user-initiated backup through an Oracle backup utility, RMAN or Oracle Enterprise Manager. NSR-DBM-ORA considers a backup scheduled through Oracle Enterprise Manager to be a manual backup. When the RMAN utility is invoked for a backup, Oracle Server backup sessions call the NSR-DBM-ORA media management library (MML) software routines to initiate the backup. A manual NSR-DBM-ORA backup includes the following interactions: 1. The Oracle Server backup session that loads the NSR-DBM-ORA MML (one such backup session for each allocated channel) contacts the nsrexecd service to obtain the NetWorker client information. 2. The Oracle Server backup sessions contact the main NetWorker service, nsrd, to obtain the required authorization and the identifier of the nsrmmd process that manages the requested backup device. 3. The Oracle Server backup sessions send the backup data to the NetWorker media service, nsrmmd, to store on the appropriate backup volumes. 4. Tracking information is stored in the NetWorker online indexes: The nsrmmd service records tracking information in the NetWorker media database by using the nsrmmdbd service. The Oracle backup sessions send tracking information to the NetWorker client file index by using the nsrindexd service. Figure 3 on page 52 shows how the Oracle Server, NetWorker server, and NSR-DBM-ORA processes interact during a regular manual NSR-DBM-ORA backup. NSR-DBM-ORA backup and restore processes 51

52 Introduction Oracle Server (NetWorker Client) Backup Pieces NetWorker Server Client File Index Media Database Storage Medium Oracle process (channel) NSR- DBM-ORA MML RMAN nsrindexd data NetWorker Module element tracking information nsrmmdbd nsrmmd nsrexecd interprocess communication nsrd GEN Figure 3 Regular manual NSR-DBM-ORA backup Deduplication backup processes Deduplication backups and restores on page 20 describes the features of a deduplication NSR-DBM-ORA backup. For scheduled deduplication backups, the steps from Regular scheduled backup processes on page 49 still apply. A deduplication NSR-DBM-ORA backup includes the following interactions: 1. The Oracle Server backup session that loads the NSR-DBM-ORA MML (one such backup session for each allocated channel) contacts the nsrexecd service to obtain the NetWorker client information. 2. Each Oracle Server backup session runs one nsravtar process at any given time. 3. The Oracle Server backup session contacts the main NetWorker service, nsrd, to obtain the required authorization and the identifier of the nsrmmd process that manages the requested backup device on the NetWorker server or storage node. 4. The Oracle Server backup session sends the backup data in the NetWorker save set format to the nsravtar process. 5. The nsravtar process applies deduplication logic to the backup data by using information in a local cache or by contacting the Avamar server, and sends the unique data blocks to the Avamar server (NetWorker deduplication node). 6. The nsravtar process sends a hash ID (one hash ID per save set) to the Oracle Server backup session. 52 NSR-DBM-ORA V5.0 Administrator s Guide

53 Introduction 7. The Oracle Server backup session sends the hash ID in save set format to the NetWorker media service, nsrmmd, to store on the NetWorker backup device. 8. Tracking information is stored in the NetWorker online indexes: The nsrmmd service records tracking information in the NetWorker media database by using the nsrmmdbd service. The media database entry contains extended attributes that identify the backup as a deduplication backup, as described in Deduplication backup information in NetWorker indexes on page 109. The Oracle backup session sends tracking information to the NetWorker client file index by using the nsrindexd service. Figure 4 on page 53 shows how the Avamar server, NetWorker, and NSR-DBM-ORA processes interact during a deduplication NSR-DBM-ORA backup. In the figure, the thickness of the data arrows indicates the amount of data passed between processes: All the data being backed up is passed between the Oracle Server backup session and nsravtar process. Hash IDs and new data blocks (never backed up before by the Avamar server) are passed between the nsravtar process and Avamar server. A single hash ID for the entire NSR-DBM-ORA save set is passed between the Oracle Server backup session and NetWorker storage node. NetWorker Server NetWorker Storage Node Hash ID Oracle data / hash ID NMO Client Oracle Server backup session with NSR-DBM-ORA MML nsravtar Deduplicated data / hash ID NetWorker Deduplication Node (Avamar Server) NetWorker Client / utility node GSAN Node 1 Node 2 GEN Figure 4 Deduplication NSR-DBM-ORA backup NSR-DBM-ORA backup and restore processes 53

54 Introduction Regular restore processes An NSR-DBM-ORA restore can be performed in either of two ways: By issuing the appropriate commands through the RMAN command line interface. Or By using the Oracle Enterprise Manager Backup Management Tools, which include an optional graphical user interface to the RMAN utility. The RMAN utility starts Oracle Server sessions on the target database. These Oracle Server sessions initiate the restore by calling NSR-DBM-ORA media management library (MML) software routines. Note: Deduplication restore processes on page 55 provides information specifically for a deduplication restore. A regular NSR-DBM-ORA restore includes the following interactions: 1. The NSR-DBM-ORA MML translates the object names requested by RMAN into a format that the NetWorker server understands, and forwards the names to the NetWorker service, nsrindexd. 2. The nsrindexd service verifies that the backup pieces exist in the client file index. 3. When the NetWorker server receives a restore request from the client, the main NetWorker service, nsrd, contacts the media service, nsrmmd. 4. The nsrmmd service calls the media database service, nsrmmdbd, to determine which media contains the requested save set and issue a mount request. 5. The nsrmmd service reads the appropriate backup volumes and passes the data to the Oracle sessions through the NSR-DBM-ORA MML. 6. The Oracle Server sessions write the data to the disk. Figure 5 on page 55 shows how the Oracle Server, NetWorker server, and NSR-DBM-ORA processes interact during a regular NSR-DBM-ORA restore. 54 NSR-DBM-ORA V5.0 Administrator s Guide

55 Introduction Oracle Server NetWorker Server (NetWorker Client) Backup Pieces Client File Index Media Database Storage Medium RMAN Oracle process (channel) nsrindexd tracking information nsrmmdbd NSR- DBM-ORA MML NetWorker Module element data nsrmmd nsrexecd interprocess communication nsrd GEN Figure 5 Regular NSR-DBM-ORA restore Once RMAN has restored the required files from the backup volumes, a database administrator can complete the standard Oracle database recovery. Deduplication restore processes A deduplication NSR-DBM-ORA restore includes the following interactions: 1. The NSR-DBM-ORA MML translates the object names requested by RMAN into a format that the NetWorker server understands, and forwards the names to the NetWorker server. 2. The NetWorker server verifies that the backup pieces exist in the NetWorker client file index and media database. 3. When the Oracle Server restore session determines from the media database information that the data exists in a deduplication backup, the Oracle session starts a nsravtar process on the NSR-DBM-ORA client. 4. When the NetWorker server receives a restore request from the client, the main NetWorker service, nsrd, contacts the media service, nsrmmd. 5. The nsrmmd service on the NetWorker server calls the media database service, nsrmmdbd, to determine which media contains the requested save set and issue a mount request. 6. The nsrmmd service reads the appropriate backup volumes and passes the data (hash ID) to the Oracle Server session. 7. The Oracle Server session passes the hash ID to the nsravtar process. NSR-DBM-ORA backup and restore processes 55

56 Introduction 8. The nsravtar process retrieves the data corresponding to the hash ID from either the primary Avamar server or the replication Avamar server, and sends the data to the Oracle Server session. 9. The Oracle Server session writes the data to the disk. 56 NSR-DBM-ORA V5.0 Administrator s Guide

57 2 Software Configuration This chapter includes the following major sections: Configuration roadmap Verify the Oracle Server configuration Verify the NetWorker resources Configuring I18N support Migrating a legacy configuration with the nsrnmoadmin command Configuring a backup with the NMC wizard Configuring a backup with the NMC legacy method Configuring a deduplication backup Configuring a probe-based backup Software Configuration 57

58 Software Configuration Configuration roadmap The Oracle Server and NetWorker server must be properly configured before the NSR-DBM-ORA software can be used for backup and restore operations. Before configuring the Oracle Server and NetWorker server, ensure that the NSR-DBM-ORA software is installed on the Oracle Server host according to the instructions in the NSR-DBM-ORA Release Notice. To perform specific configuration procedures, you can use either of the following through NetWorker Management Console (NMC): Client backup configuration wizard for Oracle Legacy configuration method (without the wizard) that uses application-independent screens in NMC To configure a regular scheduled backup, follow the instructions in the following sections that apply to your particular environment: 1. Verify the Oracle Server configuration according to Verify the Oracle Server configuration on page Verify the NetWorker resources according to Verify the NetWorker resources on page If required, configure internationalization (I18N) support according to Configuring I18N support on page To use the new backup configuration wizard to modify a legacy configuration that was not created with that wizard, migrate the configuration first according to Migrating a legacy configuration with the nsrnmoadmin command on page Complete the backup configuration by using either the wizard or NMC: Configuring a backup with the NMC wizard on page 68 Configuring a backup with the NMC legacy method on page 70 (This section includes details on creation of nsrnmo and RMAN scripts and manual configuration of save set bundling and policy uniformity.) Refer to the following for additional information on configuring a deduplication backup or probe-based backup: Configuring a deduplication backup on page 86 Configuring a probe-based backup on page 90 Chapter 6, Cluster and RAC Systems, provides information on configuring any required cluster or Real Application Cluster (RAC) systems. 58 NSR-DBM-ORA V5.0 Administrator s Guide

59 Software Configuration Verify the Oracle Server configuration The Oracle Server system must be properly installed and configured before the NetWorker server and NSR-DBM-ORA software is configured. To set up the Oracle Server system: 1. Install and configure the Oracle Server software components, including RMAN. The appropriate Oracle installation guide provides more information. 2. Set up and configure the target database and Oracle Recovery Catalog. The Oracle Recovery Manager documentation provides more information on the Recovery Catalog. 3. Set up and configure the Oracle networking software, Oracle Net. 4. Register the target database with the Recovery Catalog. The Oracle backup and recovery documentation provides more information. Note: Detailed information on these steps is available from Oracle user documentation and Oracle support services. Oracle support contact information is available at the Oracle website. Verify the NetWorker resources Verify that the required NetWorker resources are configured on the NetWorker server, according to the information in the following sections. 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 2 on page 59 describes the main NetWorker Server resource attributes. Verify that the attribute settings in the Server resource are valid for the NSR-DBM-ORA backup environment. Modify the settings as required. Table 2 NetWorker Server resource attributes Attribute Name Parallelism Administrator 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 users with NetWorker Administrator privileges. The initial default setting of the attribute is root@hostname, where hostname is the NetWorker server hostname. Specify the required NetWorker privileges on page 60 provides more information. Specifies the key or pass phrase to use for AES encryption of Oracle data during an NSR-DBM-ORA backup. The pass phrase is required to restore the Oracle data from the backup. NSR_AES_ENCRYPTION on page 191 provides more information. The NetWorker server online help and the NetWorker Administrator s Guide provide more information on how to configure a NetWorker Server resource and its attributes. Verify the Oracle Server configuration 59

60 Software Configuration Specify the required NetWorker privileges Certain NSR-DBM-ORA operations require specific NetWorker privileges. The NetWorker privileges are specified through the User Group resource. NetWorker user group privileges on page 60 provides more information. One NSR-DBM-ORA operation that requires special privileges is deletion. NSR-DBM-ORA attempts to remove 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: Cancel a manual backup on page 101 Cancel a scheduled backup on page 105 Note: If the Oracle user is not granted the required NetWorker privileges in these cases, NSR-DBM-ORA fails to remove the backup save set entries from the NetWorker index. However, RMAN might remove the corresponding entries from the RMAN catalog, which would leave the NetWorker index and RMAN catalog unsynchronized. To resynchronize the index and catalog, issue the appropriate NetWorker media management command to manually remove the inconsistent save set entries from the NetWorker index. To enable NSR-DBM-ORA to remove an entry from the NetWorker index, ensure that the Oracle user has the required NetWorker privileges. Verify that the required user group privileges exist according to NetWorker user group privileges on page 60. NetWorker user group privileges The NetWorker server includes an access control feature. This feature allows NetWorker administrators to assign users to NetWorker user groups. Each user group has a specific set of privileges associated with it, as defined in the Privileges attribute of the User Group resource. The NetWorker server is installed with two preconfigured user groups: Administrators Members of this group have privileges to perform all NetWorker operations. The root user on a UNIX system is always a member of this group and cannot be removed from the group. Users By default, members of this group have privileges to back up and recover local data and monitor NetWorker operations. They cannot view or edit configurations. Note: The privileges associated with the Users group can be customized to fit the requirements of the NetWorker users in the group. The privileges associated with the Administrators group cannot be changed. By default, the NetWorker server assigns the following privileges to all users: Monitor NetWorker Recover Local Data Backup Local Data The default user group configurations are sufficient for RMAN backup, restore, and crosscheck operations using NSR-DBM-ORA. If the default user group configurations are changed, ensure that the required privileges are assigned for the operations. 60 NSR-DBM-ORA V5.0 Administrator s Guide

61 Software Configuration Verify that the required user group privileges exist for the NSR-DBM-ORA operations, as described in Table 3 on page 61. The NetWorker Administrator s Guide provides information on how to modify existing privileges. Note: Proxy backups and restores require the same privileges as regular Oracle backups and restores, plus the privileges required by the PowerSnap Module. The NetWorker PowerSnap Module documentation provides more information on the required privileges. Table 3 User group privileges required for NSR-DBM-ORA operations Operation Operating system user that performs operation Required user group privileges Migration of a legacy backup configuration with the nsrnmoadmin command Root user on the Oracle Server Configure NetWorker Regular manual Oracle backup Oracle user on the Oracle Server Recover Local Data, Backup Local Data (These privileges are set by default) Regular scheduled Oracle backup Oracle user on the Oracle Server Recover Local Data, Backup Local Data (These privileges are set by default) Root user on the Oracle Server Monitor NetWorker, Backup Local Data (These privileges are set by default) Regular Oracle restore Oracle user on the Oracle Server Recover Local Data (This privilege is set by default) RMAN crosscheck Oracle user on the Oracle Server Recover Local Data (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 Root user on the Oracle Server Recover Local Data (This privilege is set by default) Save set bundling Root user on the Oracle Server Operate NetWorker, and all its prerequisite privileges The Oracle user is defined as the following: 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.! IMPORTANT If the correct user group privileges are not assigned, an Oracle backup or restore fails with an error message that indicates the required user group privileges. The NetWorker Administrator s Guide provides more information on NetWorker user groups and setting user group privileges. NetWorker Schedule resource You can set the backup schedule to one of the existing schedules (provided by the NetWorker Schedule resources on the server) for the NSR-DBM-ORA client by using either backup configuration wizard or the legacy configuration method. Verify the NetWorker resources 61

62 Software Configuration A NetWorker Schedule resource specifies the attributes of the backup schedule. The NetWorker Administrator s Guide provides more information on the features of a Schedule resource. The NSR-DBM-ORA software does not honor the NetWorker backup levels (except skip) that are specified in the NetWorker Schedule resource.! IMPORTANT For scheduled NSR-DBM-ORA backups, the NetWorker backup levels that appear in the Schedule resource do not determine the NSR-DBM-ORA backup levels. The level of the NSR-DBM-ORA backup must be specified as either full or incremental in the RMAN backup script. The backup level is determined by the level in the RMAN script only. You must configure a Schedule resource through the legacy method with NMC, as described in Configure a Schedule resource with NMC on page 81. NetWorker Device resources The NetWorker server uses a supported tape or disk storage device to write data during an Oracle backup and to read data during an Oracle restore. The NetWorker server configuration must include a Device resource for each storage device to be used for backups and restores. In addition, each storage device must contain a labeled and mounted volume. Configure the required NetWorker Device resources with the NMC program. The NetWorker Administrator s Guide provides more information on storage devices, the NMC program, and how to configure Device resources. The NetWorker Administrator s 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 volume pools NetWorker software directs backups to groups of media or backup volumes called pools. A pool is a specific collection of backup volumes that the NetWorker server uses to store, sort, and organize backup data. For example, backups of Oracle data such as tablespaces and archived redo logs can be directed to volumes in specific devices. Each NetWorker volume pool is defined by its Pool resource in the NetWorker server. The attribute settings in the Pool resource act as a filter that the server uses to determine the type of data to write to volumes in the pool. Each volume pool has a Pool Type attribute. Note: With NSR-DBM-ORA, the only valid pool types are backup and backup clone. Each NetWorker volume belongs to either a preconfigured pool or a user-created pool. Each pool has a specific label template associated with it, providing an automated method to identify the media assigned to a pool. NetWorker software uses pools of volumes and label templates to track the data is on each volume. Note: If a customized volume pool is not specified for Oracle backup volumes, the NetWorker server routes data for an Oracle backup to the appropriate volume pool. 62 NSR-DBM-ORA V5.0 Administrator s Guide

63 Software Configuration Configure any required NetWorker Pool resources and corresponding Label Template resources with the NMC program. The NetWorker Administrator s Guide and NMC online help provide more information. Setting the NSR_DATA_VOLUME_POOL parameter To send data from a manual or scheduled backup to a specific pool, you can set the NSR_DATA_VOLUME_POOL parameter in the RMAN backup session. Chapter 3, Backup Procedures, provides more information on the two types of backups. Note: In the case of proxy backups, the parameter is used to specify the volume pool for live backups only (backups to secondary storage only). The parameter cannot specify the snapshot pool for instant backups. The only way to specify the snapshot pool is by configuring the NetWorker resources, as described in Configuring the NetWorker Pool resources on page 162. NSR_DATA_VOLUME_POOL is mandatory if backup copies are generated during a manual backup only. Separate NetWorker pools must be defined for each backup copy. Backup copies on page 25 provides more information on how to generate backup copies during a manual backup. Appendix A, Parameters in an RMAN Session, provides more information on the NSR_DATA_VOLUME_POOL parameters. Firewall support The NSR-DBM-ORA software provides firewall support. The ports that the NSR-DBM-ORA software uses for the firewall depend on the corresponding ports configured for the NetWorker server. To configure the firewall that the NSR-DBM-ORA software uses, follow the firewall configuration instructions in the NetWorker Administrator s Guide for the particular NetWorker server platform. Verify the NetWorker resources 63

64 Software Configuration Configuring I18N support Internationalization (I18N) on page 31 describes the features of NSR-DBM-ORA internationalization (I18N) support. To configure I18N support: 1. Ensure that you meet the Requirements for I18N support on page Follow the configuration steps in Configure I18N support on page 64. Requirements for I18N support Ensure that all of the following I18N requirements are met: The NSR-DBM-ORA client host includes a supported internationalized version of the operating system, properly configured to operate in the non-english locale. The Oracle software provides the required National Language Support (NLS) or Globalization support, and the Oracle database is configured with the required non-ascii character set. The Oracle Globalization Support documentation provides details. A supported NetWorker release 7.5 or later is installed. For I18N support during proxy operations, a supported release of the PowerSnap Module is installed and configured, as described in the NSR-DBM-ORA Release Notice. The NetWorker documentation provides details on any other I18N requirements. Configure I18N support Note: Configuration of proxy backups or restores with the NSR-DBM-ORA wizard is not supported. Wizard references in the following steps do not apply to the configuration of proxy operations. The PowerSnap Module documentation provides details on the PowerSnap options that support non-ascii values. To configure I18N support on the NSR-DBM-ORA client host: 1. Log in as the root user, then shut down the NetWorker services, set the environment variable LC_ALL to the appropriate locale, and restart the NetWorker services. For example, in a Japanese locale on UNIX, set LC_ALL as follows: # nsr_shutdown # export LC_ALL=JA_jp.eucJP # /etc/init.d/networker start 2. Set the environment variable NLS_LANG to the character set supported by the operating system and Oracle database, and then restart the Oracle Server. The Oracle Globalization Support documentation provides details on the NLS_LANG variable. 64 NSR-DBM-ORA V5.0 Administrator s Guide

65 Software Configuration 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 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; 3. If you do not configure a scheduled backup with the configuration wizard, set the NLS_LANG parameter in the nsrnmo script to the same value as the environment variable NLS_LANG. For example, in a Japanese locale, set NLS_LANG in the nsrnmo script as follows: NLS_LANG=JAPANESE_JAPAN.JA16EUC Note: If you configure the scheduled backup with the configuration wizard, you can set NLS_LANG on a wizard screen. The wizard autopopulates the NLS_LANG field if NLS_LANG is set in the NWORA resource file. 4. To enable proxy catalog synchronization, set the NSR_ORACLE_NLS_LANG parameter to the same value as the environment variable NLS_LANG by using the nsrnmoadmin command. For example, in a Japanese locale, set the parameter by typing the following command: nsrnmoadmin -r add NSR_ORACLE_NLS_LANG JAPANESE_JAPAN.JA16EUC Configuring the NWORA resource file with the nsrnmoadmin program on page 180 provides details on the nsrnmoadmin command. The command sets the parameter value in the NWORA resource file, which is described in The NWORA resource file on page 176. Migrating a legacy configuration with the nsrnmoadmin command You can use the nsrnmoadmin command to migrate a scheduled backup configuration that was created with a legacy method (without the configuration wizard in NSR-DBM-ORA 5.0) to the configuration storage framework that is supported by the new NSR-DBM-ORA wizard. After the migration, you can use the new wizard to modify the backup configuration. As an alternative to using the nsrnmoadmin command for the migration, you can use the Specify the RMAN Script Template (Optional) screen of the NSR-DBM-ORA wizard to retrieve an existing configuration from an RMAN script. To migrate a legacy configuration with the nsrnmoadmin command: 1. Ensure that you meet the Requirements for using the nsrnmoadmin command for migration on page Use the proper nsrnmoadmin command and options, according to the Migration command syntax and options on page 67. Migrating a legacy configuration with the nsrnmoadmin command 65

66 Software Configuration Requirements for using the nsrnmoadmin command for migration Before using the nsrnmoadmin command to migrate a backup configuration, ensure that the appropriate requirements are met: The required NetWorker releases are installed, as described in the NSR-DBM-ORA Release Notice. The nsrnmo script contains the mandatory ORACLE_HOME setting. The RMAN script contains a single valid value for each of the following: Target database username Password of the target database user Net service (instance) name The RMAN script contains correct syntax for the following commands: allocate channel backup connect release channel send The RMAN script does not contain any of the following allocate channel for maintenance configure proxy Note: Migration of a proxy backup configuration is not supported. You have all of the NetWorker privileges needed to query and update the Client resources on a NetWorker server, as described in Table 3 on page 65. The NetWorker documentation provides information on the required user group privileges. If you use the nsrnmoadmin command in interactive mode (without the -Y option), you can provide the names of all the users that will use the wizard to modify the configuration (after it has been migrated): When you use nsrnmoadmin in interactive mode (without the -Y option), you are prompted by default for the names of all such users in ACL format (user@hostname). If you do not provide the usernames when prompted, you must add the usernames at a later time to the NetWorker Lockbock resource for the client by using NMC to edit the resource. The NetWorker Administrator s Guide provides details on editing the Lockbox resource in the section on lockbox password management. When you use nsrnmoadmin in noninteractive mode (with the -Y option), the migration does not prompt for any input. After the migration, you must add the usernames to the NetWorker Lockbox resource for all the users that will use the wizard to modify the configuration. 66 NSR-DBM-ORA V5.0 Administrator s Guide

67 Software Configuration! IMPORTANT If you migrate the backup configuration of a cluster virtual client, you must do one of the following to enable scheduled backups of the client: - During the migration, when nsrnmoadmin prompts for names of wizard users to add to the Lockbox resource, specify the name root@physical_hostname. - After the migration, use NMC to edit the Lockbox resource for the cluster virtual client, and add the name root@physical_hostname to the resource. Migration command syntax and options You must type the nsrnmoadmin command for migration on the operating system command line, as root user on UNIX The command user must meet the migration requirements listed in Table 3 on page 61. The nsrnmoadmin command syntax and options are as follows: nsrnmoadmin -M -s server_name [-c client_name] [-g group_name] [-N save_set_name] [-Y] nsrnmoadmin -P -s server_name [-c client_name] [-g group_name] [-N save_set_name] The -M and -P options are mutually exclusive. Command options and settings in brackets ([ ]) are optional. Do not include the brackets when typing the command. Table 4 on page 67 describes the nsrnmoadmin command options. Table 4 Options of the nsrnmoadmin command for migration (page 1 of 2) Option Description -M Specifies the migrate option. The nsrnmoadmin program performs the following: 1. Queries the NetWorker server resource database to locate all of the Client resources that match the values specified by the -c, -g, -N, and -s options. 2. Migrates each legacy configuration (the nsrnmo script, RMAN script, NWORA resource file, Client resource) to the configuration format that is supported by the new NSR-DBM-ORA wizard. Note: The nsrnmoadmin program can only migrate a configuration that physically resides on the host where the nsrnmoadmin command is typed. To migrate the Client resources for different physical hosts, you must run the nsrnmoadmin program on each physical host, or write a script to automate the process. -P Specifies the probe option. The nsrnmoadmin program performs a probe to query the NetWorker server resource database and locate all of the Client resources that match the values specified by the -c, -g, -N, and -s options, and prints the results to standard output. The program does not actually migrate any legacy configurations. Note: The nsrnmoadmin program can only probe configurations that physically reside on the host where the nsrnmoadmin command is typed. To probe the Client resources created for different physical hosts, you must run the nsrnmoadmin program on each physical host. -c client_name Optional. Specifies the hostname of the NetWorker client to be configured. Typically, this option specifies a virtual client in a cluster. The default value is the hostname of the local physical client. -g group_name Optional. Specifies the name of the NetWorker group for the query operation. If this option is not specified, then a group name is not included in the criteria for the query of the server resource database. -N save_set_name Optional. Specifies the value set in the Save Set attribute of the Client resource. If this option is not specified, then a save set name is not included in the criteria for the query of the server resource database. Migrating a legacy configuration with the nsrnmoadmin command 67

68 Software Configuration Table 4 Options of the nsrnmoadmin command for migration (page 2 of 2) Option Description -s server_name Mandatory. Specifies the hostname of the NetWorker server that backs up the client being configured. -Y Optional. Specifies non-interactive mode, which causes the nsrnmoadmin program to proceed with a migration without prompting for confirmation. If this option is not specified, the nsrnmoadmin program displays all of the fields to be updated in the Client resource and requests confirmation to proceed with the migration. Configuring a backup with the NMC wizard To configure a backup with the wizard: 1. Review the information in About the backup configuration wizard on page Ensure that you meet the Requirements for using the backup configuration wizard on page Follow the configuration steps in Configure a backup with the wizard on page 69. About the backup configuration wizard NSR-DBM-ORA release 5.0 includes a new NMC-based backup configuration wizard (also known as Client Backup Configuration in NMC) that is integrated with a supported NMC release 7.5 or later. Configuration wizards on page 28 describes the main features of the backup configuration wizard. The wizard can configure the Client, Group, and Policy (browse or retention) resources for a scheduled backup. Other NetWorker resources must be configured manually (without the wizard) through NMC, as described in Configuring a backup with the NMC legacy method on page 70. The wizard option for configuring a "typical" scheduled backup provides a more simplified workflow that generates predefined values (for the number of backup channels, backup name format, and so on). The wizard help provides details on the predefined settings used for a typical scheduled backup. To use the NSR-DBM-ORA wizard to modify an existing legacy configuration that was not created with the wizard, you must first migrate the configuration according to Migrating a legacy configuration with the nsrnmoadmin command on page 65. The following sources provide more information on the configuration wizard: NetWorker Administrator s Guide or Release Notice Descriptive inline text in the wizard Online help in the wizard Requirements for using the backup configuration wizard Before you use the backup configuration wizard, ensure that all of the following requirements are met: The NMC user that starts the wizard (the wizard user) has the Configure NetWorker privileges on the NetWorker server where the configuration is created. 68 NSR-DBM-ORA V5.0 Administrator s Guide

69 Software Configuration Communication between the NMC server, NetWorker server, and NSR-DBM-ORA client uses nsrauth authentication. The NetWorker documentation provides any requirements for nsrauth authentication. The required NetWorker releases are installed on the NMC server, NetWorker server, and NSR-DBM-ORA client hosts, as described in the NSR-DBM-ORA Release Notice. Configure a backup with the wizard To create or modify a backup configuration with the wizard: 1. Start the NetWorker Management Console software. 2. Open the Administration window: a. In the Console window, click Enterprise. b. In the left pane, select a NetWorker server in the Enterprise list. c. In the right pane, select the application. d. From the Enterprise menu, click Launch Application. The Administration window is launched as a separate application. 3. In the Administration window, click Configuration. 4. In the Configuration window, click Clients. 5. Start the wizard by the appropriate method: If you are creating a new backup configuration, use one of the following methods: Select Configuration > Client Backup Configuration > New. In the left pane under the client name, right-click Clients and select Client Backup Configuration > New. In the main Clients list, right-click the NSR-DBM-ORA client and select Client Backup Configuration > New. If you are modifying an existing backup configuration, right-click the NSR-DBM-ORA client in the right pane, and select Client Backup Configuration > Modify. 6. On each wizard screen that appears, specify the required options and values for the backup configuration. If you use the wizard to configure a deduplication backup, ensure that the Filesperset field is set to 1 on the Specify the RMAN Options (Part 1 of 2) screen. Each wizard screen includes an online help button that you can click to access descriptions of all the fields and options on the screen: On all but the last screen, click Next to proceed. On the last screen, Review and Accept the Client Configuration, click Create or Modify to create or modify the configuration, respectively, and click Finish to exit the wizard. If you choose to save configuration settings to an RMAN script on disk, you can edit the script later and also use the script for a manual NSR-DBM-ORA backup. The resources required for a manual backup must be configured with the legacy method (without the wizard). Configuring a backup with the NMC wizard 69

70 Software Configuration! IMPORTANT When you use the wizard to configure a cluster virtual client, the wizard attempts to perform all of the additional settings required for the cluster environment, including the following: - Creating the required Client resources. - Adding the required ACL entries to the Lockbox resource, for the physical hosts provided in the Remote Access field on the NetWorker Client Properties screen of the wizard. - Setting the NSR_CLIENT parameter. - Adding the -c virtual_clientname option to the Backup Command attribute in the Client resource of the virtual client. In the Client resource of the virtual client, ensure that the Remote Access attribute is set with user@physical_hostname for each of the physical hosts of the cluster; otherwise, the backup might fail. Configuring a backup with the NMC legacy method The following sections describe how to configure backups with the legacy method (without the configuration wizard). About backup configuration with the legacy method NSR-DBM-ORA release 5.0 still supports the legacy method of backup configuration, as used in previous NSR-DBM-ORA releases. To configure a scheduled backup, you can still manually create an RMAN script and nsrnmo script, set parameters in the NWORA resource file if needed, and configure the NetWorker resources with NMC. As an alternative, you can use the backup configuration wizard to configure a scheduled backup, as described in Configuring a backup with the NMC wizard on page 68. However, NetWorker resources other than the Client and Group resource must still be configured manually with NMC. For a manual backup, the NetWorker Client resource must be modified manually through the legacy method, as required. Create RMAN scripts for backups Create an appropriate RMAN script to perform the preferred type of manual or scheduled backup on the Oracle Server host. NSR* parameters in the script must be set with the methods described in Setting the NSR* parameters on page 190. The use of the send command is recommended where possible. The send command on page 201 provides more information. NSR* parameters cannot be set through other methods, for example, by using the setenv or set command on the operating system command line. Appendix A, Parameters in an RMAN Session, provides complete information on the NSR* parameters in the RMAN script or session. RMAN backup scripts can be stored as flat ASCII files. Alternatively, if a Recovery Catalog is used, backup scripts can be stored in the Recovery Catalog database. The appropriate Oracle backup and recovery documentation provides information on storing the backup scripts in the Recovery Catalog database. 70 NSR-DBM-ORA V5.0 Administrator s Guide

71 Software Configuration The following sections provide details on RMAN scripts for manual backups and scheduled backups. RMAN scripts for manual backups If automatic channel allocation and persistent settings are used, the backup command can be run as a stand-alone command. Automatic channel allocation on page 24 provides more information. Example 10 RMAN script for a manual backup The following RMAN script is for a manual backup of an entire Oracle database to the volume pool MondayFulls of the (remote) NetWorker server mars.fujitsu.com : run { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=mars.fujitsu.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, NSR-DBM-ORA) 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 NSR-DBM-ORA uninstalled), backups can be directed to disk files through Oracle s backup implementation. In the preceding RMAN backup script, the format string FULL_%d_%U specifies the name of each backup piece. This name can be anything, provided that each backup piece has a unique name on the NetWorker server. Substitution variables, such as %d and %U, can be used to guarantee unique names: %d specifies the name of the database. %U specifies a unique Oracle system-generated filename. A format string such as FULL or FULL_%d will not generate unique names. Similarly, the format string FULL_%U will not generate unique names for two databases that are being backed up to the same NetWorker server.! IMPORTANT If a backup piece name is not unique, the Oracle backup fails. During a manual backup, the prefix RMAN: automatically precedes the backup piece name in the NetWorker media database. For example, if the backup piece name specified in the RMAN script is accounts_data_file, the manual backup records the save set name as RMAN:accounts_data_file in the media database. The mminfo command displays the save set name in this form. The following sources provide more information: The appropriate Oracle backup and recovery documentation provides information on how to write RMAN scripts. The Oracle Enterprise Manager documentation provides information on how to use the Oracle Enterprise Manager Backup Wizard to generate RMAN scripts. Configuring a backup with the NMC legacy method 71

72 Software Configuration Appendix B, RMAN Commands, provides important information on RMAN commands. Regular backup information in NetWorker indexes on page 108 describes the information stored for a manual backup in the NetWorker indexes. Example 11 RMAN script for AES encryption during an Oracle backup The following RMAN script performs a nonproxy backup of the Oracle database to the NetWorker server mars.fujitsu.com by using 256-bit AES encryption, as specified by the NSR_AES_ENCRYPTION parameter setting: run { allocate channel t1 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=mars.fujitsu.com, NSR_AES_ENCRYPTION=TRUE) ; backup full filesperset 4 format FULL_%d_%U (database); release channel t1; } The AES encryption uses the key or pass phrase that is set in the Datazone pass phrase attribute of the NetWorker Server resource. NSR_AES_ENCRYPTION on page 191 provides more information.! IMPORTANT Keep a record of all pass phrases used for 256-bit AES encryption. Be careful when you change the pass phrase on the NetWorker server. If the pass phrase on the server is changed and you cannot remember the pass phrase used for an NSR-DBM-ORA backup, the encrypted data cannot be recovered. The NetWorker Administrator s Guide provides more information on pass phrases. RMAN scripts for scheduled backups Example 17 on page 116 shows a sample Oracle restore of an AES encrypted backup, with the NSR_ENCRYPTION_PHRASES parameter that specifies the original pass phrase that was used for the backup.! IMPORTANT For scheduled backups (both regular and proxy backups), do not include send as part of the allocate channel command. The send command must be separate. For example, NSR-DBM-ORA does not support the following for scheduled backups: allocate channel t1 type SBT_TAPE send NSR_ENV=(NSR_SERVER=mars.fujitsu.com ) ; The following is the correct form of the commands: allocate channel t1 type SBT_TAPE ; send channel t1 NSR_ENV=(NSR_SERVER=mars.fujitsu.com ) ; With automatic channel allocation, specifying the send command before the backup or restore command causes the following error: RMAN-06422: no channels found for SEND command Automatic channel allocation on page 24 provides information on automatic channel allocation. 72 NSR-DBM-ORA V5.0 Administrator s Guide

73 Software Configuration Example 12 RMAN script for a scheduled backup The following RMAN script is for a scheduled backup of an entire Oracle database to the volume pool MondayFulls. The Recovery Catalog is used in this case: connect target target_user/target_passwd@target_netservicename; connect rcvcat rcvcat_user/rcvcat_passwd@rcvcat_netservicename; run { set command id to xxx ; 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 The command connect target target_user/target_passwd@target_netservicename is mandatory in each RMAN script for a scheduled backup. This command establishes the proper connection to the target database. Specify the correct values in the connect target command: target_user is the user with SYSDBA privileges for the target database. target_passwd is the password of the target_user (for connecting as SYSDBA), specified in the target database s orapwd file. target_netservicename is the Net service name of the target database. This name is mandatory in the connect target command. A password file must be used for the target database. To use the password file, the orapwd utility might need to be used and the REMOTE_LOGIN_PASSWORDFILE parameter set to exclusive in the initoracle_sid.ora file. The appropriate Oracle documentation provides more information. Notes: Since each scheduled backup RMAN script requires a connect target command, each Oracle instance requires a separate scheduled backup RMAN script. In the connect target command, do not use the value internal for target_user or the value oracle for target_passwd. The command connect rcvcat rcvcat_user/rcvcat_passwd@rcvcat_netservicename is mandatory if the Recovery Catalog is used for the scheduled Oracle backup. This command establishes the proper connection to the Recovery Catalog database. Specify the correct values in the connect rcvcat command: rcvcat_user is the owner of the Recovery Catalog database. rcvcat_passwd is the password of the rcvcat_user. rcvcat_netservicename is the Net service name of the Recovery Catalog database. To enable the scheduled backup to be canceled, the scheduled Oracle backup script must include set command id to xxx (where xxx can be any string of characters Configuring a backup with the NMC legacy method 73

74 Software Configuration enclosed in single quotes). Cancel a scheduled backup on page 105 provides more information on how to cancel a scheduled backup. The remainder of the scheduled backup script in Example 12 on page 73, starting with the first allocate channel command, is similar to the manual backup script in Example 10 on page 71 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. NSR-DBM-ORA sets these two parameters to the values specified in the Client resource for the scheduled Oracle backup, and these values cannot be overridden. To have the scheduled backup automatically use a volume pool, the backup group can be specified in the Pool resource. The scheduled backup uses that pool unless the parameter NSR_DATA_VOLUME_POOL is set in the RMAN script. Then that parameter s setting takes precedence over any pool associated with the scheduled backup group. If NSR_DATA_VOLUME_POOL is set in the RMAN script to a pool different from the one associated with the backup group, the scheduled backup uses the NSR_DATA_VOLUME_POOL pool. It is the user s responsibility to set that parameter correctly in the RMAN script for a scheduled backup. Each scheduled backup RMAN script must be stored as a text file. The database administrator should give minimal permissions to the scheduled backup RMAN script file. This way, unauthorized users cannot see the sensitive user IDs and passwords of the target and Recovery Catalog databases. If a single Oracle instance has multiple RMAN scripts associated with it (for example, to perform tablespace-level or file-level, full or incremental backups, and so on), the database administrator might choose to place the two common connect commands in a single file and invoke those two connect commands in all RMAN scripts by using command. Test RMAN scripts for scheduled backups When you create an RMAN script, test the script before using it for scheduled backups. To test the RMAN script, type one of the following commands: rman cmdfile script_name send NSR_ENV=(NSR_SERVER=NetWorker_server_name, NSR_GROUP=group_name) rman nocatalog cmdfile script_name send NSR_ENV=(NSR_SERVER=NetWorker_server_name, NSR_GROUP=group_name) where: 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. 74 NSR-DBM-ORA V5.0 Administrator s Guide

75 Software Configuration Customize the nsrnmo script Customize the nsrnmo script on the Oracle Server host by modifying the parameters in the script. The NSR-DBM-ORA installation on the Oracle Server host stores a sample nsrnmo script in the /opt/nsr directory. The sample script filename is nsrnmo.sh. Multiple versions of the nsrnmo script can be created (for example, one for each Oracle instance) on the same Oracle Server host. Each version of the script must have a unique name, starting with the letters nsr or To create a new version of the nsrnmo script: 1. Copy the sample script file (nsrnmo on UNIX ) to a file with a different name. 2. Customize the parameters in the new file. For example, you might create the new script file named nsrnmo_proddb on UNIX. All versions of the nsrnmo script must be located in the same directory as the NetWorker executables. Do not move the nsrnmo scripts to a different directory. Notes: A nsrnmo script from a previous NSR-DBM-ORA release works with NSR-DBM-ORA release 5.0. However, the nsrnmo script installed with NSR-DBM-ORA release 5.0 might include new parameter settings not found in the script from the previous release. To facilitate the correct reporting of scheduled backup save sets for a UNIX NSR-DBM-ORA client within the group details window of the NetWorker Management Console (NMC), specify the following shell within the nsrnmo script on UNIX: /bin/bash, if it exists on the UNIX client /bin/ksh, if /bin/bash does not exist on the UNIX client The nsrnmo script on Solaris zones On a Solaris system with Solaris zones, a sparse root zone can have shared directories that are mounted from the global zone. Such directories are read-only on the sparse root zone. If NSR-DBM-ORA is installed on a sparse root zone and /opt is one of the shared directories, the nsrnmo script in /opt/nsr is read-only on the sparse root zone. In this case, the nsrnmo script must be edited on the global zone. If multiple sparse root zones are configured on a physical computer, all of the virtual sparse root zones see the nsrnmo script in /opt/nsr. In this case, each sparse root zone should use a unique script filename, such as nsrnmo1, nsrnmo2, and so on. The Backup Command attribute in the Client resource for each sparse root zone must contain the unique nsrnmo filename for that zone. Configure a Client resource with NMC on page 81 provides more information on the Client resource. Parameters in the nsrnmo script The sample nsrnmo script installed with NSR-DBM-ORA contains parameters that must be customized for a particular scheduled Oracle backup. The parameters in the sample nsrnmo script are all undefined by default. The nsrnmo script contains only the parameters required on the particular system where the script is installed. The LD_LIBRARY_PATH parameter appears in the nsrnmo script on Linux and Solaris. Follow the instructions in the Oracle installation guide to determine to what value to set the parameter LD_LIBRARY_PATH. Configuring a backup with the NMC legacy method 75

76 Software Configuration The ORACLE_HOME parameter is mandatory for each scheduled backup, and must be set in the nsrnmo script. The other parameters in the nsrnmo script are optional, and can be left undefined in the script, if preferred. Note: For other parameters to be in effect during a scheduled backup, lines must be added in the nsrnmo script to define and export the parameters. The use of the UNIX setenv command to set the parameters has no effect. The following sections describe the parameters that can be set in the nsrnmo script for scheduled backups. The comments in the nsrnmo script file provide details on the parameters: ORACLE_HOME on page 76 LD_LIBRARY_PATH on page 76 NSR_RMAN_ARGUMENTS on page 77 NSR_SB_DEBUG_FILE on page 77 ORACLE_SID on page 77 ORACLE_USER on page 78 PRECMD on page 78 POSTCMD on page 79 TNS_ADMIN on page 80 ORACLE_HOME This parameter is mandatory for each scheduled backup. Set ORACLE_HOME in the nsrnmo script file to the home directory of the Oracle Server installation. The RMAN executable, rman, must be located in the subdirectory bin of $ORACLE_HOME. For example, if the Oracle Server installation is located in the directory /disk3/oracle/app/oracle/product/10.0, ORACLE_HOME must be set in the nsrnmo script as follows: ORACLE_HOME=/disk3/oracle/app/oracle/product/10.0 LD_LIBRARY_PATH This parameter is optional for a scheduled backup. Set LD_LIBRARY_PATH in the nsrnmo script file to the pathname of the directory that contains the Oracle libraries, typically $ORACLE_HOME/lib or $ORACLE_HOME/lib64. For example, if the Oracle libraries are located in the directory /disk3/oracle/app/oracle/product/10.0/lib, set LD_LIBRARY_PATH in the nsrnmo script as follows: LD_LIBRARY_PATH=/disk3/oracle/app/oracle/product/10.0/lib Uncomment the line export LD_LIBRARY_PATH (by removing the # symbol at the start of the line) under the export_environment variables() function heading in the nsrnmo script: export_environment_variables() { export ORACLE_HOME export NSR_RMAN_ARGUMENTS : : export LD_LIBRARY_PATH } 76 NSR-DBM-ORA V5.0 Administrator s Guide

77 Software Configuration NSR_RMAN_ARGUMENTS This parameter is optional for a scheduled backup. Set NSR_RMAN_ARGUMENTS to a double-quoted string that contains any valid combination of options for the RMAN executable, rman. The appropriate Oracle Recovery Manager documentation provides details on the valid options. For example, to append RMAN output to the message log file /nsr/applogs/msglog.log, set NSR_RMAN_ARGUMENTS in the nsrnmo script as follows: NSR_RMAN_ARGUMENTS="msglog /nsr/applogs/msglog.log append" To append RMAN output to the message log file /nsr/applogs/msglog.log if a Recovery Catalog is not used, set NSR_RMAN_ARGUMENTS in the nsrnmo script as follows: NSR_RMAN_ARGUMENTS="nocatalog msglog /nsr/applogs/msglog.log append" NSR_SB_DEBUG_FILE This parameter is optional for a scheduled backup. It is used only for debugging purposes. Enable debugging by setting NSR_SB_DEBUG_FILE to the complete pathname of a file to receive detailed debug information for the scheduled backup. This file will exclude MML-specific debug information, which is directed to NSR_DEBUG_FILE (if set in the RMAN script). Note: If NSR_SB_DEBUG_FILE is undefined (by default), no debug information is generated. If a file with the specified pathname cannot be created, debug information is either directed to the default location or not generated. For example, to send detailed debug information for the scheduled backup to the /usr/logs/schedbkup.log file, set the parameter NSR_SB_DEBUG_FILE in the nsrnmo script as follows: NSR_SB_DEBUG_FILE=/usr/logs/schedbkup.log NSR-DBM-ORA error messages on page 212 provides more information on how the debug information is written if the parameter NSR_SB_DEBUG_FILE is set to an invalid pathname. ORACLE_SID This parameter is required for a scheduled backup in the following cases: The connect target and connect rcvcat commands for the scheduled backup are stored in a separate file, and the connect commands are invoked in the RMAN script by using command. Save set bundling is enabled for the scheduled backup. A proxy backup is performed with catalog synchronization enabled. Chapter 7, Proxy Backups and Restores, provides more information on proxy backups and catalog synchronization. Set ORACLE_SID in the nsrnmo script file to the system identifier (SID) value of the Oracle database to be backed up. For example, if catalog synchronization is enabled for proxy backups and the SID of the Oracle database to be backed up is orcl10, ORACLE_SID must be set as follows: ORACLE_SID=orcl10 Configuring a backup with the NMC legacy method 77

78 Software Configuration ORACLE_USER This parameter is optional for a scheduled backup configured through the legacy method (without the wizard). Enable the scheduled backup for operating system authentication by setting ORACLE_USER to the username of the Oracle operating system user, which is set up to connect to the Oracle database through operating system authentication. Note: Using ORACLE_USER to perform an NSR-DBM-ORA backup through operating system authentication is not supported for the following: - A scheduled backup configured through the new configuration wizard. - A probe-based backup. - A scheduled proxy backup. For example, to perform a scheduled NSR-DBM-ORA backup on UNIX through operating system authentication (the backup must be configured through the legacy method), set ORACLE_USER to the required Oracle operating system username: ORACLE_USER=Oracle_OS_username PRECMD This parameter is optional. Set PRECMD to the complete pathname of a file containing a preprocessing script to be executed before the RMAN backup script. If the pre-command script fails (returns a nonzero value), the scheduled Oracle backup does not proceed (that is, the RMAN script is not executed).! IMPORTANT The script file must have permissions that allow execution by the root user, as the scheduled Oracle backup is always launched by root. The script should return a zero value when it succeeds and a nonzero value when it fails. The return of a nonzero value will cause the scheduled backup to fail. A sample preprocessing script for UNIX is shown as follows. This script is stored in the file whose complete pathname is specified in the parameter PRECMD in the nsrnmo script. For example, if the script is stored in the /usr/scripts/orashutdown file, set the parameter PRECMD as follows: PRECMD=/usr/scripts/orashutdown This sample script shuts down the Oracle database, presumably for an offline database backup. The su command is required in the script since the nsrnmo script runs as root user: #!/bin/ksh # Define Site Specifics Here TARGET_DATABASE=proddb ERRFILE=/tmp/precmd.log ORACLE_USER=proddb # # Scheduled backup launches as "root" run PRECMD as oracle user su - $ORACLE_USER -c "{ # Shutdown target database and start in maintenace mode export ORACLE_SID=$TARGET_DATABASE svrmgrl <<EOF1 > $ERRFILE connect internal shutdown startup mount 78 NSR-DBM-ORA V5.0 Administrator s Guide

79 Software Configuration exit EOF1 }" # Do checking as root since "su" will always return its status export status # Define status otherwise it is local to if [] statement status=0 # Scan file for errors and only return true or false grep -e error -e warning -e fatal $ERRFILE > /dev/null 2>&1 if [ $? -eq 0 ]; then status=1 else status=0 fi exit $status POSTCMD This parameter is optional. Set POSTCMD to the complete pathname of a file that contains a postprocessing script to be executed after the RMAN backup script. If the RMAN backup script fails, the failure is reported, and the postprocessing script is executed nevertheless. If the postprocessing script fails, an error message is reported.! IMPORTANT The script file must have permissions allowing execution by the root user, as the scheduled Oracle backup is always launched by root. The script should return a zero value when it succeeds and a nonzero value when it fails. A sample postprocessing script for UNIX is shown as follows. This script is stored in the file whose complete pathname is specified in the parameter POSTCMD in the nsrnmo script. For example, if the script is stored in the /usr/scripts/orastartup file, set the parameter POSTCMD as follows: POSTCMD=/usr/scripts/orastartup This sample script starts up the Oracle database, presumably after an offline backup. The su command is required in the script since the nsrnmo script runs as root user: #!/bin/ksh # Define Site Specifics Here TARGET_DATABASE=proddb ERRFILE=/tmp/postcmd.log ORACLE_USER=proddb # # Scheduled backup launches as "root" run POSTCMD as user proddb su - $ORACLE_USER -c "{ # Mount target database as ready for use export ORACLE_SID=$TARGET_DATABASE svrmgrl <<EOF > $ERRFILE connect internal alter database open; exit EOF }" # Do checking as root since "su" will always return its status export status # Define status otherwise it is local to if [] statement status=0 # Scan file for errors and only return true or false Configuring a backup with the NMC legacy method 79

80 Software Configuration grep -e ORA- -e error -e warning -e fatal $ERRFILE > /dev/null 2>&1 if [ $? -eq 0 ]; then status=1 else status=0 fi exit $status TNS_ADMIN This parameter is mandatory if the Oracle Net configuration files are located in a directory other than the default $ORACLE_HOME/network/admin directory. In this case, set the value of TNS_ADMIN to the pathname of the directory that contains the Oracle Net configuration files. To set TNS_ADMIN in the nsrnmo script, follow the example shown in LD_LIBRARY_PATH on page 76. Replace LD_LIBRARY_PATH with TNS_ADMIN. Uncomment the line export TNS_ADMIN in the script. Configure a Group resource with NMC Note: As an alternative, you can use the backup configuration wizard to configure the Group resource, as described in Configuring a backup with the NMC wizard on page 68. Configuring a probe-based backup on page 90 provides details on configuration requirements for a probe-based backup. For a scheduled NSR-DBM-ORA backup, a NetWorker Group resource must be configured that specifies the attributes of the backup group. The Group resource specifies a set of NetWorker Client resources that all start to back up data at a specified time, once the following occurs: The Autostart attribute is enabled. The backup start time is specified in the Group resource. By configuring one or more NetWorker backup groups for scheduled backups, the backups can be: Distributed to alleviate network traffic. Scheduled for a time of day when performance demands on the database and NetWorker server are lower. One or more Client resources configured for the Oracle Server host can be assigned to a NetWorker backup group. All NetWorker backup groups can be created and modified. All backup groups except the Default group can be deleted. To use the Default group for testing scheduled backups, change its Autostart attribute to Enabled. Note: To have a regular scheduled backup automatically use a volume pool associated with the backup group, specify the group name in the Pool resource for the volume pool.! IMPORTANT For a regular scheduled Oracle backup, the Snapshot attribute in the Group resource must be set to False. 80 NSR-DBM-ORA V5.0 Administrator s Guide

81 Software Configuration You can create a NetWorker Group resource with the NMC interface. The NetWorker Administrator s Guide and NMC online help provide more information. Configure a Schedule resource with NMC Review the summary information in NetWorker Schedule resource on page 61. Configure the NetWorker Schedule resource with NMC, to specify the days of the week when a scheduled Oracle backup runs. The NetWorker server provides several preconfigured schedules. Both the preconfigured schedules and customized schedules can be created and modified. The NetWorker Administrator s Guide and NMC online help provide more information on how to use the NMC interface. Customize a NetWorker Schedule resource for an Oracle backup. In the Schedule resource, select a level for each day of the week: Level full, incremental, or level 1 to 9 specifies that the NetWorker server runs the backup script on that day. Level skip specifies that the NetWorker server does not run the backup script on that day. Specify the name of the NetWorker schedule in the Schedule attribute of the Client resource, as described in Configure a Client resource with NMC on page 81. Configure a Client resource with NMC Note: As an alternative, you can use the backup configuration wizard to configure the Client resource, as described in Configuring a backup with the NMC wizard on page 68. Configuring a probe-based backup on page 90 provides details on configuration requirements for a probe-based backup. A NetWorker Client resource is a set of attributes assigned to the NSR-DBM-ORA client host and stored on the NetWorker server. Before NSR-DBM-ORA software can be used for backups or restores, a Client resource must be configured for the NSR-DBM-ORA client host. If the NetWorker server software is installed on the NSR-DBM-ORA client host, a basic Client resource for the NSR-DBM-ORA client is created automatically during the NetWorker installation. The Client resource must be customized for an NSR-DBM-ORA backup. NetWorker indexes and policies used for restores on page 112 provides more information on how the NetWorker server uses the browse and retention policies to manage Oracle backup data and enable the data to be restored. Configuring the NetWorker Client resource on page 163 provides information on how to configure the Client resource for proxy backups. To configure the Client resource for a regular scheduled backup by using the NMC interface, specify the required values for each attribute, according to Table 5 on page 82. Leave the following attributes blank: Directive Archive Users Configuring a backup with the NMC legacy method 81

82 Software Configuration Remote User Password Note: On a Solaris system with Solaris zones, ensure that the security fields (such as Remote Access and Privileges) of NetWorker resources used during NSR-DBM-ORA backups and restores refer to the hostname of the zone in which NSR-DBM-ORA operates. Each Oracle installation requires a separate Client resource. The Backup Command attribute of the Client resource must contain only one nsrnmo script name, and ORACLE_HOME is a mandatory parameter in each nsrnmo script. If multiple RMAN scripts are specified for the Save Set attribute of the Client resource: The RMAN scripts are executed in arbitrary order, possibly in parallel. If the nsrnmo script also contains a well-defined setting for PRECMD or POSTCMD, the precommand and postcommand files will be: Common for all the RMAN scripts Executed once for each RMAN script The sequence of execution of precommand RMAN script postcommand triplets is arbitrary. To include preprocessing and postprocessing with the backups of the various Oracle database instances of an Oracle installation, define a separate NetWorker Client resource for each Oracle instance. Note: If a scheduled Oracle backup is retried, the specified precommand and postcommand will be executed again for that backup. Figure 6 on page 84 shows a sample Client resource for a UNIX NSR-DBM-ORA client.. Table 5 NetWorker Client resource attributes (page 1 of 2) Attribute Name Backup Command Description Specifies the hostname of the Oracle Server host. For a scheduled backup configured through the legacy method with NMC (not through the wizard), specifies the name of a single customized nsrnmo script to use for the backup. For example, the nsrnmo script name might be nsrnmo or nsrnmo2 on UNIX. On a Solaris system with Solaris zones where NSR-DBM-ORA is installed on sparse root zones, the Backup Command attribute in the Client resource for each sparse root zone must contain the unique nsrnmo filename for that zone. Note: If you configure a scheduled backup through the configuration wizard, the wizard automatically adds the nsrnmostart program name to this attribute. In that case, do not modify this attribute. Browse Policy Specifies the length of time that the NetWorker server retains an entry for an Oracle backup in the online client file index. This attribute applies only to scheduled backups. Note: For a scheduled backup, if the parameter NSR_SAVESET_BROWSE is set as described in Appendix A, Parameters in an RMAN Session, its value overrides the Browse Policy attribute setting in the Client resource. To set a specific browse policy for a manual backup, use the parameter NSR_SAVESET_BROWSE. If the parameter is not set, the NetWorker server uses the most appropriate value for the browse policy. Group Specifies the NetWorker backup group to use for a scheduled backup. Configure a Group resource with NMC on page 80 provides more information on NetWorker backup groups. 82 NSR-DBM-ORA V5.0 Administrator s Guide

83 Software Configuration Table 5 NetWorker Client resource attributes (page 2 of 2) Attribute Remote Access Description Specifies the fully qualified hostname of a remote system, to enable restores of the backups to that remote system. On a Solaris system with Solaris zones, the Remote Access attribute must contain the hostname of the zone in which NSR-DBM-ORA operates. Note: If backups from a cluster, or recovery to a host other than the one being backed up, are not required, do not modify the Remote Access attribute. Retention Policy Specifies the minimum length of time that the NetWorker server maintains information about Oracle backup data in the online media database. This attribute applies only to scheduled backups. Note: For a scheduled backup, if the parameter NSR_SAVESET_RETENTION is set as described in Appendix A, Parameters in an RMAN Session, its value overrides the Retention Policy attribute setting in the Client resource. To set a specific retention policy for a manual backup, use the parameter NSR_SAVESET_RETENTION. If the parameter is not set, the NetWorker server uses the most appropriate value for the retention policy. Save Set Specifies the complete pathname of each RMAN script to be used for a scheduled backup, preceded by RMAN:. Do not include any spaces between the prefix RMAN: and the script name. For example, if two separate RMAN backup scripts are created in the files /disk/rman_scripts/archlogbkup and /disk/rman_scripts/fullbkup (to be run by the nsrnmo script in the Backup Command attribute), specify the complete file pathnames prepended by RMAN: in the Save Set attribute: RMAN:/disk/rman_scripts/archlogbkup RMAN:/disk/rman_scripts/fullbkup Note: If you configure a scheduled backup through the configuration wizard, the wizard automatically includes the prefix RMAN: in the Save Set attribute setting, as described in Backup configuration storage with the wizard on page 29. The save set information for the scheduled backup is stored in the NetWorker indexes as described in: Regular backup information in NetWorker indexes on page 108 Deduplication backup information in NetWorker indexes on page 109 Schedule Specifies the NetWorker backup schedule to use for a scheduled backup. Configure a Schedule resource with NMC on page 81 provides more information on NetWorker backup schedules. Configuring a backup with the NMC legacy method 83

84 Software Configuration Figure 6 UNIX Client resource for scheduled backups Configure an notification To send an notification of the scheduled backup results to the owner of a save set, edit the Owner Notification attribute in the Client resource for the Oracle Server (or Oracle instance). In the Owner Notification attribute, specify a notification command directed to the login ID of the owner, for example: /usr/bin/mail -s server1-server2-server3 backup jdoe The NetWorker Administrator s Guide and NMC online help provide more information on how to edit the attributes of the NetWorker Client resource. Configure save set bundling This section describes how to manually configure save set bundling for NSR-DBM-ORA scheduled backups. As an alternative, you can use the backup configuration wizard to configure the scheduled backup and set the NSR_BUNDLING parameter to enable save set bundling. Configuring a backup with the NMC wizard on page 68 provides more information. 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 NSR-DBM-ORA V5.0 Administrator s Guide

85 Software Configuration To enable save set bundling: Set the NSR_BUNDLING parameter value to enabled by typing the following command: nsrnmoadmin -r add NSR_BUNDLING enabled By default, the NSR_BUNDLING parameter is disabled. Configuring the NWORA resource file with the nsrnmoadmin program on page 180 provides details on the nsrnmoadmin command. The command sets the parameter value in the NWORA resource file, which is described in The NWORA resource file on page 176. Ensure that NSR-DBM-ORA scheduled backups are configured properly according to the Configuration roadmap on page 58. Ensure that the user group privileges for the root or administrative user on the NSR-DBM-ORA 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 60. 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 ensure the following: The ORACLE_SID parameter is set in the nsrnmo script, as described in Customize the nsrnmo script on page 75. 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 178. NSR-DBM-ORA 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, NSR-DBM-ORA must retrieve the connection strings from the connection file specified by the parameter in the NWORA resource file. Ensure that the NetWorker server is release 7.4 or later, to support staging of the NSR-DBM-ORA save set bundles. In a RAC system, ensure that all channels are allocated on the same NSR-DBM-ORA client node where the backup is initiated. Save set bundling does not support load balancing across different RAC nodes. To disable save set bundling, set the NSR_BUNDLING parameter value to disabled by typing the following command: nsrnmoadmin -r update NSR_BUNDLING disabled Configure policy uniformity This section describes how to manually configure policy uniformity for NSR-DBM-ORA backups. As an alternative, you can use the backup configuration wizard to set the NSR_INCR_EXPIRATION parameter to enable policy uniformity. Configuring a backup with the NMC wizard on page 68 provides more information. Policy uniformity can be enabled and disabled independently of save set bundling. If save set bundling is enabled, as described in Configure save set bundling on page 84, policy uniformity should also be enabled. Configuring a backup with the NMC legacy method 85

86 Software Configuration To enable policy uniformity: Set the NSR_INCR_EXPIRATION parameter value to enabled by typing the following command: nsrnmoadmin -r add NSR_INCR_EXPIRATION enabled By default, the NSR_INCR_EXPIRATION parameter is disabled. Configuring the NWORA resource file with the nsrnmoadmin program on page 180 provides details on the nsrnmoadmin command. The command sets the parameter value in the NWORA resource file, which is described in The NWORA resource file on page 176. Ensure that NSR-DBM-ORA scheduled backups are configured properly according to the Configuration roadmap on page 58. Ensure that the user group privileges for the root or administrative user on the NSR-DBM-ORA 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 60. 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 ensure the following: The ORACLE_SID parameter is set in the nsrnmo script, as described in Customize the nsrnmo script on page 75. 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 178. NSR-DBM-ORA 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, NSR-DBM-ORA 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 NSR-DBM-ORA 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: nsrnmoadmin -r update NSR_INCR_EXPIRATION disabled Configuring a deduplication backup To configure a deduplication NSR-DBM-ORA backup: 1. Review the following sections: Deduplication backups and restores on page 20 Requirements for a deduplication backup on page 87 Best practices for a deduplication backup on page Follow the configuration steps in Configure a deduplication backup on page NSR-DBM-ORA V5.0 Administrator s Guide

87 Software Configuration Requirements for a deduplication backup Before you configure a deduplication backup, ensure that all of the following requirements are met: The NSR-DBM-ORA client platform and operating system support deduplication. The NetWorker client and server releases support NSR-DBM-ORA deduplication. The NSR-DBM-ORA Release Notice provides more details. The Avamar server is installed and configured as a NetWorker deduplication node. The NetWorker documentation provides more details. The NetWorker backup device (receives only the backup metadata or hash ID during the NSR-DBM-ORA deduplication backup) is configured as an advanced file type device (AFTD), as described in the NetWorker Administrator s Guide. Best practices for a deduplication backup This section provides recommendations on when to use NSR-DBM-ORA deduplication, and configuration tips to improve the performance of a deduplication backup. The benefits of deduplication are dependent on the environment. Deduplication may be beneficial in a data warehouse environment where the data does not change frequently. It may also be beneficial for databases where only a small percentage of data is updated repeatedly, or new data is added to a database but the old data does not change much. Deduplication is not recommended for RMAN incremental backups. During an incremental backup, Oracle transmits only the data blocks that have changed, which guarantees a very low rate of duplication. When the overhead of deduplicating data is added to the overhead of an Oracle incremental backup, the result is decreased performance and insignificant benefits for the amount of data stored. During planning and configuration of a deduplication backup, keep in mind these best practices that can improve the backup performance: Do not create more than four backup channels for a deduplication backup. Do not use RMAN multiplexing for a deduplication backup. To disable multiplexing, ensure that filesperset is set to 1. If you use the wizard to configure the deduplication backup, ensure that the Filesperset field is set to 1 on the Specify the RMAN Options (Part 1 of 2) screen. Do not use RMAN binary compression (for example, ZLIB) with a deduplication backup. Do not include a deduplication client in the same group as non-deduplication clients. Once a deduplication node (Avamar server) is selected for an initial full backup of a client, continue to use the same deduplication node for all of the client's backups, to take advantage of the data already stored on the server. Configuring a deduplication backup 87

88 Software Configuration 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 NSR-DBM-ORA backup that runs during such a maintenance mode period may be suspended until the Avamar server resources become available. Ensure that the same cache is used to back up the same data every time by not changing the values of the parameters NSR_DEDUP_CACHE_ENABLED and NSR_DEDUP_CACHE_TAG. The following sources provide more details: NSR_DEDUP_CACHE_ENABLED on page 193 NSR_DEDUP_CACHE_TAG on page 193 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.fujitsu.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. Avamar and NetWorker documentation provides more information on Avamar server and NetWorker requirements for deduplication backups. Configure a deduplication backup To configure a scheduled deduplication backup, you can use either the configuration wizard or the legacy configuration method. Note: You must configure a manual deduplication backup with the legacy method only. However, you can generate the base RMAN script for a manual backup with the configuration wizard, described in Configuring a backup with the NMC wizard on page 68. To use the configuration wizard (for a scheduled backup only), follow the instructions in Configuring a backup with the NMC wizard on page 68. On the Specify the De-duplication Options screen, apply these additional settings: Select to enable deduplication. Specify the hostname of the deduplication node (Avamar server) that will store the deduplicated backup data. 88 NSR-DBM-ORA V5.0 Administrator s Guide

89 Software Configuration When you select to enable deduplication, the wizard automatically sets the parameter NSR_DEDUP_CACHE_TAG for each channel. Note: You cannot override the default NSR_DEDUP_CACHE_TAG setting. To use the legacy configuration method (without the wizard), follow the instructions in Configuring a backup with the NMC legacy method on page 70. Note: For a manual deduplication backup, the Client resource needs to include only the two attribute settings in step a on page 89. Apply these additional settings for a deduplication backup: a. Set the following attributes in the Client resource for the NSR-DBM-ORA client by using NMC: Select the De-duplication Backup attribute, to enable deduplication. For the De-duplication Node attribute, specify the hostname of the deduplication node (Avamar server) that will store the deduplicated backup data. Note: For a manual deduplication backup, the De-duplication Node attribute must have the same value as the NSR_DEDUP_NODE setting in the RMAN script. b. Set the following parameters in the RMAN backup script, if required: NSR_DEDUP_BACKUP on page 193 (for a manual backup only) NSR_DEDUP_CACHE_TAG on page 193 NSR_DEDUP_NODE on page 194 (for a manual backup only) Example 13 on page 89 shows a sample RMAN script for a manual deduplication backup. For a scheduled deduplication backup, if the Client resource contains the two attribute settings described in step a on page 89, the RMAN script must not include the parameters NSR_DEDUP_BACKUP and NSR_DEDUP_NODE. Example 13 RMAN script for a manual deduplication backup The following RMAN script shows the mandatory parameter settings for a manual deduplication backup. The NSR_DEDUP_CACHE_TAG parameter must be set to a different value for each allocated channel: run { allocate channel ch1 type 'SBT_TAPE'; allocate channel ch2 type 'SBT_TAPE '; send 'NSR_ENV=(NSR_SERVER=mars.fujitsu.com, NSR_CLIENT=oracle.fujitsu.com, NSR_DEDUP_BACKUP=TRUE, NSR_DEDUP_NODE=node3.fujitsu.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 89

90 Software Configuration Configuring a probe-based backup To configure a probe-based NSR-DBM-ORA backup: 1. Review the following sections: Probe-based backups on page 21 Requirements for a probe-based backup on page Follow the configuration steps in Configure a probe-based backup on page 90. 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 NSR-DBM-ORA Release Notice. If you want to use the nsrnmoprobe program provided with NSR-DBM-ORA to check for the number of Oracle logs generated since the last probe-based backup (as a condition that triggers a probe-based backup), ensure that you have reviewed the details on nsrnmoprobe in Configure a probe-based backup on page 90. If you want to check for a user-defined condition (other than the number of generated Oracle logs) that triggers a probe-based backup, a script/program is created that meets the requirements of the Probe Command attribute of the Probe resource, as described in Configure a probe-based backup on page 90. For example, the user-defined condition that triggers a probe-based backup is that more than two tape drives are idle in a jukebox. To check for this condition, a script named nsrjukeboxprobe is created in the /opt/nsr directory on Solaris. When the script runs and checks the number of idle tape drives in the jukebox, it returns one of the following values: 0 Signifies that more than two tape drives are idle in the jukebox. 1 Signifies that two or fewer tape drives are idle in the jukebox. Other than 0 or 1 Signifies that an error occurred during the probe. The NetWorker Administrator s Guide provides more information on user-defined probes in the section on creating a client probe. Configure a probe-based backup To configure a probe-based NSR-DBM-ORA backup: 1. Create a separate NetWorker Probe resource for the nsrnmoprobe program and any other script/program that checks for a user-defined condition. Set the Probe resource attributes as described in Table 6 on page NSR-DBM-ORA V5.0 Administrator s Guide

91 Software Configuration Table 6 NetWorker Probe resource attributes Attribute Name Probe Command Command Options Description Name of the Probe resource for the probe script/program used to check for a probe-based backup condition. Each Probe resource must have a unique name, which does not have to be the same as the probe script/program name. Name and path of the probe script/program that checks ( probes ) for the condition that triggers a probe-based backup. The script/program meets the following requirements: Name starts with nsr or save. Location is the same directory as used for the NetWorker client binaries. Permissions of the script/program file include the execute permission. Returns one of the following code values when it finishes running its probe: - 0 Signifies that the backup condition has been met. - 1 Signifies that the backup condition has not been met. - Other than 0 or 1 - Signifies that an error occurred during the probe. To use the probe program that is included with the NSR-DBM-ORA software, set this attribute to nsrnmoprobe. The nsrnmoprobe program checks for the number of Oracle logs generated since the last probe-based backup and triggers a new probe-based backup when the number exceeds the change threshold. Required for the nsrnmoprobe program only, a comma-separated list of the settings of one or more of the following parameters. Example 14 on page 92 outlines the parameter settings that nsrnmoprobe requires in each possible scenario. Parameter LOG_THRESHOLD NSR_DEBUG_FILE NSR_ORACLE_CONNECT_FILE ORACLE_HOME ORACLE_SERVICE Description Mandatory. Specifies the change threshold, which is the minimum number of redo logs (generated since the last probe-based backup) required to trigger a new probe-based backup. When the number of logs generated since the last probe-based backup equals or exceeds the change threshold, nsrnmoprobe triggers a probe-based backup. Optional. Specifies the pathname of the log file that receives debug information from the probe-based backup triggered by nsrnmoprobe. Set only if both of the following are true: The Client resource is not configured with the wizard; it is configured through the legacy method with NMC. The NWORA resource file is not set up with the Oracle home and database connection information. Specifies the pathname of the RMAN connection file, which contains the connection strings required to connect to the Oracle database that is to be probed. Example 14 on page 92 provides a sample setting of this parameter. Set only if both of the following are true: The Client resource is not configured with the wizard; it is configured through the legacy method with NMC. The NWORA resource file is not set up with the Oracle home and database connection information. Specifies the home directory pathname for the Oracle database that is to be probed. Example 14 on page 92 provides a sample setting of this parameter. Set only if both of the following are true: The Client resource is not configured with the wizard; it is configured through the legacy method with NMC. The NWORA resource file is set up with the Oracle home and database connection information through the command nsrnmoadmin r add sid=net_service_name home=oracle_home connect=connect_filepath. Specifies the Net service name for the Oracle database that is to be probed. In this case, the ORACLE_SERVICE setting must be the same as the NSR_ORACLE_SID setting in the NWORA resource file. Example 14 on page 92 provides a sample setting of this parameter. Configuring a probe-based backup 91

92 Software Configuration Note: The State attribute of the Probe resource is visible only in diagnostic mode. At the end of each successful probe-based backup, the nsrnmoprobe program stores the current log sequence number and database instance number in the State attribute. The State attribute is not used with user-defined probes. 2. Configure the NetWorker Group resource for a probe-enabled backup group. Set the probe-specific attributes in the Group resource, as described in the NetWorker Administrator s Guide (the section on creating and scheduling a probe group). The Group resource has been extended to include several new attributes that must be set for a probe-based backup group. When probing is enabled through the Group resource attributes, probing occurs continuously throughout the backup window, which is the time window defined by the Probe Start Time and Probe End Time attributes. Note: If a probe-enabled backup group is started manually, probing occurs immediately (only once, not repeatedly at intervals) and the backup starts only if the probe conditions are met. 3. Configure the NetWorker Client resource for the NSR-DBM-ORA client according to the instructions in the appropriate section: Configuring a backup with the NMC wizard on page 68 Configure a Client resource with NMC on page 81 In the Client resource: For the Probe attribute, specify the name of the required Probe resource from step 1. This attribute associates the Client resource with the probe script/program specified in the Probe resource. Note: A Client resource can be associated with only one probe. The configuration wizard does not display the Probe field. If you configure a Client resource with the wizard, you must then use NMC manually to edit the Client resource and set the Probe attribute. For the Group attribute, specify the probe-enabled group from step 2. Note: A probe-based backup group must include at least one probe-enabled client. Example 15 on page 93 describes the configuration of a probe-based backup that is triggered by both nsrnmoprobe and a user-defined probe. Example 14 Possible Command Options settings for the nsrnmoprobe program To use the nsrnmoprobe program that is provided with the NSR-DBM-ORA software, the Probe resource must be set up properly, as described in Configure a probe-based backup on page NSR-DBM-ORA V5.0 Administrator s Guide

93 Software Configuration The Command Options attribute in the Probe resource must include specific parameter settings, which depend on the particular scenario: The LOG_THRESHOLD parameter is always mandatory. The NSR_DEBUG_FILE parameter is optional. Three possible scenarios dictate the required settings in the Command Options attribute: a. The Client resource has been configured through the legacy method with NMC (not with the wizard), and the NWORA resource file has not been set up with the Oracle home and database connection information. In this case, Command Options must include the parameters LOG_THRESHOLD, NSR_ORACLE_CONNECT_FILE, and ORACLE_HOME. (NSR_DEBUG_FILE is optional.) For example, Command Options is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log, NSR_ORACLE_CONNECT_FILE=/RMAN/rmanpw, ORACLE_HOME=/oracle/hp_11_31_ia/64bit/product/ b. The Client resource has been configured with the wizard, and the NWORA resource file has not been set up with the Oracle home and database connection information. In this case, Command Options must include the LOG_THRESHOLD parameter. (NSR_DEBUG_FILE is optional.) For example, Command Options is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log c. The Client resource has been configured through the legacy method with NMC (without the wizard), and the NWORA resource file is set up to retrieve Oracle home and database connection information. In this case, the NWORA resource file must be set up through the command nsrnmoadmin r add sid=net_service_name home=oracle_home connect=connect_filepath. Command Options must include the parameters LOG_THRESHOLD and ORACLE_SERVICE, where ORACLE_SERVICE is set to the same Net service name as NSR_ORACLE_SID in the NWORA file. (NSR_DEBUG_FILE is optional.) Configuring the NWORA resource file with the nsrnmoadmin program on page 180 provides important details on the nsrnmoadmin command. For example, Command Options is set as follows: LOG_THRESHOLD=10, NSR_DEBUG_FILE=/tmp/probe.log, ORACLE_SERVICE=proddb.world Example 15 Multiple probes for a probe-based backup A probe-based backup is triggered when both of the following are true: At least 25 Oracle log files are generated on an NSR-DBM-ORA 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 NSR-DBM-ORA client and storage node are Solaris machines. Configuring a probe-based backup 93

94 Software Configuration The nsrnmoprobe program is installed with the NSR-DBM-ORA software in /opt/nsr on the NSR-DBM-ORA client. The nsrnmoprobe program checks for the number of Oracle log files generated on the NSR-DBM-ORA client. A script named nsrjukeboxprobe is created with execute permissions and stored in the /opt/nsr directory on the storage node. The script checks for the number of idle tape drives in the jukebox, and returns either of two values: 0 Signifies that more than two tape drives are idle in the jukebox. 1 Signifies that two or fewer tape drives are idle in the jukebox. To configure the probe-based backup, the following steps are performed: 1. A Probe resource is created for the nsrnmoprobe program with the following attribute settings: Name NSR-DBM-ORA probe Probe Command nsrnmoprobe Command Options LOG_THRESHOLD=25, NSR_DEBUG_FILE=/tmp/probe.log 2. A Probe resource is created for the user-defined probe with the following attribute settings: Name Jukebox probe Probe Command nsrjukeboxprobe 3. A Group resource is created with the required attribute settings for the probe-enabled backup group, including the following: Name probe_group Probe Based Backup Enabled (this is a checkbox in NMC) Probe Success Criteria All 4. A Client resource is created for the NSR-DBM-ORA client through the configuration wizard. The Client resource includes the following attribute settings: Name mars Backup Command nsrnmostart -C Group probe_group Probe NSR-DBM-ORA probe Save Set RMAN:/orcl102_FULL 5. A Schedule resource is created with the following attribute settings: Name SkipAll Period Either Week or Month Calendar Skip level is selected for every day in the period 6. A dummy Client resource is created for the storage node through the legacy method (without the wizard). The Client resource includes the following attribute settings: Name marmaris Backup Command (blank) Group probe_group 94 NSR-DBM-ORA V5.0 Administrator s Guide

95 Software Configuration Probe Jukebox probe Save Set SKIP (a keyword is required in this attribute) Schedule SkipAll Note: The Skip level in the SkipAll schedule causes the backup to be skipped on the storage node. The probe runs on the storage node as specified through the Group resource; the probe is not affected by the Schedule resource. Configuring a probe-based backup 95

96 Software Configuration 96 NSR-DBM-ORA V5.0 Administrator s Guide

97 3 Backup Procedures This chapter includes the following major sections: Manual backup procedures Scheduled backup procedures Regular backup information in NetWorker indexes Deduplication backup information in NetWorker indexes Backup Procedures 97

98 Backup Procedures Manual backup procedures To perform a manual NSR-DBM-ORA backup of Oracle data: 1. Review information in Product features on page 19 about the features that apply to your particular backup. 2. Review Requirements for a manual backup on page Review the information on how to cancel a manual backup in Cancel a manual backup on page Perform the manual backup by either of the following methods: Use the RMAN command line interface, according to Manual backup through the RMAN command line interface on page 99. Use the Oracle Enterprise Manager Backup Management Tools, according to Manual backup through Oracle Enterprise Manager Backup Management Tools on page 99.! IMPORTANT The NetWorker server bootstrap and client indexes are not automatically backed up at the end of a manual Oracle backup, as they are for a scheduled Oracle backup. After running a manual Oracle backup, perform a NetWorker server bootstrap backup according to NetWorker server bootstrap backup on page 100. Regular NetWorker server bootstrap backups help to ensure adequate preparation for disaster recovery. Monitor a manual backup on page 101 provides information on how to monitor the status of a manual NSR-DBM-ORA backup. Scheduled backup procedures on page 104 provides information on scheduled NSR-DBM-ORA backups. Requirements for a manual backup Before starting a manual backup, ensure that the required configurations and scripts are in place: The Oracle system is properly configured, as described in Chapter 2, Software Configuration. The Oracle Server has the Net service configured. If a Recovery Catalog is to be used, the Recovery Catalog is set up and the target database registered. The NetWorker server has the required resources configured, as described in Chapter 2, Software Configuration : Server Client Device Pool If using an RMAN script for the manual backup, the script is created, as described in Create RMAN scripts for backups on page NSR-DBM-ORA V5.0 Administrator s Guide

99 Backup Procedures The required backup devices and volumes are set up: A volume is labeled (and mounted, as required) in each configured backup device. If auto media management is enabled for a tape device or autochanger, a tape is loaded in the tape device or autochanger for the NetWorker server to use automatically. Manual backup through the RMAN command line interface A manual Oracle backup can be started by using the RMAN command line interface on the Oracle Server host. If the RMAN script for a manual backup from Example 10 on page 71 is stored in the file /disk1/scripts/full_backup.txt on a UNIX Oracle Server, and the Net service has been configured to connect to the databases payroll and rcvcatdb, then the manual Oracle backup can be started with the following command: rman target internal/oracle@payroll rcvcat rman/rman@rcvcatdb cmdfile \ /disk1/scripts/full_backup.txt\! IMPORTANT The NetWorker server bootstrap and client indexes are not automatically backed up at the end of a manual Oracle backup, as they are for a scheduled Oracle backup. After running a manual Oracle backup, perform a NetWorker server bootstrap backup according to NetWorker server bootstrap backup on page 100. Regular NetWorker server bootstrap backups help to ensure adequate preparation for disaster recovery. Cancel a manual backup on page 101 provides information on how to cancel a manual NSR-DBM-ORA backup. Manual backup through Oracle Enterprise Manager Backup Management Tools The Oracle Enterprise Manager Backup Management Tools can be used instead of the RMAN command line interface to start an Oracle database backup. The Oracle Enterprise Manager Backup Management Tools include a graphical user interface to RMAN for generating the required RMAN commands and performing backup and restore operations.! IMPORTANT After the completion of an NSR-DBM-ORA backup or restore, the Oracle Enterprise Manager job queue history displays the status of the job as failed, even if the backup or restore completed successfully. This is due to a known problem with Oracle Enterprise Manager. View the job output to confirm that the backup or restore completed successfully. The Oracle Enterprise Manager documentation included with the product kit provides more information on using the Oracle Enterprise Manager Backup Management Tools. Manual backup procedures 99

100 Backup Procedures NetWorker server bootstrap backup The bootstrap is a special save set that the NetWorker server software creates in preparation for disaster recovery. The bootstrap save set contains the information needed to restore the online NetWorker indexes and resource configuration files to the state just before the bootstrap was created. The NetWorker server automatically performs a backup of its bootstrap and the client index of the Oracle Server only at the end of a scheduled Oracle backup. This is done by the NetWorker savegrp program that performs the scheduled backup. Note: If only manual (unscheduled) Oracle backups are run, and the client index and bootstrap are not backed up manually, then no backups of the online client index and NetWorker server bootstrap will be available for use in the event of a disaster recovery on the NetWorker server. After finishing a manual Oracle backup, the bootstrap and client index must also be backed up. Back up the bootstrap and index To back up the NetWorker server bootstrap and index: 1. On a UNIX NetWorker server, log in as the root user. 2. Type the following savegrp command: savegrp -O -l full -P printer_name -c Oracle_Server_name -c NetWorker_server_name where: printer_name is the name of the printer where the bootstrap information is printed at the end of the bootstrap backup. Oracle_Server_name is the hostname of the Oracle Server. NetWorker_server_name is the hostname of the NetWorker server. After successfully backing up the bootstrap and the client index by using the savegrp command: Confirmation of the savegrp completion appears in the NetWorker Administrator program. Information is sent to the printer_name printer about the saved bootstrap. Note: Store the bootstrap printout in a safe place. The printed bootstrap information includes dates, locations, and save set ID numbers for the bootstrap save sets backed up during the past month. With this information, determine which volumes are needed to recover the NetWorker indexes and resource configuration files during a disaster recovery. The following sources provide information on the savegrp command and options: NetWorker Administrator s Guide for the particular NetWorker server platform savegrp entry in the NetWorker Command Reference Guide savegrp man page on UNIX The NetWorker Administrator s Guide provides information on bootstrap backups. The NetWorker Disaster Recovery Guide provides information on how to use the bootstrap backup during a disaster recovery. 100 NSR-DBM-ORA V5.0 Administrator s Guide

101 Backup Procedures Cancel a 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 a manual Oracle backup. Specify the required NetWorker privileges on page 60 provides more information. The following sections describe how to cancel a running or nonresponding manual backup. Cancel a running manual backup To cancel a running manual Oracle backup (not including a backup initiated by Oracle Enterprise Manager) during the RMAN script execution on any platform, press either Ctrl+C, or the equivalent attention key combination on the system. Note: If this method of canceling a manual Oracle backup is not successful, use the alter system kill command described in Cancel a scheduled backup on page 105. Cancel a nonresponding manual backup The following are the steps for canceling a nonresponding Oracle backup. However, if these steps do not work, contact Oracle for assistance. Note: When using these steps, NSR-DBM-ORA does not attempt to remove the backup save set entries from the NetWorker index. As a result, the NetWorker index and RMAN catalog might become unsynchronized. To cancel a nonresponding Oracle backup on UNIX: 1. Include the set command id to xxx command in the RMAN backup script that is used for the Oracle backup. Otherwise, the query in the next step will fail. Example 12 on page 73 provides a sample script with the command. 2. Run the following query in the Oracle svrmgrl or sqlplus program to determine the Oracle process ID that corresponds to each RMAN channel: select spid, client_info from v$process p, v$session s where p.addr=s.paddr and client_info like %id=% ; 3. Type the following kill command to cancel the Oracle backup process: kill -9 pid where pid is the appropriate Oracle process ID. Monitor a manual backup To monitor the status of Oracle backup and restore operations, use the NMC interface program. The NetWorker server program displays progress and completion messages that advise when a backup or restore is complete, and information on why a backup or restore cannot proceed. The NetWorker Administrator s Guide provides more information on viewing these types of messages with the NetWorker program. Appendix C, Troubleshooting and Error Messages, provides information on how to obtain RMAN-specific and NSR-DBM-ORA diagnostic and error messages. The following figures show the types of Oracle backup messages displayed in the Monitoring Window of the NMC interface: Manual backup procedures 101

102 Backup Procedures Figure 7 on page 102 shows messages displayed in the Sessions tab. Figure 8 on page 103 shows messages displayed in the Devices tab. Figure 9 on page 103 show messages displayed in the Log tab. The NetWorker Administrator s Guide and NMC online help provide more information. Figure 7 Oracle backup messages in Sessions tab of Monitoring window 102 NSR-DBM-ORA V5.0 Administrator s Guide

103 Backup Procedures Figure 8 Oracle backup messages in Devices tab of Monitoring window Figure 9 Oracle backup messages in Log tab of Monitoring window Manual backup procedures 103

104 Backup Procedures Scheduled backup procedures To prepare for a scheduled NSR-DBM-ORA backup of Oracle data: 1. Review information in Product features on page 19 about the features that apply to your particular backup. 2. Ensure that the required backup configurations are in place, as described in Configuration roadmap on page Run a test scheduled Oracle backup according to Test a scheduled backup on page Review the steps for canceling a scheduled backup in Cancel a scheduled backup on page 105. At the end of a successful scheduled backup, NSR-DBM-ORA automatically backs up the NWORA resource file if it exists, as described in NWORA resource file backup on page 167. Monitor a scheduled backup on page 106 provides information on how to track the status of scheduled backups. The following sections describe the backup information stored in the NetWorker indexes: Regular backup information in NetWorker indexes on page 108 Deduplication backup information in NetWorker indexes on page 109 Test a scheduled backup After the NSR-DBM-ORA environment for scheduled backups on the Oracle Server is set up, test a scheduled backup manually by using the NMC program. Before starting the backup, check for the following: All the required parameters have been set, either through the wizard or through the legacy method in the nsrnmo and RMAN scripts. For a legacy configuration, any required preprocessing and postprocessing scripts (optional) are in place. The NetWorker server and Oracle Server have been correctly configured. Test a scheduled backup as follows: 1. Start the NMC program as the root user on UNIX. 2. Select the appropriate NetWorker server to perform the backup. 3. Select the correct group name for the backup. 4. Start the scheduled backup for the specified group. The NetWorker software immediately backs up the clients in the backup group. The NetWorker Administrator s Guide and NMC online help provide information on how to use the NMC interface to perform these steps. A savegroup completion report in provides the scheduled backup results. Note: Cancel a scheduled backup on page 105 provides information on how to cancel the scheduled Oracle backup. 104 NSR-DBM-ORA V5.0 Administrator s Guide

105 Backup Procedures Scheduled backup error messages If the scheduled backup fails, an error message is produced. The NetWorker Administrator s Guide provides information on how to obtain more details about the scheduled backup by using the NetWorker administration program. For additional debug information, set the NSR_SB_DEBUG_FILE parameter through one of the following methods: Use the configuration wizard to set the parameter in the Advanced Environment Options field on the Specify the Environment Options (Optional) screen. Use the legacy configuration method to set the parameter in the nsrnmo script. NSR_SB_DEBUG_FILE on page 77 provides details on the parameter. If the scheduling portion of a scheduled NSR-DBM-ORA backup succeeds but the actual backup fails, error messages and debug information might be generated in the locations described in RMAN error messages on page 211. Cancel a 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 a scheduled Oracle backup. Specify the required NetWorker privileges on page 60 provides more information. NSR-DBM-ORA currently supports use of the Stop button in the NetWorker Administrator program to cancel a running scheduled Oracle backup only if the NetWorker server and Oracle Server are both running on UNIX platforms. The level of Stop button support depends on the NetWorker server operating system (where the Oracle Server operating system is already assumed to be UNIX). If the NetWorker server system is UNIX, then the Stop button is supported. Note: Although the progress message might indicate that the backup has exited prematurely (before finishing), the NSR-DBM-ORA processes might still be running on the Oracle Server host. To cancel a running scheduled Oracle backup when the Stop button does not work, the running rman process must be interrupted on the Oracle Server host: 1. In the NetWorker Administrator program, click the Stop button to prevent NSR-DBM-ORA from retrying the backup. 2. For each allocated channel, perform the following: a. View the RMAN message log file to determine the Oracle session ID for the channel. (The log filename is specified in the NSR_RMAN_ARGUMENTS parameter, set either through the Advanced Environment Options field in the wizard or through the nsrnmo script in a legacy configuration.) 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; Scheduled backup procedures 105

106 Backup Procedures where session_id is the Oracle session ID from the RMAN message log in step a. c. Run the following alter system command in the Oracle svrmgrl or sqlplus program to terminate the channel: alter system kill session session_id, serial# ; where: session_id is the Oracle session ID from step a. serial# is the serial number from step b. Cancel a nonresponding manual backup on page 101 describes how to also cancel a nonresponding scheduled backup. Monitor a scheduled backup Scheduled Oracle backups can be monitored the same way as manual Oracle backups. Monitor a manual backup on page 101 provides more information. In addition, messages appear in the appropriate Group window in the NetWorker server program and a report is generated upon completion of a scheduled Oracle backup. Information about scheduled NSR-DBM-ORA backups is displayed on the Groups and Sessions tabs of the Monitoring window in the NMC interface program: During the backup, the Sessions tab lists one save session for each channel used by NSR-DBM-ORA for the backup. The display shows the rate of data being backed up and total size of the backed-up data. After the backup, the Groups tab enables you to select the backup group and display details about the group, including the Completed successfully box that contains one entry for each channel used by NSR-DBM-ORA for the backup. Figure 10 on page 107 shows the type of group details displayed, including the size of each save set. Note: For a deduplication backup, the NMC display shows the total size of the data prior to deduplication, not the size of the deduplicated data. The display also does not indicate that the data is for a deduplication backup that is stored on the Avamar server. The NetWorker Administrator s Guide provides details on viewing information about scheduled backups in the NMC program. 106 NSR-DBM-ORA V5.0 Administrator s Guide

107 Backup Procedures Figure 10 Group details for regular scheduled backups Automation of NSR_SERVER and NSR_GROUP parameter settings Note: The information in this section is applicable to a legacy configuration only, not to a configuration set up through the NSR-DBM-ORA 5.0 wizard. The parameters NSR_SERVER and NSR_GROUP must not be set in a scheduled backup RMAN script. NSR-DBM-ORA automatically passes server and group information (received from the NetWorker server that started the backup) to Oracle Server processes, created for each allocated channel. NSR-DBM-ORA also passes an internal parameter, NSR_SAVESET_NAME, to set the save set name.! IMPORTANT Do not set the parameter NSR_SAVESET_NAME. To pass the information to the Oracle Server processes, NSR-DBM-ORA invokes the RMAN executable with send as a command line option. The send command on page 201 provides more information. Scheduled backup procedures 107

108 Backup Procedures Regular backup information in NetWorker indexes The NetWorker server maintains information about each backup in its online indexes. Chapter 1, Introduction, provides more information about the online indexes. This section describes the information maintained in the NetWorker indexes for regular manual and scheduled backups. Deduplication backup information in NetWorker indexes on page 109 describes information about deduplication backups. The NetWorker client file index contains the filename backup_piece_name for the save set name for either a manual or scheduled NSR-DBM-ORA backup. The NetWorker media database contains the following information, depending on the type of backup and the NetWorker server version used to perform the backup: For a manual backup, the name RMAN:backup_piece_name for the save set name. For a scheduled backup with a NetWorker server release prior to 7.3.2, the value from the Save Set field of the Client resource for the save set name. For a scheduled backup with NetWorker server release or later, the name RMAN:backup_piece_name for the save set name. Query the online NetWorker indexes by using the NetWorker commands, nsrinfo and mminfo. To query the client file index, use the nsrinfo command. For example: nsrinfo -n oracle -s NetWorker_server_hostname Oracle_Server_hostname To query the media database, use the mminfo command. For example: mminfo -v -s NetWorker_server_hostname -c Oracle_Server_hostname The NetWorker Command Reference Guide and the UNIX man pages provide more information on these NetWorker commands. The following examples show the command output for a manual or scheduled NSR-DBM-ORA backup, where the backup piece is named 1hiu83f4_1_1 and the scheduled backup is performed with NetWorker server release or later: The client file index includes the backup piece name for the save set: nsrinfo -n oracle -s ca-oracle1 ca-oracle1 1hiu83f4_1_1, date= Thu Dec 11 16:05: The media database includes the prefix RMAN: with the backup piece name for the save set: mminfo -v -s ca-oracle1 -c ca-oracle1 volume client date time size NMO.001 ca-oracle1 12/11/08 16:05: MB ssid fl level name cb full RMAN:1hiu83f4_1_1 Note: The media database also includes information about the bootstrap, index, and NWORA resource file backups that occur as part of each scheduled backup. The preceding mminfo command sample does not show the bootstrap, index, and NWORA resource file information for the scheduled backup. 108 NSR-DBM-ORA V5.0 Administrator s Guide

109 Backup Procedures Cross-check the client file index and media database by using the save time. For example: mminfo -c ca-oracle1 -t nsrinfo -n oracle -t 12/11/08 16:05:59 ca-oracle1 Deduplication backup information in NetWorker indexes The deduplication backup information maintained in the NetWorker indexes is for the NetWorker save set stored on the NetWorker storage node, which contains only a single file with the hash ID and NetWorker metadata for the backup. Note: The backup size recorded in the NetWorker indexes does not match the amount of data backed up during the deduplication backup. The following examples show the index query results from the nsrinfo and mminfo commands, where the backup piece is named 35ji3i75_1_1: As for a regular backup, the client file index includes the backup piece name for the save set of the deduplication backup: nsrinfo -n oracle -vv molecule UNIX file '35ji3i75_1_1', size=212, off=0, app=oracle(25), date= Wed Jun 04 16:12: , (unknown fid), file size=0 In this case, the size of the backup piece is the size of the Avamar hash ID (20 bytes) plus the size of the NetWorker metadata that contains the backup piece name. To query the media database, use the mminfo command with the -q dedupe option (displays only save sets created through deduplication) and the -S option (lists the extended options for the deduplication backups): mminfo -S -q dedupe ssid= savetime=06/04/08 16:12:22 ( ) RMAN:35ji3i75_1_1 level=full sflags=vf size=216 files=1 insert=06/04/08 create=06/04/08 complete=06/04/08 browse=07/04/08 23:59:59 retent=06/04/09 23:59:59 clientid=08b98b ae ae45-000c de6f33 *Client path: /NetWorker/server_name/client_name; *Data set size: ; *De-Dup session id: 27; *De-Dup snapup time: ; *De-duplication: Yes; *De-duplication host: scip2d088.lss.fujitsu.com ; *Domain: /NetWorker/server_name; *New data on De-Dup Node: ; *New files: 1; *Replication host: scip2d089.legato.com; *Size on De-Dup Node: ; group: Default; Clone #1: cloneid= time=06/04/08 16:12:23 retent=06/04/09 flags=f frag@ 0 volid= file/rec= /0 rn=0 last=06/04/08 The save file size reported by mminfo is the same as that reported by nsrinfo, except for an extra four bytes due to a NetWorker end-of-save-set marker. When a deduplication backup is deleted (for example, by a user or the NetWorker server), the backup information is deleted immediately from the NetWorker indexes, and a request is queued for deletion of the backup from the Avamar server. The Deduplication backup information in NetWorker indexes 109

110 Backup Procedures 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. 110 NSR-DBM-ORA V5.0 Administrator s Guide

111 4 Data Restore and Recovery This chapter includes the following sections: About restore and recovery RMAN scripts for restore and recovery Performing an Oracle data restore and recovery Data Restore and Recovery 111

112 Data Restore and Recovery About restore and recovery Only Oracle data that has been backed up according to the instructions in Chapter 3, Backup Procedures, can be restored. Note: The NetWorker server interface cannot be used to restore Oracle data that was backed up with NSR-DBM-ORA. Review the following sections in preparation for the Oracle data restore and recovery procedures: NetWorker indexes and policies used for restores on page 112 Recovery configuration wizard on page 112 RMAN scripts for restore and recovery on page 115 NetWorker indexes and policies used for restores During an Oracle backup, the NetWorker server adds an entry for each backup piece in the online client file index and records the location of the data in the media database. These entries provide information required to restore every Oracle data object backed up: The client file index entry is maintained until the browse policy specified for the client s save set expires. The media database entry is maintained until the retention policy specified for the client s save set expires. When the retention policies for all the save sets on a backup volume expire, the volume becomes recyclable and eligible for automatic relabeling by the NetWorker server. The save set entries, however, remain in the media database until the volume is actually relabeled. When the volume is relabeled, the data on it becomes inaccessible and can no longer be restored. NSR-DBM-ORA uses the client file index entries to restore Oracle backup pieces. Set the browse policy to a period long enough to retain the client index entries for restoring the Oracle backup pieces. Note: After a browse policy expires, the NetWorker scanner program can be used to rebuild the online indexes. However, index entries regenerated by using scanner might cause the NetWorker indexes to become unsynchronized with the RMAN catalog and lead to problems. To avoid problems, ensure that the backup pieces have unique names, as described in RMAN scripts for manual backups on page 71. The NetWorker Administrator s Guide provides more information on how the NetWorker server uses browse and retention policies to manage Oracle backup data and track the location and status of the data on backup volumes. Recovery configuration wizard NSR-DBM-ORA 5.0 software supports a new recovery configuration wizard that is integrated with the NetWorker Management Console (NMC). The recovery configuration wizard used in NSR-DBM-ORA release 4.5 or earlier is replaced by the NMC-based wizard in NSR-DBM-ORA release NSR-DBM-ORA V5.0 Administrator s Guide

113 Data Restore and Recovery You can run the recovery configuration wizard from the NetWorker Console Administration window, which you can start on any supported host by using a web browser session and specifying the Console server URL. The NSR-DBM-ORA Release Notice provides details on the NetWorker requirements for the support of the NMC-based configuration wizards. To configure a restore with the wizard: 1. Review the information in Features of the recovery configuration wizard on page Ensure that you meet the Requirements for using the recovery configuration wizard on page Follow the steps in Configure a restore with the wizard on page 114. Features of the recovery configuration wizard The recovery configuration wizard can create an RMAN script for the following types of restore and recovery: Current time restore and recovery of a whole or partial Oracle database, where a partial database is a set of tablespaces or datafiles. The wizard can configure a tablespace restore as long as the control file contains information about the tablespace. Point-in-time restore and recovery of a whole Oracle database. Restore of individual archived redo logs. Restore and recovery of Oracle data to a different database through the creation of a duplicate database on either the local host or a remote host, using backups of the original target database. The database duplication script created by the wizard uses the RMAN duplicate command to create a duplicate database while the original database is retained. The duplicate database can either be an identical copy of the original database or contain only a subset of the original tablespaces. For example, the duplicate database can be created to run independently on a remote host, for the purpose of practicing restore and recovery operations while the production database remains in operation on the local host: If the duplicate database is to be created on the same host as the original database, the RMAN script is also generated on the local host. In this case, the wizard requests names for the duplicate database, datafiles, and redo logs that differ from those of the original database. If the duplicate database is to be created on a remote host, the RMAN script is generated on either the local or remote host, as specified in the wizard. In this case, the wizard requests a name for the duplicate database that differs from that of the original database. (The datafile and redo log names can be the same as for the original database.) The recovery configuration wizard can only create a new RMAN script for restore and recovery. The wizard cannot modify an existing RMAN script. You must use a text editor to modify an RMAN script that was created by the wizard. RMAN scripts for restore and recovery on page 115 provides more information about RMAN scripts for restore and recovery. About restore and recovery 113

114 Data 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: NSR-DBM-ORA Release Notice Descriptive inline text in the wizard Online help in the wizard Requirements for using the recovery configuration wizard Before you use the recovery configuration wizard, ensure that all of the following 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 NSR-DBM-ORA client configuration is stored. Communication between the NMC server, NetWorker server, and NSR-DBM-ORA client uses nsrauth authentication. The NetWorker documentation provides any requirements for nsrauth authentication. The required NetWorker releases are installed on the NMC server, NetWorker server, and NSR-DBM-ORA client hosts, as described in the NSR-DBM-ORA Release Notice. The NetWorker Client resource for the NSR-DBM-ORA client was created through one of the following: Backup configuration wizard in NSR-DBM-ORA 5.0 Migration of a legacy configuration with the nsrnmoadmin command Legacy configuration method (without the wizard), where the value of the Save Set attribute of the Client resource has the RMAN: prefix Prior to creation of a database duplication script, the AUXILIARY instance exists on the local or remote host, and is accessible through Oracle Net. The Oracle Database Backup and Recovery Advanced User s Guide provides details on how to create an AUXILIARY instance. Configure a restore with the wizard To create an RMAN restore script with the recovery configuration wizard: 1. Start the NetWorker Management Console software. 2. Open the Administration window: a. In the Console window, click Enterprise. b. In the left pane, select a NetWorker server in the Enterprise list. c. In the right pane, select the application. d. From the Enterprise menu, click Launch Application. The Administration window is launched as a separate application. 3. In the Administration window, click Configuration. 4. In the Configuration window, click Clients. 114 NSR-DBM-ORA V5.0 Administrator s Guide

115 Data Restore and Recovery 5. To start the wizard, right-click the NSR-DBM-ORA 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. Note: The RMAN script created by the recovery wizard does not contain any connection strings to connect to the target database or to the recovery catalog. Before you can use this script to restore a database you must update the connect strings.! IMPORTANT When you create an RMAN restore script with the wizard and select the offline or online mode option for tablespaces, you might need to manually edit the script and insert an "alter database open;" command before the sql...tablespace... commands, if it will be required for your particular database (if the database will not be open at the point where the sql commands are to be run). RMAN scripts for restore and recovery An appropriate RMAN script is required to perform the preferred type of Oracle restore operation on the Oracle Server host. You can create the RMAN script either manually or by using the recovery configuration wizard. Recovery configuration wizard on page 112 provides details on the recovery configuration wizard. RMAN restore scripts can be stored as text files. Alternatively, if a Recovery Catalog is used, restore scripts can be stored in the Recovery Catalog database. The Oracle backup and recovery documentation provides more information on storing the restore scripts in the Recovery Catalog database. The NSR* parameters in the script must be set by the methods described in Setting the NSR* parameters on page 190. The use of the send command is recommended where possible. The send command on page 201 provides more information. Example 16 RMAN script to restore a tablespace The following RMAN script performs a restore of an Oracle tablespace by using the (remote) NetWorker server mars.fujitsu.com. The Oracle data is restored to the NetWorker client server1.fujitsu.com. This RMAN script also includes the recovery step, which is explained in Perform an Oracle data recovery on page 121: run { allocate channel t1 type SBT_TAPE ; allocate channel t2 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=mars.fujitsu.com, NSR_CLIENT=server1.fujitsu.com ) ; sql alter tablespace users offline immediate ; restore tablespace users; recover tablespace users; sql alter tablespace users online ; release channel t1; RMAN scripts for restore and recovery 115

116 Data Restore and Recovery } release channel t2; Create RMAN scripts for backups on page 70 provides more information on setting NSR* parameters in an RMAN script. Example 17 RMAN script to restore an AES encrypted backup By default, if the NSR_ENCRYPTION_PHRASES parameter is not set, NSR-DBM-ORA obtains the encryption phrase from the NetWorker server for decrypting an AES encrypted backup during an Oracle restore. The NSR_ENCRYPTION_PHRASES parameter must be set if both of the following are true: The Oracle data being restored was backed up with 256-bit AES encryption. Example 11 on page 72 shows a sample Oracle backup with AES encryption. The encryption phrase on the NetWorker server has changed since the Oracle data was backed up. If both of these conditions are true, ensure that the NSR_ENCRYPTION_PHRASES parameter is set through the send command in the RMAN restore script. NSR_ENCRYPTION_PHRASES on page 194 provides more information. The following RMAN script performs a nonproxy Oracle restore of the database by using the encryption phrase, original_encryption_phrase, that was originally used to back up the database. The encryption phrase must be in double quotes: run { allocate channel t1 type SBT_TAPE ; send NSR_ENV=(NSR_SERVER=mars.fujitsu.com, NSR_CLIENT=server1.fujitsu.com, NSR_ENCRYPTION_PHRASES="original_encryption_phrase") ; restore database; release channel t1; } Example 18 RMAN script to restore from a specified pool By default, NSR-DBM-ORA and NetWorker use configuration settings and information in the media database to determine the backup volume to use for an NSR-DBM-ORA 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 196 provides more information. 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; } 116 NSR-DBM-ORA V5.0 Administrator s Guide

117 Data Restore and Recovery Performing an Oracle data restore and recovery To perform a restore and recovery of Oracle data: 1. Review Requirements for an Oracle data restore on page Perform the Oracle data restore by either of the following methods: Use the RMAN command line interface, according to Restore through the RMAN command line interface on page 119. Use the Oracle Enterprise Manager Backup Management Tools, according to Restore with Oracle Enterprise Manager Backup Management Tools on page 120. Note: Use of the Oracle Enterprise Manager Backup Management Tools is not supported with the recovery configuration wizard. 3. Complete the Oracle data recovery, if required, according to Perform an Oracle data recovery on page 121. Requirements for an 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, as described in Chapter 2, Software Configuration. The NetWorker server has the required resources configured, as described in Chapter 2, Software Configuration : Server Client Device Pool If using an RMAN restore script, the script is created, as described in RMAN scripts for restore and recovery on page 115. The volume required for the restore operation is mounted in a configured backup device: If you use a stand-alone tape drive, the volume is mounted manually. If you use an autochanger, the NetWorker server mounts the volume automatically. To determine the volumes required for the restore, you can use the nsrnmoinfo command, as described in Using the nsrnmoinfo command to determine the volumes for restore on page 117. Using the nsrnmoinfo command to determine the volumes for restore To determine the NetWorker volumes that contain the Oracle backup pieces to be restored, you can use the nsrnmoinfo command. The nsrnmoinfo program is installed with the NSR-DBM-ORA software in the same directory as the NetWorker client software. Performing an Oracle data restore and recovery 117

118 Data Restore and Recovery The nsrnmoinfo command syntax and options are as follows: nsrnmoinfo[.exe] [-c NetWorker_client_name] [-s NetWorker_server_name] [-f filename] [backup_piece_name1 [backup_piece_name2...]] where: NetWorker_client_name specifies the hostname of the NetWorker client whose index contains information on the Oracle backup pieces. By default, the client is the local host. NetWorker_server_name specifies the hostname of the NetWorker server to query for the volumes. By default, the server is the local host. filename specifies the name of a text file that contains a list of one or more backup piece names for restore: The file must contain each backup piece name on a separate line. The file cannot contain spaces or comments (for example, comment lines preceded with the # symbol). backup_piece_name1 and backup_piece_name2 specify backup piece names for restore. Command options in brackets ([ ]) are optional. Do not include the brackets when typing the command. To use the nsrnmoinfo command, specify the names of the backup pieces by either or both of the following: List the backup piece names as options of the nsrnmoinfo command. List the backup piece names in a text file, and specify the name of the file with the -f option of the nsrnmoinfo command. The nsrnmoinfo command displays a list of one or more volumes required for the Oracle restore: For each backup piece, the list includes the accessible volumes containing the backup piece, which the NetWorker server will use for the restore. For each volume, the list includes the following: The name and location of the volume. The save time of the backup piece on the volume. The listed volumes are the most accessible ones, which the NetWorker server intends to use for the restore at the time that the command is typed: The command lists clones of volumes if the original volumes are not accessible. If any listed volumes are removed from the NetWorker devices or deleted after the nsrnmoinfo command is typed, the server can perform the restore by using different volumes that are accessible. For example, the server can use an accessible clone (already mounted in a drive or available for mounting in a jukebox) instead of a listed volume. 118 NSR-DBM-ORA V5.0 Administrator s Guide

119 Data Restore and Recovery Example 19 Sample nsrnmoinfo commands for Oracle restores Each of the following nsrnmoinfo commands displays a list of the volumes required to restore the specified backup pieces: The following command searches in the NetWorker index of the client mars on the server server1 for information on the volumes that contain the backup pieces backupc_1 and backupc_2: nsrnmoinfo -c mars -s server1 backupc_1 backupc_2 The following command searches in the NetWorker index of the local host for information on the volumes that contain the backup pieces listed in the file backup2.txt: (Both the NetWorker client and server are assumed to be the local host.) nsrnmoinfo -f backup2.txt The following command searches in the NetWorker index of the client mars for information on the volumes that contain both: The backup piece backupc_3. The backup pieces listed in the file backup3.txt. (The NetWorker server is assumed to be the local host.) nsrnmoinfo -c mars backupc_3 -f backup3.txt Example 20 Volume information displayed by the nsrnmoinfo command The following nsrnmoinfo command searches in the NetWorker index of the local host on the server mars for information on the volumes containing the backup pieces backup1 and backup2: nsrnmoinfo -s mars backup1 backup2 The nsrnmoinfo command displays the following type of information: backup1: mars.003 at /space/nw_volume1 (save time ) mars.004 at /space/nw_volume2 (save time ) backup2: mars.005 at /dev/rmt/0cbn (save time ) According to this command display: Volumes mars.003 and mars.004 are required to restore the backup piece backup1. Volume mars.005 is required to restore the backup piece backup2. Restore through the RMAN command line interface An Oracle data restore can be started by using the RMAN command line interface on the Oracle Server host. To restore an Oracle database to a different system from the one backed up, follow the instructions in Restore to a different host on page 120. If the RMAN restore script on page 115 is stored in the file /disk1/scripts/restore.txt and the Net service has been configured to connect to the databases payroll and rcvcatdb, the Oracle restore can be started with the following command: rman target internal/oracle@payroll rcvcat rman/rman@rcvcatdb cmdfile \ /disk1/scripts/restore.txt\ Performing an Oracle data restore and recovery 119

120 Data Restore and Recovery Restore to a different host In some cases, an Oracle database must be restored to a different system from the one that was originally backed up. Some situations where this could occur include, but are not limited to, performing a disaster recovery or duplicating a database on a remote host. The appropriate Oracle documentation provides more information. To restore an Oracle database to different system: 1. On the NetWorker server that contains the backup to be restored, specify the hostname of the different system for the Remote Access attribute in the Client resource of the original system. 2. Install and configure NSR-DBM-ORA on the different system where the Oracle data is to be restored. 3. Install and configure RMAN on the different system. 4. Create an appropriate RMAN restore script. 5. In the RMAN script, set the parameter NSR_SERVER to the name of the NetWorker server that contains the backup. 6. In the RMAN script, set the parameter NSR_CLIENT to either the name of the NetWorker client (Oracle Server host) that was backed up or the value of NSR_CLIENT that was used during the backup. 7. Use the appropriate RMAN command to run the script to restore the Oracle database files. Restore with Oracle Enterprise Manager Backup Management Tools Note: Use of the Oracle Enterprise Manager Backup Management Tools is not supported with the recovery configuration wizard. The Oracle Enterprise Manager Backup Management Tools include a graphical user interface to RMAN. This interface can be used instead of the RMAN command line interface to do the following: Generate the required RMAN commands. Perform backup and restore operations.! IMPORTANT After the completion of an NSR-DBM-ORA backup or restore, the Oracle Enterprise Manager job queue history displays the status of the job as failed, even if the backup or restore completed successfully. This is due to a known problem with Oracle Enterprise Manager. View the job output to confirm that the backup or restore completed successfully. The Oracle Enterprise Manager documentation included with the product kit provides more information on using the Oracle Enterprise Manager Backup Management Tools. 120 NSR-DBM-ORA V5.0 Administrator s Guide

121 Data Restore and Recovery Perform an Oracle data recovery After restoring the NSR-DBM-ORA 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 115. After the RMAN restore script has completed successfully, type the commands at the operating system command line. The appropriate Oracle backup and recovery documentation provides more information on Oracle data recovery procedures. Performing an Oracle data restore and recovery 121

122 Data Restore and Recovery 122 NSR-DBM-ORA V5.0 Administrator s Guide

123 5 Disaster Recovery This chapter includes the following sections: About disaster recovery Preparing an Oracle database for disaster recovery Performing a disaster recovery Sample postcommand script Disaster Recovery 123

124 Disaster Recovery About disaster recovery It is important to develop a plan for recovering from a disaster on the computer system. Back up important data on a daily basis. To prepare for a disk crash or loss of data, develop and test a plan for recovering data. You must determine the required frequency of backups. Consider that backup frequency is a trade-off between the time spent backing up data, and the time spent later recovering a database after a crash. The following sections describe how to prepare for disaster recovery on an Oracle Server or NetWorker server host, and how to perform an Oracle disaster recovery to a new host. This disaster recovery information pertains to single-instance databases only. The information does not pertain to disaster recovery for: ASM environments (for example, requiring backups of ASM metadata) PowerSnap Module environments RAC environments Preparing an Oracle database for disaster recovery To prepare an Oracle database environment for disaster recovery, you must back up the following minimum list of files: Oracle database (all the datafiles) 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 containing the Oracle DBID Password file, in the following location by default: $ORACLE_HOME/dbs/orapw$ORACLE_SID Registry files:: On UNIX, oratab is typically in /var/opt/oracle or /etc 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. 124 NSR-DBM-ORA V5.0 Administrator s Guide

125 Disaster Recovery After manual Oracle backups, perform regular backups of the NetWorker server bootstrap and Oracle client file index by using the procedure described in NetWorker server bootstrap backup on page 100. To back up the required files in preparation for disaster recovery, perform the following: 1. Create the DBID text file on page Set up a postcommand script for backup of Oracle-related files on page Set up RMAN backups of the database and related files on page Set up RMAN backups of Recovery Catalog on page 126 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 125. In the sample postcommand script provided with the NSR-DBM-ORA software, the DBID text file is assumed to be dbid.txt, located in the $ORACLE_HOME directory. Sample postcommand script on page 128 provides details on the sample postcommand script. Set up a postcommand script for backup of Oracle-related files You can use a postcommand script to back up the files that Oracle RMAN does not back up, such as the following files: Initialization parameter file PFILE (user-managed parameter file) Network files, including listener.ora, sqlnet.ora, tnsnames.ora Text file containing the Oracle DBID, as described in Create the DBID text file on page 125 Password file in the following location by default: $ORACLE_HOME/dbs/orapw$ORACLE_SID Registry files: on UNIX, oratab is typically in /var/opt/oracle or /etc RMAN scripts, if applicable You can either create a postcommand script from scratch, or modify the postcommand script that is provided with the NSR-DBM-ORA software. On UNIX, you can use any name for the postcommand script. Note: During a scheduled NSR-DBM-ORA backup, the nsrnmostart process passes the options -s server_name -g group_name to the postcommand script if the script name begins with nsrnmodr. Preparing an Oracle database for disaster recovery 125

126 Disaster Recovery In a scheduled RMAN backup, include the postcommand script by one of the following methods: If you use the NSR-DBM-ORA wizard to configure the RMAN backup, specify the postcommand script in the wizard. If you use the legacy method (without the wizard) to configure the RMAN backup, set the POSTCMD parameter in the nsrnmo script. Sample postcommand script on page 128 provides details on the postcommand script that is provided with the NSR-DBM-ORA software. Set up RMAN backups of the database and related files Set up an RMAN backup with NSR-DBM-ORA 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 NSR-DBM-ORA. 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 125 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 126. Oracle documentation provides more information on setting up and running Recovery Catalog backups. Performing a disaster recovery The following sections provide guidelines for different types of disaster recovery operations: NetWorker server recovery on page 127 Oracle disaster recovery to a new host on page NSR-DBM-ORA V5.0 Administrator s Guide

127 Disaster Recovery 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 degree of severity of the disaster determines the procedures that must be performed to recover data on the NetWorker server. With respect to NetWorker backups, recall that the bootstrap is a critical file, backed up only after scheduled Oracle backups. If only manual Oracle backups are performed, back up the bootstrap and client index manually. NetWorker server bootstrap backup on page 100 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 The NetWorker Disaster Recovery Guide provides information on how to recover the NetWorker server from various types of disasters. Related documentation on page 9 describes how to access the guide. 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 NSR-DBM-ORA software on the new host, and create a Client resource for the new host. 3. Ensure that the user performing the recovery on the new host is listed in the Remote Access attribute in the Client resource of the original host. (This is required for directed recovery in NetWorker.) 4. To recover Oracle files that were backed up through a postcommand script, use either the NetWorker User GUI or the recover command. For example, a typical recover command is as follows: recover s NetWorker_server c client_name_of_original_host d /var/opt/oracle a /var/opt/oracle/oratab 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. Performing a disaster recovery 127

128 Disaster Recovery Sample 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 125. The NSR-DBM-ORA software includes a sample postcommand script that you can modify for your environment. The NSR-DBM-ORA installation provides a sample postcommand script that is specific to UNIX, depending on the platform where NSR-DBM-ORA is installed. The sample script is installed in the bin subdirectory under the NetWorker software directory, for example, under /opt/nsr. 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 NSR-DBM-ORA backup, the nsrnmostart process passes the options -s server_name -g group_name to the postcommand script if the script name begins with nsrnmodr. View the sample postcommand script provided with NSR-DBM-ORA as follows in Example 21 on page 128. Example 21 Sample postcommand script on UNIX The sample postcommand script named nsrnmodrpostcmd is installed with the NSR-DBM-ORA 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 128 NSR-DBM-ORA V5.0 Administrator s Guide

129 Disaster Recovery fi save -s $SRV -g $GRP /var/opt/oracle/oratab save -s $SRV -g $GRP $ORACLE_HOME/dbid.txt Sample postcommand script 129

130 Disaster Recovery 130 NSR-DBM-ORA V5.0 Administrator s Guide

131 6 Cluster and RAC Systems This chapter includes the following sections: Considerations for cluster and RAC systems Cluster systems RAC systems Cluster and RAC Systems 131

132 Cluster and RAC Systems Considerations for cluster and RAC systems To prepare for successful NSR-DBM-ORA operations on cluster and RAC systems, consider the following: Parameters in the RMAN script or session on page 132 NetWorker software configuration on page 133 Backup failover on page 133 Parameters in the RMAN script or session The parameters NSR_CLIENT and NSR_SERVER must be correctly set in the RMAN script or session. Appendix A, Parameters in an RMAN Session, provides more information on how to set the required parameters. NSR_CLIENT During an Oracle backup, the NetWorker server creates entries about the backed-up data in the online client file index. During an Oracle restore, the data is retrieved by first searching this client file index. The parameter NSR_CLIENT that is set in the RMAN script provides the following information to the NetWorker server: During a backup, the name of the NetWorker client whose index file should be used to record the backup information. During a restore, the name of the NetWorker client whose index file should be used to search for the save set to be restored. If NSR_CLIENT is not set, the NetWorker server uses the name of the local physical host. Set the parameter NSR_CLIENT to the same value for all channels allocated during the backup. The value of NSR_CLIENT (either the default value or an explicitly defined value) used for a backup should be the same as the value of NSR_CLIENT used for the restore of that backup. Setting NSR_CLIENT to the name of the virtual (as opposed to the physical) host might be preferable, so the backup and restore scripts run successfully unmodified, regardless of the physical host that executes the scripts.! IMPORTANT If NSR_CLIENT is set to any value other than the default value during a backup or restore, the Remote Access attribute must be modified in that NetWorker Client resource. The NetWorker Administrator s Guide provides more information. For each Oracle backup and restore, set NSR_CLIENT by using either the rman send command on the operating system command line or the send command in the RMAN script. Note: Setting NSR_CLIENT in the system environment has no effect. 132 NSR-DBM-ORA V5.0 Administrator s Guide

133 Cluster and RAC Systems NSR_SERVER Set the parameter NSR_SERVER for a manual Oracle backup or restore if the NetWorker server is a remote system for the node running the RMAN session. The parameter must be set to the server name for each channel. Note: The parameter NSR_SERVER does not need to be set for a scheduled Oracle backup. NetWorker software configuration Ensure the correct NetWorker software configuration by performing the following tasks: 1. Ensure that the system is set up properly: In the NetWorker Client resource of each host, the Save Set attribute is set to: RMAN:RMAN_script_pathname In the directory that contains the savefs program file, there is an empty file named pathownerignore. Create the pathownerignore file if it does not exist. The NetWorker Release Notice provides more information on the default directory for the savefs program. 2. Configure a Client resource on the NetWorker server for each RAC node that will be used to run backups and restores. In each Client resource, use the fully qualified IP name as the client name. Configure a Client resource with NMC on page 81 provides information on how to configure a Client resource for NSR-DBM-ORA backups. 3. In the Remote Access attribute in the Client resource for a virtual host, specify the name of each physical host that can store and retrieve the backups. Backup failover Neither RMAN nor NSR-DBM-ORA supports Transparent Application Failover (TAF). As a result, if a failure occurs during a backup, the backup is not automatically restarted from the point of failure on another node. Only connect-time failover is supported. Connect-time failover on page 138 provides more information. Cluster systems A cluster system typically includes multiple nodes connected by a shared SCSI bus to which common storage is attached. In a cluster system, cluster services such as disk services can be defined and assigned their own IP addresses and names (virtual hosts). The services and their associated storage can migrate for failover between the physical nodes in the cluster. Together, the NSR-DBM-ORA and NetWorker server software can back up and restore an Oracle database configured on cluster disk services. The NetWorker server treats each cluster service as an independent client and stores the associated backup entries in the online indexes under the name of the service. After properly configuring a cluster service as a NetWorker client, NSR-DBM-ORA can be used with the NetWorker server to back up and restore the database associated with the service, independent of the actual node that provides the service. Cluster systems 133

134 Cluster and RAC Systems To configure a cluster system for Oracle backup and restore operations that use NSR-DBM-ORA, follow the Roadmap for backup/restore configuration in a cluster system on page 134. Roadmap for backup/restore configuration in a cluster system The Oracle Server and NetWorker server systems must be configured before NSR-DBM-ORA can be used with the NetWorker server for Oracle backup and restore operations in a cluster system. Before configuring Oracle backup and restore operations in a cluster system, ensure the following: The NSR-DBM-ORA software is properly installed according to the instructions in the NSR-DBM-ORA Release Notice. The Oracle Server and NetWorker server system configurations are completed according to the instructions in the Configuration roadmap on page 58. To properly configure Oracle backup and restore operations with NSR-DBM-ORA in a cluster system: 1. Configure the storage for the database as a cluster disk service. The appropriate cluster administration guide from the particular cluster software vendor provides more information. 2. Configure a Client resource on the NetWorker server for the virtual host and each physical host that will run backups and restores. 3. Create an RMAN script that includes the appropriate NSR_CLIENT parameter settings. NSR_CLIENT on page 132 provides more information. Backup failover When a node failure occurs during a manual (unscheduled) Oracle backup, a database administrator (DBA) must restart the backup after instance recovery. Since the Oracle Net services are configured with a cluster service name, the restarted backup is executed on the physical node that takes control of the cluster service. When a node failure occurs during a scheduled Oracle backup, the NetWorker server restarts the backup (from the beginning, not from the point of failure) if the Client Retries attribute in the NetWorker Group resource is set to a value greater than zero. The restarted backup is executed on the node that takes control of the cluster service. 134 NSR-DBM-ORA V5.0 Administrator s Guide

135 Cluster and RAC Systems RAC systems The NSR-DBM-ORA software supports backups and restores of 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.fujitsu.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, NSR-DBM-ORA enables Oracle backups on either a single node or several nodes of the RAC system. A parallel Oracle backup uses Oracle instances running in parallel on multiple nodes of the cluster. In the RMAN backup script created for running a parallel Oracle backup, allocate multiple channels for the backup and specify that each channel run on a specific node. The parameter NSR_CLIENT must be set to the same value for each channel. NSR_CLIENT on page 132 provides more information on setting the parameter. NSR-DBM-ORA software enables restores of the Oracle data to any physical node in the cluster, regardless of which physical node originally performed the backup. To enable Oracle backup and restore operations, follow the configuration steps in Roadmap for backup/restore configuration in a RAC system on page 135. Roadmap for backup/restore configuration in a RAC system To properly configure Oracle backup and restore operations with NSR-DBM-ORA 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 138 provides guidelines. The appropriate Oracle documentation provides more information. RAC systems 135

136 Cluster and RAC Systems 4. Install NSR-DBM-ORA on each node of the cluster to be used for backup and recover operations. The NSR-DBM-ORA Release Notice provides more information. 5. Configure a Client resource on the NetWorker server for the virtual host and each physical host that will run backups and restores. 6. Create the appropriate RMAN backup and restore scripts for the preferred types of Oracle backups and restores on the RAC system. The following sections provide more information: Creating RMAN backup scripts on page 140 Creating RMAN restore scripts on page Review the additional issues concerning Oracle recover operations in Archived redo logs on page 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 136. 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 NSR-DBM-ORA backup. 2. On the NetWorker server, create a NetWorker Storage Node resource for each RAC node to be used for the NSR-DBM-ORA backup. The NetWorker Administrator s 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 NSR-DBM-ORA backup. The NetWorker Administrator s 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 NSR-DBM-ORA 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 NSR-DBM-ORA backup and to initiate the backup. 7. For the RAC node that will initiate the NSR-DBM-ORA backup, create a NetWorker Client resource with the attribute settings required for the backup, as described in NetWorker software configuration on page 133: The Remote Access attribute must include the hostnames of all the other RAC nodes. The Storage Nodes attribute must contain curphyhost, followed by nsrserverhost. The Storage Nodes attribute must be set to the following: curphyhost nsrserverhost 8. For each of the other RAC nodes that will not initiate the NSR-DBM-ORA backup, create a basic Client resource. (Settings in these other Client resources do not affect the NSR-DBM-ORA backup.) 136 NSR-DBM-ORA V5.0 Administrator s Guide

137 Cluster and RAC Systems 9. On the RAC node that will initiate the NSR-DBM-ORA backup, create the required nsrnmo script and RMAN backup script. The RMAN script must include the NSR_CLIENT setting, as described in NSR_CLIENT on page 132. Example 22 on page 137 shows how to set up three RAC nodes as storage nodes for NSR-DBM-ORA backups. Example 22 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 NSR-DBM-ORA 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 NSR-DBM-ORA backups and initiate the backups. (The choice of node A was arbitrary; node B or node C could have been chosen instead.) In all the RMAN backup and restores scripts, NSR_CLIENT must be set to the hostname of node A. In the NetWorker Client resource for node A: The Remote Access attribute is set to the hostnames of nodes B and C. The Storage Nodes attribute is set to: curphyhost nsrserverhost The remaining attributes are set, as required. For example: The Backup Command attribute is set to the nsrnmo script name. The Group attribute is set to the backup group name. The Save Set attribute is set to the RMAN script pathname. The following RMAN script uses all three nodes to perform the backup. Each node backs up data to its local tape drive: connect target sys/oracle@connect_identifier; run { allocate channel t1 type SBT_TAPE connect sys/oracle@net_service_name_of_instance_a ; 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 ; RAC systems 137

138 Cluster and RAC Systems } 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 If multiple listeners support a single service, a connect-time failover reroutes the connection request to another listener if the first listener is down or cannot make the connection. To enable the connect-time failover in RAC, there must be a listener on each node, and each instance must use the same Net service name. When using the local Net service naming method, the client s tnsnames.ora file should include the following parameters: o92pa.fujitsu.com = (DESCRIPTION = (ADDRESS_LIST = (FAILOVER = ON) (ADDRESS = (PROTOCOL = tcp) (HOST = nodea) (PORT = 1521)) (ADDRESS = (PROTOCOL = tcp) (HOST = nodeb) (PORT = 1521)) ) (CONNECT DATA = (SERVICE_NAME = proddb) ) ) Set the FAILOVER parameter to ON. The default value is ON for an ADDRESS_LIST, and OFF when ADDRESS_LIST is not specified. Note: FAILOVER was introduced in Oracle8i. Include the ADDRESS_LIST parameter: If multiple addresses are specified, but the ADDRESS_LIST parameter is omitted, the Oracle Net service reads the addresses sequentially and attempts to connect to the last one only. If the ADDRESS_LIST parameter is specified, the addresses are tried in the order they appear in the list. 138 NSR-DBM-ORA V5.0 Administrator s Guide

139 Cluster and RAC Systems In the CONNECT_DATA section, use SERVICE_NAME instead of the system identifer (SID). SERVICE_NAME should be different from SID. Note: SERVICE_NAME was introduced in Oracle8i. GLOBAL_DBNAME should not appear in the SID_LIST_LISTENER parameter of the listener.ora file since it disables the failover. When a node or listener to which a client tries to connect is not available, the next listener on the list is contacted. When the instance is down but the listener is running, the failover occurs only if the instance is configured to dynamically register with the listener. Dynamic instance registration Dynamic instance registration was introduced in Oracle8i. During dynamic instance registration, the database registers itself with the Oracle listener on startup and unregisters itself on shutdown. To perform dynamic instance registration: Set the INSTANCE_NAME and SERVICE_NAME parameters in the initialization file (initoracle_sid.ora). There can be several services for a single instance. If the listener does not listen on the default port (1521), set the LOCAL_LISTENER parameter in the initialization file. The SID_LIST_LISTENER parameter in listener.ora must not include SID_DESC for the RAC instances. It is not necessary to have the listener.ora file when the listener listens on the default port. When the instance is down, the listener does not know how to connect to it. As a result, the listener tries the next connect option specified in the ADDRESS_LIST in the tnsnames.ora file. Note: Some applications such as Oracle Enterprise Manager still require static database registration with a listener. Static instance registration With static registration, the information about the instance is manually configured in the listener.ora file through SID_DES in the SID_LIST_LISTENER parameter. The listener contains continuous information about the instance, even if the instance is down. As a result, when the instance is down, the listener still tries to connect to it rather than try the next connect option specified in the tnsnames.ora file. 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. RAC systems 139

140 Cluster and RAC Systems 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 NSR-DBM-ORA 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) NSR-DBM-ORA 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 NSR-DBM-ORA backup. Creating RMAN backup scripts A single RMAN backup script can be used to run a parallel Oracle backup with NSR-DBM-ORA 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 23 RMAN script for a manual Oracle backup on a RAC system Suppose a RAC system consists of two nodes named node1.fujitsu.com and node2.fujitsu.com. The Oracle instances named instance1 and instance2 are running on node1.fujitsu.com and node2.fujitsu.com, respectively. The NetWorker server is located on a separate node, server1.fujitsu.com. The following RMAN script for a manual backup is intended to run on node1.fujitsu.com by using the NOCATALOG mode of RMAN. The script sets NSR_CLIENT to node1.fujitsu.com and NSR_SERVER to server1.fujitsu.com. As a result, the NetWorker server stores the backup information in the node1.fujitsu.com client file index, as described in NSR_CLIENT on page 132. Two channels are allocated to each of the nodes, node1.fujitsu.com and node2.fujitsu.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_node2 ; allocate channel t4 type SBT_TAPE connect user_name/user_passwd@connect_string_of_node2 ; send NSR_ENV=(NSR_CLIENT=node1.fujitsu.com, NSR_SERVER=server1.fujitsu.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 142 provides a sample script to back up all the archive log files in a RAC system. 140 NSR-DBM-ORA V5.0 Administrator s Guide

141 Cluster and RAC Systems Creating RMAN restore scripts A single RMAN restore script can be used to run a parallel Oracle restore with NSR-DBM-ORA 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: NSR-DBM-ORA 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 24 RMAN script for an Oracle restore on a RAC system Refer to Example 23 on page 140. A RAC system consists of two nodes named node1.fujitsu.com and node2.fujitsu.com. The Oracle instances named instance1 and instance2 are running on node1.fujitsu.com and node2.fujitsu.com, respectively. The NetWorker server is located on a separate node, server1.fujitsu.com. The following RMAN restore script is to be run on node2.fujitsu.com. The script restores the backup that was created by the backup script in Example 23 on page 140. This restore script sets NSR_CLIENT to node1.fujitsu.com and NSR_SERVER to the remote NetWorker server name. As a result, the NetWorker server will obtain the backup information from the node1.fujitsu.com client file index. Two channels are allocated to each of the nodes, node1.fujitsu.com and node2.fujitsu.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.fujitsu.com, NSR_SERVER=server1.fujitsu.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.fujitsu.com for each channel in the RMAN backup script. In order to restore the backup data to node2.fujitsu.com, add node2.fujitsu.com to the Remote Access attribute in the NetWorker Client resource for node1.fujitsu.com. The NetWorker Administrator s Guide provides more information on how to modify the Client resource. Restoring all archived logs from each node on page 142 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. RAC systems 141

142 Cluster and RAC Systems 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 142 Restoring all archived logs from each node on page 142 Backing up all archived logs from each node All the archived log files in a RAC system can be backed up from a single node (for example, a node named ops1.fujitsu.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.fujitsu.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 (for example, a node named ops1.fujitsu.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.fujitsu.com, NSR_CLIENT=ops1.fujitsu.com ) ; restore (archive log all); release t1; release t2; } 142 NSR-DBM-ORA V5.0 Administrator s Guide

143 7 Proxy Backups and Restores This chapter includes the following sections: Overview of proxy backups and restores Proxy backup and restore system Proxy backup processes Proxy restore processes Software configuration roadmap Proxy backup requirements Proxy backup information in the NetWorker indexes Proxy restore requirements Catalog synchronization for proxy backups Proxy backups and restores on cluster systems Proxy Backups and Restores 143

144 Proxy Backups and Restores Overview of proxy backups and restores Proxy backups and restores provide continuous snapshot-based protection and availability of Oracle data on specific types of primary storage. The NSR-DBM-ORA software supports proxy backups and restores of Oracle data with the following requirements: The proxy backups create snapshots of Oracle data that reside on primary storage devices supported by the PowerSnap Modules that work with the NSR-DBM-ORA. The proxy operations use the particular PowerSnap Module software designed for the primary storage. The following sources provide details on the installation requirements for proxy operations: NSR-DBM-ORA Release Notice NetWorker PowerSnap Module documentation (Refer to the PowerSnap Module version for the primary storage system.) Types of proxy backups Instant backups NSR-DBM-ORA supports the following types of proxy backups, in cooperation with the appropriate PowerSnap Module: Instant backups on page 144 Live backups on page 144 An instant backup creates a point-in-time copy (snapshot) of Oracle data and stores this copy on the primary storage system. Instant backups can be scheduled to occur many times in a single day, with little impact to the Oracle Server or network. The group of Oracle datafiles in the point-in-time copy is referred to as a snap set. A snapshot policy must be configured to control the lifecycle of the snap set. This policy specifies the frequency of instant backups and how long snapshots are retained before being recycled. Software configuration roadmap on page 156 provides more information. Note: NSR-DBM-ORA supports scheduled instant backups only. Manual (unscheduled) instant backups are not supported.! IMPORTANT Instant backups protect against logical failures only. To protect against physical failures, the point-in-time copy must be backed up to secondary storage. Live backups NSR-DBM-ORA supports the following two types of live backup, which back up a snapshot to secondary (traditional) storage: Deferred live backup An existing point-in-time copy (snapshot), that is created during an instant backup, is backed up to secondary storage, such as tape. The snapshot is retained on the primary storage. 144 NSR-DBM-ORA V5.0 Administrator s Guide

145 Proxy Backups and Restores Immediate live backup A point-in-time copy (snapshot) is created, and immediately backed up to secondary storage, such as tape. The snapshot is then automatically deleted from the primary storage. A snapshot policy must be configured to enable live backups. Software configuration roadmap on page 156 provides more information. FSC-Kommentar: Abschnitt Important nach oben verschoben A proxy client host that is separate from the Oracle Server host can be used to move the point-in-time copy to the traditional storage medium, such as tape. Using a proxy client as a secondary host reduces the impact on the Oracle Server. Note: The proxy client can be a NetWorker storage node. Types of proxy restores NSR-DBM-ORA supports the following types of proxy restores, in cooperation with the appropriate PowerSnap Module: Instant restores on page 145 Rollbacks on page 145 Restores from secondary storage on page 145 Instant restores Rollbacks During an instant restore, the saved data is retrieved from a mounted point-in-time copy that was created with an instant backup. A minimal amount of time is required for this type of restore. A rollback restores a whole point-in-time copy to a source location by using the hardware s particular capabilities. Rollbacks are destructive restores because they overwrite the entire contents of a snapshot unit, such as a volume or disk. Use the NetWorker PowerSnap Module documentation to determine if a rollback is supported on a specific type of hardware. Restores from secondary storage If the point-in-time copy was backed up to secondary storage through a live backup, the PowerSnap Module software uses the NetWorker recover program to retrieve the data. Overview of proxy backups and restores 145

146 Proxy Backups and Restores Proxy backup and restore system For proxy backups and restores, the NSR-DBM-ORA, NetWorker server and client, and appropriate PowerSnap Module software function with the components of the Oracle backup and restore system. The implementation of a proxy backup and restore strategy requires a knowledge of how the Oracle and NetWorker software components work together. The Oracle backup and restore system consists of the following: Oracle Server Recovery Manager (RMAN) Recovery Catalog (optional) Oracle Enterprise Manager (OEM) Backup Management Tools (optional) The following sections provide more information on RMAN and the Recovery Catalog: Oracle Recovery Manager on page 47 Oracle Recovery Catalog on page 47 The NetWorker software components required for proxy backups are the following: NetWorker server NetWorker client (installed on the Oracle Server and proxy client host) NSR-DBM-ORA (installed on the Oracle Server) NetWorker PowerSnap Module (installed on the Oracle Server and proxy client host) Note: NetWorker storage node software should be installed on the proxy client host. Figure 11 on page 147 illustrates the architecture of the proxy backup and restore system. It provides an overview of the functional relationship between the Oracle and NetWorker software components. The interactions of the components are described in the following sections: Proxy backup processes on page 147 Proxy restore processes on page NSR-DBM-ORA V5.0 Administrator s Guide

147 Proxy Backups and Restores Oracle Server Host RMAN NetWorker Client PowerSnap Proxy Client (NetWorker Storage Node) NetWorker Server Oracle Server Recovery Catalog NSR- DBM-ORA MML NetWorker Client PowerSnap Module PowerSnap Module NetWorker Server Oracle Data Files Point-in-Time Copy of Oracle Data Files Primary Storage Storage Medium GEN Figure 11 Proxy backup and restore system Proxy backup processes During a proxy backup of Oracle data, Oracle Server processes interact with the NetWorker server through the NSR-DBM-ORA and PowerSnap Module software. The NSR-DBM-ORA media management library (MML) is integrated with the Oracle Server kernel software. Note: Certain RMAN features, such as checking for corrupt blocks, are not applicable to proxy backups because the MML controls that process. When a proxy backup is initiated, the RMAN utility starts the Oracle Server processes that call the MML proxy-specific routines. The MML routines communicate with the PowerSnap Module service. On the Oracle Server host, the PowerSnap Module uses a storage platform-specific application programming interface (API) to take a snapshot of the Oracle data on the primary storage. Proxy backup processes 147

148 Proxy Backups and Restores If a live backup is performed, the PowerSnap Module moves the Oracle data from the point-in-time copy (snapshot) on the primary storage to the NetWorker server or storage node. The NetWorker server or storage node then stores the Oracle data on the secondary storage, such as a tape. At the end of the proxy backup, the NetWorker server updates the online client and media indexes with information about the backup. The NetWorker Administrator s Guide provides more information about NetWorker server and NetWorker client programs and services. Note: A proxy backup can be started only by automatic or manual invocation of the scheduled NetWorker backup group. A proxy backup cannot be scheduled through Oracle Enterprise Manager or started from RMAN. The NetWorker PowerSnap Module documentation provides information on how to manually invoke a scheduled backup. Scheduled proxy backup A scheduled backup is a backup of Oracle data that the NetWorker server initiates. The following sections describe the process steps in the three types of scheduled proxy backup: Scheduled instant backup on page 148 Scheduled immediate live backup on page 150 Deferred live backup on page 152 Note: To simplify the descriptions and illustrations in these sections, certain steps have been omitted, such as the step to obtain the proper NetWorker authorization. Scheduled instant backup A scheduled instant backup involves the following steps: 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, on the Oracle Server host run the savefs program to verify the existence of the RMAN scripts to be used for the backup. 3. If the savefs program succeeds, the savegrp program starts the PowerSnap program, nsrsnap, on the Oracle Server host. Otherwise, the backup fails. 4. If an existing point-in-time copy needs to be removed (for example, it is expired according to the snapshot policy), the nsrsnap program invokes the nsrsnapck program to remove both the point-in-time copy from the storage system and the corresponding NetWorker index entries. Note: If the point-in-time copy was not copied to secondary storage, the nsrsnapck program invokes the nsroraclecat program to remove the corresponding RMAN catalog entries. Automatic catalog synchronization with the nsroraclecat program on page 183 provides more information. 5. The nsrsnap program contacts the nsrexecd service, which starts the nsrnmo script for the scheduled backup. 6. The nsrnmo script sets the required parameters and invokes the NSR-DBM-ORA program, nsrnmostart. 148 NSR-DBM-ORA V5.0 Administrator s Guide

149 Proxy Backups and Restores 7. The nsrnmostart program starts the RMAN utility to run the required RMAN backup script. 8. RMAN starts an Oracle process that calls the MML, which contacts the PowerSnap master program, nsrpsd, to perform the instant backup: PowerSnap processes create the point-in-time copy that comprises the backup. The nsrmmd service performs the following: Stores metadata (used only by the PowerSnap Module) about the point-in-time copy on the media belonging to the configured snapshot pool. Records tracking information about the metadata in the NetWorker media database by using the nsrmmdbd service. The nsrindexd service records information about the point-in-time metadata in the NetWorker client file index. The nsrindexd service records tracking information about each backup piece name in the NetWorker client file index. The client index contains one entry per datafile. The Oracle Server records the backup entry in the RMAN catalog. 9. After the RMAN script completes successfully, the nsrnmostart program backs up the NWORA resource file, described in The NWORA resource file on page If the Snapshot Policy resource specifies that the point-in-time copy must be copied to secondary storage, the nsrsnap program performs the steps in Deferred live backup on page 152. Note: The point-in-time copy is not deleted from the primary storage. 11. The savegrp program backs up the NetWorker server bootstrap and Oracle client file indexes. Figure 12 on page 150 shows how the Oracle Server and NetWorker processes interact during a scheduled instant backup. Proxy backup processes 149

150 Proxy Backups and Restores Oracle Server (NetWorker Client) Oracle Data Files Primary Storage PowerSnap Proxy Client (NetWorker Storage Node) Point-in-Time Copy of Oracle Data Files NetWorker Server Client File Index data Oracle process PowerSnap processes PowerSnap processes tracking information nsrindexd NSR- DBM-ORA MML nsrpsd nsrexecd nsrmmd Media Database RMAN nsrnmostart nsrnmo nsrsnap PowerSnap elements NetWorker Module elements Snapshot Pool Media interprocess communication nsrmmdbd nsrd nsrsnapck nsrexecd savegrp nsroraclecat (optional) savefs Start Here GEN Figure 12 Scheduled instant backup Scheduled immediate live backup A scheduled immediate live backup involves the following steps: Note: The first seven steps are the same as those in Scheduled instant backup on page 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, on the Oracle Server host run the savefs program to verify the existence of the RMAN scripts to be used for the backup. 3. If the savefs program succeeds, the savegrp program starts the PowerSnap program, nsrsnap, on the Oracle Server host. Otherwise, the backup fails. 150 NSR-DBM-ORA V5.0 Administrator s Guide

151 Proxy Backups and Restores 4. If an existing point-in-time copy needs to be removed (for example, it is expired according to the snapshot policy), the nsrsnap program invokes the nsrsnapck program to remove both the point-in-time copy from the storage system and the corresponding NetWorker index entries. Note: If the point-in-time copy was not copied to secondary storage, the nsrsnapck program invokes the nsroraclecat program to remove the corresponding RMAN catalog entries. Automatic catalog synchronization with the nsroraclecat program on page 183 provides more information. 5. The nsrsnap program contacts the nsrexecd service, which starts the nsrnmo script for the scheduled backup. 6. The nsrnmo script sets the required parameters and invokes the NSR-DBM-ORA program, nsrnmostart. 7. The nsrnmostart program starts the RMAN utility to run the required RMAN backup script. 8. RMAN starts Oracle processes that call the MML, which contacts the PowerSnap master program, nsrpsd, to perform the immediate live backup: PowerSnap processes create the point-in-time copy, move the data to secondary storage, and then delete the point-in-time copy from the primary storage. The nsrmmd service records the tracking information about the secondary storage save sets in the NetWorker media database by using the nsrmmdbd service. The nsrindexd service records the tracking information for each backup piece name and for each stored operating system datafile in the NetWorker client file index. The client index contains two entries per datafile. The Oracle Server records the backup entry in the RMAN catalog. 9. After the RMAN script completes successfully, the nsrnmostart program backs up the NWORA resource file, described in The NWORA resource file on page The savegrp program backs up the NetWorker server bootstrap and Oracle client file indexes. Figure 13 on page 152 shows how the Oracle Server and NetWorker processes interact during a scheduled immediate live backup. Proxy backup processes 151

152 Proxy Backups and Restores Oracle Server (NetWorker Client) Oracle Data Files Primary Storage PowerSnap Proxy Client (NetWorker Storage Node) Point-in-Time Copy of Oracle Data Files NetWorker Server Client File Index data Oracle process PowerSnap processes PowerSnap processes tracking information nsrindexd NSR- DBM-ORA MML nsrpsd nsrexecd nsrmmd Media Database RMAN nsrnmostart nsrnmo nsrsnap PowerSnap elements NetWorker Module elements Secondary Storage Medium interprocess communication nsrmmdbd nsrd nsrsnapck nsrexecd savegrp nsroraclecat (optional) savefs Start Here GEN Figure 13 Deferred live backup Scheduled immediate live backup A deferred live backup runs automatically as part of a scheduled backup, as specified by the Backup Snapshots attribute of the Snapshot Policy resource. The NetWorker PowerSnap Module documentation provides more information. A deferred live backup involves the following steps: 1. The nsrsnap or nsrsnapadmin program invokes the PowerSnap processes to copy the point-in-time copy to secondary storage. Note: The point-in-time copy is not deleted from the primary storage. 2. The nsrmmd service records the tracking information about the deferred live backup in the NetWorker media database by using the nsrmmdbd service. 3. The nsrindexd service records the tracking information for each stored operating system datafile in the NetWorker client file index. 152 NSR-DBM-ORA V5.0 Administrator s Guide