Dell NetWorker for OpenVMS Specifications

Add to My manuals
37 Pages

advertisement

Dell NetWorker for OpenVMS Specifications | Manualzz

Dell EMC NetWorker

Version 18.1

OpenVMS ECO Readme

Rev 01

January 14, 2022

Copyright © 2003-2022 Dell Inc. or its subsidiaries. All rights reserved.

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

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” DELL MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO

THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR

PURPOSE. USE, COPYING, AND DISTRIBUTION OF ANY DELL SOFTWARE DESCRIBED IN THIS PUBLICATION REQUIRES AN APPLICABLE SOFTWARE

LICENSE.

Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA.

Dell EMC

Hopkinton, Massachusetts 01748-9103

1-508-435-1000 In North America 1-866-464-7381 www.DellEMC.com

2 OpenVMS ECO Readme

Preface

This document describes the changes made in each Engineering Change Order (ECO) for the Dell

EMC NetWorker for OpenVMS 18.1 software. ECO packages are cumulative. That is, changes included in ECO-1 are also included in all future ECOs.

Topics include:

Preface ................................................................................................................................................ 3

Revision History .................................................................................................................................. 4

PART 1: New and Changed Features .................................................................................................. 5

CHAPTER 1 NetWorker for OpenVMS V18.1 ECO Summary .......................................................... 6

CHAPTER 2 NetWorker for OpenVMS V18.1 ECO-2 Details ......................................................... 10

AFTD Device Creation Wizard........................................................................................................... 10

Remote Device Path Details ...................................................................................... 11

CHAPTER 3 NetWorker for OpenVMS V18.1 ECO-1 Details ......................................................... 12

Legacy OpenVMS Versions and TCPIP Network I/O ......................................................................... 12

Automatic Device Configuration ...................................................................................................... 14

Jbverify Enhancements and Corrections .......................................................................................... 14

Changes for BTL Mapping of Fibre Channel Devices ........................................................................ 15

Creating File and Advanced File Devices .......................................................................................... 16

Syntax ........................................................................................................................ 16

Limitations ................................................................................................................. 18

Recover -b Enhancement ................................................................................................................. 19

Pre and Post Command Support ...................................................................................................... 19

CHAPTER 4 Multi-Level Backup for Database Modules ............................................................... 20

Overview ........................................................................................................................................... 20

Operation .................................................................................................................. 20

Backup Schedule and Client-side Script Synchronization ......................................... 21

NetWorker Backup Levels ......................................................................................... 22

OpenVMS ECO Readme 3

Database Module Templates .................................................................................... 23

Performing Multi-level Backups is Optional .............................................................. 23

Manual Backups ........................................................................................................ 23

NetWorker Module for Oracle Rdb – Configuration ........................................................................ 25

DCL Script Configuration ........................................................................................... 25

Example: Restoring Rdb Backups .............................................................................. 27

Troubleshooting Tips ................................................................................................. 29

NetWorker Module for Oracle – Configuration ............................................................................... 30

Script Configuration................................................................................................... 30

Example: Restoring Oracle Backups .......................................................................... 32

PART 2: ECO Installation and Verification ........................................................................................ 34

CHAPTER 5 Installing an ECO Package.......................................................................................... 35

Download and Validation ................................................................................................................. 35

Installing the ECO Package ............................................................................................................... 36

Example Installation .................................................................................................. 37

Revision History

The following table presents the revision history of this document.

Revision

Rev-01

Date

January 12, 2021

January 14, 2022

Description

This is the first release of this document. It includes information about ECO-1.

This release includes information about ECO-2. Rev-02

4 OpenVMS ECO Readme

PART 1: New and Changed Features

This section describes new and changed features of the NetWorker for OpenVMS V18.1 release. It is organized into a chapter containing tables that summarize all the ECOs released to date and, if necessary, subsequent chapters that provide additional details about the changes in those ECOs.

OpenVMS ECO Readme 5

CHAPTER 1 NetWorker for OpenVMS V18.1

ECO Summary

The following tables summarize the updates made for each ECO, starting with the most recent.

Table 1 – Changes for ECO-2

Reference

Number

Description

WW207 The NSRINFO program does not honor client remote Access settings. These settings are specified in the Globals 2 of 2

Configuration section of the client properties dialog. The usual workaround was to provide the user with Remote Access All privilege.

WW212 It is possible for a save process to become stuck in the RWMBX state. Once in this state, the save is Abandoned. Typically, the save command is retried and operates normally, which results in a successful save. But it can happen that the save is not retried, resulting in a failed or incomplete backup. In either case, the hung save process remains until removed by the system administrator with the STOP/ID command. This problem can be exacerbated on multiprocessor systems, or systems with many

CPU cores, high parallelism settings, and the use of debugging flags that generate a large amount of output from the save processes.

WW213 New AFTD Device creation using the NMC New Device Wizard does not work properly. The usual workaround was to use the

New Device Properties dialog box to create the device instead.

WW214 The logical names for the NetWorker installation directories have an inconsistent case. Most logical names are all uppercase, but the NSR$SYSROOT logical name can be defined with lower case values: nsr$specific: and nsr$common, instead of

NSR$SPECIFIC and NSR$COMMON.

Resolution

ECO-2 corrects this deficiency.

Remote access settings are now properly considered when viewing remote client index entries with

NSRINFO.

ECO-2 resolves this problem.

ECO-2 corrects this deficiency.

Refer to AFTD Device Creation

Wizard for details about using the

NMC New Device Wizard with the

NetWorker OpenVMS storage node.

ECO-2 corrects the case inconsistency in these logical name definitions.

6 OpenVMS ECO Readme

Table 2 – Changes made in V18.1 ECO-1

Reference

Number

Description

General Starting with ECO-1 NetWorker has begun to take advantage of improvements within the OpenVMS operating system and available TCPIP networking software.

WW205 Although rare, certain tape media or positioning errors can be ignored during read resulting in an incomplete recovery or cloning operation. In both cases, the error is unnoticed.

For cloning operations this can result in an unrecoverable, incomplete new save set copy that is incorrectly marked as complete and browsable in the Media database potentially leading to data loss. See DTA 546707 .

WW199 Automatic configuration of tape devices and medium changers does not work. The devices are discovered, but it is still necessary to manually configure these devices with the jbconfig device configuration program.

WW198 Several enhancements and bug fixes were provided for the jbverify utility program.

Resolution

Refer to Legacy OpenVMS Versions and

TCPIP Network I/O for details about

changes in the way NetWorker supports legacy versions of OpenVMS.

This problem is corrected in ECO-1.

This problem is corrected in ECO-1. For

more information see Automatic Device

Configuration .

These problems are corrected in ECO-1.

For more information see Jbverify

Enhancements and Corrections .

These problems are corrected in ECO-1.

For more information see Changes for

BTL Mapping of Fibre Channel Devices .

WW197

WW195

WW190

WW188

Fibre Channel device identification. The underlying device database layer in NetWorker on OpenVMS incorrectly identified some fibre channel tape and media devices, leading to various issues such as the inability to automatically detect jukeboxes or tape drives and inconsistent device locking across cluster members for shared devices. This primarily affected both dvdetect and jbconfig.

WW195 Various miscellaneous issues with dvdetect, including update sequence errors. These issues prevented automatic device discovery for both Parallel SCSI and FC based devices. The usual workaround was to re-run jbconfig on the affected storage node.

WW194

WW189

Unnecessarily long timeouts when sensing tape drive capabilities in dvdetect, jbedit, and jbconfig. For these and similar programs, sensing tape drive information might have required a long time and eventually fail with a medium offline error. The long timeout and eventual error message were unnecessary since in these cases, it does not matter whether the tape drive has a volume mounted.

These problems are corrected in ECO-1.

These problems are corrected in ECO-1.

OpenVMS ECO Readme 7

WW186 High CPU and I/O overhead in the nsrexecd when a monitored daemon (such as nsrsnmd) is stopped by

STOP/ID or similar means on OpenVMS.

WW185 Inability to create File or Advanced File devices using

NetWorker server V19.0 or newer. As of V19 of the

NetWorker server, it became very difficult to impossible to create a file or an AdvFile device on the OpenVMS storage node through the NMC. The specific difficulties depend on the version of the NetWorker server (V19.1 through V19.4 all exhibit different specific errors; but none work correctly). Existing devices created with an earlier version of the NetWorker server (Prior to V19.0) are not affected.

WW184 Previous versions of the NetWorker recover program on

OpenVMS did not support the -b option to recover from a specified pool or list of pools.

WW183 Database module saves (Oracle or Oracle/Rdb) were incapable of storing the save level within the media database. All saves were hardcoded with a level of full.

WW182 Recover ACCVIO while adding alias files for recover, such as on a system disk. The following is an example of the types of messages displayed: recover> add recover_usr:

`/DISK$TST:[000000]/DIR1/DIR2/FILE.TXT;1 ’ @ Tue

Jul 23 09:48:25 2019 (dev DISK$TST:, FID 566 8 0) has a different fid than recover_usr: `/ALTDIR/FILE.TXT;1 ’ @ Tue Jul 23

09:48:25 2019 (dev , FID 566 8 0).

A subsequent add or recover command generates the

ACCVIO. Careful reading of the message shows that the second file name shows no device name. The second file name may be corrupted in some way other than shown here. It is possible to work around this problem by adding files in a different order or adding files in smaller groups and restoring the groups.

WW179 The edit command within the nsradmin program fails with an RMS-F-SYN, file specification syntax error, as shown below: nsradmin> edit type: NSRLA

%EDT-F-OPENIN, error opening /tmp/.580913479.

%EDT-F-OPENIN, error opening

/tmp/.580913479.00000a as input

This problem is corrected in ECO-1.

The ECO-1 release contains a workaround for this issue. For more

information, see Creating File and

Advanced File Devices .

This feature is included in ECO-1. For

more information, see Recover -b

Enhancement .

This problem is corrected in ECO-1. For

more information, see CHAPTER 4 Multi-

Level Backup for Database Modules .

This problem is corrected in ECO-1.

This problem is corrected in ECO-1.

8 OpenVMS ECO Readme

-RMS-F-SYN, file specification syntax error

WW178 When exiting, nsrwatch displays a CMA-F-EXIT_THREAD register dump. This should not occur but is not harmful.

WW174

WW173

Minor enhancements to informational messages for save when an invalid backup device is specified (e.g., an offline device) and for informational messages in response to

NMC Wizard features that are not implemented on

OpenVMS.

WW172 Reverse name lookup errors with the nsrsnmd daemon using the MultiNet TPCIP stack. The MultiNet implementation of getnameinfo does not provide all the expected information for nonservice-based ports.

WW166 Pre and post commands do not work through the Apps and Modules panel on the NMC.

This problem is corrected in ECO-1.

This problem is corrected in ECO-1.

The ECO-1 release contains a workaround to accommodate the missing information on the MultiNet platform.

The ECO-1 release contains and updated implementation of pre- and postprocessing. For more information, see

Pre and Post Command Support .

OpenVMS ECO Readme 9

CHAPTER 2 NetWorker for OpenVMS V18.1

ECO-2 Details

This chapter provides details about the changes in NetWorker for OpenVMS V18.1 as mentioned

in Table 1 – Changes for ECO-2.

AFTD Device Creation Wizard

To use the NMC New Device Creation Wizard dialog for creating AFTD devices on the OpenVMS storage node, you must specify the device access information manually and with the correct syntax to satisfy both the expectations of the Wizard and the OpenVMS storage node.

In general, use a UNIX-like syntax to specify the device and directory for the AFTD device. ECO-2 enhances the OpenVMS storage node so that it can properly process such a string into a valid device and directory specification on the OpenVMS system. The following walkthrough illustrates how to accomplish this task using an OpenVMS device and directory of DISK$STORAGE:[NW_AFTD] , which has a format of /DISK$STORAGE/NW_AFTD/ when used as a remote device path in the NMC

New Device Wizard:

1.

On the OpenVMS system, create an empty directory to house the AFTD storage. The

OpenVMS storage node software does not create this directory for you.

$ create/directory DISK$STORAGE:[NW_AFTD]

2.

Open the NMC, choose Devices, then New Device Wizard.

3.

Select Advanced File Type Device (AFTD) and click Next.

4.

Choose the OpenVMS storage node from the dropdown

5.

In the Browse or Manual group, select Manually enter local or remote device paths .

6.

Enter the remote device as follows and click Next: rd=nodename:/DISK$STORAGE/NWAFTD/ where, nodename represents a fully qualified DNS name of the OpenVMS system, such as mynode.domain.com.

7.

On the Configure Attributes tab, specify suitable values for NetWorker Device Name, comment, Target Sessions and Max sessions, or take the default values that are provided.

Click Next.

8.

On the Label and Mount Devices tab, choose the appropriate pool and click Next.

9.

Review the Configuration settings. If the settings shown are correct, press Configure.

Otherwise, press Back and change the incorrect selections.

10 OpenVMS ECO Readme

10.

The Check Results tab should show that the new AFTD device was successfully added. It will also be labeled if the label option (the default) was selected. If not, review the inputs, particularly the remote device path to ensure it follows the conventions used in this walkthrough.

11.

Click Finish

Remote Device Path Details

As mentioned in Creating File and Advanced File Devices from ECO-1, the strings allowed for

remote access paths within the NetWorker server software have become more restrictive over various release of NetWorker V19. Originally, native OpenVMS device and directory specifications could be used when specifying the path for File and AdvFile type devices. That is no longer true.

Instead, use a UNIX-style path when specifying remote access paths for File and AdvFile type devices.

Moreover, the original recommendation for path specifications in ECO-1 have been changed to accommodate the more restrictive remote path specifications allowed by the NMC New Device

Wizard. This ensures that AdvFile devices (in particular) can be created with either the New

Device Properties dialog or using the New Device Wizard within the NetWorker NMC

administrative interface. The new values are shown in Table 4 – How to Specify Remote File

Device Names and Device Access Information .

OpenVMS ECO Readme 11

CHAPTER 3 NetWorker for OpenVMS V18.1

ECO-1 Details

This chapter provides details about the changes in NetWorker for OpenVMS V18.1 ECO-1 as

mentioned in Table 2 – Changes made in V18.1 ECO-1 .

Legacy OpenVMS Versions and TCPIP Network I/O

The available features and capabilities of the networking software on OpenVMS platforms has improved dramatically across the operating system and TCPIP software releases that NetWorker supports. Starting with ECO-1 NetWorker has begun to take advantage of some of these improvements, which include support for network I/Os larger than 64Kb and support for 64-bit data buffers. To effect this change, the way NetWorker performs some types of transfers has been modified and now assumes capabilities that do not exist on older platforms. To continue to

support older platforms, feature select logical names have been added as shown in Table 3 –

TCPIP Feature Selection . For versions of OpenVMS V8.3 and newer, these logical names are not

necessary. But for older installations, particularly those prior to V8.2 these logical names ensure proper operation. In all cases, the OpenVMS version applies to both the Alpha and Integrity architectures, as appropriate.

12 OpenVMS ECO Readme

Table 3 – TCPIP Feature Selection

Logical Name Recommended Values OpenVMS Version

NSR$MAX_SOCKET_XFER 65024 V8.2 and earlier

Earlier versions of the operating system, and in some cases the TCPIP product limit the size of a socket read or write to 65535 bytes. TCPIP Services for OpenVMS V5.6 (and newer) and VSI TCPIP V10.6 and newer do not have this restriction. Consult the vendor documentation for your TCPIP stack to ensure socket I/Os can exceed this limit. If not, use this logical name to limit the maximum size of these transfers to the recommended value.

NSR$RPC_32BIT_BUF 1 V8.2 and earlier

Forces NetWorker to use 32-bit buffers for socket RPC communication. This avoids known problems with socket I/O using 64-bit buffers. Define this logical name to any value to force the use of 32-bit buffers.

The logical names in Table 3 should be defined system wide. Place these definitions in the

SYS$STARTUP:NSR$STARTUP.COM command procedure just below the optional definition of the

NSR$MAX_WRITESZ logical name as shown below:

$! If you are using the TCPware IP stack and you notice RPC errors when

$! transferring large files, please uncomment the line below (to define the

$! NSR$MAX_WRITESZ logical name as indicated).

$!

$! define/system/executive nsr$max_writesz 65024

$! define/system/executive nsr$max_socket_xfer 65024 ! as necessary

$! define/system/executive nsr$rpc_32bit_buf 1 ! as necessary

If the logical names are not defined when necessary, various errors with the recover program can occur. These errors include:

1.

Inability to establish a recover session with the NetWorker server after a timeout of approximately 1 minute.

2.

RCP errors during automatic or browser based recovery.

It may be necessary to run recover with debug logging to enable the error printouts. In the event of these types of errors, please perform the following steps and try the operation again:

1.

define the nsr$max_socket_xfer and nsr$rpc_32bit_buf logical names as shown above.

2.

Execute: @NSR$SYSTEM:NSR$STARTUP to restart the NetWorker software on the OpenVMS client.

OpenVMS ECO Readme 13

Automatic Device Configuration

Automatic configuration of fibre channel and parallel SCSI medium changer and tape devices has never been fully functional with the OpenVMS Storage Node. In all cases, devices are detected, but cannot be auto configured. The workaround has been to run jbconfig on the storage node to configure the devices. Numerous issues contribute to this behavior including:

1.

Several errors in dvdetect that prevent the medium changer auto configuration phase from

fully completing ( WW195 ).

2.

For Fibre Channel devices, the BTL mapping issue, Changes for BTL Mapping of Fibre

Channel Devices , prevents the automatic detection logic to discover FC tape devices.

3.

The device detection manager (ddmgr) service on the NetWorker server does not properly parse the to be configured devices field of the NSR Unconfigured Library resource. This problem makes it impossible for the ddmgr to associate the detected device names in the

NSR Storage Node resource with the unconfigured library. So, manual configuration is always required.

Starting with ECO-1, issues one and two on the OpenVMS storage node have been resolved and a workaround for issue three has been added. For the workaround, the BTL emulation layer now strips the terminating colon character from the physical device name. So, for example,

“$2$MGA1:” becomes “$2$MGA1”. This change bypasses the problem in the ddmgr and allows it to correctly match the discovered devices on the OpenVMS Storage Node with those reported in the unconfigured library resource. The new behavior is the default, so no user configuration is necessary to activate this workaround.

Though unlikely, it might be necessary in some cases to modify the RAP database with the nsradmin command to remove old or errant NSR unconfigured library resources and unconfigured device information from the associated NSR Storage Node

Resource. Consult with your Dell support specialist for assistance in this case. In most cases, simply installing the ECO and performing an auto-configuration is all that is necessary. Note that it is not necessary to re-configure existing libraries if they are currently working.

Jbverify Enhancements and Corrections

The version of jbverify included with the base V18.1 release:

1.

Does not support the new naming conventions required for File and Advance File type devices.

2.

Does not properly support scanning for Advanced File Devices on the OpenVMS file system.

3.

Has poor integration with the SCSI medium changer (NSR jukebox) interface.

14 OpenVMS ECO Readme

As a result, the validation of the NSR Jukebox, or any Advanced File type device was unreliable.

ECO-1 and later updates jbverify with:

1.

Changes for the device path names required by the NetWorker server V19 and newer.

2.

Enhancements when scanning for the existence of Advanced File Type device access paths.

3.

Fixes for the medium change device integration issues.

Jbverify still has the following known restrictions:

1.

Remote device validation is not supported. The -l (check local devices only) option is always in affect.

2.

The Tapeexercise utility is not provided nor supported. The -t (perform tapeexercise on tapes) option will fail because the tapeexercise utility is not provided.

3.

It is not possible to validate disabled devices. The -a (check all devices) option remains unimplemented.

Changes for BTL Mapping of Fibre Channel Devices

The OpenVMS Storage Node treats Parallel SCSI and Fibre Channel (FC) devices similarly to allow a common implementation for device discovery and to integrate smoothly with the NetWorker software device implementation. To accomplish this, backup devices on OpenVMS (tape and medium changers) are presented as simple devices with a SCSI Bus, Target, and LUN (BTL) designation.

Parallel SCSI devices are mapped to a bus based on the device controller letter, a target based on the unit number and a LUN based on the reported SCSI LUN value of the device itself.

Fibre Channel devices are also mapped to the BTL nomenclature. FC medium changer devices

(NSR jukebox) are assigned bus 29 and tape devices (NSR Device) are assigned bus 30. In both cases, the LUN value is always zero.

In earlier versions of the OpenVMS Storage Node software, the target value associated with a FC device was based on the order of enumeration from the $GETDVI system service. That meant that the same device could have different BTL designations over time as similar devices were removed or replaced (such as when a tape drive is added or removed from a library).

To make the BTL designations for FC devices more consistent, the algorithm for assigning the target value of FC devices has been changed. The new algorithm assigns the device unit number as the target . Thus, the BTL designation is just as consistent as the device names on the OpenVMS system.

Examples:

OpenVMS ECO Readme 15

1.

$2$MGA3: – This is a FC tape device ($2$MGA) with a unit number of 3. Within NetWorker the BTL designation is 30.3.0. If the device unit number changes for any reason, the BTL changes accordingly.

2.

$2$GGA0: -- This is a FC medium changer device ($2$GGA) with a unit number of 0. Within NetWorker the BTL designation is 29.0.0.

Note: the allocation class ($2$), device type (MG or GG), and controller letter (A) for

FC devices is constant. It is always $2$MGA for tape devices and $2$GGA for medium changer devices. Different devices of the same type are differentiated by unit number.

This change should have no effect in most environments. However, in some cases, it may be necessary to scan for devices from the NMC to reset any stale control port definitions for the medium changer.

Creating File and Advanced File Devices

Note: This section has been modified for ECO-2 to describe the more restrictive syntax for remote path specifications used when creating File and AdvFile type devices with the NMC administrative interfaces.

The NetWorker server releases V19 and newer are incompatible with the creation of File and

Advanced File type devices on the NetWorker for OpenVMS Storage Node. Starting with ECO-1, the NetWorker for OpenVMS Storage Node can accept a specially formatted path specification for remote File device names and for the Device Access Information field of Advanced File type devices. This path specification includes all the OpenVMS components that make up an OpenVMS directory specification (device name, and directory), but is formatted in a way that the

NetWorker server V19 and newer can support.

Syntax

The syntax for the path name is:

/disk/ dir{/subdir…}

Where,

• Braces, { }, indicate additional, optional subdirectories.

A leading slash, /, is required.

Disk is an OpenVMS disk device specification, such as DISK$USER1. Do not terminate the device name with a colon character, as that interferes with the interpretation of the remote path by the NMC.

Dir and subdir are the text portion of the OpenVMS directory string. The OpenVMS bracket, [], and period, ., delimiters are not supported.

A final directory slash, /, is not required but is accepted if present.

16 OpenVMS ECO Readme

A good rule-of-thumb when converting from a traditional OpenVMS directory specification is to start with an initial slash character then replace the OpenVMS device and directory delimiters with the slash character. So, for example, DUA1:[ABC.DEF] becomes /DUA1/ABC/DEF/. Additional examples are shown in the following table.

Table 4 – How to Specify Remote File Device Names and Device Access Information

OpenVMS Directory

DISK$USER1:[NW_DATA]

NW$ROOT:[STORAGE.FILE] 1

Remote File Device Name AdvFile

Device Access

Information rd=vmsnode:/disk$user1/nw_data/ /disk$user1/nw_data/ rd=vmsnode:/nw$root/storage/file/ /nw$root/storage/file/

1.

NW$ROOT is a rooted logical name defined in the following manner: define/translation=(concealed, terminal)/system NW$ROOT $1$DKA100:[NW.]

As indicated in Table 4 – How to Specify Remote File Device Names and Device Access

Information , the location in the NMC for this path is different for File type devices than for

AdvFile type devices. For File type devices, the directory path is part of the device name. It is specified in the Name property on the NMC Create Device dialog box. For Advanced File type devices, the directory path does not have to be part of the device name. It is specified within the

Device access information property. These differences are shown in the following figures.

Figure 1 – Creating a File Type Device

OpenVMS ECO Readme 17

Figure 2 – Creating an Advanced File Type Device

Limitations

The device path specification has the following limitations.

The directory specified must exist on the OpenVMS storage node machine prior to the device configuration steps on the NetWorker server. The directory must be available to the nsrsnmd service running on the storage node. By default, this service runs under the

OpenVMS NSR$EXECD account.

ODS-5 extended characters are not supported for any part of the directory specification.

Character case is ignored (case-insensitive processing is used).

Combining traditional OpenVMS syntax separators with the UNIX formatted path is not supported. For example: /DISK$USER1:/top.subdir.subdir2/ is not supported, nor is

/DISK$USER1:/[top.subdir.subdir2].

In general, system-wide logical names, such as a device logical device name (e.g.,

DISK$USER1) can be freely used as part of a full directory specification (e.g.,

/DISK$USER1/AFTD/STORAGE). Rooted logical names defined system-wide can be used (as

18 OpenVMS ECO Readme

shown in Table 4 ). However indiscriminate use of other logical name forms may lead to

unexpected behavior.

Additional UNC path specifications for the Advanced File Device access information field are not supported.

Recover -b Enhancement

Starting with ECO-1 the recover command supports the -b pools option. This option specifies the pool or pools that must be used when performing a recover. To specify multiple pools, specify the

-b option multiple times or provide a comma-separated list of pools with one use of the option.

Combining comma separated lists and multiple uses of -b is supported. If the exact file requested cannot be found within the pool list, then the file is skipped, and the recovery continues. If this option is unspecified then all pools are considered valid.

Pre and Post Command Support

Pre and Post commands supplied on the NMC, Apps and Modules panel did not work properly in the base V18.1 release. Pre and Post processing capability has been added with the following restrictions:

1.

The Pre and Post command procedure must be in the NSR$SYSTEM directory.

2.

The Pre and Post command procedure must begin with either “nsr” or “save” and have a

.COM file type. For example: NSRDISMOUNT.COM or SAVE_POST.COM.

3.

The Pre and Post command can have up to 8 parameters: For example: NSRMOUNT.COM

$1$DKA0 PROD, where $1$DKA0 and PROD are P1 and P2, respectively.

4.

In a cluster environment, the post command can be associated with individual clients or the cluster alias, but not both. For example, consider a cluster with two nodes. The cluster alias name is COOKIE, and the nodes are FUDGE and OREO. In this case a post command can be associated with OREO, FUDGE, or both, but not COOKIE; or a post command can be associated with COOKIE, but not with OREO or FUDGE.

5.

If a client is implemented more than once in a policy, only one post command can be associated with one of the clients.

OpenVMS ECO Readme 19

CHAPTER 4 Multi-Level Backup for Database

Modules

This chapter describes the changes to both Oracle and Oracle Rdb backups in the NetWorker for

OpenVMS V18.1 ECO-1 release.

Previous versions of the database modules supported level=full backups only though the media manager API. It was possible to perform incremental backups through modifications of the clientside scripts, but these backups were still marked as full backups within the media manager database.

Since both Oracle and Oracle Rdb support different backup types, such as full, incremental, and cumulative, similar changes were made for both Oracle and Oracle Rdb.

Overview

To support saving databases with different save levels (such as full and incremental) some changes were made to the integration of the OpenVMS database modules with NetWorker and with the database manager of choice. The changes are not extensive and are conceptually common to both Oracle and Oracle/Rdb database modules. They are:

1.

Ensure the client-side backup scripts have access to the backup level as specified by the

NetWorker server. This allows the backup script to make reliable determinations about the type of backup to perform.

2.

Make the backup level available to the database manager (through the NetWorker database module shareable images) and ensure that it is used when establishing the save session with the NetWorker server. This controls the level attribute associated with the media database record for the saveset.

Updated DCL and Oracle script files are provided as examples of how to perform different types of backup based on the backup level provided by the NetWorker server.

Operation

From a high level, scheduled database backups occur as follows:

1.

The NetWorker server starts the backup. It specifies several arguments for use by the client. Most importantly for this case are the program to start ( nsrnmostart or nsrrdbstart ), the saveset name, which indicates the DCL script to execute, and the save level.

20 OpenVMS ECO Readme

2.

The specified start program accesses the database backup script provided by the saveset name and invokes the appropriate database management software to back up the database: RMAN for Oracle databases or RMU for Rdb databases.

3.

Once the backup starts within the context of the database manager, it invokes (System

Backup Tape) SBT functions within the appropriate NetWorker shareable image

(LIBNWORA_SHR.EXE or LIBNWRDB_SHR.EXE). These shareable images are dynamically loaded by the database manager software. The logic in the shareable image acts as a pipe between the database backup stream and the NetWorker storage media and provides for similar indexing as is done for normal file system backups.

The remainder of this section provides a common operational overview. Separate sections follow with implementation specific detail and sample configurations.

Backup Schedule and Client-side Script Synchronization

For multilevel backups, the most critical relationship to configure correctly is that between the server-side schedule (and the backup levels that it may specify) and the client-side backup scripts that invoke the database backup commands through the client-side database manager.

The backup level specified by the NetWorker server must be appropriate for the database being backed up and synchronized with the client-side script that performs that backup. In other words, if the NetWorker server asks for a full backup, the script should perform a full backup. Conversely, the NetWorker server should not ask for a backup level that cannot be supported by the database. The requested backup level is controlled through the schedule associated with the workflow as defined on the NetWorker server. The actual backup level performed is controlled through the client-side DCL script that performs the backup. So, it is up to the DCL script to ensure that the correct backup command is issued based on the level provided by the NetWorker server.

Note that if a mismatch occurs between requested backup level and the script or database manager capabilities, the client-side backup script can control the disposition of the backup. By default, the templates provided will exit with an

OpenVMS failure status whenever the backup level is inappropriate.

There are minor differences between the Oracle and the Oracle Rdb implementations:

1.

RMAN supports full, incremental, and cumulative (level 1) backup levels. RMU supports full and incremental, but the incremental performed is a cumulative incremental.

Therefore, the Rdb template procedure treats incremental or cumulative (level 1) backup requests identically.

2.

The implementation of the database module for Oracle on OpenVMS has an extra level of indirection that does not occur with the implementation of the database module for Rdb.

OpenVMS ECO Readme 21

For Oracle (RMAN), two processes are started: nsrnmostart 1 and then nsrorabck , which executes the client-side RMAN script. For Rdb (RMU) only one process is started: nsrrdbstart , which executes the client-side DCL script.

3.

The client-side scripts are configured differently: a.

The Oracle DCL script references different RMAN scripts that perform the various levels of backup, full, incremental, or cumulative as requested by the NetWorker server. b.

The Rdb DCL script executes different RMU commands based on the backup level specified by the NetWorker server without referencing other scripts. So, it is somewhat less complex to configure.

If the type of backup requested by the NetWorker server is not synchronized with the type of backup performed, then the NetWorker media database will contain the wrong value for the level attribute associated with the backup saveset.

NetWorker Backup Levels

Starting with NetWorker V19.1, the NetWorker server no longer recognizes numerical backup levels, except for ‘1’, which is cumulative incremental. The backup levels available wi thin the NMC

and their applicability to the NetWorker database modules on OpenVMS are shown in Table 5 .

Table 5 – NetWorker Levels for Database Backup

Backup Level Specified on

NMC Schedule

Incremental

Cumulative incremental

Full

Skip

NSR_BACKUP_LEVEL Logical

Name Equivalence in the DCL

Script

"incr"

"1"

"full"

N/A

Database Module Behavior

Performs an incremental backup (all changed data since last backup).

Performs a cumulative incremental backup (all data since the last full backup).

Performs a full backup.

This level is processed entirely on the NetWorker server. It is not seen by the client side DCL script.

1 Some older implementations may have specified nsrorastart as the backup command in the client definition on the NetWorker server. Though recommended, it is not necessary to update these definitions to the newer nsrnmostart name because the OpenVMS installation provides both and they are functionally the same.

22 OpenVMS ECO Readme

Backup Level Specified on

NMC Schedule

Logs only

NSR_BACKUP_LEVEL Logical

Name Equivalence in the DCL

Script

"txnlog" (the DCL script is not invoked in this case)

Database Module Behavior

This value is not currently supported by the NetWorker

DB module on OpenVMS.

Database Module Templates

To make it easier to configure the client-side backup scripts, the NetWorker database modules include templates for the DCL and, in the case of Oracle, RMAN, scripts that perform the database backup. These templates illustrate how to configure multilevel backup for either database system. The examples are necessarily simple but provide enough guidance to illustrate how database backups can be configured.

The templates are in the NSR$SYSTEM directory after the installation of NetWorker with the database module option selected. They include:

1.

NSR$ORA_BACKUP_TEMPLATE.COM -- DCL command procedure that invokes one of three different RMAN scripts, depending on the value of the backup level. a.

NSR$ORA_ML_TEMPLATE_L0F.RCV – example full Oracle backup script. b.

NSR$ORA_ML_TEMPLATE_L1C.RCV – example cumulative incremental Oracle backup script. c.

NSR$OAR_ML_TEMPLATE_L1I.RCV – example incremental Oracle backup script.

2.

NSR$RDB_BACKUP_TEMPLATE.COM – DCL procedure to invoke the appropriate RMU command based on the value of the backup level.

Performing Multi-level Backups is Optional

Previous versions of the NetWorker for OpenVMS database modules were configured to perform full backups only. It is still possible to perform full backups all the time if that is preferred. To ensure full backups for each invocation, configure the software as follows:

1.

Ensure the backup level associated with the client and schedule within the NMC is always full.

2.

Configure the DCL script to perform the full backup action only.

Manual Backups

In general, manual database backups are not recommended because it can be difficult to determine the correct settings for several critical parameters. RMU requires all such parameters be specified as logical names prior to its invocation. RMAN has the capability to transfer

OpenVMS ECO Readme 23

parameter settings via its send command to channels allocated for use with the NetWorker SBT library. Refer to the Dell EMC NetWorker OpenVMS Version Administration Guide and the template DCL scripts provided with the NetWorker Module for database backups for more information.

24 OpenVMS ECO Readme

NetWorker Module for Oracle Rdb – Configuration

To configure the NetWorker Module for Oracle Rdb, you must create an Rdb backup script on the

OpenVMS client. This script specifies the RMU commands that will be used to back up the Oracle

Rdb database. The NetWorker Module for Oracle Rdb provides a template Rdb backup script that you can modify for use at your site.

The Oracle Rdb software does not provide a method of generating unique backup file names. Therefore, the script you use for Rdb backups must create unique file names for each backup attempt. The template script uses a date and time scheme to ensure that each backup has a unique file name. If you write your own backup script, ensure that it generates unique save set names as well.

DCL Script Configuration

To configure the client-side script, make a copy of the template,

NSR$SYSTEM:NSR$RDB_BACKUP_TEMPLATE.COM and edit it to suit your needs. The script is heavily commented and provides guidance about how to configure the backup operation.

In summary, the script operation begins by sampling the value of the NSR_BACKUP_LEVEL logical name. It then selects one of two RMU backup commands based on this value:

1. RMU/BACKUP/LIBRARIAN – to perform a full backup

2. RMU/BACKUP/INCREMENTAL/LIBRARIAN – to perform an incremental backup.

Once the command is selected, a unique file name is generated, and the backup is performed.

The script also allows for pre- and post- processing activities. These can be simple one- or twoline commands or they can invoke complex scripts. It is important that any such script return a valid OpenVMS status code so that the backup script can make the proper decision about continuing the backup or returning an error status to NetWorker. See the script itself for details about pre- and post- processing.

The DCL script template assumes an RDB version of V7.3. Please double check that the execution of the SYS$LIBRARY:RDB$SETVER command within the script is appropriate for your version of Rdb.

To configure the script, you need to provide the name of the database to backup. In addition, you may want to modify the default value for the BACKUP_NAME symbol.

1.

DATABASE_NAME – this symbol should specify the name of the database to be backed up.

For example: “DISK$DB:[RDB_FILES]PERSONNEL”

OpenVMS ECO Readme 25

2.

BACKUP_NAME – this symbol provides a prefix for the unique file name generated by the script for the backup. The default value is “RDB_DB”. Within the template script, this generates a backup name of the form: “RDB_ DB_YYYY-MMDD_hhmmss”. Rdb appends the file extension “.RBF” to this backup name. So, as an example, the final name as stored within NetWorker, could be RDB_DB_2020-10-15_175658.RBF.

The BACKUP_NAME field can be exploited to provide more nuanced file naming. As coded in the template file it merely provides a prefix to the final name generated for the RMU backup. But it is easy to modify. One possibility is to provide the actual or mnemonic name of the database being backed up, and whether the backup is a FULL or INCREMENTAL type. This can enhance the ability to filter a large list of names when using nsrinfo and can be helpful during a restore operation.

Backup Levels

The BACKUP_LEVEL symbol within the DCL backup script is set to the requested backup level from the NetWorker server. For proper operation with Rdb, this value should be full, incremental, or

cumulative as specified on the NMC. This level is expressed as a string value as shown in Table 5 –

NetWorker Levels for Database Backup . The default error handling for values other than

incremental, full, or cumulative incremental is to fail the backup with a FATAL OpenVMS error code (SS$_BADPARAM, bad parameter value). The error and message are posted to the details pane for the backup on the NMC.

Because an Oracle Rdb Incremental backup is cumulative, the default DCL backup script template treats incremental or cumulative levels identically and performs an Rdb Incremental command.

26 OpenVMS ECO Readme

Example: Restoring Rdb Backups

The following example provides guidance on how to restore an Rdb database using the

NetWorker Module for Oracle Rdb. The sample performs a restore using a full and then incremental backup. The methodology is similar when restoring a single full database backup except that only a single restore is required.

Because the Oracle Rdb incremental backups are cumulative, there are never more than two possible backups to restore. The full and the desired incremental backup based on the recovery objective. For example, assume a schedule with a full backup every Sunday and incremental backups on Monday through Saturday. To restore the database to Wednesday’s backup, restore the full backup from the previous Sunday and then the Wednesday incremental.

The following example assumes that a client-side DCL script, called NSR$RDB_73.COM has been configured. This script is identical to the provided template script except that the

DATABASE_NAME symbol has been filled in with the name of the database; in this case,

$1$DGA64:[RDB73_DATABASE]MF_PERSONNEL. In addition, the example assumes that a workflow with an appropriate schedule has been configured for the Rdb database backup client and associated with a Policy on the NetWorker server, and that the user has executed the

NSR$SYSTEM:NSR$LOGIN.COM command procedure. Minimally:

The client specifies the NSR$RDB_73.COM procedure as the save set.

The client backup command is nsrrdbstart.

The schedule associated with the workflow in which the client resides specifies incremental and full back up levels only. In the sample case, the schedule is weekly with full backups on Sunday and incremental backups at all other times. Note that this is the same as the default schedule provided with the Application workflow.

Performing a Full then Incremental Rdb Database Backup

Once configured, it is easy to start a scheduled backup on the NMC. Select Protection, expand policies to the policy containing the sample workflow, then select the workflow. Right-click on the workflow and select Start. This starts the backup using the backup level specified by the schedule associated with the workflow. By overriding the backup level for the current date in the schedule, it is possible to perform a full backup on a day that is normally incremental or an incremental backup on a day that is normally full.

The example performs a full backup, followed shortly thereafter by an incremental backup. This provides the two backups.

Correlating nsrinfo and mminfo Information

To perform the restore, the file names associated with the full backup and incremental backup are required. These names are available via the nsrinfo command. In addition, the mminfo command can provide detail about the backups, including the save level, the volume and backup time.

OpenVMS ECO Readme 27

The information from the media and client indexes is also available through the NMC under the Media tab. The Client Indexes option provides the information shown here by the nsrinfo command and the Save Sets option provides the information shown here by the mminfo command.

For the simple backup and restore in this example, using mminfo is not necessary because nsrinfo provides enough information to determine which files to restore, based on backup time and the size of the backup. But for the sake of completeness, the example correlates output of mminfo and nsrinfo, which might be desired for more complex scenarios.

The following shows the output for mminfo and nsrinfo for the example. The mminfo query has selected only backups from 10/22/2020 11:30 for the client associated with the backup created with the expected saveset name. It also specifies a custom report rather than the default. This limits the output to those savesets of interest and provides the information necessary to correlate with the nsrinfo output.

$ nsrmminfo s svr “ otR” -c clnt t “10/22/2020 11:30” “ N”“NSR$RDB_73.COM” –

_$ r”volume,level,savetime(18),nsavetime,sumsize,ssid”

Volume lvl date time save time size ssid

S01187L3 incr 10/22/20

S01187L3 incr 10/22/20

S01187L3 incr 10/22/20

S01187L3 full 10/22/20

12:41:42

12:14:11

11:44:22

11:40:27

1603392102 347 KB

1603390451 347 KB

1603388662 347 KB

1603388427 883 KB

3348222678

3364998227

3381773560

3398550644

As can be seen from the mminfo display, the most recent full backup has an exact save time of

1603388427 and the most recent incremental has an exact save time of 1603392102. To find the file names associated with these records, use the nsrinfo command:

$ nsrmminfo -s svr -v -n oracle t “1603388427” clnt scanning c lient `clnt’ for savetime 1603388427(10/22/20 11:40:27) from the oracle namespace on server svr

UNIX file `RDB_DB_2020-1022_114026.RBF’, NSR size=903572, (unknown fid), file size=0

1 objects found

$ nsrmminfo -s svr -v -n oracle t “1603392102” clnt scan ning client `clnt’ for savetime 1603392102(10/22/20 12:41:42) from the oracle namespace on server svr

UNIX file `RDB_DB_2020-1022_124140.RBF’, NSR size=355084, (unknown fid), file size=0

1 objects found

Performing the Restore

Based on the file names provided by the nsrinfo command, use RMU to restore the full backup from RDB_DB_2020-10-22_114026.RBF and the subsequent incremental backup from

RDB_DB_2020-10-22_124140.RBF. For this example, the original database is dropped and then restored.

28 OpenVMS ECO Readme

The RMU commands issued in the example are specific to the example database.

Review the BACKUP and RESTORE commands from the Oracle Rdb for OpenVMS

Oracle RMU Reference Manual for details.

-- First delete the existing database --

$ SQL$

SQL> DROP DATABASE FILENAME ‘$1$DGA64:[RDB73_DATABASE]MF_PERSONNEL’;

SQL> EXIT

-- Restore the database from the FULL backup –

$ RMU/RESTORE/LIBRARIAN/NOCDD/NOAFTER/LOG/DIRECTORY=$1$DGA64:[RDB73_DATABASE]

RDB_DB_2020-10-22_114026.RBF

%RMU-I-RESTXT_00, Restored root file $1$DGA64:[RDB73_DATABASE]MF_PERSONNEL.RDB;1

%RMU-I-RESTXT_21, Starting full restore of storage area (RDB$SYSTEM)

$1$DGA64:[RDB73_DATABASE]MF_PERS_DEFAULT.RDA;1 at dd-mmm-yyyy hh:mm:ss.cc

. . .

%RMU-I-COMPLETED, RESTORE operation completed at dd-mmm-yyyy hh:mm:ss.cc

-- Restore the incremental backup --

$ RMU/RESTORE/LIBRARIAN/NOCDD/LOG/INCREMENTAL/DIRECTORY=$1$DGA64:[RDB73_DATABASE]

RDB_DB_2020-10-22_124140.RBF

$1$DGA64:[RDB73_DATABASE]MF_PERSONNEL.RDB;1, restore incrementally? [N]:Y

%RMU-I-RESTXT_00, Restored root file $1$DGA64:[RDB73_DATABASE]MF_PERSONNEL.RDB;1

%RMU-I-RESTXT_22, Starting incremental restore of storage area (RDB$SYSTEM)

$1$DGA64:[RDB73_DATABASE]MF_PERS_DEFAULT.RDA;1 at dd-mmm-yyyy hh:mm:ss.cc

. . .

%RMU-I-COMPLETED, RESTORE operation completed at dd-mmm.yyyy hh:mm:ss.cc

At this point the database has been restored.

Troubleshooting Tips

The logical name RMU$DEBUG_SBT can be used for RMU commands to generate debug tracing messages for backup, restore, and query operations using the /LIBRARIAN qualifier. Define it system wide if parallel operations are performed so that each process has access to the logical name.

The DUMP/BACKUP command can be used to verify a backup without performing a restore. For example:

RMU/DUMP/BACKUP/LIBRARIAN/OPTIONS=NORMAL/EXIT_ERROR <filename>

Where, <filename> is the file name (such as RDB_DB_2020-10-22_124140.RBF) as stored within

NetWorker.

OpenVMS ECO Readme 29

NetWorker Module for Oracle – Configuration

To configure the NetWorker Module for Oracle, you must create between 2 and 4 client-side scripts based on the templates provided. The number of scripts to complete depends on the strategy for backup and restore since each backup level supported requires a different RMAN script. The NetWorker Module for Oracle provides templates for all scripts to make their creation easier.

The template script files are preconfigured for an incremental backup strategy. Thus, the RMAN script templates include various forms of the BACKUP INCREMENTAL command. This does not mean that such a strategy is required. If the schedule selected for backup always specifies a full backup, then only full backups occur. The RMAN script appropriate for the specified backup level can be changed so that it does not use the BACKUP INCREMENTAL command and instead uses the normal BACKUP command, avoiding the incremental strategy altogether. Refer to the Oracle®

Database Backup and Recovery User’s Guide for more information about selecting a backup strategy for the Oracle Database.

Script Configuration

To configure the client-side DCL script, make a copy of the template,

NSR$SYSTEM:NSR$ORA_BACKUP_TEMPLATE.COM and edit it to suit your needs. The script is heavily commented and provides guidance about how to configure the backup operation.

By default, the NetWorker software expects all the scripts (DCL and RCV) to exist in

NSR$SYSTEM. To override the default, specify the full file specification for the DCL script in the saveset attribute for the client on the NetWorker server. In addition, ensure the RMAN script files are present in the same directory as the DCL script.

In summary, the script operation begins by sampling the value of the NSR_BACKUP_LEVEL logical name. Then, based upon that value, selects one of three possible RMAN scripts to associate with the backup operation. Within the template DCL script, one of the following is selected:

1.

NSR$ORA_ML_TEMPLATE_L0F.RCV – selected for full backups. This script executes an

Oracle incremental Level 0 backup.

2.

NSR$ORA_ML_TEMPLATE_L1I.RCV – selected for incremental. This script executes an

Oracle Incremental Level 1 backup.

3.

NSR$ORA_ML_TEMPLATE_L1C.RCV – selected for cumulative backups. This script executes an Oracle Incremental Level 1, Cumulative backup.

Once the script is selected, NetWorker executes the RMAN command(s) contained within it.

Most of the symbols within the DCL script are optional. However, the following symbols are required:

1.

ORACLE_HOME – the location of the Oracle Server installation.

30 OpenVMS ECO Readme

Configuring RMAN Scripts

As mentioned previously, there are three template scripts provided in NSR$SYSTEM:

1.

NSR$ORA_ML_TEMPLATE_L0F.RCV

2.

NSR$ORA_ML_TEMPLATE_L1C.RCV

3.

NSR$ORA_ML_TEMPLATE_L1I.RCV

The last three characters of the name encode the purpose of the script. L0F means Level 0 full backup, L1C means level 1 cumulative backup, and L1I means level 1 incremental backup. The naming convention is not required but makes the purpose of each script more obvious. The template scripts are functionally the same except for the different backup commands. To configure these scripts, copy them to a name of your choice (ensuring that the names you use are the same as specified in the DCL script configured earlier). Add the necessary identifiers and passwords for the connect statements and modify the specifics of the backup command to suit the needs of the environment.

Backup Levels

2.

NSR_RMAN_SCRIPT – this is the RMAN script to be executed by the backup operation. The

DCL script template assigns this value based on the value of the NSR_BACKUP_LEVEL logical name.

Some additional symbol definitions are often desirable:

3.

NSR_ORA_USER – this is an OpenVMS user account that should be used to execute the

RMAN command. If unspecified, NetWorker executes the RMAN commands using the

NSR$EXECD account. However, in most cases, these commands require special access rights or permissions that might not be associated with the NSR$EXECD account. Note that if used, the NSR_ORA_USER account needs to have at least the same permissions as the

NSR$EXECD account. Alternatively, NSR$SYSTEM:NSRORABCK.EXE can be installed with the necessary privileges. NetWorker starts the backup script using the specified user account.

4.

NSR_ORA_SCRIPT_OUTPUT – this is a fully specified file specification used to capture all output from the execution of the RMAN script. This can be very useful when troubleshooting configuration or run time issues.

The BACKUP_LEVEL symbol within the DCL backup script is set to the requested backup level from the NetWorker server. For proper operation, this backup level should be full, incremental, or

cumulative as specified on the NMC. This level is expressed as a string value as shown in Table 5 –

NetWorker Levels for Database Backup . The default error handling for values other than

incremental, full, or cumulative is to fail the backup with a FATAL OpenVMS error code

(SS$_BADPARAM, bad parameter value). The error and message are posted to the details pane for the backup on the NMC.

OpenVMS ECO Readme 31

Example: Restoring Oracle Backups

Whether you use an incremental strategy or not, restoring the oracle database is done in the same way. When restoring incremental backups, RMAN uses the level 0 backup as the starting point, then updates changed blocks based on level 1 backups where possible to avoid reapplying changes from redo one at a time. Recovering with incremental backups requires no additional effort on your part. If incremental backups are available, then RMAN uses them during recovery.

The following show an example of an interactive database restore using RMAN. This restore is based on a sample database using the template DCL and RMAN scripts provided in NSR$SYSTEM.

The example assumes that the necessary Oracle environment has been setup for the user process using the ORAUSER command procedure. The commands needed in your environment may be significantly different. User input is shown in bold font. Some output has been omitted for brevity.

$ rman target sys/pw@connect-id catalog usr/pw@connect-id

Recovery Manager: Release 11.2.0.4.0 – Production on Day Mon dd hh:mm:ss yyyy

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: EXAMPLE (DBID=1745065308) connected to recovery catalog database

RMAN> shutdown database closed database dismounted

Oracle instance shut down

RMAN> startup mount connected to target database (not started)

Oracle instance started database mounted

RMAN> run

2> {

3> allocate channel t1 type 'sbt_tape'

4> PARMS='SBT_LIBRARY=NSR$SYSTEM:LIBNWORA_SHR.EXE';

5> send "'NSR_ENV=(NSR_CLIENT=CLNT,NSR_SERVER=SVR)'";

6> restore database;

7> recover database;

8> sql 'alter database open';

9> release channel t1;

10> } allocated channel: t1 channel t1: SID=134 device type=SBT_TAPE channel t1: EMC NetWorker Module for Oracle v18.1.0 sent command to channel: t1

Starting restore at dd-MMM-yy channel t1: starting datafile backup set restore channel t1: specifying datafile(s) to restore from backup set

32 OpenVMS ECO Readme

... channel t1: restore complete, elapsed time: hh:mm:ss

Finished restore at dd-MMM-yy

Starting recover at dd-MMM-yy channel t1: starting incremental datafile backup set restore channel t1: specifying datafile(s) to restore from backup set

... channel t1: restore complete, elapsed time: hh:mm:ss starting media recovery media recovery complete, elapsed time: hh:mm:ss

Finished recover at dd-mmm-yy sql statement: alter database open released channel: t1

RMAN> exit

Recovery Manager complete.

OpenVMS ECO Readme 33

PART 2: ECO Installation and Verification

The DELL EMC NetWorker for OpenVMS V18.1 software is provided as a full layered product release (base release) with subsequent maintenance releases provided as Engineering Change

Order (ECO) kits.

34 OpenVMS ECO Readme

CHAPTER 5 Installing an ECO Package

This chapter briefly describes downloading, validating, and installing the software.

When installing ECOs, it is only necessary to install the latest one. All ECOs are cumulative and include the changes in any previous ECO. So, it is not necessary to install intervening ECOs.

Similarly, it is not possible to install an ECO package on its own since it depends on elements in the base release. Therefore, ECO installation must be preceded by the installation of the base release.

Download and Validation

Use the following procedure to download and validate the software:

1.

Connect to the OpenVMS system and download the desired NetWorker for OpenVMS package from https://www.dell.com/support/home/en-us/productsupport/product/networker-for-openvms/drivers . There are separate packages for Alpha and Integrity systems.

A link to the SHA256 checksum value for the download appears when the down-arrow next to the Download button is expanded. The checksum helps ensure the software has been downloaded completely and without modification as shown below. Please make a note of this value for use later in this procedure.

2.

If not already done, start SSL or SSL1 by typing one of the following commands on the

OpenVMS system: a.

To start SSL: @SYS$STARTUP:SSL$STARTUP.COM

. b.

To start SSL1: @SYS$STARTUP:SSL1$STARTUP.COM

.

3.

If not already done, define the openssl command symbols as follows: a.

For SSL: @SSL$COM:SSL$UTILS.COM

b.

For SSL1: @SSL1$COM:SSL1$UTILS.COM

4.

Validate the integrity of the downloaded package by typing the following command and comparing the output to the checksum value saved from Step 1.

For the Integrity package:

$ openssl dgst -sha256 LGTO-I64VMS-SNCLNT181_ECO1-V1801-0-4.EXE;1

OpenVMS ECO Readme 35

SHA256(LGTO-I64VMS-SNCLNT181_ECO1-V1801-0-4.EXE;1)=

637d92ca18db140fb1b55bd52831249dba7812fff9e46447b8c20431edc77e07

For the Alpha package:

$ openssl dgst -sha256 LGTO-AXPVMS-SNCLNT181_ECO1-V1801-0-4.EXE;1

SHA256(LGTO-AXPVMS-SNCLNT181_ECO1-V1801-0-4.EXE;1)= a08d3b2ba1eeb60a28c433ef4703d611dbec74771861064e8c2dd341b5637673

Note: the checksums shown in these examples may not match the checksums associated with the actual packages downloaded. Please use the checksum value from the website download page for package verification.

5.

Run the downloaded package to expand it, providing the PRODUCT installation files, as shown below:

For the Integrity package:

$ RUN LGTO-I64VMS-SNCLNT181_ECO1-V1801-0-4.EXE

UnZipSFX 5.42 of 14 January 2001, by Info-ZIP ([email protected]).

inflating: lgto-i64vms-snclnt181_eco1-v1801-0-4.pcsi

inflating: lgto-i64vms-snclnt181_eco1-v1801-0-4.pcsi_vnc

For the Alpha package:

$ run LGTO-AXPVMS-SNCLNT181_ECO1-V1801-0-4.EXE

Archive: nw$resd:[v1801_eco01.kit]lgto-axpvms-snclnt181_eco1-v1801-0-4.exe;1

inflating: lgto-axpvms-snclnt181_eco1-v1801-0-4.pcsi

inflating: lgto-axpvms-snclnt181_eco1-v1801-0-4.pcsi_vnc

Once the ECO package is fully expanded, it can be installed with the OpenVMS PRODUCT command.

Installing the ECO Package

To install the ECO, you must first have installed the base software release for V18.1. That package is LGTO-I64VMS-SNCLNT-V1801-0-1 or LGTO-AXPVMS-SNCLNT-V1801-0-1 , depending on platform. You can verify that the base release is installed as follows:

$ product show product snclnt

------------------------------------ ----------- ---------

PRODUCT KIT TYPE STATE

------------------------------------ ----------- ---------

LGTO I64VMS SNCLNT V18.1-0 Full LP Installed

------------------------------------ ----------- ---------

If the base V18.1-0 release is not installed, you must acquire that package and install it before you can install the ECO.

Once the base software release is installed, use the PRODUCT command to install the downloaded and inflated ECO package, which is LGTO-I64VMS-SNCLNT181_ECO1-V1801-0-4.PCSI

or LGTO-AXPVMS-SNCLNT181_ECO1-V1801-0-4.PCSI

, depending on platform.

36 OpenVMS ECO Readme

Example Installation

The following provides a brief example of ECO package installation. See the OpenVMS documentation for more information about the PRODUCT command. For more information about the installation and configuration of NetWorker on OpenVMS, see the NetWorker Release 18.1

OpenVMS Installation Guide available on https://www.dell.com/support .

This example assumes the PCSI and PCSI_VNC files from the downloaded package are in the user's current directory. The Alpha package is used in this example. The directions and installation for the Integrity package are identical except for the difference in the package names.

1.

Ensure the base product is installed:

$ product show product snclnt

------------------------------------ ----------- ---------

PRODUCT KIT TYPE STATE

------------------------------------ ----------- ---------

LGTO AXPVMS SNCLNT V18.1-0 Full LP Installed

------------------------------------ ----------- ---------

2.

Install the ECO:

$ product install snclnt181_eco1

Performing product kit validation of signed kits ...

%PCSI-I-VSIVALPASSED, validation of nw$resd:[v1801_eco01.kit]lgto-axpvmssnclnt181_eco1-v1801-0-4.pcsi;1 succeeded

The following product has been selected:

LGTO AXPVMS SNCLNT181_ECO1 V18.1-0 Patch (remedial update)

Do you want to continue? [YES] y

. . .

Answer the various questions to complete the installation.

3.

Verify the ECO is installed:

$ product show product snclnt/full

--------------------------- ----------- --------- -----------------------

PRODUCT KIT TYPE STATE MAINTENANCE

--------------------------- ----------- --------- -----------------------

LGTO AXPVMS SNCLNT V18.1-0 Full LP Installed LGTO AXPVMS SNCLNT181_ECO1

V18.1-0

The ECO is listed under the maintenance column of the full display.

OpenVMS ECO Readme 37

advertisement

Related manuals