backing up sap maxdb using networker › content › dam › dell-emc › ... · this paper is...

BACKING UP SAP MAXDB

USING NETWORKERMichael DickPrincipal Solutions Architect

Backup and Recovery Systems

Dell [email protected]

Updated October 2016

2013 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Introduction ..................................................................................................................... 4

History of SAP MaxDB .................................................................................................... 5

Uses Of SAP MaxDB ...................................................................................................... 5

Ways to back up SAP MaxDB ......................................................................................... 6

Using NetWorker to back up SAP MaxDB ....................................................................... 7

Creating the Backup Templates .................................................................................... 11

Configuring SAP MaxDB backups on Linux using NetWorker ....................................... 15

Configuring SAP MaxDB backups on Windows using NetWorker.................................. 17

Configuring multiple backup streams ............................................................................. 18

Backing up SAP MaxDB using NetWorker 8.x and 9.x .................................................. 21

Scheduled backups of SAP MaxDB using NetWorker 8.0 ......................................... 24

Scheduled backups of SAP MaxDB using NetWorker 9.0 ......................................... 27

Restoring SAP MaxDB using NetWorker ....................................................................... 29

Troubleshooting MaxDB backups .................................................................................. 38

Appendix A – Parameter Reference .............................................................................. 39

NSR_HOME .............................................................................................................. 39

NSR_HOST ............................................................................................................... 39

NSR_POOL ............................................................................................................... 39

NSR_EXPIRE ........................................................................................................... 39


NSR_NOTVERBOSE ................................................................................................ 40

NSR_USEOUTPUT ................................................................................................... 40

NSR_IGNOREERROR .............................................................................................. 41

NSR_EBIDTYPE ....................................................................................................... 41

NSR_SAVEINTERVAL .............................................................................................. 41

NSR_BACKUPNAME ................................................................................................ 41

NSR_AVOIDPSSIDBUG ........................................................................................... 42

NSR_AVOIDPSSIDBUG ........................................................................................... 42

NSR_SAVETIMEFORMAT ........................................................................................ 42

NSR_SIZEROUNDUP ............................................................................................... 44

NSR_AVOIDTIMEBUG ............................................................................................. 44

NSR_CLIENT ............................................................................................................ 44

NSR_USECLIENTFOR ............................................................................................. 45

References .................................................................................................................... 46

Biography ...................................................................................................................... 46

Disclaimer: The views, processes or methodologies published in this article are those of

the authors. They do not necessarily reflect Dell EMC’s views, processes or

methodologies.


Introduction

This paper is intended as a guide to backing up SAP MaxDB using Networker 8 and 9. It

is not intended to be an introduction or administrative guide to MaxDB or SQL

programming. For a detailed discussion of MaxDB administration and tuning please go

to maxdb.sap.com


History of SAP MaxDB

SAP MaxDB started in 1977 as a research project at the Technical University (TU) in

Berlin and was initially named RDS. Between 1977 and 1997, what is now known as

SAP MaxDB, underwent many name changes. It was known as Reflex DDB/4 and

ADABAS D during the time it was owned by Nixdorf Computer AG (Siemens Nixdorf

Information Systems AG and Software AG). In 1993, this research database, now

named ADABAS D started shipping with SAP R/3. In 1997, SAP AG took over ADABAS

D and renamed it ADABAS D for SAP R/3. In 2003, SAP AG and MySQL joined in a

partnership and rebranded the database to MaxDB. In 2007, this reselling agreement

was terminated. SAP AG is now managing the development, sales, and support of the

SAP MaxDB database system.

Uses Of SAP MaxDB

What makes SAP MaxDB so interesting is that MaxDB runs fully in memory; only

security-related changes require access to the disk drives. This, of course, makes

MaxDB very fast. While MaxDB can be used to run complete SAP instances, it is mainly

used for LifeCache. LifeCache combines the advantages of main-memory based data

retention with a complete operating concept, which includes backup and recovery.


Ways to back up SAP MaxDB

There are two primary ways to back up MaxDB; with the internal backup tool and with a

third party tool such as NetWorker®. Using the internal tool, we can create a backup on

either a file type device (mostly local to the DB server) or a tape device. Both

approaches have obvious disadvantages. The disadvantages with the file type device

are that it is stored on expensive disk and, in order to have offsite copies, must be

backed up again with a backup application. The disadvantage of tape is, besides the

known disadvantages of tape, that it creates a backup server out of a database server.

Using a third party application will back up MaxDB directly to a backup device,

eliminating these disadvantages. The backup server can then clone copies for offsite

storage without impacting the database system. The third party tool used in this article is

NetWorker (version 8 and version 9) while the MaxDB version referred to is 7.9. The

procedures outlined here are only valid for MaxDB versions 7.5 and higher. Figure 1

shows the command and data flow for a MaxDB backup using NetWorker as third party

backup tool.

Figure 1

MaxDB Kernet DBM Server

Backup Tool Client (NSR

save)

Backup Tool Server

Component

Data Store Backup Device

Database Manager CLI

Start backup by calling savepnpc

savepnpc is calling dbmcli

dbmcli is calling the database manager

with start_backup <template_name>

Backup History

Data is send via named

pipes to the client site of

the backuptool

client sends backup data to

server

MaxDB Database Server

Backup Server


Using NetWorker to back up SAP MaxDB

While the internal MaxDB backup tool is quite nice, it lacks the ability to schedule full and

incremental backups. This is where NetWorker comes into the picture. Log file backups

can be automated using the Automatic Log Backup function of SAP MaxDB. Using this

function, we can choose to backup log files when the segment is full (default behavior),

or backup log files at certain time intervals. These log file backups can then be written to

NetWorker through a backup template. Using the automated log backup feature

simplifies the taking of log backups.

The following section will explain how to set up MaxDB backups to write to EMC

NetWorker. It is only a small step to automate the backups, once we are able to write to

NetWorker using SAP MaxDB Database Studio or command line.

The backup configuration using NetWorker requires that backup environment

parameters be set. The default locations for the configuration files differs by operating

system and is shown in the configuration section specific to these operating systems. A

non-default location for the configuration file can specified by setting the variable

NSR_ENV to this location using dbmcli. The command syntax for setting the setting

NSR_ENV is

dbmcli –d <db_name> -n <server_name> -u <user>,<password> dbm_configset –raw NSR_ENV

<absolute_path>

The configuration file informs the database manager where NetWorker is located and

how to address it.

Table 1 shows the variables recognized in the configuration file and a short description.

An explanation of each of the variables with their complete syntax can be found in

Appendix A.


Variable Description

NSR_HOME Absolute path of the directory where the NetWorker

binaries are installed. This parameter is mandatory.

NSR_HOST NetWorker server host name. This parameter is

mandatory.

NSR_POOL Pool to save the MaxDB backups. This parameter is

mandatory.

NSR_EXPIRE This parameter overwrites the expiration on the client with

the expiration given. This value is optional.

NSR_NOTVERBOSE By default, the NetWorker programs are started with the –v

(verbose) option. This parameter is used to turn off this

default behavior. This parameter is optional.

NSR_USEOUTPUT By default, the output of the NetWorker save program is

used to check for errors. This variable turns this behavior

off and only the return code of save is checked. Use this

parameter with caution as save can produce a 0 return

code even if an error occurred. This parameter is optional.

NSR_IGNOREERROR Ignores error messages from the pipe. The form of these

error messages is pipe_name:error_message. Repeat this

parameter for each error to be ignored. This parameter is

optional.

NSR_EBIDTYPE Determines how backups are identified. By default,

backups are identified by their backup time (NSAVETIME).

With this parameter, backups can be identified by their

SSID. This parameter is optional.

NSR_SAVEINTERVAL Wait time in seconds between 2 save calls in a parallel


backup. The default value is 10. This parameter is optional.

NSR_AVOIDPSSIDBUG A bug exists in NetWorker 6.0 and up, causing an error

when mminfo –q pssid=0 is used. Use this parameter to

avoid this error. By default, mminfo is called with –q

pssid=0. This parameter is optional (do some research on

this and impact of this value).

NSR_SAVETIMEFORMAT Sets the savetime format. This parameter is required in

cases where the current default value does not correspond

to the NetWorker output. This parameter is optional.

NSR_SIZEROUNDUP This parameter is required in cases where the size

transferred by the NetWorker save program is rounded

down for the backup. This parameter is optional.

NSR_AVOIDTIMEBUG This parameter is necessary in cases where mminfo does

not work without the –t option. It is database version-

specific and can only be used for the following MaxDB

versions as of the specified build numbers:

7.2.05 from Build 018




This parameter is optional.

NSR_CLIENT Name of NetWorker client. This name must match the

client configured in NetWorker. This parameter is optional.

NSR_USECLIENTFOR This parameter decides what the NSR_Client parameter is

used for. It can either be mminfo (default) or save and


mminfo. This parameter is optional.

NSR_BACKUPNAME The name of the backup. Can contain placeholders such

as <database_name> and/or <node>. This value is

optional.

NSR_AVOIDVSSBUG Mandatory with MaxDB on Windows and NetWorker 8.1.1

and up. Set to “WITHOUT DOUBLE QUOTES”

Table 1


Creating the Backup Templates

The first step is to create the necessary backup templates within the MaxDB Database

Studio. The examples in this paper use a Linux version of the Database Studio.

However, the Windows version of the Database studio is similar. One of the major

differences between Linux and Windows is the way these operating systems handle

named pipes. In Linux, a named pipe is a special file that can be created and destroyed

anywhere in the filesystem (i.e.: /backup/some-pipe). On Windows, however, a named

pipe uses a pseudo filesystem that needs to be referenced (i.e.: \\.\pipe\some-pipe).

After installing the Database Studio into the default location on Linux, the binary can be

found under /opt/sdb/DataBaseStudio/. Start the Database Studio by typing

/opt/sdb/DataBaseStudio/dbstudio. If this is the first time you start the Database Studio,

you must import the database you want to back up into your database landscape. This is

beyond the scope of this paper. Please consult the SAP MaxDB Administration Guide for

the necessary steps.


After the Database Studio has been opened, right click on the instance on MaxDB you

want to back up and choose Administration Tasks -> Backup.


Choose for which type of backup you want to create a template. The types shown are

Complete Data Backup, Incremental Data Backup and Log Backup.

Click on next and choose to either create (new), edit or copy a template.


Fill out the name of the backup device, change device type to Pipe and choose

NetWorker as the backup tool. Lastly, specify the Pipe location and Pipe name as

<location>/<pipe_name>. If the MaxDB database runs on a Windows server, the pipe

location is \\.\pipe\<pipe_name>. Make sure that the pipe file does NOT exist, as the

backup will fail if the pipe file exists. Click on OK and click on OK.

The example above shows a pipe create for Linux. We are now ready to run a full

backup of MaxDB using NetWorker as a third-party backup tool. Please be aware that a

backup taken with a certain pipe name MUST be restored from the same pipe name. To

create templates for incremental or log file backups, use the same procedure choosing

incremental or log file backup. Due to the fact that a restore has to occur out of the same

pipe name the backup occurred, it is a good idea to just use one pipe name, for example

nsrpipe, for all backups. If parallel templates or backup groups for parallel processing

where setup, use a naming scheme like nsrpipe1, nsrpipe2, and so on.


Configuring SAP MaxDB backups on Linux using NetWorker

This section outlines the steps necessary to configure a backup of SAP MaxDB to

NetWorker if MaxDB is running on a Linux server. The steps in order are:

Create a directory for the required pipe. This is somewhat optional, as the pipe can be

created anywhere one chooses. It is, however, good form to not create a pipe in /. In any

case, this directory must have read, write and execute permissions for the user running

the database. Not having these permissions for the user running the database will result

in an access denied error. The default user created during the install is sdb, the default

group created is sdba. Do NOT create a file with the name of the pipe in its subdirectory

as this will also result in

an error (see section on Troubleshooting MaxDB backups) The named pipe will be

created and deleted dynamically during the backup process. The example below will use

/backup as the sub directory for the pipes.

mkdir /backup

chown sdb /backup

chgrp sdba /backup

chmod 700 /backup

The last line is to restrict access to this directory to the database user.

Create the environment file and populate with the required and optional parameters. The

default location for this environment file on Linux is /nsr/sapdb and the default name of

this file is env. The screenshot below shows an example environment file for NetWorker.

For a complete discussion of all parameters see Appendix A.


Configuring SAP MaxDB backups on Windows using NetWorker

This section outlines the general configuration steps to back up SAP MaxDB if MaxDB is

running on a Windows server. The default location of the required configuration file on

Windows is c:\Program Files\nsr\sapdb. The name of the configuration file is env. This

location and name can be changed using dbmcli config_set.

Please note that the extended client package is required to back up MaxDB with

NetWorker 9. As with Linux, we must create an environment file and populate with the

required and optional parameters. The screenshot below shows an example of an

environment file created for a MaxDB installation running on Windows 2012 and using

NetWorker 9.0.1.


Configuring multiple backup streams

Sometimes, when we have a very large database, or when the time to complete a

backup is of the essence, it is necessary to configure multiple streams in a backup job.

There are 2 ways of doing this. First, one can configure a parallel backup template. This

parallel template can then be used in the same the way a single stream template can be

used. To create a parallel backup template, right click the database, choose

Administration Tasks -> Backup. Choose the backup level (Complete Data Backup,

Incremental Data Backup or Log Backup). Click on New and choose New Parallel

Backup Template.

Set the appropriate template properties.


Click on OK to create the template. One can now use this template in the dbmcli

command to run parallel backups.

Second, one can use dbmcli to create a backup group with more than one pipe

assigned. The group name created will then replace the template name in the dbmcli

backup command. The screenshots below show the creation of a backup group

NSRBackup with 4 associated pipes.


The screenshot below shows the result of this operation.

One can now use the name NSRBackup in the dbmcli backup command which gets

called from savepnpc or the pre-script.


Backing up SAP MaxDB using NetWorker 8.x and 9.x

This section will explain how to manually back up MaxDB using the Database Studio and

NetWorker 8.x as well as NetWorker 9.x as the backup tool. Right click on the database

to be backed up and choose backup. Choose the backup template we have created to

back up MaxDB to NetWorker and click next.

The summary screen will appear and we are now ready for the backup. Click on Start to

begin the backup process.


The results window will be shown after the backup is done.


To check on the backup, we can look into the SAP MaxDB administration window and

choose the Backup tab. All known backups will be shown here, ordered by date.


Scheduled backups of SAP MaxDB using NetWorker 8.0

We can also use NetWorker itself to schedule a backup of a MaxDB database. To do

this, we will be using savepnpc to call dbmcli with the created templates to back up the

data to NetWorker. In order to set up scheduled backup with NetWorker, we need to

create a client definition and a NetWorker group. The save set in the client definition

should specify a short file such as /etc/hosts or /etc/resolv.conf. This is necessary

because even though we use savepnpc as the backup command, the definition requires

a save set.

put savepnpc into the backup command field.


The next step in setting up a savepnpc backup is to create the required resource file.

The name of this file corresponds to the group name that is being run. In our example,

we have 2 groups; MaxDB_Full and MaxDB_Logs. The resource file name must

therefore be /nsr/res/MaxDB_Full.res and MaxDB_Logs.res, respectively. These

resource files contain pre and post commands as well as other optional variables.

Please consult the NetWorker Administrators Guide and the NetWorker Command

Reference Guide for a complete discussion on savepnpc.


Now we can schedule the relevant groups in NetWorker to backup MaxDB.

We can now check for the existence of backups with either the NetWorker Administrator

GUI or with the use of mminfo. The screenshot below shows an mminfo output of some

MaxDB backups


Scheduled backups of SAP MaxDB using NetWorker 9.0

There are differences in configuring scheduled backups between NetWorker 8.x and

NetWorker 9.x. NetWorker 9.x has discontinued the savepnpc program which we used in

the SAP MaxDB backup automation with NetWorker 8.x. One must now use save with a

pre script to call the MaxDB backup command. For a more in-depth discussion on the

differences in how savepnpc and pre/post scripts work, consult the NetWorker Admin

and Command Reference guides. The environment file is the same as in NetWorker 8.0.

The only real difference is that we do not have a res file named according to the group,

but that we are using a pre script in the client definition. This pre script must be in a

location which is in the searchpath (/usr/sbin on linux, C:\Program Files\EMC

NetWorker\nsr\bin on Windows). The screenshot below shows a simple script on

Windows.

One could add some code to provide some log output as well.

Once the script is in place, it is a sample matter of creating a client definition with a pre

script.


As the saveset cannot be blank, we just point it to an empty file. In Apps & Modules, we

specify the appropriate pre command

We can now add this client to a policy and run scheduled backups using NetWorker 9.


Restoring SAP MaxDB using NetWorker

The MaxDB Database Studio is used to restore the backed up data from NetWorker.

Because of this, it does not matter if the backup was created in NetWorker 8.x or

NetWorker 9.x. In order to start the restore, open the Database Studio, right click on the

Database name, and choose Administration -> Restore. This will open the restore

wizard.


In the next window, choose the recovery type. The choices are to recover the last

backup, to recover a specific backup and to recover to a specific point in time (PIT).

Recover a medium does not play a big role in our case, as everything is written to the

same medium (that is the same backup name we have chosen). In our case this is either

DBFullBackup or DBLogBackup. However, under most circumstances, one would

choose either Recover Last Backup, Recover specific backup and/or recover a specific

point in time

The window below shows the screen if we choose to recover a specific backup. The

latest backup is checked by default, but we can choose to recover from any of the known

backups. You will notice that only full backups are shown here.


We can choose to recover to a specific point in time by checking the “Recover Until”

checkbox. This will automatically restore the appropriate full backup and apply the

appropriate redo logs to roll the database forward to the desired point in time.

After choosing the recover method, we can see the summary screen. The summary

screen below is for a point in time restore as we can see by the inclusion of the log

backups


If we do not choose to do a point in time restore, we will see a summary screen like the

one below


We can see the difference is that the point in time restore automatically chooses the

appropriate full backup and log backups to roll the database forward to the specific point

in time. We can now start the recovery by clicking on the Start button.

The screenshot below shows the successful completion of a recovery (Non-point in

time).


Here we have a point in time restore, waiting to continue with restoring the appropriate

redo logs.

After clicking Continue, the appropriate log files will be recovered and applied, and the

database will be restarted.


The database is now ready for use after the recovery.


Troubleshooting MaxDB backups

There are some log files we can look at should the backup or restore fail. Most of the log

files can be viewed in one of two ways, namely with the Database Manager and via

command line.

The following log files may be important if a backup or recovery to or from a external

backup tool fails. All relevant logs are stored in the rundirectory of the database. (default

on Linux/Unix: /var/opt/sdb/globaldata/wrk/<SID>).

The log files are:

dbm.prt

The database manager log file. This log file contains the backup and recovery calls, and

if an error occurred, the error message(s).

dbm.ebp

The External Backup Protocol log file. This file is created with each action of a supported

backup tool and overwritten whenever the database manager starts. It contains

configuration values, calls to the database kernel, return codes and output of the backup

tools.

dbm.ebl

The External Backup Tool Log file. This file contains a summary of the last <n>

dbm.ebp log files. The number <n> can be configured with the DBM parameter

DBM_EBLSIZE.

dbm.ebf

This file contains the External Backup History (backup ID’s, external backup ID’s, etc).

This file is not overwritten, so all backup history can be found in this file.

KnlMsg

The database kernel messages file. This file can be important if the cause of a backup or

restore failure is NOT the external backup tool, but rather the actual data processing by

the database kernel.


Appendix A – Parameter Reference

Explanation of configuration variables used.

NSR_HOME

This parameter specifies where the NetWorker binaries are stored on the NetWorker

client (MaxDB server) host.

Syntax

NSR_HOME <Absolute_Path_To_NSR_Binaries>

NSR_HOST

This parameter specifies the hostname of the NetWorker server to be used to store the

backups.

Syntax

NSR_HOST <Networker_Server_Name>

NSR_POOL

Specifies the NetWorker pool to be used.

Syntax

NSR_POOL <Networker_Pool_Name>

NSR_EXPIRE

This parameter overwrites the saveset expiry date configured on the client. The

expiration date is passed to the save process (-e) and must be in the nsr_getdate()

format. (See NetWorker Command Reference Guide for more information on the

nsr_getdate() format).


Syntax

NSR_EXPIRE <character_string>

<character_string> :: =

tod hh:[mm:[ss]] | [hhmm] [AM|PM] [zone]

date mm/dd/[yy] or monthname dd [,yy]

day day_of_week

relative time [number] unit

Example

NSR_EXPIRE month

NSR_NOTVERBOSE

By default, the NetWorker programs save and recover are started with the verbose (-v)

option. This parameter is used to control this behavior.

Syntax

NSR_NOTVERBOSE <option>

<option> :: = NONE | SAVE | RECOVER | “SAVE AND RECOVER”

NSR_USEOUTPUT

The parameter specifies if the out of the NetWorker save program is checked for error

messages. By default this parameter is set to check for error messages (value: SAVE). If

set to NONE, only the return code (0 or non-0) of save is used to determine if a backup

was successful. Since save can return 0 in case of error, it is recommended not to use a

value of NONE.

Syntax

NSR_USEOUTPUT <option>

<option> :: = SAVE | NONE


NSR_IGNOREERROR

Specifies the error messages of save to be ignored. All error messages specified in form

<pipe_name>:<Error_Text> are ignored. Repeat this parameter for each error message

to be ignored.

Syntax

NSR_IGNOREERROR <string>

Example

NSR_IGNOREERROR “ using unlocked access”

NSR_EBIDTYPE

This parameter identifies whether the Database Manager uses NetWorker backup time

or NetWorker Save Set Identifiers for restore. The default is to use backup times for

restores, since this does not require elevated access on the operating system (recover –

S <ssid> requires administrator level access).

Syntax

NSR_EBIDTYPE <option>

<option> :: = NSAVETIME | SID

NSR_SAVEINTERVAL

Wait time in seconds between 2 save calls during parallel backups.

Syntax

NSR_SAVEINTERVAL <time_in_seconds>

NSR_BACKUPNAME

This is the name under which the backup should be saved. NSR_BACKUPNAME

honors the placeholders <database_name> and <node>.


Syntax

NSR_BACKUPNAME <name>

<name> ::= [[ASCII][<database_name>][<node>]]

Example:

NSR_BACKUPNAME DB-Backup_of_<database_name>_on_<node>

NSR_AVOIDPSSIDBUG

As of NSR 6.x, a known software bug exists when using mminfo –q pssid=0. This

parameter is to avoid this bug. The default value is NO.

Syntax

NSR_AVOIDPSSIDBUG <option>

<option> ::= NO | YES | “WITHOUT DOUBLE QUOTES”

NSR_AVOIDPSSIDBUG

Turns off VSS processing of backups done through a pipe. If set, the system inserts the

option –o “VSS:*=off” into the parameter list.

Syntax

NSR_AVOIDVSSBUG “WITHOUT DOUBLE QUOTES”

NSR_SAVETIMEFORMAT

This parameter specifies the savetime format for analyzing the output of mminfo. This

parameter is required for cases where the current default value does not correspond to

the NetWorker output. Default values are mm/dd/yy HH:MM:SS AM: for NSR outputs

that are 8 characters long and mm/dd/yyyy HH:MM:SS AM: for NSR outputs that are 10

characters long. Only one format can be configured, and this format can differ from the

default value provided that the specific syntax elements are used.


Syntax

NSR_SAVETIMEFORMAT <format>

<format> ::=

[<separator_definition><separator>]<datetime_format>[<separator><AM_definition>][<separator>

<PM_definition>]

<separator_definition> :: = SEPARATOR=<new_separator>

<new_separator> ::= sign that does not occur in <date_time_format>, <AM_definition> and

<PM_definition>

<separator> :: = when <separator_definition> is missing, the comma sign (','), otherwise

<new_separator>

<datetime_format> :: = { <year> | <month> | <day> | <hour> | <minute> | <second> | <AM> |

<PM> [<datetime_separator>] }

<datetime_separator> :: = any character, except y, m, d, H, M, S, a, A, p, P

<year> :: = yy | yyyym <month> :: = mm <day> :: = dd <hour> :: = HH <minute> :: = MM

<second> :: = SS <AM> :: = am | AM | a.m. | A.M. <PM> :: = pm | PM | p.m. | P.M.

<AM_definition> :: = AM=<local_AM_string>

<local_AM_string> :: = string in any order without the sign <separator>

<PM_definition> :: = PM=<local_PM_string>

<local_PM_string> :: = string in any order without the sign <separator>


NSR_SIZEROUNDUP

This parameter specifies how the size specification for backups is transferred within the

NetWorker save program. It is necessary for cases where the size transported by the

NetWorker save program is rounded down. The default value is NOROUNDUP. Using

FIRSTDECIMAL increases the size specification by 0.1. Using Normal increases the

size specification by 0.5. Using LASTINTEGER increases the size specification by 1.

Syntax

NSR_SIZEROUNDUP <value>

<value> ::= NOROUNDUP | FIRSTDECIMAL | NORMAL | LASTINTEGER

Example We have a backup of 14.1GB, but want to continue to use 14GB as the backup size.

NSR_SIZEROUNDUP FIRSTDECIMAL

NSR_AVOIDTIMEBUG

This parameter is necessary for cases where the NetWorker mminfo program does not

work without the –t option. Please note that this parameter can only be used for specific

MaxDB database versions.

Syntax

NSR_AVOIDTIMEBUG <value>

<value> ::= string in nsr_getdate(3) format

NSR_CLIENT

Client name which is used by the Database Manager when calling the NetWorker

programs mminfo and/or save. How the NSR_CLIENT name is used by the Database

Manager is determined with the value of the Parameter NSR_USECLIENTFOR.


Syntax

NSR_CLIENT <client_name>

<client_name> ::= valid name of Networker client

NSR_USECLIENTFOR

Determines how the value selected for NSR_CLIENT is to be used. Default value is

MMINFO, which uses the value of NSR_CLIENT for the NetWorker mminfo program

only.

Syntax

NSR_USECLIENTFOR <value>

<value> ::= MMINFO | “SAVE and MMINFO


References

1. MaxDB Administration online manual at www.maxdb.sap.com

2. SAP MaxDB Expert Session presentation – External Backup Tools by Melanie

Handreck and Heike Gursch

3. MaxDB Database Administration (version 7.6/7.7)

4. MaxDB history at en.wikipedia.org

Biography

Michael Dick is a Principal Solutions Architect with the Backup and Recovery Systems

Division of Dell EMC. Michael has 15 years experience with Linux and UNIX systems

administration and tuning, as well as experience with TCP/IP networking across LAN’s

and WAN’s and SAN’s in complex environments.

Michael’s specialty is the design and implementation of Backup and Recovery systems

in large-scale enterprise environments.

Dell EMC believes the information in this publication is accurate as of its publication

date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” DELL EMC

MAKES NO RESPRESENTATIONS 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 EMC software described in this publication

requires an applicable software license.

Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries.

http://www.maxdb.sap.com/

backing up sap maxdb using networker › content › dam › dell-emc › ... · this paper is...

Documents