3COM Database Adapter Module User Manual

NSR-ORA V3.2

Database Adapter Module for NetWorker

Edition October 2001

Delivery subject to availability; right of technical modifications reserved. All hardware and software names used are trademarks of their respective manufacturers. This manual was produced by

cognitas. Gesellschaft für Technik-Dokumentation mbH www.cognitas.de

1 Preface

This guide provides information about how to install, configure and operate the “NetWorker Save and Restore for ORAcle (NSR-ORA)” V3.2 NetWorker component.

1.1 Audience

The information in this guide is intended for system and database administrators.

1.2 Conventions

This manual uses the following typographical conventions and symbols to make information easier to access and understand.

boldface Indicates emphasized words, e.g.:

Using Oracle 8 be always careful for every instance being offline or online!

fixed-width Examples and information displayed on the screen, win-

dow titles, names of buttons, menues, fields for input or output, scroll lists. For example:

Click on the Cancel button to close the Help window.

fixed width, boldface

italic Directory pathnames, names of files, parameters, com-

System Administrator’s Guide U42252-J-Z915-1-76

Commands, text and other input you type exactly as shown, e.g.:

sh> start_amon.sh start ora

mands and machines, or new terms defined in the glossary or within the chapter, e.g.:

The SQLDBA parameter contains the pathname of sqldba, svrmgrl or sqlplus.

This Symbol is used to indicate and cautionary notes that e.g. prevent you form making a mistake

This Symbol indicates important information.

Preface What is New in Release 3.2

1.3 What is New in Release 3.2

With release V3.2 a number of changes have been made to NSR-ORA, influencing this guide:

● NSR-ORA V3.2 does now support Oracle 8.x or 9i

● Version 9 of the Oracle database does not include the SVRMGRL command

any more. So NSR-ORA now uses the command stored in the SQLDBA variable to communicate with the database. However, functionality of NSR-ORA has not been changed.

● NSR-ORA V3.2 now supports the backup on Network Attached Storage

filers (NAS filers) by NetworkAppliance

(NetApp). Furthermore NetWorker supports backups performed directly onto a NetApp filer by using snapshots (for further information see chapter “Using NSR-ORA with NetApp Filers”).

● The configure_nsrora configuration skript provides some new parameters,

described in section “Configuration” .

● The NetWorker V6.0 software provided by Fujitsu Siemens Computers now

comes with two new algorithms for compression. Using these new compression modes causes in part a considerable improvement of compression rates and simultaneously reduces CPU load. This feature is only supported bei Fujitsu Siemens Computers NetWorker for Solaris and LINUX.

1.4 Update from Previous Releases

If you want to update NSR-ORA from a previous release you will find the necessary information in section “How to Proceed for an Update from an Earlier

Version” .

System Administrator’s Guide U42252-J-Z915-1-76

2 Introduction

This guide to Backing up and Restoring a Database describes the functionality, installation, configuration and adminstration of the NetWorker component “NetWorker S nent allows to integrate ORACLE databases into the Networker data backup concept.

NetWorker is intended for automatic data backup in heterogeneous networks. Among its advantages are the large number of supported backup media and simple user prompting in spite of the wide range of functions. However, the backup of database files with NetWorker is only possible offline. Where a database needs to be recovered, NetWorker can restore the faulty files and return the database to a consistent, updated status, although additional steps need to be performed with ORACLE tools.

NSR-ORA closes the gap between NetWorker and ORACLE as it can communicate with both of them. It can be used to back up ORACLE databases online or offline. Backup is possible in normal and compressed modes. Whether the database is located in a Unix file system or on raw devices is immaterial. When using NetApp NAS filers the database can be backed up on tapes and also as a snapshot on the NAS filer directly. The database (thus also NSR-ORA) and the NetWorker server need not be installed on the same computer; database backup is also possible from NetWorker clients.

NSR-ORA enables you to initiate the recovery of an inconsistent database to a specific second automatically. NSR-ORA automatically checks the status of the database and commences the required restore and recovery measures to restore the current status. This means that you can perform a database recovery at any time even without any knowledge of ORACLE (you will find further information about recovery in the chapter “Recovery”).

ave and Restore for ORAcle (NSR-ORA)” V3.2. This software compo-

For a better understanding of the database interface, the fundamental ORACLE database terms are described briefly below:

● The physical database structure

● The logical database structure

● The database backup

● Archive mode of the database.

System Administrator’s Guide U42252-J-Z915-1-76

Introduction The Physical Database Structure

2.1 The Physical Database Structure

The physical database (see figure 1) consists of at least one control file, one parameter file, at least two redolog files and at least one database file.

control file

redolog files

configuration file

database file

Figure 1: The physical database structure

● The database file(s) contain the data dictionary as well as the actual user

data (tables, indices, views etc.).

● The redolog files contain information on database recovery. They instantly

record any change made regarding the database. A database always possesses at least two redolog files which are written cyclically.

● The control file(s) contain structural and management information.

● In the configuration file specifies the configuration of a database.

A database also possesses suitable programs (executables), which ensure its functionality and form the Database Management System (DBMS).

2.2 The Logical Database Structure

At the logical level (see figure 2), ORACLE only recognizes tablespaces (database-specific, user-defined and temporary) consisting of at least one physical database file. This tablespace structure also constitutes a backup unit for NSRORA. The allocation between tablespaces and the corresponding files is performed by NSR-ORA.

System Administrator’s Guide U42252-J-Z915-1-76

Introduction The Database Backup

database files

control file

SYSTEM

Figure 2: Logical database structure

USER

Tablespaces

TEMP

redolog files

2.3 The Database Backup

Every recovery procedure depends on a correctly performed database backup, which consists of copies of the database files being made at operating system level and transferred to an external storage medium or created as a NAS snapshot. These copies depict a state that is not identical to the current one.

In the case of one or more database files being lost, the backup copies serve as the starting time for a required recovery. During any recovery, all redolog files accruing since the backup are reapplied, thus updating from the backup to the current status.

2.4 Archive Mode of the Database

To ensure that all the redolog files accruing since the backup are available, the database must be operated in ARCHIVELOG mode, which makes sure that redolog files are not overwritten unless they have first been archived on a separate disk area (archive directory) by ORACLE’s archiving function (see

figure 3).

System Administrator’s Guide U42252-J-Z915-1-76

Introduction Archive Mode of the Database

NSR-ORA checks that the database is in ARCHIVELOG mode, and will abort the backup of the database if this is not the case if an online backup is to be carried out. An offline backup can be performed even if the database is not in ARCHIVELOG mode.

2.5 Function Scope

Physical faults that bring normal database operation to a halt basically fall into the following four categories:

● loss of a (all) control file(s)

● loss of a current online redolog file

● loss of files containing system data

● loss of files containing user data.

As a rule, the loss of a control file does not pose major problems because the control file can be mirrored at the software level using the control_files parameter in the ORACLE parameter file init<ORACLE_SID>.ora. ORACLE strongly recommends saving at least two copies of the control file on different disks. We agree with this recommendation.

The loss of a current online redolog file is also precluded almost completely by mirroring (at the software level by ORACLE or at the hardware level by mirror disks).

For this reason, neither of these fault categories (loss of the control file

and loss of current online redolog files) is taken into account during an

automatic recovery of the database. Only in recovery until time with ora_recut is the relevant control file also recovered. Nor is NSR-ORA in a

position to recognize or correct logical database errors (for instance, if incorrect files are loaded into the database).

The ORACLE Administrator Guide explains what you can do if you should lose the control file and/or a number of redolog files. You can also refer to the chapter

“Recovery” of this manual, which describes the restrictions that apply to

automatic recovery for ORACLE Parallel Server (OPS) systems.

In the other two cases (loss of files containing system or user data), NSR-ORA offers various ways of recovering the data: fully automatic or manual recovery or restore of a specific database level (recovery until time).

System Administrator’s Guide U42252-J-Z915-1-76

3 The individual Components

The individual components for backing up and recovering an ORACLE database in a NetWorker environment are described in the following section. Four different areas are dealt with:

● The archiving monitor

● The backup component

● The recovery component

● The overall configuration

Each section starts with a functional description. This is followed by an explanation of the required configuration steps, after which the procedure and operations are illustrated with the help of practical examples. Two configuration tools are provided for your convenience: configure_nsrora and configure_networker.

The installation and configuration of NSR-ORA and the two configuration tools are dealt with in chapter “Installation and Configuration”. We recommend you to read through chapter “Introduction” before you start carrying out the installation and configuration described in chapter “Installation and Configuration”.

3.1 The Archiving Monitor

During the operation of an ORACLE database, the online redolog files are archived by the database system in an archive directory to protect the database from data losses. For this, the database must be in ARCHIVELOG mode (“Automatic archival ENABLED”). However, the database system is not responsible for the subsequent management of the offline redolog files created in this manner. If the archive directory becomes full, your database will come to a halt. This administrative gap is bridged by the archiving monitor (amon) (see figure 4).

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Archiving Monitor

DBMS

database files

control file

SYSTEM

USER

Tablespaces

Database interface NSR-ORA

Volume management

Volume pool management

Multiplexing

Jukebox support

TEMP

Archiving

monitor

Oracle’s

archiving

process

redolog files

Treshold

value

3.1.1 Starting and Ending the Archiving Monitor

A control program start_amon.sh is provided in the directory ${NSR_INST}/oracle/bin for coordinating the activities of the archiving monitor. This program can be invoked at operating system level with the relevant parameters (start, status, stop).

start_amon.sh [-t {nsr|emc}] <command> [<ORACLE_SID> ...]

The -t option is required if NSR-ORA (nsr) and NSR-ORA-EMC (emc) are installed on one machine, so that it is possible to distinguish which archiving monitor is to be started.

If ORACLE_SID is not specified, the environment variable $ORACLE_SID is evaluated. If this variable is not set, amon is started for all configured ORACLE instances; otherwise only for the specified ORACLE_SIDs.

The following commands are available:

start Starts the archiving monitor stop Stops the archiving monitor status Status inquiry

The start command is used to start the archiving monitor. This requires the database to be in ARCHIVELOG mode.

The configuration file dbo${ORACLE_SID}.init is then read out and the archiving monitor (amon daemon) is started. All important events are recorded in a protocol file located in the directory ${DBO_CONFIG_DIRECTORY}/prot.

The stop command deactivates the archiving monitor.

The status check status shows, among other things, the following information:

● the time the archiving monitor is activated

● the database to be monitored

● the archive directory

● the maximum number of offline redolog files

● the current number of offline redolog files

Example:

The following entries are assumed in the configuration file in this example:

NSR_SERVER=psi DBO_CONFIG_DIRECTORY=/nsr/oracle/ora

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Archiving Monitor

AMON_GROUP=amon_ora_psi AMON_MAX_LOGS=4 AMON_INTERVALL=1800 AMON_MIRROR_GROUP=amon2_ora_psi AMON_MIRROR_SERVER=psi

With these prerequisites fulfilled, the user can start the archiving monitor:

sh> start_amon.sh start ora ORACLE_SIDs : ora start amon for oracle instance ora ...

A subsequent status enquiry generates the following output:

# start_amon.sh status ora ORACLE_SIDs : ora Configuration and Status summary of amon at 15.09.00 (11:30:41): System : psi Database : ora Networker Server : psi Save Group : amon_ora_psi Mirror Server : psi Mirror Group : amon2_ora_psi User : root Protocol File : /nsr/oracle/ora/prot/amon.prot Networker Directory : /opt/nsr Archive Directory : /home/oracle/dbs Archive Format : arch Interval (seconds) : 1800 Maximum # of Logs : 4 Actual # of Logs : 2 daemon is up since : 13.09.00 (15:15:00)

If the archiving monitor is inactive, the following display appears:

sh> start_amon.sh status ora amon is down at 14:46:54 on 13.09.00

If the functions of the archiving monitor are temporarily not required (e.g. if the database is shut down, a recovery is carried out, or a change is made to the archive directory), it can be deactivated:

sh> start_amon.sh stop ora ORACLE_SIDs : ora stop amon for oracle instance ora ...

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Archiving Monitor

3.1.2 Logging

While the archiving monitor is active, the occupancy level of the archive directory and other important events are logged at regular intervals (AMON_INTERVALL) in the protocol file

${DBO_CONFIG_DIRECTORY}/prot/redologs/amon.prot.

Protocol file

There are four generations of the protocol file. The current protocol file is appended to the file amon<sid>.old with each restart. If this file exceeds a size of 5 Mbytes, it is renamed from amon<sid>.002 to amon<sid>.003 and

amon<sid>.old is changed to amon<sid>.002.

Archiving log file

All of the files backed up by the archiving monitor are logged in the /nsr/oracle/<ORACLE_SID>/prot/save_logfiles file. There are four generations of this file.

With each restart, the file is appended to save_logfiles.old, if it does not exceed 1 Mbyte as a result. Were this size to be exceeded, save_logfiles.old is renamed save_logfiles.002 and the current file is renamed save_logfiles.old.

The following is a representative sample from the log file:

00-05-08:16:51:59: Amon Instanz /opt/networker/oracle/bin/amon (26293) startet ============================ 00-05-08:16:51:59: INFO: NSR_SERVER <psi> 00-05-08:16:51:59: INFO: Variable CONTR_SERVER set to <psi> 00-05-08:16:51:59: INFO: Amon Group name set to <amonorapsi> 00-05-08:16:51:59: INFO: AMON_MAX_LOGS <5> 00-05-08:16:51:59: INFO: AMON_MIN_LOGS <1> 00-05-08:16:51:59: INFO: AMON_INTERVAL <1800> 00-05-08:16:51:59: INFO: mail user <root> 00-05-08:16:51:59: INFO: amon_watch_dog_cmd </usr/bin/mailx -s ’Redologs not saved in 900 seconds’ root> 00-05-08:16:51:59: INFO: AMON_WATCH_DELAY <900> 00-05-08:16:51:59: INFO: AMON_SAVE_ARG_NR <50> 00-05-08:16:51:59: INFO: AMON_PS_FILE </nsr/oracle/ora/tmp/amon.ps> 00-05-08:16:51:59: INFO: AMON_RM_WITHOUT_MIRROR_DELAY <0> 00-05-08:16:52:00: INFO: forked expect proc <26301>

00-05-08:16:52:00: ARCHIVE_DIR=/oradb/db734/ora/saparch 00-05-08:16:52:01: ARCHIVE_FORMAT=oraarch%t_%s.dbf 00-05-08:16:52:01: AMON_EXP_TIME= 00-05-08:16:52:01: forked got process nr 26309

00-05-08:16:52:01: INFO: PS_FILE </nsr/oracle/ora/tmp/amon.ps> 00-05-08:16:52:01: INFO: checking Nr of Redologs 00-05-08:16:52:01: /oradb/db734/ora/saparch 00-05-08:16:52:01: DEBUG:oraarch1_42.dbf 01/11/00 14:55:59 s: 0 m: 0

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

......

00-05-08:16:52:01: DEBUG:oraarch1_54.dbf 01/21/00 13:13:15 s: 0 m: 0 00-05-08:16:52:01: DEBUG: Print of a save_cmd: /opt/networker/bin/save -i -l full -g amonorapsi -s psi 00-05-08:16:52:01: oraarch1_42.dbf oraarch1_43.dbf oraarch1_45.dbf oraarch1_44.dbf oraarch1_46.dbf oraarch1_47.dbf oraarch1_48.dbf oraarch1_49.dbf oraarch1_50.dbf oraarch1_51.dbf oraarch1_52.dbf oraarch1_53.dbf oraarch1_54.dbf.

3.2 The Backup Component

The backup component of NSR-ORA allows the online as well as offline full or partial backup of an ORACLE database within an archiving process. (see

figure 5). In case of an online backup, the database must be in the

ARCHIVELOG mode. The extent of an archiving process is defined by means of a configurable file structure in the directory $DBO_CONFIG_DIRECTORY of the NSR-ORA administrator (refer to the section “Configuration and manage-

ment”).

In the case of Oracle 8.0 backups, the Oracle shared libraries ibclm.so,

libclntsh.so and libmipc.so must be linked to /usr/lib. Where Oracle is used with 64-bit support, these libraries must be linked accordingly to /usr/lib64s.

When backing up Oracle 8.1 under Linux, the Oracle shared libraries libjox8.so, libskgxp8.so and libclntsh.so.8.0 must be linked to /usr/lib. This is the only way that data backup is possible with NSR-ORA.

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

DBMS

database files

control file

SYSTEM

USER

Tablespaces

Database interface NSR-ORA

Backup

component

NetWorker user interface

Volume management

Volume pool management

Multiplexing

Jukebox support

TEMP

Archiving

monitor

Oracle’s

archiving

process

redolog files

Treshold

value

3.2.1 Offline Backup of the Database

configure_nsrora and configure_networker can be used, if required, to create a new client and a new group called OFFLINE<oracle_sid><client>. If this client is backed up, an offline backup is performed, i.e. the database is shut down before the backup and then rebooted after the backup.

Furthermore, an offline backup of the database is performed whenever the database is closed at the time of the backup. This procedure consists of the following phases:

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

1. The database is started up briefly to determine the database files allocated to a tablespace. Normally, several tablespaces are backed up during an archiving process.

2. The database is closed.

3. All the database files of a tablespace are backed up, irrespective of whether system files or raw devices are involved.

The database must not be started up during an offline backup! You will

receive an error message at the end of the backup if the database was started up in the meantime.

If you want to back up a database that is currently online under OPS, and

the instance that is to be used for the backup is offline, that instance can only be started automatically under Oracle 7 and an online backup will be carried out instead. You may get an inconsistent backup under Oracle

8. You should therefore always note under Oracle 8 before the backup that all instances are either offline or online!

If you use the default configuration described in Chapter 4, a copy of the control file is also made every day, and - when you carry out an offline backup - the online redolog files are also backed up.

Please note that the database is started up briefly once in the course of an offline backup, in order to request the paths to the database files and the raw devices. This alters the time-stamps on the database files and the control file. It follows that the state of the database after an offline backup will not be identical to its state before the backup.

If you want to make a snapshot of your database so that you can exactly recreate its current state at some later time, we recommend you use one of the following two procedures, which are carried out while the database is stopped:

1. Back up all the tablespaces, the online redolog files and the control file directly, using NetWorker (i.e. without using NSR-ORA). You will need to know all the necessary pathnames in order to do this.

2. Then carry out the backup using NSR-ORA and the save set /nsr/oracle/$ORACLE_SID/${ORACLE_SID}_full_save. This ensures that the control file and redolog files are only backed up after the tablespaces, so that the time-stamps of the control file will be as expected by ORACLE.

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

3.2.2 Online Backup of the Database

An online backup of the database is performed whenever the database is open at the time of the backup. In contrast to offline backups, the following phases are carried out:

1. All database files allocated to a tablespace are determined.

2. Backup is commenced with the ORACLE-specific command alter tablespace <tablespacename> begin backup.

3. All database files of this tablespace are backed up, irrespective of whether they are system files or raw devices.

4. Completion of the backup is indicated to the database system with the command alter tablespace <tablespacename> end backup.

3.2.3 Configuration and management

The configuration file dbo${ORACLE_SID}.init, which must be located in the directory ${DBO_CONFIG_DIRECTORY}/config, can be used to determine cer- tain characteristics of the backup component. The following representation shows the parameters which are relevant to the backup component and located in the dbo${ORACLE_SID}.init configuration file (a model file named dbo.init is stored in the directory $NSR_INST/oracle/config). This configuration file is cre- ated automatically using the program configure_nsrora (see also the chapter

“Installation and Configuration”).

The backup_TS_on_different_clients configuration file allows to split a backup among different NetWorker servers; when using ORACLE Parallel Server (OPS) also among different NetWorker clients.

To enable this feature, the file backup_TS_on_different_clients must be created in the /nsr/oracle/$ORACLE_SID/config direcory. If the file does not exist, NSR-ORA behaves as usual. You can find an example of such a configuration file in the /opt/nsr/oracle/config directory (for HP-UX: /opt/networker/oracle/config). The entries also are described there in detail.

If you split a backup, Recover until Time is not possible any more.

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

3.2.4 Checking backups (troubleshooting)

If an error occurs when backing up the database or if one of the backup processes does not end cleanly, the entire database backup is aborted and all tablespaces are reset to the status NoSave.

You can check whether a backup has been completed successfully by examining the protocol files (*.prot) which are located in the directory /nrs/oracle/${ORACLE_SID}/prot and its subdirectories.

Log files from local backups (not for NAS filers)

This file directory contains two protocol files:

● In the file save_history you will find an overview of the backups that have been

carried out. For each backup of a tablespace or redolog file, it contains a record of the date and time, the name of the backed up tablespace or redolog, whether the backup was online or offline and the result of the backup. You should examine this file regularly to check that backing up the redolog files is being performed correctly.

● The file actual_saves_of_tablespaces contains the output of the shell script

saveinfo.sh from the most recent tablespace backup (see below). When you

evaluate this file, note the date of the backup. It always shows the most recently completed backup, even if this was some time ago.

If there are error messages in this file (or in the output from saveinfo.sh)

you should first check the individual protocol files, which are described below; this will often give you more information about the encountered error.

In the NetWorker windows you will find information about any problem which NetWorker encountered while backing up the tablespaces or redolog files, e.g. problem regarding access to tapes or devices.

If you encounter an error that is related to ORACLE you should also check your database.

The subdirectory tablespaces contains a protocol file for each backed up tablespace. These files have names of the form save_${ORACLE_SID}_${TS}.prot, where ${TS} stands for the name of the tablespace. There is also the file save_${ORACLE_SID}_overview.prot, which contains any information regarding the backups that does not relate to a particular tablespace. The protocol files in this subdirectory are overwritten by each new backup.

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

The shell script saveinfo.sh in the directory $NSR_INST/oracle/bin evaluates the protocol files save*.prot in the subdirectory tablespaces and tells you the status, the start and end of a backup, the type of backup (online|offline) and the names and sizes of the backed up tablespaces.

You can call saveinfo.sh at any time, even while there is a backup in progress. It is called automatically when a tablespace backup has been completed and writes its output to the file actual_saves_of_tablespaces. This information is also sent to you by mail.

Please note that only the above-mentioned protocol files and the

saveinfo.sh tool provide you with complete information on the status and success of a backup process.

AMON Recordings

The file /nrs/oracle/${ORACLE_SID}/prot/save_logfiles contains a log of all redolog files backed up by the archiving monitor (see the section “Logging”). The subdi- rectory /nrs/oracle/${ORACLE_SID}/prot/dbg contains debug information, which can be evaluated by Fujitsu Siemens Computers if errors are encountered.

If you want to observe a backup in progress on the screen, you can do so using the command nsrwatch or from the main NetWorker window.

Please note that only the above-mentioned protocol files and the saveinfo.sh tool provide you with complete information on the status and success of a backup process.

If you call ora_recut, additional debugging information, which can be evaluated by Fujitsu Siemens Computers specialists if an error occurs, is entered in the directory /nsr/${ORACLE_SID}/tmp/RUT.

The global consistency of the backup schedules must always be checked

to ensure that all tablespaces occur in at least one backup cycle. If a tablespace does not occur in at least one partial backup interval, it is never saved! Consequently, a configuration tool has been supplied (see the section “Establishing tablespace names”) for supporting this task.

At least one backup process is started for each backup if the attribute

Backup Command was set to nsrora_save_cmd for the relevant client in the Clients window. Otherwise, at least two backup processes are started

for each backup - one by NetWorker and one by NSR-ORA. Please keep this in mind when setting the concurrency of the NetWorker server. The

System Administrator’s Guide U42252-J-Z915-1-76

The individual Components The Backup Component

concurrency used by NSR-ORA when backing up tablespaces is one less than the concurrency of NetWorker when nsrora_save_cmd is not used, because NSR-ORA always uses one backup for internal purposes.

The database must not be started up while an offline backup is in

progress. Under ORACLE Parallel Server (OPS), the instance which is carrying out the backup is given exclusive access to the database; this also prevents the database from being started up by any other instance. In other cases you will receive an error message at the end of the backup if the database was started up in the meantime.

If you want to back up a database which is currently online under OPS, while the instance that is to be used for the backup is offline, that instance will be started and an online backup will be carried out instead.

System Administrator’s Guide U42252-J-Z915-1-76

4 Installation and Configuration

The following chapter describes the installation and configuration of NSR-ORA.

4.1 Quick Start

This section gives experienced users an short overview of all steps required to install and configure NSR-ORA. It is a synopsis of the information presented in this chapter and the rest of the manual and is intended to help you to get NSRORA “up and running” quickly and easily.

In order to install NSR-ORA and prepare it for use you need to carry out the following steps:

1. Install NSR-ORA on the database computer (Enabler and NSR-ORA package) using the relevant command for the respective platform. Refer to the sections “Licensing NSR-ORA” and “Installing NSR-ORA from CD”.

2. Now start the database (with startup or, in the case of OPS, with startup parallel) so that configure_nsrora can determine the tablespace names.

3. Call up the configure_networker tool and fill in the informations described in section “Parameters for configure_nsrora”.

4. Make sure that you have NSR administrator rights.

5. Call up the configure_networker tool (refer also to the section “Configuring

NetWorker”).

When using a NetApp filer in order to perform NDMP-backups, you may have to define some NetWorker ressources manually (see “Configuring Net-

Worker”).

6. Specify the Start time for the database group in NetWorker and set the attribute Autostart to Enabled (for further information, please refer to your NetWorker documentation).

7. Highlight the required data carriers for the database and the archiving monitor amon (see the manual NetWorker - Installing, Configuring and Operating).

8. Make sure that the database is in the archive mode using the command archive log list.

System Administrator’s Guide U42252-J-Z915-1-76

Installation and Configuration Installation

9. Start the archiving monitor amon using the following command:

start_amon.sh start $ORACLE_SID

(refer also to section “Starting and Ending the Archiving Monitor“)

10.Check the results of your first backup (see “Checking backups (troubleshoo-

ting)” for this).

4.2 Installation

NSR-ORA is supplied together with NetWorker on CD-ROM. The installation is carried out (analogous to the installation of NetWorker) on the NetWorker client on which the ORACLE database is located.

In addition to NSR-ORA, you also have to install an enabler for NSR-ORA itself on the NetWorker server.

4.2.1 Licensing NSR-ORA

Before you can use NSR-ORA, you first have to install the enabler for NSR-ORA on the NetWorker server. This is how you install the enabler:

For NetWorker servers from Fujitsu Siemens Computers from NetWorker Version V5.5A21

1. Insert the license diskette into the drive of your NetWorker server.

2. Log in as root.

3. Enter the following command:

# keylic

The installation then continues interactively.

For different NetWorker servers (prior to Version V5.5A21 or third party)

1. Insert the license diskette into the drive of your Database server.

2. Log in as root.

3. Enter the following command:

● For NetWorker clients from Fujitsu Siemens Computers (Solaris or

LINUX):

System Administrator’s Guide U42252-J-Z915-1-76

Installation and Configuration Installation

# /opt/nsr/keylic -s <server>

<server> is the name of the NetWorker server.

● For NetWorker servers from Fujitsu Siemens Computers prior to

NetWorker Version V5.5A21 and Reliant UNIX clients or third-party clients for Solaris:

# /opt/nsr/oracle/bin/keylic -s <server>

<server> is the name of the NetWorker server.

● For clients under HP-UX:

# doscp /dev/floppy/<devicename>:/NSR-ORA <file> # /opt/networker/oracle/bin/keylic -f <file> -s <server>

<file> is any file name and <server> is the name of the NetWorker server.

Example (for a NetWorker server backup01):

# doscp /dev/floppy/c0t1d0:/NSR-ORA nsrorakey # keylic -f nsrorakey -s backup01

The installation then continues interactively.

In order to backup a database on a local volume using NSR-ORA the key

diskette NSR-ORA V3.2 (NetWorker license NetWorker Module for Oracle, UNIX Client) is required.

For using the NDMP functionality additionally the new license NetWorker Oracle Module for NDMP is required. For this the key diskette NSRONDM

is to be installed.

Both of the licenses may be installed on the NetWorker server by using the keylic command.

NetApp Licences

On the NetApp filer the snaprestore license is to be installed. To check this you can start the NetApp command license using a telnet connection. If this license is not available, please contact your NetApp filer administrator.

4.2.2 Installing NSR-ORA from CD

This section describes how to install NSR-ORA from CD for the different platforms.

System Administrator’s Guide U42252-J-Z915-1-76

+ 55 hidden pages