ibm db2 high availability solution ibm tivoli system automation

Installation GuideIBM DB2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms

Target Audience ■ Technical Consultants ■ System Administrators

CUSTOMERDocument version: 1.5 – 2012-10-22

Document History

CAUTION

Before you start the implementation, make sure you have the latest version of this document.

You can find the latest version at the following location: http://service.sap.com/

instguidesnw <Your SAP NetWeaver Release> Installation Installation - SAP NetWeaver Systems

The following table provides an overview of the most important document changes:

Version Date Description

1.0 2006-08-11 Initial version

1.02 2008-03-10 Updated version

1.03 2010-07-22 Updated version (including graceful cluster switch)

1.04 2010-11-30 Update of section Updating the Database Fix Packs

1.5 2012-10-22 Update: Addition of DB2 for Linux, UNIX, and Windows Version 10.1, introduction of SAP cluster components

2/82 CUSTOMER 2012-10-22

http://service.sap.com/instguidesnw


Table of Contents

Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Virtual Host Name and Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Reusing the Host Name and IP Address of a Single Server . . . . . . . . . . . . . . . . 19

2.3.2 Setting Up a New Virtual Host Name and IP Address . . . . . . . . . . . . . . . . . . . . 20

2.4 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Restrictions for Shared-Disk Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2 Restrictions for the HADR Setup and the SAP Cluster Setup . . . . . . . . . . . . . . 22

Chapter 3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Setting Up File Systems for Shared Disk Scenario . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Setting Up the ssh/rsh Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Changing the Password of the SAP Connect User . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Configuration of Log Archiving for HADR Setup . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Preparing the Global Host and Installing the Central Services . . . . . . . . . . . . . 30

4.2 Downloading the Latest DB2 Software and SA MP License . . . . . . . . . . . . . . . . 30

4.3 Installing the Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Setting Up a Standby Database Server Using Homogeneous System

Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 Installing the Primary Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Installing the SA MP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.7 Setting Up the High-Availability Database Cluster . . . . . . . . . . . . . . . . . . . . . . 34

4.7.1 Installing the SA MP License for the Database Cluster . . . . . . . . . . . . . . . . . . . 34

4.7.2 The Cluster Setup Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2012-10-22 CUSTOMER 3/82

4.7.3 Copying the Files and Scripts for the Cluster Setup to a Local

Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.7.4 Setting Up the Database Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.7.5 Changing References to the Virtual Host Name or IP Address . . . . . . . . . . . . . 37

4.7.6 Enabling HADR Takeover by Force (DB2 Version 8.2 and V9.1

only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.8 Setting Up the High-Availability SAP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8.1 Installing the SA MP License for the SAP Cluster . . . . . . . . . . . . . . . . . . . . . . . 40

4.8.2 Setting up High Availability for SAP Central Services . . . . . . . . . . . . . . . . . . . . 40

4.8.3 Setting Up High Availability for the SAP Web Dispatcher . . . . . . . . . . . . . . . . . 41

4.8.4 Setting Up High Availability for SAProuter . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.8.5 SA MP for SAP Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 5 Post-Installation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Validating the Database Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Checking the Database Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.2 Checking the Database Cluster Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Validating the SAP Cluster Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.1 Checking the Setup of the SAP Cluster Components . . . . . . . . . . . . . . . . . . . 49

5.2.2 Checking the Failovers of SAP Cluster Components . . . . . . . . . . . . . . . . . . . . 51

5.3 Performing a Backup of the SA MP Core Policy . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 6 Updating the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1 Updating the Database Fix Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2 Updating SA MP Fix Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Upgrading from DB2 UDB Version 8 or from DB2 V9.1, V9.5, or

V9.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 7 Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1 Uninstalling the Database Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Uninstalling the SA MP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 Deleting the Database Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter A Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.1 SA MP Policy for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.1.1 Cluster Configuration File sapdb2scscluster.conf . . . . . . . . . . . . . . . . . . . . . . . 59

A.1.2 Cluster Setup Script sapdb2scscluster.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.2 Syntax of SA MP Setup Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4/82 CUSTOMER 2012-10-22

A.2.1 Script prereqSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.2.2 Script installSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A.2.3 Script uninstallSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.3 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.3.1 Troubleshooting Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.3.2 Requesting SAP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.3.3 Symbol Resolution Failed for db2start on AIX . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.3.4 DB2 Immediately Stops After the db2start/startdb/startjeedb

Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.3.5 DB2 Immediately Starts After the db2stop/stopdb/stopj2eedb

Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.4 Graceful Cluster Switch (Micro–Outage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.4.1 Basic Concept of the Graceful Cluster Switch . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.4.2 Performing a Graceful Cluster Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.4.3 Cluster Switch Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.5 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2012-10-22 CUSTOMER 5/82

This page is left blank for documents that are printed on both sides.

1 Introduction

Purpose

This document describes how to set up a high-availability (HA) solution for IBM DB2 for Linux, UNIX,

and Windows (versions 8, 9.1, 9.5, 9.7, and 10.1) using IBM Tivoli System Automation for Multiplatforms

(SA MP) when your operating system is AIX, Solaris SPARC, or Linux.

SA MP is a high-availability cluster solution that provides several monitoring mechanisms to detect

system failures and a set of rules to initiate the correct action without any user intervention. The set

of rules is called a policy, which describes the relationships between applications or resources. This

provides SA MP with extensive up-to-date information about the system landscape so that it can restart

the resource on the current node or move the whole application to another cluster node.

IBM provides a free two-node license of SA MP for the IBM DB2 database server only. Additionally, if

you have purchased a license for the DB2 pureScale Feature from SAP, you can use SA MP to make

your SAP services highly available. For more information, see SAP Note 1746101.

Due to the database reconnect feature of SAP NetWeaver, a database server failure and a subsequent

failover controlled by SA MP within the database cluster to another node is almost transparent to the

clients. The running transactions of the work processes are terminated. The users of transactions within

the affected dialog processes receive a message. SAP NetWeaver reconnects to the database server as

soon as it is available again.

Setup Types for Database Clusters

There are two setup types to make a DB2 server highly available using SA MP:

■ SA MP with a shared disk (shared disk approach):

The database is located on a shared disk. The disk is shared between two servers. When the first

server fails, the second server assigns the virtual IP to the network adapter, mounts the shared disk,

and starts the DB2 instance and database.

■ SA MP with HADR (High Availability and Disaster Recovery):

HADR is a DB2 replication feature to make the database server highly available (shared nothing

approach). In this scenario, you have two separate DB2 database servers: a primary and a standby

database server. The servers are kept in sync and, in the event of failure, the standby database server

takes over the workload.

The two setup types are described in more detail below.

1 Introduction

2012-10-22 CUSTOMER 7/82

http://service.sap.com/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=1746101&_NLANG=en&_NVERS=0

SA MP with a Shared Disk

The figure below shows a setup of two database servers that share the database software and the database

itself on a shared disk. Both database servers have access to the shared disk but only one of them is

running at a time and is connected to the shared disk. The SAP NetWeaver application server instances

are running on different machines. SAP NetWeaver only knows the virtual host name or the virtual

IP address of the database cluster. SA MP assigns the virtual IP address to the node on which the DB2

software is currently running.

In the event of failure of node 1, SA MP detects the failure and assigns the virtual IP address to a network

adapter on node 2 (en0), mounts the shared disk and starts the DB2 instance on node 2. During the

activation of the database, DB2 triggers a crash recovery to bring the database into a consistent and

usable state. All open transactions from node 1 are rolled back and all committed transactions that

were still in the memory when the crash occurred are completed. This process can take a while.

Figure 1: SA MP with a Shared Disk: Example Based on DB2 V9.1

SA MP with HADR

The figure below shows a setup of two database servers. Both database servers have their own storage

and are up and running. In HADR, one server has the role of the primary server. This means that all

clients are connected to this server. All transactions are written to logs. The log data is transferred via

TCP/IP to the second database server, the standby server. This standby server updates the local database

by rolling forward the transferred log files. So the standby server is kept in sync with the primary server.

HADR is a replication feature only. This means that it has no failure detection and no automation

facilities. SA MP monitors the two database servers. When the primary database server crashes, SA MP

1 Introduction

8/82 CUSTOMER 2012-10-22

initiates the HADR takeover by the standby server and also ensures that the virtual IP address is assigned

to the new primary server.

DB2 also provides a client reroute feature, which ensures that all clients know the standby database

server. In the event of failure, the clients reroute their connections to the standby server. For more

information, see the IBM white paper Enable Database High Availability Using DB2 HADR and Tivoli SA MP

in an SAP Environment in the Reference Documentation [page 12].

RECOMMENDATION

We recommend that you use SA MP for monitoring the database servers and moving the virtual

IP address since this is transparent to all application servers and the monitoring infrastructure.

Figure 2: SA MP with HADR: Example Based on IBM DB2 V9.1

If the primary server crashes, the takeover only requires a few seconds since the second database server

is already running and the database is already in a consistent state.

However, the synchronization algorithm takes some additional time for updates. You can choose

between the following synchronization modes for HADR:

■ SYNC (synchronous)

This mode provides the greatest protection against transaction loss, and using it results in the

longest transaction response time among the three modes. In this mode, log writes are considered

successful only if logs have been written to log files on the primary database and if the primary

database has received acknowledgment from the standby database that the logs have also been

written to log files on the standby database. The log data is guaranteed to be stored at both sites.

1 Introduction

2012-10-22 CUSTOMER 9/82

■ NEARSYNC (near synchronous)

While this mode has a shorter transaction response time than the synchronous mode, it also

provides slightly less protection against transaction loss. In this mode, log writes are considered

successful only if the log records have been written to the log files on the primary database and if

the primary database has received acknowledgment from the standby system that the logs have

also been written to the main memory on the standby system. Data is only lost if both sites fail

simultaneously and if the target site has not transferred all of the log data that it has received to

nonvolatile storage.

■ ASYNC (asynchronous)

This mode has a high chance of transaction loss if the primary system fails. It also has a short

transaction response time. In this mode, log writes are considered successful only if the log records

have been written to the log files on the primary database and have been delivered to the TCP layer

of the primary system's host machine. Since the primary system does not wait for acknowledgment

from the standby system, transactions might be considered committed when they are still on their

way to the standby server.

■ SUPERASYNC (super asynchronous)

This mode is available for IBM DB2 as of version 9.5 FP8. The super asynchronous mode

complements the existing set of synchronization modes by ensuring that transactions can never

be blocked or experience elongated response times due to network interruptions or congestion,

therefore allowing transactions to be processed more quickly than in any other HADR

synchronization mode.

RECOMMENDATION

We recommend that you use NEARSYNC for the HADR synchronization mode.

CAUTION

You must ensure that your network can rapidly manage the synchronization workload. If you

do not ensure a rapid synchronization, the network becomes a bottleneck for the performance

of the database server:

■ The primary database has to wait for acknowledgment of the shipped log data in the SYNC

and NEARSYNC modes.

■ The primary database has to wait to send new messages to the standby server in the ASYNC

mode when the TCP/IP buffers are full.

The distance between the two database servers can be much larger than in the shared disk setup since

the two database servers only need a network connection to each other. So you can place them at

different locations to protect your data, for example, against fire.

1 Introduction

10/82 CUSTOMER 2012-10-22

High Availability Feature (HA) as of DB2 Version 9.5

As of DB2 V9.5, a new cluster management API is available. Using this interface, DB2 can communicate

with the associated cluster manager to change the cluster configuration according to actions and state

changes of DB2.

For example, if you do not have this feature enabled, you have to start and stop DB2 using cluster

manager commands. With the DB2 HA feature, you can use native db2start or db2stop to manage

your DB2 database. The commands change the state of the DB2 resource in the cluster configuration

and prevent the cluster manager from bringing the resource back online or offline. From the user

viewpoint, the whole cluster handling has now become transparent. By using this feature, you reduce

the risk of wrong configuration of your cluster when you change the configuration of DB2. For example,

if you add a new container to your cluster on a new shared disk, DB2 adds this shared disk to your

resource group to make sure that the failover also mounts the new disk at the other node.

In addition, the new tool DB2 high-availability instance configuration utility (db2haicu) was

introduced, which you can use to enable HA and to configure the cluster manager in your system

environment.

CAUTION

The db2haicu tool also provides an interactive mode for cluster setup. For SAP systems, you still

have to use the sapdb2scscluster.sh script to set up the cluster. The sapdb2scscluster.sh uses

db2haicu for the cluster setup and ensures that the cluster is set up in a supported way so that

startdb and stopdb scripts work correctly.

Setup Types for SAP Clusters

SAP systems have more than one instance that can be made highly available using SA MP. The SAP

central services and the enqueue replication server are mandatory instances for SAP high availability.

Additional candidates for high availability are the SAP Web Dispatcher and SAProuter. Each instance

requires two nodes for high availability. We recommend that you use the same two nodes for all SAP

instances. (These two nodes can be the same as the database cluster nodes.)

Each SAP instance can be stored on a shared disk or can be duplicated in local directories on each SAP

cluster node, so there are two setup types for an SAP instance:

■ SA MP with an SAP instance on a shared disk (shared-disk approach):

The SAP instance is located on a shared disk. The disk is shared between two servers. When the

first server fails, the second server assigns the virtual IP to the network adapter, mounts the shared

disk, and restarts the SAP instance.

■ SA MP with an SAP instance on a local disk (local-disk approach):

The SAP instance is located on a local disk for each SAP cluster node. When one node fails, the

second node assigns the virtual IP to the network adapter and restarts the SAP instance.

1 Introduction

2012-10-22 CUSTOMER 11/82

RECOMMENDATION

We recommend that you use local directories. Local directories lead to a faster failover, and in

addition the cluster setup tool automates and simplifies cluster setup.

In the following, we briefly describe how to configure the SAP instances for high availability.

SA MP with SAP Central Services and Enqueue Replication Server

One SAP central service instance exists for Java (Java SCS) and ABAP (ASCS). Each stack has it own

instance, which contains at least one process for the message server, for the enqueue server, and for

gateway. These central services run on the primary node of the cluster with a virtual IP. The enqueue

replication server (ERS) runs on the second node of the cluster. When the primary node fails, the

central services are started on the ERS host, and the enqueue server is rebuilt from the shared memory

of the enqueue replication server. After the enqueue server has been rebuilt and the central services

are up and running again, the enqueue replication server acts as failover for the second node of the

cluster (the original primary node) as soon as possible. This ensures high availability again without loss

of locks for SAP business transactions.

SA MP with SAP Web Dispatcher

The SAP Web Dispatcher can be used for dispatching HTTP(s) requests. In a highly available SAP system,

the SAP Web Dispatcher is combined with a virtual IP address and is active on one node in the cluster.

When this node fails, the cluster manager automatically restarts the SAP Web Dispatcher on the second

node of the cluster.

SA MP with SAProuter

SAProuter acts as an intermediate station (proxy) in a network connection between SAP systems and

controls the access to your network. In a highly available SAP system, SAProuter is combined with a

virtual IP address and is active on one node in the cluster. When this node fails, the cluster manager

automatically restarts SAProuter on the second node of the cluster.

Application Servers

There is no need for a failover or two-node clusters for an application server because you can set up

more than one application server, which is already a scaleout solution. Nevertheless, SA MP can also

be used to restart SAP application servers automatically in the event of failure.

1.1 Reference Documentation

The following section provides information about additional documentation that might be useful:

■ SAP documentation

■ SA MP documentation

■ Reliable Scalable Cluster Technology (RSCT) documentation

1 Introduction


12/82 CUSTOMER 2012-10-22

Since SA MP is based on RSCT, make sure that you also refer to this documentation.

■ IBM DB2 HADR documentation

■ Important SAP Notes

NOTE

Before you start the installation, make sure that you read the latest version of SAP Note 960843.

It contains the most recent information about the installation of SA MP, as well as corrections to

this document.

SAP Documentation

Document URL

Installation Guide – SAP Systems Based on SAP NetWeaver 7.0 <ABAP; ABAP+Java; Java> on <OS>: IBM DB2 for Linux, UNIX, and Windows

http://service.sap.com/instguidesnw70 Installation

Installation Guide – SAP Systems Based on SAP NetWeaver 7.3 <ABAP; ABAP+Java; Java> on <OS>: IBM DB2 for Linux, UNIX, and Windows

http://service.sap.com/instguidesnw73 Installation

Database Upgrade Guide – Migration to Version 9.5 of IBM DB2 for Linux, UNIX, and Windows

http://service.sap.com/instguides Database Upgrades DB2 UDB

Database Upgrade Guide – Upgrading to Version 9.7 of IBM DB2 for Linux, UNIX, and Windows


Database Upgrade Guide – Upgrading to Version 10.1 of IBM DB2 for Linux, UNIX, and Windows


SA MP Documentation

Document URL

IBM Tivoli System Automation for Multiplatforms - home page

http://www.ibm.com/software/tivoli/products/sys- auto-

linux/

IBM Tivoli System Automation for Multiplatforms – product manuals

http://publib.boulder.ibm.com/tividd/td/IBM

TivoliSystemAutomationforMultiplatforms2.2.html

IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide

http://publib.boulder.ibm.com/tividd/td/ITSAFL/

SC33-8272-01/en_US/PDF/HALBAU01.pdf

IBM Tivoli System Automation for Multiplatforms - Base Component Reference


SC33-8274-01/en_US/PDF/HALBRE01.pdf

IBM Tivoli System Automation for Multiplatforms - End-to-End Automation Management Component Administrator’s and User’s Guide


SC33-8275-00/en_US/PDF/HALEAU00.pdf

IBM Tivoli System Automation for Multiplatforms - End-to-End Automation Management Component Reference


SC33-8276-00/en_US/PDF/HALERE00.pdf

1 Introduction


2012-10-22 CUSTOMER 13/82


http://service.sap.com/instguidesnw70


http://service.sap.com/instguides



http://www.ibm.com/software/tivoli/products/sys-auto-linux/

http://www.ibm.com/software/tivoli/products/sys-auto-linux/

http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.2.html


http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8272-01/en_US/PDF/HALBAU01.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8272-01/en_US/PDF/HALBAU01.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8274-01/en_US/PDF/HALBRE01.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8274-01/en_US/PDF/HALBRE01.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8275-00/en_US/PDF/HALEAU00.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8275-00/en_US/PDF/HALEAU00.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8276-00/en_US/PDF/HALERE00.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8276-00/en_US/PDF/HALERE00.pdf

Reliable Scalable Cluster Technology (RSCT) - Documentation

Document URL

IBM Reliable Scalable Cluster Technology (RSCT) - Diagnosis Guide

http://publib.boulder.ibm.com/epubs/pdf/bl5dia03.pdf

IBM Reliable Scalable Cluster Technology (RSCT) - Library

http://publib.boulder.ibm.com/infocenter/clresctr/ vxrx/

index.jsp?topic=/com.ibm.cluster.rsct.doc/

rsctbooks.html

IBM DB2 HADR Documentation

Document URL

IBM DB2 Information Center – High Availability Disaster Recovery Overview

http://publib.boulder.ibm.com/infocenter/db2luw/ v10r1/

topic/com.ibm.db2.luw.admin.ha.doc/doc/c0011267.html

IBM Redbook: High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows

http://www.redbooks.ibm.com/redbooks/pdfs/sg247363. pdf

IBM White Paper: Enable Database High Availability using DB2 HADR and Tivoli SA MP in an SAP Environment

http://www.ibm.com/developerworks/db2/library/long/

dm-0708ha/index.html

IBM DB2 High Availability Feature Documentation

Document URL

IBM DB2 Information Center – High Availability Feature

http://publib.boulder.ibm.com/infocenter/db2luw/ v10r1/

topic/com.ibm.db2.luw.admin.ha.doc/doc/c0051345.html

IBM White Paper: Automated Cluster Controlled HADR (High Availability Disaster Recovery) Configuration Setup using the IBM DB2 High Availability Instance Configuration Utility (db2haicu)

http://www.ibm.com/software/sw-library/en_US/detail/

B337860U68046M89.html

The following SAP Notes are referenced within this document. Make sure that you always have the

most recent version of each SAP Note. You can find the SAP Notes on SAP Service Marketplace at:

http://service.sap.com/notes

SAP Notes

SAP Note Number Title

70856 DB2 specific actions when renaming DB host

816773 DB6: Installing an SAP OEM license

960843 DB6: Installation of System Automation for Multiplatforms

1746101 DB6: High Availability with SAP on DB2 using SA MP

1568539 DB6: HADR – Virtual IP or Automatic Client Reroute

1555903 DB6: Supported DB2 Database Features

1552925 Linux: High Availability Cluster Solutions

1530812 DB6: Graceful Maintenance Tool

1443426 DB6: Graceful Cluster Switch

960843 DB6: Cluster Setup Tool

821904 Separating SCS instances for ABAP and J2EE

1 Introduction


14/82 CUSTOMER 2012-10-22


http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.ibm.cluster.rsct.doc/rsctbooks.html



http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0011267.html


http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf

http://www.ibm.com/developerworks/db2/library/long/dm-0708ha/index.html

http://www.ibm.com/developerworks/db2/library/long/dm-0708ha/index.html



http://www.ibm.com/software/sw-library/en_US/detail/B337860U68046M89.html

http://www.ibm.com/software/sw-library/en_US/detail/B337860U68046M89.html

http://service.sap.com/notes












SAP Note Number Title

1447436 DB6: Specific COMMIT after TRUNCATE TABLE command

1.2 Naming Conventions

In this document, the following naming conventions apply for the terms and variables used:

Database Terminology

Term Abbreviation

IBM DB2 10.1 for Linux, UNIX, and Windows DB2 10.1

IBM DB2 V9.7 for Linux, UNIX, and Windows DB2 V9.7

IBM DB2 Version 9.5 for Linux, UNIX, and Windows DB2 Version 9.5, DB2 V9.5

IBM DB2 Version 9.1 for Linux, UNIX, and Windows DB2 Version 9.1, DB2 V9.1

IBM DB2 UDB for UNIX and Windows Version 8 DB2 UDB Version 8

IBM DB2 High Availability Disaster Recovery HADR

IBM Tivoli System Automation for Multiplatforms SA MP

IBM Reliable Scalable Cluster Technology RSCT

Variables

Variable Description

<DBSID> Name of the database in upper case

<dbsid> Name of the database in lower case

<SAPSID> System ID of the SAP system in upper case

<sapsid> System ID of the SAP system in lower case

1 Introduction

1.2 Naming Conventions

2012-10-22 CUSTOMER 15/82


2 Planning

Make sure that you read the following sections:

■ Hardware Requirements [page 17]

■ Software Requirements [page 18]

■ Virtual Host Name and Virtual IP Address [page 19]

■ Restrictions [page 21]

2.1 Hardware Requirements

To set up the DB2 server in an HA environment using the free two-node license of SA MP, the following

hardware requirements must be met:

Requirement Type Requirement

Server Hardware Two separate servers for the database.Both servers must meet the DB2 requirements as described in the IBM documentation DB2 Installation Prerequisites for <OS> at:http://www.ibm.com/software/data/db2/udb/ sysreqs.html

Physical Disks For shared disk setup only:One shared disk, which you can mount from both database servers. No synchronization is required since the disk is mounted by only one server at a time. NFS is not supported.

RECOMMENDATION

We recommend that you use Storage Area Network (SAN).

Memory For shared disk setup, both servers should have at least the memory configured for DB2 since the configuration is moved between the two nodes.For HADR setup, both servers must have the same amount of memory since buffer pool operations are also replayed by the standby database server.

Disk Space 300 MB additional free disk space on each node within the HA cluster for the SA MP Software

NOTE

Make sure that the directories /usr/sbin, /opt and/var have at least 100 MB of free disk space available.

2 Planning

2.1 Hardware Requirements

2012-10-22 CUSTOMER 17/82

http://www.ibm.com/software/data/db2/udb/sysreqs.html

RECOMMENDATION

We recommend that you use two identical machines for the cluster setup. Since in a shared disk

setup, the database manager configuration and the database registry are transferred during

movement of DB2 from one node to the other, the configuration must suit both of them.

In the HADR setup, the primary server has to wait until the standby database server sends the

acknowledgment back to the primary server. This means that the standby server also impacts the

performance of the primary server.

2.2 Software Requirements

Cluster Setup Tool

To set up a high-availability solution for IBM DB2 for Linux, UNIX, and Windows using IBM Tivoli

System Automation for Multiplatforms (SA MP), you require the cluster setup tool attached to SAP

Note 960843. The cluster setup tool comprises the script sapdb2scscluster.sh (also referred to as

“cluster setup script” in this document) and a configuration file. The cluster setup tool is also available

on the software DVDs for DB2 V9.1 FP 5, DB2 V9.5 FP1, DB2 V9.7, and DB2 10.1.

NOTE

The information provided in this document is based on the cluster setup tool version 6 or higher.

We recommend that you use the latest version of the cluster setup tool.

Supported Operating Systems

The following operating systems are supported with SA MP:

SA MP Version Supported Operating System

Version 2.2 or higher (DB2 V8.2, V9.1, or V9.5) AIX 64 bit, Red Hat Enterprise Linux, SuSE Linux Enterprise Server

Version 3.1 or higher (DB2 V9.7) AIX 64 bit, Red Hat Enterprise Linux, SuSE Linux Enterprise Server, Solaris on SPARC

Version 3.2.2.1 or higher (DB2 10.1) AIX 64 bit, Red Hat Enterprise Linux, SuSE Linux Enterprise Server, Solaris on SPARC

For more information about the required operating system versions, see the product availability matrix

for your SAP system release on SAP Service Marketplace at http://service.sap.com/pam. Note that

the product availability matrix might include more operation systems that are supported with DB2 for

LUW, but that are not supported with SA MP.

Required Fix Pack Levels

The following DB2 Fix Pack levels are required:

DB2 Version Fix Pack Level

DB2 10.1 No special Fix Pack is required.

2 Planning

2.2 Software Requirements

18/82 CUSTOMER 2012-10-22


http://service.sap.com/pam

DB2 Version Fix Pack Level

DB2 V9.7 No special Fix Pack is required.

DB2 V9.5 At least Fix Pack 1

DB2 V9.1 At least Fix Pack 1

DB2 Version 8 At least Fix Pack 13

Additional Requirements

The following additional software requirements must be met for the use of SA MP:

■ Perl must be installed on the database servers. On Linux, Public Domain Korn Shell (pdksh) must

also be installed.

For more information, see IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide at:

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-04/en_US/PDF/

halgre20.pdf

■ All nodes must run on the same operating system.

■ All host machines must have the same operating system patch level.

■ See also the latest SA MP release notes at:


HALRL205.pdf

2.3 Virtual Host Name and Virtual IP Address

The virtual host name and the virtual IP address are used to access the cluster. The virtual host name

is a reference on the DNS server or to the virtual IP address in the /etc/hosts files. The cluster binds

the virtual IP address to the active cluster node. All clients have to refer either to the virtual host name

or directly to the virtual IP address. Therefore, the clients always connect to the node of the cluster

where the clustered DB2 or the SAP instance is currently running.

To set up such an environment, you can choose between the following options:

■ You reuse the host name and IP address of a single server as virtual host name and IP address [page 19].

■ You set up a new virtual host name and IP address [page 20].

For a new installation or system copy, we always recommend approach 2. Approach 1 is only

recommended for an existing SAP system that you want to make highly available.

2.3.1 Reusing the Host Name and IP Address of a Single Server

To reuse the host name and the IP address of the single database server as virtual host name and virtual

IP address, you have to replace the physical host name and the physical IP address of the single database

server with a new host name and a new IP address because you specify the old host name and the old

2 Planning


2012-10-22 CUSTOMER 19/82

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-04/en_US/PDF/halgre20.pdf


http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8214-05/en_US/PDF/HALRL205.pdf

http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8214-05/en_US/PDF/HALRL205.pdf

IP address of the database server as the new virtual host name and virtual IP address in the cluster setup

configuration file sapdb2scscluster.conf.

The advantage of this approach is that you do not have to change the references to the database host

or SAP instance host of your SAP system landscape and of additional monitoring tools. However,

additional services that are installed on the server are not available anymore on the specified host name

or IP address.

The following figure provides an example of such a reuse before and after the database cluster has been

set up:

Figure 3: Reuse of Host Name and IP Address of Single Database Server

The host name db2_sa_mp_1 of the single database server is reused as virtual host name; the IP address

17.2.10.1 is reused as virtual IP address. To avoid naming conflicts, the database server needs a new

network identity. Therefore, the database host name is changed to db2_sa_mp_3 and the IP address to

17.2.10.3.

The host name and IP address of the second database server (Node 2) remain the same and both database

servers are now addressed with the new virtual address and IP address.

You have to change the entries of the host name in db2nodes.cfg to the new physical host name of

node 1. This file is located in the DB2 instance directory.

2.3.2 Setting Up a New Virtual Host Name and IP Address

To set up a new virtual host name and a new virtual IP address, you specify the new host name and the

new IP address in the cluster setup configuration file sapdb2scscluster.conf.

2 Planning


20/82 CUSTOMER 2012-10-22

The following figure shows an example of how you set up a new virtual host name or IP address before

and after the database cluster has been set up:

Figure 4: Setup of New Virtual Host Name and IP Address

The database server keeps its host name db2_sa_mp_1 and its IP address 17.2.10.1. A new virtual host

name db2_sa_mp_cl and a new virtual IP address 17.2.10.3 are chosen for the failover cluster. If you

already have an SAP NetWeaver system running on this database server (Node 1), you have to change

all references to the database host in the SAP system landscape and in the monitoring tools. Although

the sapdb2post.sh script automatically replaces some of the references in your SAP system landscape,

you have to make some of the changes manually.

For more information, see Changing References to the Virtual Host Name or IP Address [page 37].

2.4 Restrictions

2.4.1 Restrictions for Shared-Disk Setup

NOTE

The following restrictions apply only for DB2 releases lower than DB2 V9.5.

If you add or remove any containers to or from tablespaces, the SA MP configuration is not updated

according to the changes that were applied to mount points. You have to configure SA MP manually.

2 Planning

2.4 Restrictions

2012-10-22 CUSTOMER 21/82

2.4.2 Restrictions for the HADR Setup and the SAP Cluster Setup

For the HADR setup, the following restrictions apply:

■ HADR is not supported in a partitioned database environment.

■ The primary and standby databases must have the same operating system version and the same

version of the DB2 database system, except for a short time during a rolling upgrade.

■ The DB2 database system release on the primary and standby databases must be of the same bit size

(32 or 64 bit).

■ READ operations on the standby database are not supported. Clients cannot connect to the standby

database.

■ Log archiving can only be performed by the current primary database.

■ You can use Self-Tuning Memory Manager (STMM) only on the current primary database.

■ Backup operations are not supported on the standby database.

■ Non-logged operations, such as changes to database configuration parameters and to the recovery

history file, are not replicated to the standby database.

■ Load operations with the COPY NO option specified are not supported.

■ HADR does not support the use of raw I/O (direct disk access) for database log files. If HADR is

started via the START HADR command or the database is activated (restarted) with HADR configured

and raw logs are detected, the associated command fails.

For the SAP cluster setup, the following restriction applies: Both nodes must have the same operating

system version.

2 Planning

2.4 Restrictions

22/82 CUSTOMER 2012-10-22

3 Preparation

Make sure that you perform the following steps before you start the installation:

1. You set up file systems for shared disk scenario [page 23].

2. You set up the ssh/rsh connection [page 25].

3. You change the password of the SAP connect user [page 26].

4. You configure the log archiving for HADR setup [page 27].

3.1 Setting Up File Systems for Shared Disk Scenario

Before you install SA MP, you have to ensure the required file systems are set up as follows:

■ All directories under /db2 must be located on the shared disk but not on NFS shares.

For example, the following file systems are required for a standard SAP system with a database that

uses DB2’s automatic storage management:

File System Description

/db2/db2<dbsid> Contains the home directory of db2<sapsid>

/db2/<DBSID>/log_dir Contains at least the online database log files

/db2/<DBSID>/db2dump Contains DB2 diagnostic log files, DB2 dump files, and further service engineer information

/db2/<DBSID>/db2<dbsid> Contains the local database directory

/db2/<DBSID>/saptemp1 Contains the temporary tablespace(s)

/db2/<DBSID>/sapdata1 SAP data for container type database managed space (DMS) FILE or for use of DB2's automatic storage management

To make sure that either of the mentioned file systems is stored on the shared disk, choose one of

the following options (where you replace <dir> with any of the directories mentioned here):

● Mount the shared disk on /db2 and create an appropriate directory, for example, /<dir>.

● Create a partition on the shared disk and mount the partition on /db2/<dir>.

For more information about the recommended file system sizes, see the installation guide and the

database upgrade guide [page 12].

■ All directories under /usr/sap/<SAPSID>/<INSTANCE> must be located on the shared disk but not

on NFS shares.

■ Make sure that all required mount points to the shared disk are not mounted at system boot time

and that the file systems check at boot time is disabled.

● On Linux, you have to set the noauto option. Furthermore, set the sixth column fs_passno

to 0 in file /etc/fstab as follows:

3 Preparation


2012-10-22 CUSTOMER 23/82

/dev/sdc1 /db2 reiserfs noauto,acl,user_xattr 0 0

/dev/sdc2 /usr/sap/<SAPSID>/<INSTANCE> reiserfs noauto,acl,user_xattr 0 0

● On AIX, you have to set the options check and mount to false.

SYNTAX

/db2: dev = /dev/fslv01 vfs = jfs2 log = /dev/loglv00 mount = false check = false options = rw account = false/usr/sap/<SAPSID>/<INSTANCE>:dev = /dev/fslv02vfs = jfs2log = /dev/loglv02mount = falsecheck = falseoptions = rwaccount = false

CAUTION

You must make sure that none of the file systems are mounted automatically during

system reboot. SA MP is the only authority allowed to mount the file systems.

■ If you have to mount the file systems listed above manually, you must disable SA MP Automation

first, that is, set it to manual mode or lock the resource. Otherwise, SA MP unmounts the file

systems immediately.

To set SA MP to manual mode or to automation mode, use the following commands as user

root, db2<dbsid> or <sapsid>adm:

Mode Command

Manual Mode (disabled): samctrl –MT

Automation Mode (enabled): samctrl –MF

To lock the resource or resource group, use the following commands as user root, db2<dbsid> or

<sapsid>adm:

● Lock (automation disabled):

◆ Resource group:

rgreq –o lock <resource group>

EXAMPLE

rgreq –o lock db2_db2ha3_0-rg

rgreq –o lock SAP_ABAP_HA3_ASCS12

◆ Resource:

rgmbrreq –o lock <resource>

EXAMPLE

rgmbrreq –o lock IBM.Application:db2mnt-db2-rs

3 Preparation


24/82 CUSTOMER 2012-10-22

rgmbrreq –o lock IBM.Application:SAP_JAVA_HA3_SCS11_MS

● Unlock (automation enabled):

◆ Resource group:

rgreq –o unlock <resource group>

EXAMPLE

rgreq –o unlock db2_db2ha3_0-rg

rgreq –o unlock SAP_ABAP_HA3_ASCS12

◆ Resource:

rgmbrreq –o unlock <resource>

EXAMPLE

rgmbrreq –o unlock IBM.Application:db2mnt-db2-rs

rgmbrreq –o unlock IBM.Application:SAP_JAVA_HA3_SCS11_MS

■ All types of local file systems are supported by SA MP, for example, reiserfs, jfs2, and so on.

3.2 Setting Up the ssh/rsh Connection

For the installation of SA MP, you have to enable ssh or rsh login for user root without password

authentication. This enables user root to connect to all nodes of the cluster including itself on any

node of the cluster.

To configure the nodes of the cluster, the SA MP cluster setup script uses ssh or rsh.

NOTE

By default, the setup script uses ssh on Linux and rsh on AIX.

Procedure

Setting Up the Connection Using ssh

For example, to use RSA authentication instead of password authentication for ssh, proceed as follows:

1. Log on to the first node of the cluster as user root.

2. Generate an RSA key for user root by entering the following command:

ssh-keygen –t dsa

You are now asked to specify the file name for the key and a passphrase:

■ Enter the default file name for the key:

~/.ssh/id_dsa

■ Do not specify any passphrase.

3. To enable key authentication for ssh on the same node, enter the following command:

cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

4. To transfer the public key to the second node, enter the following command:

scp ~/.ssh/id_dsa.pub root@<hostname>:~/id_dsa.pub

3 Preparation

3.2 Setting Up the ssh/rsh Connection

2012-10-22 CUSTOMER 25/82

5. Log on to the second node of the cluster as user root.

6. To enable key authentication for ssh on the second node, enter the following command:

cat ~/id_dsa.pub >> ~/.ssh/authorized_keys

7. To remove the public key file from the home of user root on the second node, enter the following

command:

rm ~/id_dsa.pub

8. To add both cluster nodes to the list of known hosts, enter the following command:

ssh-keyscan –t dsa <host1_short_name>,<host1_full_name>, <host1_ip> >> ~/.ssh/

known_hosts

ssh-keyscan –t dsa <host2_short_name>,<host2_full_name>, <host2_ip> >> ~/.ssh/

known_hosts

9. Follow the same procedure in the opposite way on the second node.

Setting Up the Connection Using rsh

If you want to use rsh and avoid password authentication, add the two nodes to the .rhosts file in the

home directory of the user root.

1. Log on to first node of the cluster as user root.

2. Add the two nodes to the file .rhosts and the user root separated by a space.

EXAMPLE

If you use the example setup shown in the Introduction [page 7], the content of .rhosts should

look as follows:

db2_sa_mp_1.company.net root

db2_sa_mp_1 root

17.2.10.1 root

db2_sa_mp_2.company.net root

db2_sa_mp_2 root

17.2.10.2 root

3.3 Changing the Password of the SAP Connect User

If you change the password of the database connect user with the dscdb6up tool, the password in the

dscdb6.conf file and the operating system password of the connect user on the database host are

changed.

On the standby database server, the password is not changed. As a result, the SAP systems cannot

connect to the standby database server if DB2 is started on this node. If you use Network Information

Service (NIS) for central user management, the password is not changed in the NIS directory.

This means that if you change the password of connect user sap<sapsid> or <sapsid>adm, you have

to manually change the operating system password on the standby database server in the failover cluster

or in the NIS directory.

3 Preparation

3.3 Changing the Password of the SAP Connect User

26/82 CUSTOMER 2012-10-22

3.4 Configuration of Log Archiving for HADR Setup

To configure log archiving for HADR setup, we recommend that you configure both the primary and

the standby database to have automatic log retrieval capability from all log archive locations. Both the

primary and the standby database must be able to retrieve log files from all the log archive locations to

which either of the databases might archive log files.

The log archiving is only performed by the primary database. If you change the HADR roles of the

database servers or if a failure occurs, the new primary database is responsible for log archiving. If you

have set up different log archive locations, your logs might be archived twice and, in the case of local

or remote catch-up, you might have to manually copy the archived logs from the old primary server

to the active log location of the new primary server.

3 Preparation

3.4 Configuration of Log Archiving for HADR Setup

2012-10-22 CUSTOMER 27/82

4 Installation

The following sections describe how to install and set up the database failover cluster.

To set up SA MP in a distributed SAP NetWeaver system, proceed as follows:

1. Prepare the global host and install the central services [page 30].

2. Install the database instance as follows:

1. Download the latest DB2 software and SA MP license [page 30].

2. Install the database server [page 30].

3. Set up a standby database server using a homogeneous system copy [page 31].

3. Install the primary application server [page 33].

4. Install the SA MP software [page 33].

5. Set up the high-availability database cluster as follows.

1. Install the SA MP DB2 license for the database cluster [page 34].

2. Set up the database cluster [page 36].

3. Change references to the virtual host name or IP address [page 37].

4. Enable HADR takeover by force [page 39] (DB2 Versions 8.2 and V9.1 only).

6. Set up the high-availability SAP cluster as follows:

1. Install the SA MP SAP license for the SAP cluster [page 40].

2. Set up high availability for the SAP central services [page 40].

3. Set up high availability for the SAP Web Dispatcher [page 41].

4. Set up high availability for the SAProuter [page 42].

5. Set up high availability for the SAP application servers (not possible with SA MP, see also SA

MP for Application Servers [page 43]).

7. Perform post-installation activities [page 45].

NOTE

You can also install SA MP after you have completed a distributed SAP NetWeaver installation.

In this case, you only need to install the second database server as described in Installing the Database

Server [page 30] and continue to set up the high availability cluster as described in Setting Up the

High Availability Cluster [page 34].

If your database server is not addressed using a virtual host name, you have to change all references

to it as described in Changing References to the Virtual Host Name or IP Address [page 37].

4 Installation

2012-10-22 CUSTOMER 29/82

4.1 Preparing the Global Host and Installing the Central Services

If you want to make the SAP central services instance highly available, you must install the instance

on a virtual host name. You can do this by using the parameter SAPINST_USE_HOSTNAME when you start

the SAP installer. For more information about the installation, see the installation guide relevant for

your SAP product on SAP Service Marketplace at http://service.sap.com/instguidesnw.

4.2 Downloading the Latest DB2 Software and SA MP License

To be able to install the latest version of DB2 and SA MP, download the required software from SAP

Service Marketplace at:

http://service.sap.com/swdc Download Database Patches (from other vendors) DB2 for UNIX and

Windows DB2 <version> software download

NOTE

■ For DB2 V9.1, the SA MP software and setup scripts are bundled with the latest DB2 V9.1

installation image. The license file for SA MP is packed together with DB2 V9.1 licenses.

■ For DB2 V9.5 and higher, the license for SA MP for the database server is included in the

DB2 license.

4.3 Installing the Database Server

Prerequisites

If you want to set up an HADR cluster and you do not use NIS/NFS for central user management, you

must ensure that the group and user IDs are identical on the cluster nodes. For the shared disk setup,

the script sapdb2scscluster.sh copies the user groups, users, and home directories to the second

node.

NOTE

■ For SAP system releases up to and including SAP Basis 4.6D, the connect user is sapr3.

■ The user sapadm is used for the SAP Host Agent.

Procedure

Install the database server as described in the appropriate installation guide:

Database Version Installation Guide Special Considerations

DB2 UDB Version 8 SAP NetWeaver 7.0 SR2 <ABAP/ABAP+Java/Java> on <OS>: IBM DB2 Universal Database for UNIX and Windowson SAP Service Marketplace at:

You must install the DB2 software on both hosts of the cluster.

CAUTION

Do not mount the software directory itself on the shared disk. Even if there

4 Installation

4.1 Preparing the Global Host and Installing the Central Services

30/82 CUSTOMER 2012-10-22


http://service.sap.com/swdc

Database Version Installation Guide Special Considerationshttp://service.sap.com /

instguidesnw70 InstallationInstallation – SAP NetWeaver Systems

are two separate database manager configurations and registries – after you have set up the cluster – only one is valid and is always transferred to the current node.

NOTE

You have to install the OEM license on each node separately.

DB2 V9.1 and higher SAP NetWeaver 7.0 (with or without enhancement packages):SAP NetWeaver 7.0 (including enhancement package) <ABAP/ABAP+Java/Java> on <OS>: IBM DB2 for Linux, UNIX, and Windows on SAP Service Marketplace at http://service.sap.com /


SAP NetWeaver 7.3 (with or without enhancement packages):SAP NetWeaver 7.3 (including enhancement package) <ABAP/ABAP+Java/Java> on <OS>: IBM DB2 for Linux, UNIX, and Windows on SAP Service Marketplace at http://service.sap.com /


If you are using DB2 V9.1 and higher, you can also install the database software once on the shared disk.

RECOMMENDATION

We recommend that you install DB2 V9.1 and higher on the shared disk in the home directory of user db2<dbsid>: /db2/db2<dbsid>/db2_software.This is the default for SAP NetWeaver 7.0 SR3 and higher.

NOTE

You have to install the OEM license once on one of the nodes.

4.4 Setting Up a Standby Database Server Using Homogeneous System Copy

CAUTION

The following section only applies to the HADR-based cluster setup. For shared-disk setup, you

must omit this section.

If you set up the switchover cluster based on the DB2 feature HADR, you have to create a standby

database as a copy of the primary database. You can use the SAP homogeneous system copy for setting

up the standby database server.

Procedure

1. Log on to the first node as user db2<dbsid>.

2. Enable archiving for the logs, for example, to a disk folder using the following command:

db2 “update db cfg for <dbsid> using LOGARCHMETH1 DISK:/db2/<DBSID>/log_archive/”

4 Installation


2012-10-22 CUSTOMER 31/82







CAUTION

Both the primary and the standby database needs to be able to retrieve log files from all the

log archive locations to which either of the databases might archive log files. To configure

log archiving for HADR, we recommend that you configure both the primary and the standby

database to have automatic log retrieval capability from all log archive locations. For more

information, see Configuration of Log Archiving for HADR Setup [page 27].

3. Create the directory /db2/<DBSID>/backup:

mkdir /db2/<DBSID>/backup

4. Create a full database backup:

db2 “backup db <dbsid> to /db2/<DBSID>/backup compress”

5. Log on to the second node as user root.

6. Create the directory /db2/<DBSID>/backup:

mkdir /db2/<DBSID>/backup

7. Transfer the backup from the first node to the second node to the directory /db2/<DBSID>/

backup:

■ For ssh, you can use the following command:

scp root@<hostname>:/db2/<DBSID>/backup/* /db2/<DBSID>/backup/.

■ For rsh, you can use the following command:

rcp root@<hostname>:/db2/<DBSID>/backup/* /db2/<DBSID>/backup/.

■ You can also transfer the file using ftp.

8. Start the SAP installer.

NOTE

You can use the parameter SAPINST_USE_HOSTNAME=<VIRTUAL HOSTNAME> of the SAP installer

to specifiy the virtual host name that the SAP installer uses for the installation. The virtual

IP address must be bound to the current host.

9. Choose Software Lifecycle Tasks System Copy Target System Distributed System <Your setup type>

Database Instance

10. For the copy method, choose Homogeneous System Copy so that you can use your backup to restore

the backup on the standby server.

11. On the Summary screen, revise the database communication parameters for the database

communication port and the password phrase to ensure that you have the same values as on the

primary database server.

12. Start the installation process.

13. When you reach the exit step to restore the database for the homogeneous system copy, exit the

installer.

You restore the database from the primary host. All subsequent installation phases have already

been executed on the primary database server.

14. Log on to the second node as user db2<dbsid>.

4 Installation


32/82 CUSTOMER 2012-10-22

15. Restore the database backup using the following command:

db2 “restore db <dbsid> from /db2/<DBSID>/backup replace history file“

16. Verify that your database is in rollforward pending state using the following command:

db2 “get db cfg for <dbsid>” | grep Rollforward

The final setup of the HADR cluster is done by the script sapdb2scscluster.sh that is provided by

SAP.

4.5 Installing the Primary Application Server

The installation of SAP application servers is not covered in this document. For more information, see

the respective installation guide that you use to install the database server. The installation guides are

available on SAP Service Marketplace at http://service.sap.com/instguidesnw.

4.6 Installing the SA MP Software

The SA MP software is bundled with DB2 V9.1 and higher on DVD images. You can find the SA MP

software in the following directory on the RDBMS DVD of IBM DB2:

■ For DB2 V9.1:

<dvd_mount>/<platform>/SA_MP/software

■ For DB2 V9.5 and higher:

<dvd_mount>/<platform>/ESE/disk1/db2/<platform>/tsamp

NOTE

As of DB2 V9.5, the SA MP software is part of the DB2 software.

Procedure

1. Log on to the first node as user root.

2. Insert and mount the database software DVD to <dvd_mount>.

3. To change to the mount directory, enter the following command:

■ For DB2 V9.1:

cd <dvd_mount>/<platform>/SA_MP/software


cd <dvd_mount>/<platform>/ESE/disk1/db2/<platform>/tsamp

4. To check that the prerequisites are met, enter the following command:

./prereqSAM

5. To start the installation, enter the following command:

./installSAM –-noliccheck

NOTE

You can ignore the warning “CT_MANAGEMENT_SCOPE not set”.

4 Installation

4.5 Installing the Primary Application Server

2012-10-22 CUSTOMER 33/82


It is automatically set during the cluster setup.

6. Install the SA MP software on the second node.

More Information

For more information about the syntax and additional parameters of the scripts prereqSAM and

installSAM, see Syntax of SA MP Setup Scripts [page 64].

4.7 Setting Up the High-Availability Database Cluster

To set up the database cluster, you have to perform the following steps:

1. Install the SA MP license for the database cluster [page 34].

2. Set up the database cluster [page 36].

3. Change the references to the virtual host name or IP address [page 37].

4. Enable HADR Takeover by Force [page 39].

4.7.1 Installing the SA MP License for the Database Cluster

You use the following procedure to install the general SA MP license for your database cluster.

NOTE

The following procedure only applies to DB2 V9.1. For DB2 V9.5 and higher, the license for SA

MP is included in the DB2 license.

Prerequisites

■ You have downloaded the license filesam32.lic from SAP Service Marketplace as described in

Downloading the Latest DB2 Software and SA MP License [page 30].

■ Check if you have installed the DB2 license. If not, install it as described in SAP Note 816773.

Procedure


2. Move the license file to the home directory of user root:

■ For Linux: /root

■ For AIX: /home/root

The cluster setup tool transfers the license to all other database cluster nodes and installs the license

on each node.

4.7.2 The Cluster Setup Tool

To set up the high availability cluster, you use the cluster setup tool, which comprises the cluster setup

configuration file and the setup scripts that are described in the following tables:

4 Installation


34/82 CUSTOMER 2012-10-22


File or Script Name Description

File sapdb2cluster.conf Contains all data that is required for the setup and maintenance of the cluster. It is created by the script sapdb2cluster.sh. During the creation process, sapdb2cluster.sh asks for all information required for your cluster setup and finally generates sapdb2cluster.conf.

Script sapdb2cluster.sh Sets up the cluster using the data contained in file sapdb2cluster.conf.During the setup process, the script sapdb2cluster.sh stops the database server, consecutively starts and stops both nodes, and finally activates the database on the original node.The script is also used to reset or delete the cluster configuration.For more information about the syntax of sapdb2cluster.sh, see Cluster Setup Script sapdb2cluster.sh [page 63].

The following files are replaced during the setup process and are required later.

File Name Description

■ startdb

■ startj2eedb

■ stopdb

■ stopj2eedb

■ sampdbcmd

Replace the former SAP scripts startdb and stopdb because you have to start and stop the database using the SA MP scripts listed here.

CAUTION

DB2 Version 8 and DB2 V9.1 only:Since SA MP monitors DB2, you cannot start and stop DB2 using the DB2 commands db2start or db2stop. For example, if DB2 is started using db2start, SA MP immediately initiates a db2stop afterwards.For more information about how to manually start and stop DB2, see Checking the Database Cluster Setup [page 45].

4.7.3 Copying the Files and Scripts for the Cluster Setup to a Local Directory

The SA MP cluster setup files and scripts are available with DB2 V9.1 and higher on DVD images. You

can find the SA MP cluster setup files and scripts in the following directory on the DVD:

/<platform>/SA_MP/scripts/

Alternatively, you can download the latest version from SAP Note 960843, which is highly

recommended.

Before you set up the cluster, you have to copy all files from directory /<platform>/SA_MP/

scripts/ to a local directory, for example, /samp_setup.

Procedure


2. Create a directory for the scripts using the following command:

4 Installation


2012-10-22 CUSTOMER 35/82


mkdir ~/samp_setup


4. Copy the setup files using the following command:

cp <dvd_mount>/<platform>/SA_MP/scripts/* ~/samp_setup/

4.7.4 Setting Up the Database Cluster

You set up the high availability cluster using the cluster setup configuration file and the setup script

sapdb2scscluster.sh (see also The Cluster Setup Tool [page 34]).

Prerequisites

■ You have to use at least version 4.0 of the cluster setup scripts that are attached to SAP Note

960843.

■ If you want to reuse the host name and IP address of a single server [page 19], you have to change the host

name and the IP address of the database server before creating the cluster.

Procedure

Generating the Cluster Configuration

1. Log on to the first database cluster node as user root.

2. Mount the shared disk (for HADR setup, you do not have to mount a shared disk).

3. Change to the directory to which you copied the cluster setup tool and the setup files and scripts:

cd ~/samp_setup

4. Execute the cluster setup script using the following command:

./sapdb2scscluster.sh

5. In the main menu, choose option 1 – DB2 Database Cluster.

6. In the database menu, choose option 1 – Create, Show or Edit Database Configuration.

This starts the configuration generator, which creates the configuration file

sapdb2scscluster.conf (or uses the existing file).

7. Provide all required parameters that could not be detected automatically.

CAUTION

Make sure that you keep the file sapdb2scscluster.conf because it is required to reset or

uninstall the cluster.

Setting Up the Database Cluster

The final cluster setup is performed by the setup cluster script sapdb2scscluster.sh based on the

information contained in file sapdb2scscluster.conf as follows:

1. Log on to the first database cluster node as user root.

2. Mount the shared disk (for HADR setup, you do not have to mount a shared disk).

3. Change to the directory to which you copied the scripts using the following command:

4 Installation


36/82 CUSTOMER 2012-10-22


cd ~/samp_setup

4. Execute the cluster setup script – assuming that you have created the cluster configuration file in

~/samp_setup – using the following command:


5. In the main menu, choose option 1 – DB2 Database Cluster.

6. In the database menu, choose option 2 – Create Database Cluster.

This starts the cluster creation process, which is based on the information specified in the


NOTE

The cluster setup tool creates the log file sapdb2scscluster.log with detailed information about

the creation process.

4.7.5 Changing References to the Virtual Host Name or IP Address

NOTE

You can omit this procedure if one of the following applies:

■ You are reusing the old host name as the virtual host name.

■ You have a new installation, that is, you directly set up the failover cluster after the installation

of the database instance before installing the application servers.

If you have chosen to set up a new virtual host name and a new virtual IP address [page 20], you must perform the

following steps. Although the script sapdb2post.sh performs some of the steps, you have to perform

other steps manually as described in the following.

Process

1. sapdb2scscluster.sh changes the default profile:

In the default profile /sapmnt/<SAPSID>/profile/DEFAULT.PFL, the database host name has to be

replaced for SAPDBHOST and j2ee/dbhost.

2. If the DB2 CLI driver is used, sapdb2post.sh changes the DB2 CLI driver settings in file

db2cli.ini, that is, the database host name is replaced.

3. sapdb2scscluster.sh changes the environment of users <sapsid>adm and sap<sapsid>:

The environment of the users <sapsid>adm and sap<sapsid> has to be adapted because most of

the environment source files contain the host name as part of their file name. For all other nodes

of the cluster, sapdb2scscluster.sh creates the appropriate links as shown in the following

example.

EXAMPLE

.dbenv_db2_sa_mp_2.sh -> .dbenv_db2_sa_mp_1.sh

4 Installation


2012-10-22 CUSTOMER 37/82

4. You change the catalog entries on all SAP NetWeaver instances:

1. Log on to the host of an SAP NetWeaver instance as user db2<dbsid>.

2. Generate a list of all catalog entries and look for an entry NODE<SAPSID> by entering the

following command:

db2 “list node directory”

3. Uncatalog the reference to the old host name using the following command:

db2 “uncatalog node NODE<SAPSID>”

4. Catalog the reference to the new virtual host name using the following command:

db2 “catalog tcpip node NODE<SAPSID>

remote <virtual_hostname> server <service_name>”

where <servicename> stands for sapdb2<SAPSID>.

5. Repeat this procedure for all SAP NetWeaver instances.

5. You change the JDBC URL:

NOTE

The following steps only apply for ABAP+Java and Java systems.

1. Log on to the host of an SAP NetWeaver instance as user root.

2. Change to the directory of the configuration tool using the following command:

cd /usr/sap/<SAPSID>/<Instance>/j2ee/configtool

3. Run the configuration tool using the following command:

./configtool.sh

4. In the left frame, choose security store.

5. In the right frame, choose the key jdbc/pool/<SAPSID>/url.

6. Change the host name in the JDBC URL to the virtual host name.

EXAMPLE

■ URL with the old host name:

jdbc:db2://db2_sa_mp_1:5912/TSP:deferPrepares=0

■ URL with the new virtual host name:

jdbc:db2://db2_sa_mp_cl:5912/TSP:deferPrepares=0

7. Choose Add.

8. To save your changes, click the disk icon in the upper left corner.

9. Close the configuration tool.

10. Restart the Java instance.

6. Change the references in remotely monitored systems.

NOTE

Make sure that you also change the references in your monitoring tools to the new virtual

host name.

4 Installation


38/82 CUSTOMER 2012-10-22

4.7.6 Enabling HADR Takeover by Force (DB2 Version 8.2 and V9.1 only)

The DB2 policy scripts do not change the roles of the HADR database with the FORCE option.

To change the role of the standby database to become the primary server, you use the DB2 command

TAKEOVER HADR. This command requires the acknowledgment of the primary database. However, if

the primary database is broken, you do not receive an acknowledgment. In this case, you have to take

over the primary role using the BY FORCE option.

Both databases can be updated if the following applies:

■ The primary database is not broken.

■ Database transactions are still processing.

■ The standby database takes over by force the role as the primary database.

As a result, you have two different primary databases that cannot automatically be synchronized.

In the shell script /usr/sbin/rsct/sapolicies/db2/hadr_start.ksh, three sections are commented

out because these three cases would initiate a TAKEOVER BY FORCE at a time when SA MP cannot ensure

that the primary database is down and the HADR cluster is in Peer state. The three sections are

commented so that you can decide whether or not you want to enable TAKEOVER BY FORCE in the

mentioned cases.

You must at least uncomment the last section for TAKEOVER BY FORCE. This section enables the takeover

of the workload by the standby server if the primary server cannot be reached anymore.

Procedure

1. Log on to the first node of the HADR cluster as user root.

2. Open the file /usr/sbin/rsct/sapolicies/db2/hadr_start.ksh in your editor.

3. Remove the number sign (#) from the beginning of lines 244, 245, and 246:

SYNTAX

243 # Uncomment following 3 lines to allow takeover even in case of non PeerStandby w/ old Primary machine Online244 logger -i -p notice -t $0 "su - ${instance_to_start?} -cdb2 takeover hadr on db ${DB2HADRDBNAME?} by force"245 su - ${instance_to_start?} –c"db2 takeover hadr on db ${DB2HADRDBNAME?} by force "246 logger -i -p notice -t $0 "NOTICE: Takeover by force issued"

4. Save the file.

5. Log on to the second node of the HADR cluster as user root and modify the file in the same way

or transfer it from the first node.

CAUTION

When you update your database to a higher Fix Pack level, you have to replace the precanned

policy scripts in this folder by the new version from the Fix Pack. Each time you replace the scripts,

you have to modify the hadr_start.ksh scripts on both nodes.

4 Installation


2012-10-22 CUSTOMER 39/82

4.8 Setting Up the High-Availability SAP Cluster

If you have purchased a license for the DB2 pureScale Feature from SAP, you are licensed to use SA MP

and the corresponding IBM Tivoli System Automation High Availability Policies for SAP for high

availability for the following SAP components:

■ SAP central services of AS ABAP and Java

■ Enqueue replication servers

■ SAP Web Dispatcher

■ SAProuter

■ SAP application servers (dialog instances)

You can use the SAP cluster setup tool to make your SAP components highly available as described in

the following sections.

NOTE

Without the additional DB2 pureScale license from SAP, the use of SA MP for non-DB2

components of your SAP system is not covered by your DB2 license. Note that you must have

obtained your DB2 pureScale license from SAP and not from other sources, such as IBM.

4.8.1 Installing the SA MP License for the SAP Cluster

As an SAP OEM pureScale customer, you are allowed to operate an SAP cluster in addition to the

database cluster. You must install the license required for this on each SAP cluster node.

Procedure

1. To install the license on each SAP cluster node, log on as the root user and use the following

command:

samlicm -i ANY_5724M00_3.2.LIC

2. To check whether you correctly installed the license, use the following command:

samlicm -s

Verify that a permanent license for the product SA for MP – SAP HA policy has been installed.

4.8.2 Setting up High Availability for SAP Central Services

Procedure


1. Log on to the first SAP cluster node as user root.

2. Mount the shared disk (not required if you use local directories).

3. Change to the directory to which you copied the cluster setup tool:

cd ~/samp_setup

4 Installation


40/82 CUSTOMER 2012-10-22

4. Execute the cluster setup tool using the following command


5. In the main menu, choose option 1 – SAP Central Services.

6. In the SAP sub-menu, choose option 1 – Create, Show or Edit SCS Configuration..




CAUTION

Make sure that you keep the file sapdb2scscluster.conf because it is required to reset or uninstall

the cluster.

Setting Up the SAP Cluster Component

The final cluster setup is performed by the cluster setup script sapdb2scscluster.sh based on the





cd ~/samp_setup




5. In the main menu, choose option 1 – SAP Central Services

6. In the SAP sub-menu, choose option 2 - Create SCS Cluster..



NOTE



4.8.3 Setting Up High Availability for the SAP Web Dispatcher

Procedure





cd ~/samp_setup

4 Installation


2012-10-22 CUSTOMER 41/82



5. In the main menu, choose option 1 – SAP Web Dispatcher

6. In the SAP sub-menu, choose option 1 – Create, Show or Edit SAP Web Dispatcher Configuration.




CAUTION


the cluster.

Setting Up the Cluster Component






cd ~/samp_setup




5. In the main menu, choose option 1 – SAP Web Dispatcher.

6. In the SAP sub-menu, choose option 2 - Create SAP Web Dispatcher Cluster.



NOTE



4.8.4 Setting Up High Availability for SAProuter

Procedure





cd ~/samp_setup

4 Installation


42/82 CUSTOMER 2012-10-22



5. In the main menu, choose option 1 – SAP Router.

6. In the SAP sub-menu, choose option 1 – Create, Show or Edit SAP Router Configuration.




CAUTION


the cluster.

Setting Up the Cluster Component






cd ~/samp_setup




5. In the main menu, choose option 1 – SAP Router

6. In the SAP sub-menu, choose option 2 - Create SAP Router..



NOTE



4.8.5 SA MP for SAP Application Servers

The use of SA MP for SAP application servers is currently not implemented in the cluster setup tool.

You can use the Tivoli wizard sampolicy to cluster your SAP application servers. For more information,

see the Tivoli System Automation for Multiplatforms: Installation and Configuration Guide.

4 Installation


2012-10-22 CUSTOMER 43/82

5 Post-Installation Activities

After you have successfully completed the installation and the cluster setup, you have to perform the

following post-installation activities:

1. You validate the data cluster, including:

1. You checking the database cluster setup [page 45].

2. You check the database cluster failover [page 48].

2. You validate the SAP cluster components, including:

1. You check the setup of SAP cluster components [page 49].

2. You check the failovers of SAP cluster components [page 51].

3. You back up the SA MP core policy [page 51].

5.1 Validating the Database Cluster

5.1.1 Checking the Database Cluster Setup

After the installation, you have to check that the failover cluster is working properly.

Procedure1. Log on to one of the cluster nodes as user root, <sapsid>adm, or db2<dbsid>.

2. To check if both nodes are online, enter the following command:

lsrpnode

OUTPUT

The following is an example output that can look as follows (RSCT versions can differ):

Name OpState RSCTVersiondb2_sa_mp_1 Online 2.4.8.0db2_sa_mp_2 Online 2.4.8.0

3. To check if the domain is online, enter the following command:

lsrpdomain

OUTPUT

The following is an example output that can look as follows (RSCT versions can differ):

Name OpState RSCTActiveVersion MixedVersions TSPort GSPortsap_tsmdb2...Online 2.4.8.0 No 12347 12348

4. To check the resource groups, enter the following command:

lsrg

OUTPUT

The following is an example output that can look as follows:



2012-10-22 CUSTOMER 45/82

Resource Group names:db2_db2tsm_0-rg

The naming convention for the resource group name is as follows:

db2_db2<dbsid>_0-rg

5. To check the status of the resource group, enter the following commands:

■ For shared disk setup:

lsrg –g db2_db2<dbsid>_0-rg

■ For HADR setup:

lsrg –g db2hadr_<dbsid>-rg

OUTPUT

The output looks as follows:

Displaying Resource Group information:For Resource Group "db2_db2tsm_0-rg".Resource Group 1: Name = db2_db2tsm_0-rg MemberLocation = Collocated Priority = 0 AllowedNode = ALLNominalState = Online ExcludedList = {} Subscription = {} Owner = Description = InfoLink = ActivePeerDomain = sap_tsmdb2OpState = Online TopGroup = db2_db2tsm_0-rg ConfigValidity = TopGroupNominalState = Online

Since most of the SA MP commands are asynchronous, there are two states for the resource

group:

State of Resource Group Description

NominalState Indicates the status that the resource group is supposed to have

OpState Indicates the status that the resource group currently has

If you just started the resource group, the NominalState is Online but the OpState is Offline or Pending

Online. If the resource group is online, OpState turns into Online as well. Shutting down the

resource group causes the same effect but vice versa.

If the resource group is not yet online, start it using the following command:

● For DB2 UDB Version 8 or DB2 V9.1:

chrg –o online db2_db2<dbsid>_0-rg

NOTE

To stop the DB2 resource group, set the NominalState to offline using the following

command:



46/82 CUSTOMER 2012-10-22

chrg –o offline db2_db2<dbsid>_0-rg

● For DB2 V9.5 and higher:

db2start

To receive more information about resource members of the cluster, use the following SA MP

command:

lsrg –Ab –m –V –g db2_db2<dbsid>_0-rg

In addition, you can use the lssam command to display all registered resources and the status

on the node where the script is issued.

The output of the lssam command looks as follows:

SYNTAX

Online IBM.ResourceGroup:db2_db2djd_0-rg Nominal=Online |- Online IBM.Application:db2_db2djd_0-rs |- Offline IBM.Application:db2_db2djd_0-rs:db6xen003 '- Online IBM.Application:db2_db2djd_0-rs:db6xen004 |- Online IBM.ServiceIP:db2ip_10_17_202_162-rs |- Offline IBM.ServiceIP:db2ip_10_17_202_162-rs:db6xen003 '- Online IBM.ServiceIP:db2ip_10_17_202_162-rs:db6xen004 '- Online IBM.Application:db2mnt-db2-rs |- Offline IBM.Application:db2mnt-db2-rs:db6xen003 '- Online IBM.Application:db2mnt-db2-rs:db6xen004

6. For HADR, check the state of the DB2 HADR database servers:

1. Log on to one of the cluster nodes as user db2<dbsid>.

2. Check if the database server is up and running.

3. Check the HADR state:

db2pd –db <dbsid> -hadr

SYNTAX

In the sample output, the database ID is SJH. The output looks as follows:

Database Partition 0 -- Database SJH -- Active -- Up 2 days 22:47:43HADR Information:Role State SyncMode HeartBeatsMissed LogGapRunAvg (bytes)Primary PeerNearsync 0 191289728ConnectStatus ConnectTime TimeoutConnected Mon Mar 12 15:48:06 2007 (1173732486) 120LocalHost LocalServiceis0081 SJH_HADR_1RemoteHost RemoteService RemoteInstanceis0082 SJH_HADR_2 db2sjhPrimaryFile PrimaryPg PrimaryLSNS0000018.LOG 6030 0x00000001F253E876StandByFile StandByPg StandByLSNS0000018.LOG 6030 0x00000001F253E876

7. Check that you can start and stop DB2 in the cluster.

■ To start and stop the members of the resource group – taking into account the relationship

between the members – use the following command:

rgmbrreq -o [start|stop|cancel] <resource_class>:<rgmbr>

■ To explicitly start and stop the DB2 instance, only use the following command:



2012-10-22 CUSTOMER 47/82

SYNTAX

rgmbrreq -o [start|stop|cancel] IBM.Application:db2_db2<dbsid>_0-rs

CAUTION

For DB2 Version 8 and DB2 V9.1 only:

Since SA MP monitors DB2, you cannot start and stop DB2 using the DB2 commands

db2start or db2stop. For example, if DB2 is started using db2start, SA MP immediately

initiates a db2stop afterwards.

5.1.2 Checking the Database Cluster Failover

You use the following procedure to check the failover of the cluster by moving the DB2 instance from

one node to the other.

Procedure

1. Log on to one cluster node as user root, <dbsid>adm, or db2<dbsid>.

2. To move DB2 to another node, enter the following command:


rgreq -o move db2_db2<dbsid>_0-rg

■ For HADR setup:

You can use the same command as for shared disk, but for DB2 V9.5 and higher we recommend

that you use the db2 takeover command as user db2<sid>:

rgreq -o move db2hadr_<dbsid>-rg

db2 takeover hadr on db <dbsid>

Result

In the shared disk setup, SA MP shuts down DB2 on the specified node, unmounts the shared disk,

removes the virtual IP address from the network adapter of this node, and sets up everything on the

other node in the cluster.

In the HADR setup, SA MP removes the virtual IP address from the primary host, issues the command

db2 takeover HADR on db <dbsid>, and finally assigns the virtual IP to the new primary server. In this

way, the standby server becomes the new primary server and vice versa.

You can monitor the process using the command getstatus or lssam –top.

However, this method does not check the monitoring and failure-detection features of SA MP. To

check the failover behavior, you can do the following:

■ You can shut down the operating system on the node where the DB2 instance is currently running.

■ Alternatively, you can kill the DB2 instance using the command db2_kill.

SA MP detects that the resources of the resource group are not online anymore and starts all required

resources on the other node.



48/82 CUSTOMER 2012-10-22

5.2 Validating the SAP Cluster Components

5.2.1 Checking the Setup of the SAP Cluster Components

The easiest way to validate your SAP cluster components is to use the cluster setup script

sapdb2scscluster.sh.

Procedure



cd ~/samp_setup

3. Execute the cluster setup script using the following command


4. In the main menu, choose option 2 - SAP Central Services.

5. In the SAP sub-menu, choose option 3 - Show SCS Cluster State.

The output should be similar to the following output, which shows a resource group for the ABAP

central services, the SAP central services, and their corresponding enqueue replication server

instance. Every resource group is online, which means all required resources are running on one

node. Additionally, the enqueue replication server is anti-collocated to the enqueue server.

Online IBM.ResourceGroup:SAP_ABAP_HA5_ASCS10 Nominal=Online

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_CO

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_CO:db6xen022

'- Offline IBM.Application:SAP_ABAP_HA5_ASCS10_CO:db6xen023

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_ES

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_ES:db6xen022

'- Offline IBM.Application:SAP_ABAP_HA5_ASCS10_ES:db6xen023

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_GW

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_GW:db6xen022

'- Offline IBM.Application:SAP_ABAP_HA5_ASCS10_GW:db6xen023

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_MS

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_MS:db6xen022

'- Offline IBM.Application:SAP_ABAP_HA5_ASCS10_MS:db6xen023

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_SE

|- Online IBM.Application:SAP_ABAP_HA5_ASCS10_SE:db6xen022

'- Offline IBM.Application:SAP_ABAP_HA5_ASCS10_SE:db6xen023

'- Online IBM.ServiceIP:SAP_ABAP_HA5_ASCS10_IP

|- Online IBM.ServiceIP:SAP_ABAP_HA5_ASCS10_IP:db6xen022

'- Offline IBM.ServiceIP:SAP_ABAP_HA5_ASCS10_IP:db6xen023

Online IBM.ResourceGroup:SAP_ABAP_HA5_ERS20 Nominal=Online

'- Online IBM.Application:SAP_ABAP_HA5_ERS20_ERS



2012-10-22 CUSTOMER 49/82

|- Offline IBM.Application:SAP_ABAP_HA5_ERS20_ERS:db6xen022

'- Online IBM.Application:SAP_ABAP_HA5_ERS20_ERS:db6xen023

Online IBM.ResourceGroup:SAP_JAVA_HA5_SCS11 Nominal=Online

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_ES

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_ES:db6xen022

'- Offline IBM.Application:SAP_JAVA_HA5_SCS11_ES:db6xen023

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_GW

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_GW:db6xen022

'- Offline IBM.Application:SAP_JAVA_HA5_SCS11_GW:db6xen023

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_MS

|- Online IBM.Application:SAP_JAVA_HA5_SCS11_MS:db6xen022

'- Offline IBM.Application:SAP_JAVA_HA5_SCS11_MS:db6xen023

'- Online IBM.ServiceIP:SAP_JAVA_HA5_SCS11_IP

|- Online IBM.ServiceIP:SAP_JAVA_HA5_SCS11_IP:db6xen022

'- Offline IBM.ServiceIP:SAP_JAVA_HA5_SCS11_IP:db6xen023

Online IBM.ResourceGroup:SAP_JAVA_HA5_ERS21 Nominal=Online

'- Online IBM.Application:SAP_JAVA_HA5_ERS21_ERS

|- Offline IBM.Application:SAP_JAVA_HA5_ERS21_ERS:db6xen022

'- Online IBM.Application:SAP_JAVA_HA5_ERS21_ERS:db6xen023

NOTE

You can skip the validation of SAP components that are not made highly available on your

system.

6. Stop the cluster tool and restart it again, or use the navigation to change to the next SAP sub-menu

as follows:

1. Press Enter to continue.

You return to the SAP sub-menu SAP Central Services.

2. In the SAP sub-menu, choose option c - Cancel to go back to the main menu.

3. In the main menu, choose option 3 - SAP Web Dispatcher.

4. In the SAP sub-menu, choose option 3 - Show SAP Web Dispatcher Cluster State.

The output should be similar to the following output, which shows one resource group for the

SAP Web Dispatcher with two resources online. The first represents the SAP Web Dispatcher process

and the second represents the virtual IP:

Online IBM.ResourceGroup:SAP_WDISP_HA5_WEBDISP Nominal=Online

|- Online IBM.Application:SAP_WDISP_HA5_WEBDISP_SAPWEBDISP

|- Online IBM.Application:SAP_WDISP_HA5_WEBDISP_SAPWEBDISP:db6xen022

'- Offline IBM.Application:SAP_WDISP_HA5_WEBDISP_SAPWEBDISP:db6xen023

'- Online IBM.ServiceIP:SAP_WDISP_HA5_WEBDISP_IP

|- Online IBM.ServiceIP:SAP_WDISP_HA5_WEBDISP_IP:db6xen022



50/82 CUSTOMER 2012-10-22

'- Offline IBM.ServiceIP:SAP_WDISP_HA5_WEBDISP_IP:db6xen023

7. Press Enter to continue.

You get back to the SAP sub-menu SAP Web Dispatcher.

8. In the SAP sub-menu, choose option c - Cancel to go back to the main menu.

9. In the main menu, choose option 4 - SAP Router.

10. In the SAP sub-menu, choose option 3 - Show SAP Router Cluster State.

The output should be similar to the following output, which shows one resource group for

SAProuter with two resources online. The first represents the router process and the second

represents the virtual IP:

Online IBM.ResourceGroup:SAP_ROUTER_SYS_ROUTER Nominal=Online

|- Online IBM.Application:SAP_ROUTER_SYS_ROUTER_SAPROUTER

|- Online IBM.Application:SAP_ROUTER_SYS_ROUTER_SAPROUTER:db6xen022

'- Offline IBM.Application:SAP_ROUTER_SYS_ROUTER_SAPROUTER:db6xen023

'- Online IBM.ServiceIP:SAP_ROUTER_SYS_ROUTER_IP

|- Online IBM.ServiceIP:SAP_ROUTER_SYS_ROUTER_IP:db6xen022

'- Offline IBM.ServiceIP:SAP_ROUTER_SYS_ROUTER_IP:db6xen023

5.2.2 Checking the Failovers of SAP Cluster Components

You check the failover of the SAP cluster components by moving SAP resource groups from one node

to the other.

Procedure1. Log on to one cluster node as user root or <dbsid>adm.

2. To move an SAP resource group to another node, enter the following command:

rgreq -o move <sap-resource-group>

EXAMPLE

The following are examples of how you can move different SAP resource groups:

rgreq -o move SAP_ABAP_HA5_ASCS10

rgreq -o move SAP_JAVA_HA5_ERS21

rgreq -o move SAP_WDISP_HA5_WEBDISP

rgreq -o move SAP_ROUTER_SYS_ROUTER

5.3 Performing a Backup of the SA MP Core Policy

SA MP stores all its information about the cluster in a policy that contains all definitions of resources,

resource groups, and their relationships. Therefore, this policy contains the core configuration of the

SA MP cluster. After the cluster setup, we recommend that you back up the SA MP core policy. In this

way, you can easily restore the initial cluster setup if you accidentally change the SA MP core policy.



2012-10-22 CUSTOMER 51/82

Procedure

Backing Up the SA MP Core Policy

To back up the SA MP core policy, proceed as follows:

1. Log on to a cluster node as user root.

2. Enter the following command:

sampolicy –s /bkp/samp/bkpPolicy.xml

Restoring the SA MP Core Policy

To restore the SA MP core policy, proceed as follows:

1. Log on to a cluster node as user root.

2. Enter the following command:

sampolicy –a /bkp/samp/bkpPolicy.xml

NOTE

The restore process replaces the current policy by the one specified and finally activates this

policy.



52/82 CUSTOMER 2012-10-22

6 Updating the Software

6.1 Updating the Database Fix Packs

You use the following procedure to update the database Fix Packs in an SA MP environment. After a

DB2 database upgrade or a Fix Pack update, you have to update the DB2 HA precanned policy files in

SA MP that are stored in the subdirectory of the DB2 software directory ha/tsa.

These policy files are required by SA MP for monitoring, starting, stopping the database server, and

transferring the registry.

Restrictions

You can also apply Fix Packs by performing a rolling update, that is, you update the standby server first,

then fail over to the already updated standby database server, and finally update the other database

server. This causes only several seconds of downtime for the failover of the database to the second node.

However, the rolling update is only recommended with DB2 and the thin client connectivity. For DB2

UDB Version 8 or higher versions with the old runtime client, you must not perform a rolling update

for the following reasons:

You must not run the application servers and the database server at different Fix Pack levels. Therefore,

you have to shut down the complete SAP system and update all database servers and the DB2 clients

on the application servers. A rolling update only updates the database server and not the DB2 clients

on the application servers. The result is that the database server has a higher Fix Pack level than the

application servers.

NOTE

The failover in the rolling update scenario is not faster. Therefore, there is no advantage in

performing a rolling update with DB2 V9.1 and higher.

Procedure

1. Log on to the first node as user <sapsid>adm.

2. To shut down the DB2 instance, enter the following command:

stopdb


4. To check if DB2 has been stopped, enter the following command:


lsrg –g db2_db2<dbsid>_0-rg

■ For HADR setup:



2012-10-22 CUSTOMER 53/82

lsrg –g db2hadr_<dbsid>-rg

In the output, check if the OpState is Offline.

5. To disable SA MP, enter the following command:

samctrl –MT

6. If the DB2 software is located on the shared disk, mount it.

7. Apply the DB2 Fix Pack to the first node as described in the appropriate SAP Note for the Fix Pack

installation:

DB2 Version SAP Note Number

DB2 UDB Version 8 603972

DB2 V9.1 978554

DB2 V9.5 1138549

DB2 V9.7 1363169

DB2 10.1 1708037

8. To remove the old HA policy, enter the following command:

rm /usr/sbin/rsct/sapolicies/db2/*

CAUTION

For DB2 V9.5 and higher:

You must not update the HA policy because it is automatically updated by db2setup.

9. To update the new HA policy, enter the following command:

cp <DB2_software_dir>/ha/tsa/* /usr/sbin/rsct/sapolicies/db2/.

10. If the DB2 software is located on the shared disk, unmount it.

11. Log on to the second node as user root.

12. If the DB2 software is located on the shared disk, mount it.

13. If the DB2 software is not located on the shared disk, you must apply the DB2 Fix Pack to this node

as described in the appropriate SAP Note (see the table in step 7).

CAUTION

You must not update the DB2 instance (db2iupdt) again because it was already updated in

step 6.

14. To remove the old HA policy, enter the following command:

rm /usr/sbin/rsct/sapolicies/db2/*

15. To update to the new HA policy, enter the following command:

cp <DB2_software_dir>/ha/tsa/* /usr/sbin/rsct/sapolicies/db2/.

16. If the DB2 software is located on the shared disk, unmount it.

17. To enable SA MP, enter the following command:

samctrl –MF


19. To start the DB2 instance, enter the following command:

startdb



54/82 CUSTOMER 2012-10-22






20. To check if DB2 is running again, enter the following command:


lsrg –g db2_db2<sapsid>_0-rg

■ For HADR setup:

lsrg –g db2hadr_<sapsid>-rg

OpState and Nominal State of the resource group come online in a short time.

CAUTION

If you share the DB2 software, you have to install the Fix Pack only once, but you must replace

the DB2 HA precanned policy on both nodes.

6.2 Updating SA MP Fix Packs

Procedure

For information about how to upgrade an SA MP installation to the latest Fix Pack, see Migrating the

Product in the document IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide that is

available at:

http://publib.boulder.ibm.com/tividd/td/

IBMTivoliSystemAutomationforMultiplatforms2.2.html

6.3 Upgrading from DB2 UDB Version 8 or from DB2 V9.1, V9.5, or V9.7

You use the following procedure to upgrade your database from DB2 UDB Version 8 or from DB2 V9.1

to DB2 V9.5 or higher. You also use this procedure to upgrade your database from DB2 V9.1, V9.5, or

V9.7 to DB2 10.1 or higher.

Prerequisites

If you enabled your DB2 Version 8 or DB2 V9.1 installation for high availability, you have to delete the

cluster before you upgrade. Otherwise, you have to reset the cluster afterwards. This step is necessary

because db2haicu has to set up the cluster to enable the DB2 HA feature.

Procedure


2. To shut down the DB2 instance, enter the following command:

stopdb


4. Change to the directory of SA MP setup scripts using the following command:

cd ~/samp_setup


6.2 Updating SA MP Fix Packs

2012-10-22 CUSTOMER 55/82



5. Run the cluster setup tool in interactive mode:

./sapdb2scscluster.sh –f ~/samp_setup/sapdb2scscluster.conf

6. Choose 4 – Delete Database Cluster.

7. Perform the upgrade to DB2 V9.5 or higher using the respective database upgrade guide.

NOTE

You have to ensure the SA MP software is updated according to the respective upgrade guide,

too.

8. Update the SA MP setup scripts using the following command:

cp <dvd_mount>/<platform>/SA_MP/scripts/* ~/samp_setup/.



10. Choose 2 – Create Database Cluster.

NOTE

If your cluster configuration file has to be updated as well, sapdb2scscluster.sh performs this

step and prompts for additional parameters.


6.3 Upgrading from DB2 UDB Version 8 or from DB2 V9.1, V9.5, or V9.7

56/82 CUSTOMER 2012-10-22

7 Uninstall

To uninstall the cluster and the software from the two database hosts, you have to perform the following

steps:

1. You uninstall the cluster [page 57].

2. You uninstall the SA MP software [page 58].

3. You delete the DB2 software [page 58].

7.1 Uninstalling the Database Cluster

To uninstall the cluster and to separate the two nodes, use the sapdb2scscluster.sh script.

Procedure1. Log on to the first node where you initially transferred the SA MP scripts to as user root (for more

information, see Setting Up the Database Cluster [page 36]).

2. If the second node becomes the server where the database is running (that is, the single database

server), move directory ~/samp_setup to the other node and log on to the other node as user

root.

3. Change to the directory using the following command:

cd ~/samp_setup



5. Choose 4 – Delete Database Cluster.

6. Change to the home directory using the following command:

cd ~

7. Delete the setup scripts using the following command:

rm –R ~/samp_setup

ResultThe cluster has been uninstalled and the node where you performed the steps mentioned above is able

to run DB2. Since the virtual host name and virtual IP address are no longer valid, you have to replace

all references to it with the host name or IP address of the single database server.

The sapdb2scscluster.sh script already updated the references in the SAP profile, the db2cli.ini

file, and sapdb2scscluster.sh restores the SAP startdb/stopdb scripts when you deleted the DB2

resource group. In addition, you have to replace all references listed for manual actions as described in

Changing the References to Virtual Host Name or IP Address [page 37].

7 Uninstall

7.1 Uninstalling the Database Cluster

2012-10-22 CUSTOMER 57/82

You can also remove the users db2<dbsid>, sap<sapsid>, and <sapsid>adm from the host where the

database instance is no longer running.

7.2 Uninstalling the SA MP Software

You uninstall the SA MP software using the uninstallSAM script from the SA MP software directory

on the DVD.

Procedure



3. Change to the directory where the SA MP software is located using the following command:

■ For DB2 Version 8 and DB2 V9.1:

cd <dvd_mount>/<platform>/SA_MP/software


cd <dvd_mount>/<platform>/ESE/disk1/db2/<platform>/tsamp

4. To uninstall the SA MP software, enter the following command:

./uninstallSAM

7.3 Deleting the Database Software

Depending on the database version that you are using, you have to delete the DB2 software as described

in the appropriate installation guide that you can find at:

■ For DB2 UDB Version 8:

http://service.sap.com/instguidesnw70 Installation Installation – SAP NetWeaver Systems

SAP NetWeaver 7.0 SR2 - Installation Guides

■ For DB2 Version 9.1, 9.5, 9.7, and 10.1:

http://service.sap.com/instguides <Your SAP NetWeaver release> Installation Installation –

SAP NetWeaver Systems SAP NetWeaver Installation Guides <your release>

7 Uninstall

7.2 Uninstalling the SA MP Software

58/82 CUSTOMER 2012-10-22



A Appendix

A.1 SA MP Policy for DB2

The following sections provide detailed information about:

■ File sapdb2scscluster.conf [page 59]

■ Script sapdb2scscluster.sh [page 63]

A.1.1 Cluster Configuration File sapdb2scscluster.conf

The sapdb2scscluster.conf policy file contains all parameters that are required to set up the DB2

cluster and the SAP cluster components properly. The following is a list of all parameters in the cluster

configuration file.

NOTE

The cluster setup tool creates the cluster configuration file and fills the parameters with values.

You do not need to edit the configuration file manually.

General Cluster Configuration Parameters

Parameter Description Value

TSA_DOMAIN_NAME Domain name of the cluster sap_<dbsid>db2

TSA_LICENSE_FILE Location of the downloaded SA MP license file

<home-root>/sam32.lic

TSA_TIEBREAKER_ IP_ADDRESS IP address of the network tie breaker (see Network Tiebreaker section in this chapter)

<ip-address>

TSA_DISK_HEARTBEAT Disk heartbeat, which separates network failures from node failures

[ <raw-device> | <LVID> | <MPATH>

| <PVID> ]

TSA_REMOTE_CMD Remote shell that you use for the setup [ ssh | rsh ]

TSA_USER_LIST Comma-separated list of users with the authority to start or stop the cluster and single resources in the cluster.

db2<dbsid>,<sapsid>adm

TSA_USER_GROUP_NAME The name of the group of TSA operators sagrp

DB2 Cluster Configuration Parameters


DB2_HOSTNAME_LIST Comma-separated list of the host names,

<host1>[,<host2>]

A Appendix


2012-10-22 CUSTOMER 59/82

Parameter Description Valueseparated by commas

DB2_CLUSTER_TYPE Cluster type: shared disk, HADR, or none

[ SAMP | HADR |NONE ]

DB2_INST_DIR Software installation directory for DB2

<db2-software-path>

DB2_COMM_PORTS Comma-separated list of DB2 communication ports

[ <name>:<port_num>[,<name>:<port_num> ]

DB2_HADR_PORTS Comma-separated list of the two DB2 HADR log shipping ports

[ <name>:<port_num>[,<name>:<port_num> ]

DB2_HADR_SYNC_MODE Synchronisation mode for HADR

[ SYNC | NEARSYNC | ASYNC | SUPERASYNC ]

DB2_HA_HOSTNAME Virtual host name of the database cluster

<virtual-hostname>

DB2_HA_IP_ADDRESS Virtual IP address of the database cluster

<virtual-ip>

DB2_DB2INSTANCE DB2 instance owner

<db2sid>

DB2_DIR_LIST Comma-separated list of DB2 directories on shared disks

[<mnt1>[,<mnt2>]]

DB2_LV_LIST Comma-separated list of logical volumes of raw shared disks (AIX only)

[<lv1>[,<lv2>]]

DB2_NETWORK_INTERFACE_LIST Comma-separated list of public HA network interfaces for DB2, at least one per node

<net>:<ip>:<sub>:<host>[|,<net>:<ip>:<sub>:<host>]

A Appendix


60/82 CUSTOMER 2012-10-22


DB2_GROUP_LIST List of user groups

<group>:<gid>:<local_group>[,<group>:<gid>:<local_group>]

DB2_USER_LIST Comma-separated list of users

<user>:<uid>:<home_dir>:<local_home_dir>:<shell>:<local_user>

<prim_group>[:<sec_group>]

[,<user>:<uid>:<home_dir>:<local_home_dir>:<shell>:<local_user>

<prim_group>[:<sec_group>]]

Graceful Cluster Switch (GCS) and Graceful Maintenance Tool (GMT): Configuration Parameters


DB2_GMT_AS_NR SAP application server number for remote function call (RFC call)

<instance-nr>

DB2_GMT_AS_HOST Host name of SAP application server <instance-hostname>

DB2_GMT_CLIENT RFC call: SAP login client <sap-client>

DB2_GMT_USER RFC call: SAP login user <sap-username>

DB2_GMT_TIMEOUT User-defined timeout for closing database connections <time-in-seconds>

DB2_GMT_CMD Graceful cluster switch (GCS) executes failover automatically. Graceful maintenance tool (GMT) requires exit script.

AUTO | EXIT

DB2_GMT_EXIT_SCRIPT Name of exit script <shell-script-name>

SAP Cluster: Configuration Parameters


SAP_SID SAP system ID <SAPSID>

SAP_CLUSTER_TYPE SAP cluster type NONE | SCS

SAP_HOSTNAME_LIST List of SAP host names <host1>[,<host2>]

SAP_NETWORK_INTERFACE_LIST Comma-separated list of public high-availability network interfaces for SAP

<net>:<ip>:<sub>:<host>

[|,<net>:<ip>:<sub>:<host>]

SAP_SERVER_TYPE SAP server type ABAP | J2EE | ABAP_J2EE

SAP_CI_HOSTNAME Host name of the SAP central instance

<sap-ci-hostname>

SAP_VERSION SAP kernel version <sap-kernel-version>

SAP Application Server: Configuration Parameters


SAP_CI_HA_IP_ADDRESS Virtual IP of the application server <as-virtual-ip>

SAP_CI_HA_IP_MASK Network mask for the virtual IP <as-netmask>

SAP_CI_INST_NR Instance number of the application server <as-inst-nr>

SAP_CI_INST_DIR Installation directory of the application server <as-inst-dir>

SAP_CI_MP Mount point of the application server <as-mount>

SAP ABAP Central Services: Configuration Parameters


SAP_ASCS_HA_HOSTNAME Virtual hostname of the ABAP central instance <ascs-v-host>

A Appendix


2012-10-22 CUSTOMER 61/82


SAP_ASCS_HA_IP_ADDRESS Virtual IP address of the ASCS <ascs-v-ip>

SAP_ASCS_HA_IP_MASK Network mask for the virtual IP <ascs-netmaskt>

SAP_ASCS_INST_NR Instance number of the ASCS instance <ascs-inst-nr>

SAP_ASCS_INST_DIR Installation directory of the ASCS instance <ascs-inst-dir>

SAP_AERS_INST_NR Instance number of the AERS instance <aers-inst-nr>

SAP_AERS_INST_DIR Installation directory of the AERS instance <aers-inst-dir>

SAP_AERS_HA_HOSTNAME Virtual host name of the AERS instance <aers-v-host>

SAP Java Central Services: Configuration Parameters


SAP_JSCS_HA_HOSTNAME Virtual host name of the Java central instance <jscs-v-host>

SAP_JSCS_HA_IP_ADDRESS Virtual IP address of JSCS <jscs-v-ip>

SAP_JSCS_HA_IP_MASK Network mask for the virtual IP <jscs-netmaskt>

SAP_JSCS_INST_NR Instance number of the JSCS instance <jscs-inst-nr>

SAP_JSCS_INST_DIR Installation directory of the JSCS instance <jscs-inst-dir>

SAP_JERS_INST_NR Instance number of the JERS instance <jers-inst-nr>

SAP_JERS_INST_DIR Installation directory of the JERS instance <jers-inst-dir>

SAP_JERS_HA_HOSTNAME Virtual host name of the JERS instance <jers-v-host>

SAProuter: Configuration Parameters


SAP_ROUTER_HA_HOSTNAME Virtual hostname of the SAProuter <sr-v-host>

SAP_ROUTER_HA_IP_ADDRESS Virtual IP of the SAProuter <sr-v-ip>

SAP_ROUTER_HA_IP_MASK Netmask of the SAProuter <sr-netmask>

SAP_ROUTER_ROUTTAB 'Configuration file of the SAProuter <path-to-saprouttab>

SAP Web Dispatcher: Configuration Parameters


SAP_WEBDISP_HA_SID SAP system ID of the SAP Web Dispatcher instance

<wd-inst-nr>

SAP_WEBDISP_HA_HOSTNAME Virtual host name of the SAP Web Dispatcher <wd-v-host>

SAP_WEBDISP_HA_IP_ADDRESS Virtual IP of the SAP Web Dispatcher <wd-v-ip>

SAP_WEBDISP_HA_IP_MASK Netmask of the SAP Web Dispatcher <wd-netmask>

SAP_WEBDISP_DIR Installation directory of the SAP Web Dispatcher

<exe-directory-of-sapwebdisp>

Network Tiebreaker

If the cluster is split into two or more subclusters (for example, because of network problems), only

one subcluster must have the authority to manage the resources of the cluster. Otherwise, data might

be corrupted when it is accessed by several nodes at the same time and the READ or WRITE operations

are not synchronized in any way.

A Appendix


62/82 CUSTOMER 2012-10-22

To ensure correct behavior in the event of a cluster split, you need a tiebreaker. Using the tiebreaker

technology, only one subcluster gets the quorum to manage the resources.

The network tiebreaker uses the following rule:

The subcluster that can be accessed from outside of the cluster gets the quorum. The network tiebreaker

uses an external IP address to resolve a tie. It uses ICMP echo requests (ping) to check the network

connectivity to an IP address that is outside of the cluster.

If the network tiebreaker is able to ping the IP address, this part of the cluster gets the quorum and

manages the resources. We recommend that you use the IP address of the gateway for the network

tiebreaker. By choosing the gateway as the tiebreaker, you ensure that all nodes that can ping the

tiebreaker can communicate with each other via the gateway. These nodes should be in the same

subcluster after a cluster split.

NOTE

Make sure that the ICMP echo request and ICMP echo reply messages are not rejected by any

firewall settings for the tiebreaker and the cluster nodes.

A.1.2 Cluster Setup Script sapdb2scscluster.sh

The script sapdb2scscluster.sh sets up the cluster according to the cluster configuration file. It

configures SA MP according to the data contained in the sapdb2scscluster.conf file and creates all

required resources, resource groups, relationships between the resources, and installs the high-

availability policy files on the cluster nodes.

SYNTAX

./sapdb2scscluster.sh [-h] [-tl <n>] [-l <LogFile>] [-f <ConfigFile>] [-[db|scs|wd|sr] -[show|create|state|switch|delete]]

Options

Parameter Description

-h Prints the usage syntax

-l <logfile> Specifies the log file name. The default log name is sapdb2scscluster.log.

-f <configfile> Specifies the configuration file name. By default, the script looks for sapdb2scscluster.conf in the current directory.

-tl <n> Specifies the trace level: 1 – Debug (Default), 2 – Warning, 3 – Error

-db -show Show and edit database cluster configuration

-db –create Create database cluster

-db -state Show database cluster state

-db -switch Graceful database cluster switch (micro-outage)

-db –delete Delete database cluster

-scs -show Show and edit SAP central services configuration

A Appendix


2012-10-22 CUSTOMER 63/82


-scs -create Create SAP central services cluster

-scs -state Show state of SAP central services cluster

-scs -delete Delete SAP central services cluster

-wd -show Show and edit SAP Web Dispatcher configuration

-wd -create Create SAP Web Dispatcher cluster

-wd -state Show state of SAP Web Dispatcher cluster

-wd -delete Delete SAProuter cluster

-sr -show Show and edit SAProuter configuration

-sr -create Create SAProuter cluster

-sr -state Show state of SAProuter cluster

-sr -delete Delete SAProuter cluster

Example

The following are examples of how you can use the script sapdb2scscluster.sh and its options:

■ Start cluster setup menu: ./sapdb2scscluster.sh

■ Show database cluster configuration immediately: ./sapdb2scscluster.sh -db -show

■ Start graceful cluster switch immediately: ./sapdb2scscluster.sh -db -switch

■ Create SAP central services cluster immediately (requires valid configuration): ./

sapdb2scscluster.sh -scs -create

A.2 Syntax of SA MP Setup Scripts

The following sections provide detailed information about:

■ Script prereqSAM [page 64]

■ Script installSAM [page 65]

■ Script uninstallSAM [page 66]

A.2.1 Script prereqSAM

The prereqSAM script determines the prerequisites of SA MP on this node. It checks the level of the

operating system, architecture, and distribution as well as the presence of required software packages.

SYNTAX

prereqSAM [--nodeleteinstlog] [--silent] [-d <inst-pkg-dir>] [-l <log-file>]

Options


--nodeleteinstlog Prevents removal of old logs. Since logs carry a Process ID (PID) in their name, it is not likely that old logs are overwritten.

A Appendix


64/82 CUSTOMER 2012-10-22


--silent Suppresses output to the command line

-d <inst-pgk-dir> Allows prerequisite checking based on NLS files in <inst-pkg-dir> although prereqSAM is not in the package directory. prereqSAM is not dependent on the packages to be installed, but needs the directory for its message files.

-l <logfile> Logs to file <log-file> instead of /tmp/prereqSAM.<pid>.log

Return Codes

Return Code Meaning

0 The version of the operating system is supported and all prerequisite packages were found installed at the correct version. The log file contains names and versions of the installed packages.

20 An installed package does not have the correct version. The log file contains the names and versions of the missing packages.

21 Package has not been found installed

22 Operating system version is not supported

23 Unable to conduct prerequisite checking due to a reason described in more detail in the log. Reason might be that a file is missing.

A.2.2 Script installSAM

The installSAM script checks the prerequisites once again and finally installs the SA MP software on

this machine.

SYNTAX

installSAM [--force] [--noliccheck] [--nodeleteinstlog] [--silent] [--upgrade] [-d <inst-pkg-dir>] [-l <logfile>]

Options


--force Allows downgrading package sam if the installed version is higher than the version of the supplied package

--noliccheck Allows first time installation even if no license file is supplied, or allows upgrade if no installed license is found. The fact is recorded in the log.

--nodeleteinstlog Prevents removal of old logs. Since logs contain a PID in their name, it is unlikely that old logs are overwritten.

--silent> Suppresses output to the command line

--upgrade Allows to upgrade SA MP if - -silent is specified

-d <inst-pgk-dir> Allows installing packages from directory <inst-pkg-dir> although installSAM is not in the package directory

-l <logfile> Logs to file <logfile> instead of /tmp/installSAM.<pid>.log

A Appendix


2012-10-22 CUSTOMER 65/82

Return Codes

Return Code Meaning

0 installSAM including prerequisite checking and installation completed successfully

1 Package installer returned with return code not0, return code and message can be found in the log.For AIX, the package installer is installp.For Linux, the package installer is rpm.

2 Package sam is already installed at the same version. If - - force is specified, the installation overwrites the same version.A warning is logged and the installation status is returned.

3 Package sam is already installed at a higher version. If – -force is specified, the installation overwrites the higher version.A warning is logged and the installation status is returned.

4 Package sam is already installed at a lower version than package version and option - - silent is specified.If - - upgrade is specified, an upgrade from a lower version is performed and the upgrade status is returned.

5 The node on which the installation task is required is online. The task is not performed.

6 SA MP base license file is not found or no installed license is detected.

7 installSAM was unable to continue because directories or files could not be detected or other conditions make it fail.

2x Prerequisite checking conducted by prereqSAM failed (see Script prereqSAM [page 64])

A.2.3 Script uninstallSAM

The uninstallSAM script removes the SA MP software.

SYNTAX

uninstallSAM [--nodeleteinstlog] [--silent] [-d <inst-pkg-dir>] [-l <log-file>]

Options

Parameters Description

--nodeleteinstlog Prevents removal of old logs. Since logs carry a PID in their name, it is not likely that old logs are overwritten.

--silent Suppresses output to the command line

-d <inst-pgk-dir> Allows uninstall from directory <inst-pkg-dir> although uninstallSAM is not in the package directory

-l <logfile> Logs to file <log-file> instead of /tmp/prereqSAM.<pid>.log

A Appendix


66/82 CUSTOMER 2012-10-22

Return Codes

Return Code Meaning

0 uninstallSAM completed successfully

1 Error occurred during uninstall

2 The domain is still online. Uninstall stopped.

3 Uninstall is not possible

A.3 Troubleshooting

A.3.1 Troubleshooting Reference Documentation

For troubleshooting and diagnosis information, see the following documentation:

■ IBM Tivoli System Automation for Multiplatforms – Base Component User’s Guide, section Appendix –

Troubleshooting at:


halgre20.pdf

■ IBM Reliable Scalable Cluster Technology (RSCT) – Diagnosis Guide at:


This guide provides information that helps you to inspect the RSCT subsystems. In addition, this

guide covers a detailed description list of messages of the subsystems.

A.3.2 Requesting SAP Support

To request SAP support, open a message on SAP Service Marketplace using component BC-DB-DB6.

A.3.3 Symbol Resolution Failed for db2start on AIX

If you have installed DB2 on the shared disk on AIX, the following error can occur when you start DB2:

SYNTAX

> db2startCould not load program db2start:Symbol resolution failed for /usr/lib/threads/libc.a[aio_64.o] because:Symbol kaio_rdwr64 (number 0) is not exported from dependent module /unix.Symbol listio64 (number 1) is not exported from dependent module /unix.Symbol acancel64 (number 2) is not exported from dependent module /unix. Symbol iosuspend64 (number 3) is not exported from dependent module /unix.Symbol aio_nwait (number 4) is not exported from dependent module /unix.Symbol aio_nwait64 (number 5) is not exported from dependent module /unix. Symbol aio_nwait_timeout (number 6) is not exported from dependent module /unix.Symbol aio_nwait_timeout64 (number 7) is not exported from dependent module /unix. System error: Error 0 Examine .loader section symbols with the 'dump -Tv' command.

A Appendix

A.3 Troubleshooting

2012-10-22 CUSTOMER 67/82




The error occurs if you do not install DB2 on the node where you did not use db2setup and you do

not have asynchronous I/O (AIO) enabled. Normally, db2setup enables AIO for you during setup.

Solution

1. Check if AIO is enabled using the following command:

lsdev –Cc aio

If AIO is enabled, the output is as follows:

aio0 Available Asynchronous I/O (Legacy)

If AIO is not enabled, the output is as follows:

aio0 Defined Asynchronous I/O (Legacy)

2. Enable AIO as follows:

1. Log on to the node as user root.

2. Open AIO configuration in smitty using the following command:

smitty aio

3. Enable AIO by the topic "Configure defined aio".

A.3.4 DB2 Immediately Stops After the db2start/startdb/startjeedb Command

Problem

After you have installed SA MP and configured SA MP to manage DB2, the native DB2 command

db2start becomes obsolete. If you use db2start to start a DB2 instance, SA MP does not know that

you want to start DB2 on this node. Once SA MP monitors that DB2 is started on this node, it immediately

stops DB2 according to the rule “this resource is supposed to be offline”.

On Linux and AIX (if syslogd is configured), an entry in the system log shows that db2_stop.ksh is

invoked to bring DB2 down.

During the setup of the cluster, the SAP scripts startdb and startj2eedb are replaced by the script

sapdb2post.sh. The new scripts use SA MP commands to start DB2 via SA MP commands.

Solution

Make sure that the scripts that you use to start DB2 are the same as on the SA MP setup images.

A.3.5 DB2 Immediately Starts After the db2stop/stopdb/stopj2eedb Command

Problem

When you have installed SA MP and configured SA MP to manage DB2, the native DB2 command

db2stop becomes obsolete. If you use db2stop to stop a DB2 instance, SA MP does not know that you

want to stop DB2 on this node. Once SA MP monitors that DB2 is stopped on this node, it immediately

A Appendix

A.3 Troubleshooting

68/82 CUSTOMER 2012-10-22

starts DB2 according to the rule “this resource is supposed to be online”. On Linux and AIX (if syslogd is

configured), an entry in the system log shows that db2_start.ksh is invoked to start DB2. During the

setup of the cluster, the SAP scripts stopdb and stopj2eedb are replaced by the script

sapdb2post.sh. The new scripts use SA MP commands to stop DB2 using SA MP commands.

Solution

Make sure that the scripts that you use to stop DB2 are the same as on the SA MP setup images.

A.4 Graceful Cluster Switch (Micro–Outage)

A.4.1 Basic Concept of the Graceful Cluster Switch

Graceful cluster switch means that you perform a planned database failover with minimal system

outage. The benefit of a planned database failover in contrast to an unplanned failover is that you can

decide when to start the failover process. The failover should be performed during a time window when

there is no or only little traffic on the database because the failover process leads to a rollback of all in-

flight SQL transactions. In such a planned failover scenario, the currently active SAP transactions are

terminated.

With a graceful cluster switch, you can significantly reduce the number of rolled back transactions.

The graceful cluster switch only works for the SAP ABAP application server and not for long-running

transactions. If there are no long-running transactions, the database failover is even fully transparent.

The graceful cluster switch is based on the micro-outage feature in the SAP database interface (DBSL)

for DB2 for Linux, UNIX, and Windows. The DBSL micro-outage feature puts SAP applications on hold

at transaction boundary and disconnects them from the database. In this way, no new requests are

accepted by the SAP work processes and they disconnect from the database. When all SAP work processes

are disconnected, the database is in a consistent state and you can perform the failover to the standby

database very fast. After the cluster switch, the SAP work processes reconnect to the database and

unfreeze the SAP applications.

NOTE

This special DBSL feature is called micro-outage to make you aware that there is still a small outage

due to the waiting time of the disconnection, the actual failover, and the reconnect process.

Furthermore, long-running transactions cannot be taken into account because the complete

failover process has to be performed within a runtime specified by the profile parameter rdisp/

max_wprun_time.

The cluster setup tool automatically detects and lists appropriate output of Java connections, remote

connections, and long-running transactions. If the cluster setup tool detects at least one of the

mentioned connections, you can either stop the failover process so that the SAP system can continue

processing without any rolled back transactions, or you can terminate all remaining SQL transactions

and the cluster switch is initiated.

A Appendix


2012-10-22 CUSTOMER 69/82

A.4.2 Performing a Graceful Cluster Switch

Prerequisites

■ You must use SAP kernel version 6.40 or higher.

■ For SAP systems with an SAP kernel up to version 7.11, the library of the SAP database interface

must contain the following patch:

DB6: patch collection 03/10

■ You need the following ABAP RFC functions:

DB6_GCS_ACTIVATE and DB6_GCS_NOTIFY.

For more information, see SAP Note 1443426

■ You must use the cluster setup script sapdb2scscluster.sh version 6 or higher that is attached

to SAP Note 960843.

Procedure

You use the following procedure to perform a planned database failover, that is, a graceful cluster

switch.


2. Change to the directory where the cluster setup tool is located.

3. Start the cluster setup tool:


4. From the menu, choose Graceful Cluster Switch.

The cluster setup tool checks if the required parameters are already configured in the configuration

file. If the required parameters are not already configured, the cluster setup tool prompts you for

the following required input parameters:

■ The client of your SAP logon user

■ Your SAP logon user

■ The SAP logon user requires the authority to change profile parameters.

■ Cluster switch timeout in seconds (you can define the maximum using SAP profile

parameter rdisp/max_wprun_time)

■ If the cluster switch feature cannot close and commit all open SQL transactions in the specified

timeout period, the cluster setup tool lists all open database connections together with ABAP

reports that are still active and asks you how you want to continue, that is, if you want to abort

or force failover.

■ The password of your SAP logon user.

NOTE

If you want to edit parameters that were already saved, choose Show and Edit Database

Configuration from the menu.

After you have specified all required parameters, the script checks if all requirements are fulfilled

for the graceful cluster switch. Then, the DBSL micro outage feature is enabled and freezes the

A Appendix


70/82 CUSTOMER 2012-10-22



SAP GUI so that no new requests can be sent to the database. Furthermore, the script waits for all

in-flight transactions to finish and to safely disconnect the database connection. As soon as all

connections are disconnected, the script automatically initiates the DB TAKEOVER HADR command.

If not all connections are closed in the specified timeout period, the cluster setup tool lists open

connections that could not be stopped (for example, long-running transactions) and asks if you

want to force the connections or cancel the failover process. A forced failover results in a rollback

of the in-flight transactions that are still active.

Once the failover is executed, the cluster setup tool disables the DBSL micro–outage feature that

unfreezes the SAP applications and continues the normal transaction processing.

A.4.3 Cluster Switch Examples

This section provides example procedures of how to perform the following:

■ A graceful cluster switch while an SAP client copy is running

■ A cluster switch with long-running transactions

Graceful Cluster Switch While an SAP Client Copy is Running

You perform the client copy as described in section Performing the Client Copy in the installation guide for

your SAP NetWeaver release that is available at:

http://service.sap.com/instguidesnw < Your SAP NetWeaver Release > Installation Installation –

SAP NetWeaver Systems .

In this example, client 000 is copied to client 100 using SAP transaction SCCL as shown in the following

figure:

Figure 5: Start Client Copy

On the Client Copy - Copy a Client screen, choose the Start Immediately pushbutton and wait until the client

copy has finished the analysis phase and is processing tables as shown in the following figure:

A Appendix


2012-10-22 CUSTOMER 71/82


Figure 6: Running Client Copy

Start the cluster setup tool in a shell and choose the graceful cluster switch task from the menu or by

using the following command:

root# ./sapdb2scscluster.sh -db -switch

Result

The following is an example of a successful script output for an SAP client copy process:

SYNTAX

Read configuration file Check general configuration Check database cluster configuration : OKStarting graceful cluster switch process Enter Parameter for Graceful Cluster Switch [1] DB2_GCS_CLIENT = 001 [2] DB2_GCS_USER = DDIC [3] DB2_GCS_TIMEOUT = 300 [4] SAP_CI_HOSTNAME = db6xenvci SAP User Password (Input Hidden): Check Prerequisites Determine HADR Roles : OK Checking HADR Peer State : OK Checking SAP DBSL feature prerequisites: : OK Graceful Cluster Switch supported: : OK Checking for transactions running for more than 60 seconds : OK Enable micro outage feature of DBSL : OK Closing all database connections...

A Appendix


72/82 CUSTOMER 2012-10-22

Status: Open Connections 0 All connections closed. Starting failover process... Execute DB2 TAKEOVER: : OK Determine HADR Roles : OK Disable micro outage feature of DBSL: : OKCluster Switch Start : Wed Mar 3 09:26:41 CET 2010Cluster Switch End : Wed Mar 3 09:31:32 CET 2010Setup completed successfully../sapdb2scscluster.sh finished on Wed Mar 3 09:31:33 CET 2010

The following figure shows the point in time where the SAP application is frozen and the DB

TAKEOVER command is executed. Note that at this specific point in time, the SAP status bar does not

make any progress. The processing continues after the failover and is not canceled.

Figure 7: Freeze SAP and Start Takeover

Cluster Switch with Long-Running Transactions

In this example, the limitations of the graceful cluster switch with long-running transactions are shown.

Most of the time, you can use SAP transaction SGEN to simulate long-running transactions, but this

depends heavily on the currently compiled ABAP code.

In your SAP system, call transaction SGEN and regenerate, for example, existing loads as shown in the

following figure:

A Appendix


2012-10-22 CUSTOMER 73/82

Figure 8: SAP Load Generator

On the SAP Load Generatorscreen, choose the Continue pushbutton and select one or even all servers as

shown in the following figure:

Figure 9: Select Server

A Appendix


74/82 CUSTOMER 2012-10-22

On the SAP Select Server screen, select one or even all servers and choose the Continue pushbutton.

On the following SAP Start Job screen, choose the Start Job Directly pushbutton:

Figure 10: Start Job

Now start the cluster setup tool in a shell and choose the graceful cluster switch task from the menu

or with the following command:

root# ./sapdb2scscluster.sh -db -switch

Result

The following is an example of the script output if the script detects long-running transactions. The

script generates a warning and asks if you want to continue the failover using the DB2 QUIESCE

command, which leads to a rollback of the still active in-flight transaction:

SYNTAX

Read configuration file Check general configuration Check database cluster configuration : OKStarting graceful cluster switch process Enter Parameter for Graceful Cluster Switch [1] DB2_GCS_CLIENT = 001 [2] DB2_GCS_USER = DDIC [3] DB2_GCS_TIMEOUT = 300 [4] SAP_CI_HOSTNAME = db6xenvci SAP User Password (Input Hidden): Check Prerequisites Determine HADR Roles : OK

A Appendix


2012-10-22 CUSTOMER 75/82

Checking HADR Peer State : OK Checking SAP DBSL feature prerequisites: : OK Graceful Cluster Switch supported: : OK Checking for transactions running for more than 60 seconds : WARNING***************WARNING: Found Long Running Transctions******************** COMMENT APPL_NAME AGENT_ID UOW_START_TIME RUNTIME SAP_USER SAP_WP_TYPE SAP_REPORT-------- ---------- --------- --------------- -------- --------- ------------ ----LONGRUNNER dw.sapHA5_DVEBMGS30 162 2010-03-04-10.58.21 14 DDIC DIA SAPLSUGPLONGRUNNER db2jcc_application 163 2010-03-04-14.16.11 6350 - - - 2 record(s) selected.WARNING: Long running transactions are active which might be canceled (rolled back)! ****************************************************************************************Checking for Java Connections : WARNING ******************* WARNING: Found Java Connections ******************************SAPHA5DB db2jcc_applica 164 10.17.202.144.18077.10030413153 HA5 1SAPHA5DB db2jcc_applica 163 10.17.202.144.17821.10030413152 HA5 1SAPHA5DB db2jcc_applica 166 10.17.202.144.5291.100304131612 HA5 1WARNING: 3 Java connections exists (DB2 QUIESCE required)! **********************************************************************************Enable micro outage feature of DBSL : OK Closing all database connections... Status: Open Connections 4 Timeout Occured. The following Connections still exist: List all open database connections APPL_NAME AGENT_ID AUTHID UOW_START_TIME STATUS SAP_USER SAP_APPL_SERVER SAP_WP_TYPE SAP_REPORT---------- --------- ------- -------------- ------ -------- --------------- ----------- ----------db2jcc_application 163 SAPHA5DB 2010-03-04-14.16.11 UOWWAIT - db6xen023 - -db2jcc_application 164 SAPHA5DB 2010-03-04-14.20.34 UOWWAIT - db6xen023 - -db2jcc_application 166 SAPHA5DB 2010-03-04-16.03.26 UOWWAIT - db6xen023 - -dw.sapHA5_DVEBMGS30 864 SAPHA5 2010-03-04-16.01.17 UOWWAIT DDIC db6xen022 ptype BTC RSPARAGENER8 Do you want to force failover (rollback of running transactions)? [Yes|No]: yes Execute DB2 QUIESCE for HA5 : OK Execute DB2 TAKEOVER : OK Determine HADR Roles : OK Execute DB2 UNQUIESCE : OK Disable micro outage feature of DBSL : OKCluster Switch Start : Thu Mar 4 16:01:45 CET 2010

A Appendix


76/82 CUSTOMER 2012-10-22

Cluster Switch End : Thu Mar 4 16:02:22 CET 2010Action finished. Press Enter to continue ...

A.5 Disclaimer

By following links to IBM Documentation you are leaving the SAP product documentation and

entering a site that is not hosted by SAP. By using the link, YOU AGREE that unless expressly stated

otherwise in your agreements with SAP you are about to access an external webpage which is not part

of SAP’s offering:

(i) the content of the linked-to site and any further external site is not product documentation and

you may not infer any product documentation claims against SAP based on this information;

(ii) the fact that SAP provides links to external sites does not imply that SAP agrees or disagrees with

the contents and information provided on such sites. SAP does not guarantee the correctness of the

information provided.

(III) SAP DOES NOT GIVE ANY REPRESENTATION REGARDING THE QUALITY, SAFETY,

SUITABILITY, ACCURACY OR RELIABILITY OF ANY EXTERNAL WEBPAGE OR ANY OF

INFORMATION, CONTENT AND MATERIALS PROVIDED THEREON;

(IV) YOU VISIT THOSE EXTERNAL WEBPAGES ENTIRELY AT YOUR OWN RISK. SAP SHALL NOT

BE DIRECTLY OR INDIRECTLY RESPONSIBLE OR LIABLE FOR ANY DAMAGE OR LOSS CAUSED

OR ALLEGED TO BE CAUSED BY OR IN CONNECTION WITH YOUR USE OF OR RELIANCE ON

ANY CONTENT, GOODS OR SERVICES AVAILABLE ON OR THROUGH ANY SUCH LINKED

WEBPAGE.

A Appendix

A.5 Disclaimer

2012-10-22 CUSTOMER 77/82

Typographic Conventions

Example Description

<Example> Angle brackets indicate that you replace these words or characters with appropriate entries to make entries in the system, for example, “Enter your <User Name>”.

ExampleExample

Arrows separating the parts of a navigation path, for example, menu options

Example Emphasized words or expressions

Example Words or characters that you enter in the system exactly as they appear in the documentation

http://www.sap.com Textual cross-references to an internet address

/example Quicklinks added to the internet address of a homepage to enable quick access to specific content on the Web

123456 Hyperlink to an SAP Note, for example, SAP Note 123456

Example ■ Words or characters quoted from the screen. These include field labels, screen titles, pushbutton labels, menu names, and menu options.

■ Cross-references to other documentation or published works

Example ■ Output on the screen following a user action, for example, messages ■ Source code or syntax quoted directly from a program ■ File and directory names and their paths, names of variables and parameters, and

names of installation, upgrade, and database tools

EXAMPLE Technical names of system objects. These include report names, program names, transaction codes, database table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE

EXAMPLE Keys on the keyboard

78/82 CUSTOMER 2012-10-22

http://www.sap.com



SAP AGDietmar-Hopp-Allee 16

69190 WalldorfGermany

T +49/18 05/34 34 34F +49/18 05/34 34 20

www.sap.com

© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the United States and other countries.Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and other countries.Oracle and Java are registered trademarks of Oracle and its affiliates.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems Inc.HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc.IOS is a registered trademark of Cisco Systems Inc.RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are trademarks or registered trademarks of Research in Motion Limited.Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or registered trademarks of Google Inc.INTERMEC is a registered trademark of Intermec Technologies Corporation.Wi-Fi is a registered trademark of Wi-Fi Alliance.Bluetooth is a registered trademark of Bluetooth SIG Inc.Motorola is a registered trademark of Motorola Trademark Holdings LLC.Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company.Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company.

2012-10-22 CUSTOMER 79/82

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company.All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

DisclaimerSome components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressly prohibited, as is any decompilation of these components.Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way.

Documentation in the SAP Service MarketplaceYou can find this document at the following address: http://service.sap.com/instguides

80/82 CUSTOMER 2012-10-22


SAP AGDietmar-Hopp-Allee 1669190 WalldorfGermanyT +49/18 05/34 34 34F +49/18 05/34 34 20www.sap.com

© Copyright 2012 SAP AG. All rights reserved.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

ibm db2 high availability solution ibm tivoli system automation

Documents

database cluster setup

sap cluster setup22chapter

database cluster failover485

cluster setup tool342012

sa mp software

sa mp license

database server304

sap central services