ibm db2 high availability solution%3a ibm tivoli system automation for multi platforms (03_2008)
TRANSCRIPT
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 1/68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 2/68
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 Description1.0 2006-08-11 Initial version
1.02 2008-03-10 Updated version
1.03 2010-05-18 Updated version
2 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 3/68
Table of Contents
Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 N aming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Virtual Host Name and Virtual IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Reusing the Host Name and IP Address of a Single Database
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Setting Up a New Virtual Host Name and IP Address . . . . . . . . . . . . . . . . . . . . 16
2.4 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Restrictions for Shared Disk Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Restrictions for HADR Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Setting Up File Systems for Shared Disk Scenario . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Setting Up the ssh/rsh Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Changing the Password of the SAP Connect User . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Configuration of Log Archiving for HADR Setup . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Downloading the Latest DB2 Software and SA MP License . . . . . . . . . . . . . . . . 234.2 Installing the Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Setting Up a Standby Database Server Using Homogeneous System
Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Setting Up the High Availability Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Installing the SA MP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2 Installing the SA MP License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.3 Setting Up the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.4 Changing References to the Virtual Host Name or IP Address . . . . . . . . . . . . . 30
2010-05-18 PUBLIC 3 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 4/68
4.4.5 Enabling HADR Takeover by Force (DB2 Version 8.2 and V9.1
only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 5 Post-Installation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1 Checking the Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Checking the Cluster Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Performing a Backup of the SA MP Core Policy . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 6 Updating the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1 Updating the Database Fix Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Updating SA MP Fix Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3 Upgrading from DB2 UDB Version 8 or DB2 V9.1 . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 7 Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1 Uninstalling the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Uninstalling the SA MP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Deleting the Database Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter A Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1 SA MP Policy for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1.1 File sapdb2cluster.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.1.2 Script sapdb2cluster.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2 Syntax of SA MP Setup Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2.1 Script prereqSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2.2 Script installSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2.3 Script uninstallSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3.1 Troubleshooting Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3.2 Requesting SAP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3.3 Symbol Resolution Failed for db2start on AIX . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3.4 DB2 Immediately Stops After the db2start/startdb/startjeedb
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3.5 DB2 Immediately Starts After the db2stop/stopdb/stopj2eedb
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4 Graceful Cluster Switch (Micro–Outage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4.1 Basic Concept of the Graceful Cluster Switch . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4.2 Performing a Graceful Cluster Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.4.3 Cluster Switch Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 5/68
1 Introduction
Purpose
This document describes how to set up a high-availability (HA) solution for IBM DB2 for Linux, UNIX
and Windows (version 8, version 9.1 and 9.5) using IBM Tivoli System Automation for Multiplatforms
(SA MP) when your operating system is AIX 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. Additional licenses
are required to set up the SAP central instance for HA.
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
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. In the case of a
failure, the other node 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. Both are kept in sync and, in the case of a failure, the standby database server takes
over the workload.
The two setup types are described in more detail below.
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
1 Introduction
2010-05-18 PUBLIC 5 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 6/68
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 case of a 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
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. In the case of a crash of the primary database server,
SA MP initiates the HADR takeover by the standby server and also ensures that the virtual IP address
is assigned to the new primary server.
1 Introduction
6 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 7/68
DB2 also provides a client reroute feature. This feature ensures that all clients know the standby database
server. In the case of a 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 9].
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
If the primary server crashes, the takeover only takes 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 have the choice
for three different synchronization modes for HADR:■ SYNC (synchronous)
This mode provides the greatest protection against transaction loss, and using its 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.
■ 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
1 Introduction
2010-05-18 PUBLIC 7 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 8/68
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 the highest chance of transaction loss if the primary system fails. It also has the
shortest transaction response time among the three modes. 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.
RECOMMENDATION
We recommend that you use NEARSYNC for the HADR synchronization mode.
CAUTION
You must ensure that your network can manage the workload for the synchronization fast.
Otherwise, the network becomes a bottleneck for the performance of the database server
since the primary database has to wait for acknowledgment of the shipped log data in the
SYNC and NEARSYNC modes or it has to wait to send new messages to the standby server in the
ASYNC mode if 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.
High Availability Feature (HA) in DB2 Version 9.5
With DB2 V9.5, a new Cluster Management API was introduced. 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 clustermanager 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 to bring the resource back online or offline. From the user point of
view, 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 mounts the new disk at the other node, too.
In addition, the new tool DB2 high availability instance configuration utility (db2haicu) was introduced
that you can use to enable HA and to configure the cluster manager in your system environment.
1 Introduction
8 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 9/68
CAUTION
The db2haicu tool also provides an interactive mode for cluster setup. For SAP systems, you still
have to use the sapdb2cluster.sh script to set up the cluster. The sapdb2cluster.sh uses
db2haicu for the cluster setup and ensures that the cluster is set up in a supported way so thatstartdb and stopdb scripts will work.
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
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 NetWeaver 7.0
SR3 <ABAP; ABAP+Java; Java> on
<OS>: IBM DB2 for Linux, UNIX, and
Windows
http://service.sap.com/instguidesnw70 Installation
Database Upgrade Guide – Migration to
Version 9.5 of IBM DB2 for Linux, UNIX,
and Windows
http://service.sap.com/instguides Database Upgrade DB2 UDB
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
http://publib.boulder.ibm.com/tividd/td/ITSAFL/
SC33-8274-01/en_US/PDF/HALBRE01.pdf
1 Introduction
1.1 Reference Documentation
2010-05-18 PUBLIC 9 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 10/68
Document URL
IBM Tivoli System Automation for Multiplatforms -
End-to-End Automation Management Component
Administrator’s and User’s Guide
http://publib.boulder.ibm.com/tividd/td/ITSAFL/
SC33-8275-00/en_US/PDF/HALEAU00.pdf
IBM Tivoli System Automation for Multiplatforms -
End-to-End Automation Management Component
Reference
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
https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/
index.jsp?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
https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/
index.jsp?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 HighAvailability 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
1 Introduction
1.1 Reference Documentation
10 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 11/68
SAP Note Number Title
960843 DB6: Installation of System Automation for Multiplatforms
1.2 Naming Conventions
In this document, the following naming conventions apply for the terms and variables used:
Database Terminology
Term Abbreviation
IBM DB2 9.7 for Linux, UNIX, and Windows DB2 9.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
2010-05-18 PUBLIC 11 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 12/68
This page is left blank for documents that are printed on both sides.
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 13/68
2 Planning
Make sure that you read the following sections:
■ Hardware Requirements [page 13]
■ Software Requirements [page 14]
■ Virtual Host Name and Virtual IP Address [page 15]
■ Restrictions [page 17]
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 databaseserver.
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
2010-05-18 PUBLIC 13 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 14/68
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
The information provided in this document is based on the SAP SA MP setup script
sapdb2cluster.sh version 4.00. The script is attached to SAP Note 960843 and is also available on the
DB2 V9.1 FP 5 DVD and DB2 V9.5 FP1 DVD.
The following software requirements must be met for the use of SA MP:
■ Supported Operating Systems for SA MP version 2.2 (DB2 V8.2, V9.1, or V9.5):
OS VersionIA 3232-bit
X86_6464-bit
Power64-bit
AIX 5.2 64 bit – X
AIX 5.3 64 bit – X
Red Hat Enterprise Linux 4.0 X X X
Red Hat Enterprise Linux 5.0 X X X
SuSE Linux Enterprise
Server 9
X X X
SuSE Linux Enterprise
Server 10
X X X
■ Supported Operating Systems for SA MP version 3.1 (DB2 9.7):
OS VersionIA3232-bit
X86_6464-bit
Power64-bit
SunSPARC
AIX 5.3 64 bit – – X –
AIX 6.1 64 bit – – X –
Red Hat Enterprise
Linux 4.0
X X X –
Red Hat Enterprise
Linux 5.0
X X X –
SuSE Linux Enterprise
Server 9
X X X –
SuSE Linux Enterprise
Server 10
X X X –
Solaris 10 on SPARC – – – X
■ The following DB2 Fix Pack levels are required:
2 Planning
2.2 Software Requirements
14 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 15/68
DB2 Version Fix Pack Level
DB2 9.7 No special Fix Pack is required.
DB2 V9.5 At least Fix Pack 1
DB2 V9.1 At least Fix Pack 1DB2 Version 8 At least Fix Pack 13
■ 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
■ Both nodes must run on the same operating system.
■ Both host machines must have the same operating system patch level.
■ See also the latest SA MP release notes at:
http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8214-05/en_US/PDF/
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 DB2 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 database server as virtual host name and IP address [page 15].
■ You set up a new virtual host name and IP address [page 16].
2.3.1 Reusing the Host Name and IP Address of a SingleDatabase 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 host name and the IP address of the single database server with a
new host name and a new IP address. You specify the old host name and the old IP address of the database
server as the new virtual host name and virtual IP address in the cluster setup configuration file
sapdb2cluster.conf.
The advantage of this approach is that you do not have to change the references to the database host
of your SAP system landscape and of additional monitoring tools. However, additional services that
are installed on the database 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 cluster has been set up:
2 Planning
2.3 Virtual Host Name and Virtual IP Address
2010-05-18 PUBLIC 15 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 16/68
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 sapdb2cluster.conf.The following figure shows an example of how you set up a new virtual host name or IP address before
and after the cluster has been set up:
2 Planning
2.3 Virtual Host Name and Virtual IP Address
16 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 17/68
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. Althoughthe 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 30].
2.4 Restrictions
2.4.1 Restrictions for Shared Disk Setup
NOTEThe 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.4.2 Restrictions for HADR Setup
For HADR setup, the following restrictions apply:
■ HADR is not supported in a partitioned database environment.
2 Planning
2.4 Restrictions
2010-05-18 PUBLIC 17 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 18/68
■ 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 theSTART HADRcommand or the database is activated (restarted) with HADR configured
and raw logs are detected, the associated command fails.
2 Planning
2.4 Restrictions
18 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 19/68
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 19].
2. You set up the ssh/rsh connection [page 21].
3. You change the password of the SAP connect user [page 22].
4. You configure the log archiving for HADR setup [page 22].
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 9].
■ 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:
/dev/sdc1 /db2 reiserfs noauto,acl,user_xattr 0 0
● On AIX, you have to set the options check and mount to false.
3 Preparation
3.1 Setting Up File Systems for Shared Disk Scenario
2010-05-18 PUBLIC 19 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 20/68
SYNTAX
/db2:dev = /dev/fslv01vfs = jfs2
log = /dev/loglv00mount = 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
◆ Resource:
rgmbrreq –o lock <resource>
rgmbrreq –o lock IBM.Application:db2mnt-db2-rs
● Unlock (automation enabled):
◆ Resource group:rgreq –o unlock <resource group>
EXAMPLE
rgreq –o unlock db2_db2ha3_0-rg
◆ Resource:
rgmbrreq –o unlock <resource>
rgmbrreq –o unlock IBM.Application:db2mnt-db2-rs
■ All types of local file systems are supported by SA MP, for example, reiserfs, jfs2, and so on.
3 Preparation
3.1 Setting Up File Systems for Shared Disk Scenario
20 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 21/68
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
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.
3 Preparation
3.2 Setting Up the ssh/rsh Connection
2010-05-18 PUBLIC 21 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 22/68
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 5], 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.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.3 Changing the Password of the SAP Connect User
22 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 23/68
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. You set up the central services instance or prepare the global host, which is not described in this
document. For more information, see the respective installation guide that you use to install the
database server.
2. You install the database instance as follows:
1. Download the latest DB2 software and SA MP license [page 23].
2. Install the database server [page 24].
3. Set up the high availability cluster [page 26].
4. Perform post-installation activities [page 33].
3. You install the central instance, which is not described in this document. For more information,
see the respective installation guide that you use to install the database server.
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 theDatabase Server [page 24] and continue to set up the high availability cluster as described in
Setting Up the High Availability Cluster [page 26].
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 30].
4.1 Downloading the Latest DB2 So ftware and SA MP License
To be able to install the latest version of DB2 and SA MP, download the required software from SAPService 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 Installation
4.1 Downloading the Latest DB2 Software and SA MP License
2010-05-18 PUBLIC 23 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 24/68
4.2 Installing the Database Server
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 sapdb2cluster.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.
You 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 UniversalDatabase for UNIX and Windows
on SAP Service Marketplace at:
http://service.sap.com/
instguidesnw70 Installation
Installation – SAP NetWeaver Systems
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
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 SR3 <ABAP/ABAP
+Java/Java> on <OS>: IBM DB2 for Linux,
UNIX, and Windows
on SAP Service Marketplace at:
http://service.sap.com/
instguidesnw70 Installation
Installation – SAP NetWeaver Systems
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 Installation
4.2 Installing the Database Server
24 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 25/68
4.3 Setting Up a Standby Database Server UsingHomogeneous 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/”
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 22].
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 SAPinst.
4 Installation
4.3 Setting Up a Standby Database Server Using Homogeneous System Copy
2010-05-18 PUBLIC 25 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 26/68
NOTE
You can use the SAPinst parameter SAPINST_USE_HOSTNAME=<VIRTUAL HOSTNAME> to specifiy
the virtual host name that SAPinst 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
SAPinst.
You restore the database from the primary host. All subsequent SAPinst phases have already been
executed on the primary database server.
14. Log on to the second node as user db2<dbsid>.
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 sapdb2cluster.sh that is provided by SAP.
4.4 Setting Up the High Availability Cluster
To set up the cluster, you have to perform the following steps:
1. Install the SA MP software on both nodes [page 26].
2. Install the SA MP license [page 27].
3. Set up the cluster [page 28].
4. Change the references to the virtual host name or IP address [page 30].
5. Enable HADR Takeover by Force [page 31].
4.4.1 Installing the SA MP Software
The SA MP software is bundled with DB2 V9.1 and higher on DVD images. For DB2 V9.1, it is located
in the following directory on the DVD:
/<platform>/SA_MP/software/.
4 Installation
4.4 Setting Up the High Availability Cluster
26 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 27/68
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
■ For DB2 V9.5 and higher:
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”.
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 50].
4.4.2 Installing the SA MP License
You use the following procedure to install the free two-node license of SA MP.
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 filesam22.lic from SAP Service Marketplace as described in
Downloading the Latest DB2 Software and SA MP License [page 23].
■ Check if you have installed the DB2 license. If not, install it as described in SAP Note 816773.
Procedure
1. Log on to the first node as user root.
2. Move the license file to the home directory of user root:
4 Installation
4.4 Setting Up the High Availability Cluster
2010-05-18 PUBLIC 27 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 28/68
■ For Linux: /root
■ For AIX: /home/root
The cluster setup script transfers the license to the second node and installs it on both nodes.
4.4.3 Setting Up the Cluster
You set up the high availability cluster using the cluster setup configuration file and the setup scripts
that are described in the following tables:
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 yourcluster setup and finally generates sapdb2cluster.conf.
Script sapdb2cluster.sh Sets up the cluster using the data contained in file
sapdb2cluster.conf.
NOTE
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 clusterconfiguration.
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 commandsdb2startor 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 Clust er
Setup [page 33].
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 database server [page 15], you have to change the
host name and the IP address of the database server bef ore creating the cluster.
4 Installation
4.4 Setting Up the High Availability Cluster
28 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 29/68
Procedure
Copying the Setup Files and Scripts 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.
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, as follows:
1. Log on to the first node as user root.
2. Create a directory for the scripts using the following command:
mkdir ~/samp_setup
3. Insert and mount the database software DVD to <dvd_mount>.4. Copy the setup files using the following command:
cp <dvd_mount>/<platform>/SA_MP/scripts/* ~/samp_setup/
Generation of Cluster Configuration
The file sapdb2cluster.conf contains all parameters that are required to properly set up and maintain
the DB2 cluster. It is created by the script sapdb2cluster.sh.
For more information about the syntax of sapdb2cluster.sh, see Script sapdb2cluster.sh [page 49].
1. Log on to the first 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:
cd ~/samp_setup
4. Execute the generator script sapdb2cluster.sh using the following command:
./sapdb2cluster.sh
5. Choose 1 – Show and Edit Database Configuration.
6. Provide all required parameters.
CAUTION
Make sure that you keep the file sapdb2cluster.conf because it is required to reset or
uninstall the cluster.
Setting Up the Cluster Using sapdb2cluster.sh
The final cluster setup is performed by the scriptsapdb2cluster.shbased on the information contained
in file sapdb2cluster.conf as follows:
1. Log on to the first 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:
cd ~/samp_setup
4 Installation
4.4 Setting Up the High Availability Cluster
2010-05-18 PUBLIC 29 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 30/68
4. Set up the cluster – assuming that you have created the cluster setup configuration file in ~/
samp_setup – using the following command:
./sapdb2cluster.sh
5. Choose 2 – Create Database Cluster .
6. For local users such as db2<dbsid>, <sapsid>adm, sap<sapsid>, or sap<sapsid>db, set the
passwords of these users on the second node using the passwd command.
NOTE
The passwords must be the same as on the first node.
For more information, see Script sapdb2cluster.sh [page 49].
4.4.4 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 16], you must perform the
following steps. Although the script sapdb2post.sh performs some of the steps, you have to performother steps manually as described in the following.
Process
1. sapdb2cluster.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. sapdb2cluster.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, sapdb2cluster.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. 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:
4 Installation
4.4 Setting Up the High Availability Cluster
30 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 31/68
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.4.5 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.
4 Installation
4.4 Setting Up the High Availability Cluster
2010-05-18 PUBLIC 31 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 32/68
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 forTAKEOVER BY FORCE. This section enables the takeover
of the workload by the standby server in case that 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
4.4 Setting Up the High Availability Cluster
32 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 33/68
5 Post-Installation Activities
After you have successfully completed the installation, you have to perform the following post-
installation activities:
1. You check the cluster setup [page 33].
2. You check the cluster failover [page 36].
3. You back up the SA MP core policy [page 36].
5.1 Checking the Cluster Setup
After the installation, you have to check that the failover cluster is working properly.
Procedure
1. 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 GSPort
sap_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 f ollows:
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:
5 Post-Installation Activities
5.1 Checking the Cluster Setup
2010-05-18 PUBLIC 33 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 34/68
■ 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-rgMemberLocation = CollocatedPriority = 0AllowedNode = ALL
NominalState = Online
ExcludedList = {}Subscription = {}Owner =Description =InfoLink =ActivePeerDomain = sap_tsmdb2
OpState = Online
TopGroup = db2_db2tsm_0-rgConfigValidity =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:
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:
5 Post-Installation Activities
5.1 Checking the Cluster Setup
34 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 35/68
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:
SYNTAX
rgmbrreq -o [start|stop|cancel]IBM.Application:db2_db2<dbsid>_0-rs
CAUTION
For DB2 Version 8 and DB2 V9.1 only:
5 Post-Installation Activities
5.1 Checking the Cluster Setup
2010-05-18 PUBLIC 35 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 36/68
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.2 Checking the 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:
■ For shared disk setup:
rgreq -o Move -n <hostname> db2_db2<dbsid>_0-rg
■ For HADR setup:
rgreq -o Move -n <hostname> db2hadr_<dbsid>-rg
NOTE
Since you specify the node to move from, you have to enter the <hostname> where the DB2
instance/primary database server is currently running.
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.
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
5 Post-Installation Activities
5.2 Checking the Cluster Failover
36 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 37/68
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.
ProcedureBacking 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.
5 Post-Installation Activities
5.3 Performing a Backup of the SA MP Core Policy
2010-05-18 PUBLIC 37 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 38/68
This page is left blank for documents that are printed on both sides.
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 39/68
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, in an SA MP environment, you must not perform a rolling update for the following reasons:
■ For DB2 UDB Version 8:
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 andthe 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.
■ For DB2 V9.1 and higher:
You can run the database server at a higher Fix Pack level than the application servers. You can
install the Fix Pack besides your current DB2 software, stop the database server, update the database
instance within seconds, and finally restart the database server. In addition, you do not have to
restart the application servers because they immediately reconnect to the database server. Using
this DB2 feature to only update the DB2 instance, which means simply re-creating the links in the
instance directory, causes only a few seconds of downtime for the database server.
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
6 Updating the Software
6.1 Updating the Database Fix Packs
2010-05-18 PUBLIC 39 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 40/68
3. Log on to the first node as user root.
4. To check if DB2 has been stopped, enter the following command:
■ For shared disk setup:
lsrg –g db2_db2<dbsid>_0-rg
■ For HADR setup:
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 9.7 1363169
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:
6 Updating the Software
6.1 Updating the Database Fix Packs
40 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 41/68
samctrl –MF
18. Log on to the first node as user <sapsid>adm.
19. To start the DB2 instance, enter the following command:
startdb
20. To check if DB2 is running again, enter the following command:
■ For shared disk setup:
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 DB2 V9.1
You use the following procedure to upgrade your database from DB2 UDB Version 8 or DB2 V9.1 to
DB2 V9.5 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
1. Log on to the first node as user <sapsid>adm.
2. To shut down the DB2 instance, enter the following command:
stopdb
3. Log on to the first node as user root.
6 Updating the Software
6.2 Updating SA MP Fix Packs
2010-05-18 PUBLIC 41 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 42/68
4. Change to the directory of SA MP setup scripts using the following command:
cd ~/samp_setup
5. Run the cluster setup tool in interactive mode:
./sapdb2cluster.sh –f ~/samp_setup/sapdb2cluster.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/.
9. Run the cluster setup tool in interactive mode:./sapdb2cluster.sh –f ~/samp_setup/sapdb2cluster.conf
10. Choose 2 – Create Database Cluster .
NOTE
If your cluster configuration file has to be updated as well, sapdb2cluster.sh performs this step
and prompts for additional parameters.
6 Updating the Software
6.3 Upgrading from DB2 UDB Version 8 or DB2 V9.1
42 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 43/68
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 43].
2. You uninstall the SA MP software [page 44].
3. You delete the DB2 software [page 44].
7.1 Uninstalling the Cluster
To uninstall the cluster and to separate the two nodes, use the sapdb2cluster.sh script as follows:
Procedure
1. Log on to the first node where you initially transferred the SA MP scripts to as userroot (for more
information, see Setting Up the Cluster [page 28]).
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
4. Run the cluster setup tool in interactive mode:
./sapdb2cluster.sh –f ~/samp_setup/sapdb2cluster.conf
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
Result
The 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 sapdb2cluster.sh script already updated the references in the SAP profile, the db2cli.ini
file, and sapdb2cluster.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 30].
7 Uninstall
7.1 Uninstalling the Cluster
2010-05-18 PUBLIC 43 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 44/68
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
1. Log on to the first node as user root.
2. Insert and mount the database software DVD to <dvd_mount>.
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
■ For DB2 V9.5 and higher:
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 and DB2 Version 9.5:
http://service.sap.com/instguidesnw70 Installation Installation – SAP NetWeaver Systems
SAP NetWeaver 7.0 incl. EHP1 SR1- Installation Guides
7 Uninstall
7.2 Uninstalling the SA MP Software
44 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 45/68
A Appendix
A.1 SA MP Policy for DB2
The following sections provide detailed information about:
■ File sapdb2cluster.conf [page 45]
■ Script sapdb2cluster.sh [page 49]
A.1.1 File sapdb2cluster.conf
The sapdb2cluster.conf policy file contains all parameters that are required to set up the DB2 cluster
properly. The following is an example of the policy file containing all relevant information based on
the setup example shown in the Introduction [page 5] (where TSM stands for the <SAPSID>, and no NFS for
home directories of local users).
EXAMPLE
# IBM_PROLOG_BEGIN_TAG# This is an automatically generated prolog.
## Licensed Materials - Property of IBM## (C) COPYRIGHT International Business Machines Corp. 2003,2005# All Rights Reserved## US Government Users Restricted Rights - Use, duplication or# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.## IBM_PROLOG_END_TAG#.-----------------------------------------------------------------.#| |#| IBM Tivoli System Automation for Multiplatforms |#| Policy for DB2 |#| Policy version: 3.00 |#| |#| Configuration Information |#| ========================= |#| |#| This script is used by other scripts to obtain |#| configuration information. |#| You must adapt the indicated lines to your environment. |#| |#'-----------------------------------------------------------------'###### START OF CUSTOMIZABLE AREA #################################### domain nameTSA_DOMAIN_NAME=sap_tsmdb2
# comma-separated list of the host namesTSA_HOSTNAME_LIST=db2_sa_mp_1, db2_sa_mp_2
A Appendix
A.1 SA MP Policy for DB2
2010-05-18 PUBLIC 45 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 46/68
# TSA License FileTSA_LICENSE_FILE=/home/root/sam21.lic# IP address of the network tie breakerTSA_TIEBREAKER_IP_ADDRESS=17.2.10.0# remote shell (ssh or rsh)
TSA_REMOTE_CMD=rsh# comma-separated list of users of the TSA operatorsTSA_USER_LIST=db2tsm, tsmadm# cluster type: samp with shared disk or hadr with sampTSA_CLUSTER_TYPE=samp# installation directory for DB2DB2_INST_DIR=/db2/db2tsm/db2_software# comma-separated list of DB2 communication ports,# each port in syntax <name>:<port_num>[,<name>:<port_num>]DB2_COMM_PORTS=sapdb2TSM:5912/tcp,DB2_db2tsm:5914/tcp,
DB2_db2tsm_1:5915/tcp,DB2_db2tsm_2:5916/tcp,DB2_db2tsm_END:5917/tcp
# comma-separated list of the two DB2 HADR log shipping ports,
# each port in syntax <name>:<port_num>[,<name>:<port_num>]DB2_HADR_PORTS=TSM_HADR_1:5950/tcp, TSM_HADR_2:5951/tcp# Synchronisation mode for HADRDB2_HADR_SYNC_MODE=NEARSYNC# Virtual host name of the clusterDB2_HA_HOSTNAME=db2_sa_mp_cl# Virtual IP address of the clusterDB2_HA_IP_ADDRESS=17.2.10.3# Network Mask for the virtual IP addressDB2_HA_IP_MASK=255.255.255.0# DB2 instance ownerDB2_DB2INSTANCE=db2tsm# comma-separated list of DB2 directories on shared disksDB2_DIR_LIST=/db2/db2tsm,/db2/TSM/db2dump,/db2/TSM/db2tsm,
/db2/TSM/log_dir,/db2/TSM/sapdata1,/db2/TSM/saptemp1# comma-separated list of public HA network interfaces for DB2,# at least one per nodeDB2_NETWORK_INTERFACE_LIST=en0:17.2.10.1:255.255.254.0:db2_sa_mp_1,en0: 17.2.10.2:255.255.254.0:db2_sa_mp_2# comma-separated list of user groups, each group in syntax# <group>:<num>:<local_group>DB2_GROUP_LIST=dbtsmadm:1001:true,dbtsmctl:1002:true,
dbtsmmnt:1003:true# comma-separated list of users, each user in syntax# <user>:<num>:<home_dir>:<local_home_dir>:<shell>:<local_user># <prim_group>[:<sec_group>]DB2_USER_LIST=db2tsm:1010:/db2/db2tsm:false:/bin/csh:true:dbtsmadm,
saptsm:1011:/home/saptsm:true:/bin/csh:true:dbtsmmnt,
tsmadm:1009:/home/tsmadm:true:/bin/csh:true:dbtsmmnt# the SAP System ID (SAPSID)SAP_SID=TSM###### END OF CUSTOMIZABLE AREA #####################################
Options
Parameter Description Default Value
TSA_DOMAIN_NAME Domain name of the cluster sap_<dbsid>db2
TSA_HOSTNAME_LIST Comma-separated list of host
names
-
TSA_LICENSE_FILE Location of downloaded SA MP
license file
■ Linux:
/root/sam22.lic
A Appendix
A.1 SA MP Policy for DB2
46 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 47/68
Parameter Description Default Value
■ AIX:
/home/root/sam22.lic
TSA_TIEBREAKER_ IP_ADDRESS IP address of the network tie
breaker, described in detail
below
–
TSA_REMOTE_CMD Remote shell to use for the setup ■ Linux: ssh
■ AIX: 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_CLUSTER_TYPE Type of the cluster; valid values:
SAMP or HADR
SAMP
DB2_INST_DIR Installation directory of the DB2software
■ DB2 V9.1 and higher:/db2/db2<dbsid>/db2_v9
■ DB2 UDB Version 8:
● Linux:
/opt/IBM/db2/V8.1
● AIX:
/usr/opt/IBM/db2/V8.1
DB2_COMM_PORTS Comma-separated list of DB2
communication ports with the
following syntax:
<name>:<port>,
For example: sapdb2TSM:5912/tcp,
DB2_db2tsm:5914/tcp,
DB2_db2tsm_1:5915/tcp,
DB2_db2tsm_2:5916/tcp,
DB2_db2tsm_END:5917/tcp
sapdb2<DBSID>:5912/tcp, DB2_db2<dbsid>:
5914/tcp, DB2_db2<dbsid>_1:5915/tcp,
DB2_db2<dbsid>_2:5916/tcp,
DB2_db2<dbsid>_END:5917/tcp
DB2_HADR_PORTS Comma-separated list of DB2
HADR log shipping ports with
the following syntax:
<name>:<port>
For example: TSM_HADR_1:5950/
tcp, TSM_HADR_2:5951/tcp
<DBSID>_HADR_1:5950/tcp,
<DBSID>_HADR_2:5951/tcp
DB2_HADR_SYNC_MODE Synchronization mode for
HADR; valid values: SYNC,
NEARSYNC, or ASYNC
NEARSYNC
DB2_HA_HOSTNAME Virtual host name of the cluster -
DB2_HA_IP_ADDRESS Virtual IP address of the DB2
database cluster server
-
DB2_HA_IP_MASK Virtual network mask of the
DB2 database cluster server
-
DB2_DB2INSTANCE DB2 instance owner db2<dbsid>
A Appendix
A.1 SA MP Policy for DB2
2010-05-18 PUBLIC 47 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 48/68
Parameter Description Default Value
DB2_DIR_LIST Comma-separated list of DB2
mount point directories on the
shared disk
/db2/db2<dbsid>, /db2/<DBSID>/log_dir,
/db2/<DBSID>/db2dump,
/db2/<DBSID>/db2<dbsid>,
/db2/<DBSID>/saptemp1,/db2/<DBSID>/sapdata1
DB2_LV_LIST AIX logical volume list for usage
of raw devices
AIX only: /dev/lv01
DB2_NETWORK_
INTERFACE_LIST
Comma-separated list of
network interfaces for the IP
address equivalency
The list must correspond to the
order in the host name list, one
network interface per host is
mandatory.
■ Linux:
eth0:<ip>:<mask>:<host1>,
eth0:<ip>:<mask>:<host2>
■ AIX: en1:<ip>:<mask>:<host1>,
en1:<ip>:<mask>:<host2>
DB2_GROUP_LIST Comma-separated list of groups
with the following syntax:
<group>:<num> :<local_group
>,
For example:
dbtsmadm:1015:true
If you use NIS for central user
management, <local_group>
has to be false for all groups.
db<sapsid>adm:<num>:<localgrp>,
db<sapsid>ctl:<num>:<localgrp>,
db<sapsid>mnt:<num>:<localgrp>
DB2_USER_LIST Comma-separated list of users.
The syntax is as follows:
SYNTAX
<user>:<num>:<home_dir>:<lo
cal_home_dir>
:<shell>:<local_user> :<prim
_group> [:<sec_group>]
For example:
db2tsm:1010:/db2/
db2tsm:false:/bin/
csh:true :dbtsmadm
If you use NFS shares for yourhome directories, the parameter
<local_home_dir> has to be
false for all users.
If you use NIS for central user
management,<local_user>has
to be false for all users.
db2<sapsid>:<num>: /db2/
db2<sapsid>:false: /bin/
csh:true:db<sapsid>adm,
<sapsid>adm:<num>: /home/
<sapsid>adm:true: /bin/
csh:true:db<sapsid>mnt
ABAP:
sap<sapsid>:<num>: /home/
sap<sapsid>:true: /bin/
csh:true:db<sapsid>mnt,
Java:sap<sapsid>db:<num>: /home/
sap<sapsid>db:true: /bin/
sh:db<sapsid>mnt
SAP_SID SAP system ID <SAPSID>
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
A Appendix
A.1 SA MP Policy for DB2
48 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 49/68
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.
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 Script sapdb2cluster.sh
The script sapdb2cluster.sh sets up the cluster according to the cluster setup configuration file. Itconfigures SA MP according to the data contained in the sapdb2cluster.conf file and creates all
required resources, resource groups, relationships between the resources, and installs the DB2 HA
policy files on the cluster nodes.
SYNTAX
sapdb2cluster.sh [-h] [-l <logfile>] [-f <configfile>][–db –[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 sapdb2cluster.log.
-f <configfile> Specifies the configuration file name. By default, the script looks for
sapdb2cluster.conf in the current directory.
-tl <n> Specifies the trace level: 1 – Debug, 2 – Warning, 3 – Error (Default)
-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
A Appendix
A.1 SA MP Policy for DB2
2010-05-18 PUBLIC 49 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 50/68
A.2 Syntax of SA MP Setup Scripts
The following sections provide detailed information about:
■ Script prereqSAM [page 50]
■ Script installSAM [page 50]
■ Script uninstallSAM [page 52]
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
Parameter Description
--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.
--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 thepackages 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.
A Appendix
A.2 Syntax of SA MP Setup Scripts
50 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 51/68
SYNTAX
installSAM [--force] [--noliccheck][--nodeleteinstlog] [--silent] [--upgrade][-d <inst-pkg-dir>] [-l <logfile>]
Options
Parameter Description
--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
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 performedand 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 50])
A Appendix
A.2 Syntax of SA MP Setup Scripts
2010-05-18 PUBLIC 51 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 52/68
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
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:
http://publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-04/en_US/PDF/
halgre20.pdf
■ IBM Reliable Scalable Cluster Technology (RSCT) – Diagnosis Guide at:
http://publib.boulder.ibm.com/epubs/pdf/bl5dia03.pdf
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 Appendix
A.3 Troubleshooting
52 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 53/68
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 0Examine .loader section symbols with the 'dump -Tv' command.
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.
A Appendix
A.3 Troubleshooting
2010-05-18 PUBLIC 53 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 54/68
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.
SolutionMake 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
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 areterminated.
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 IBM DB2 for LUW. 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
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
54 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 55/68
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.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 tool sapdb2cluster.sh version 4.01 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.
1. Log on to the first node as user root.
2. Change to the directory where the cluster setup tool is located.
3. Start the cluster setup tool:
./sapdbcluster.sh
4. From the menu, choose Graceful Cluster Switch.
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
2010-05-18 PUBLIC 55 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 56/68
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
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 ExamplesThis 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 .
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
56 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 57/68
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:
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:
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
2010-05-18 PUBLIC 57 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 58/68
root# ./sapdb2cluster.sh -db -switch
Result
The following is an example of a successful script output for an SAP client copy process:
SYNTAX
Read configuration fileCheck general configurationCheck database cluster configuration :
OKStarting graceful cluster switch processEnter 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 PrerequisitesDetermine HADR Roles : OKChecking HADR Peer State : OKChecking SAP DBSL feature prerequisites: :
OKGraceful Cluster Switch supported: :
OKChecking for transactions running for more than 60 seconds : OK
Enable micro outage feature of DBSL :OKClosing all database connections...Status: Open Connections 0All connections closed.
Starting failover process...Execute DB2 TAKEOVER: :
OKDetermine HADR Roles :
OKDisable 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../sapdb2cluster.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.
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
58 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 59/68
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
A.4 Graceful Cluster Switch (Micro–Outage)
2010-05-18 PUBLIC 59 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 60/68
Figure 8: SAP Load Generator
On the SAP Load Generator screen, choose the Continue pushbutton and select one or even all servers as
shown in the following figure:
Figure 9: Select Server
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
60 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 61/68
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# ./sapdb2cluster.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 fileCheck general configurationCheck database cluster configuration :
OKStarting graceful cluster switch processEnter 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
A.4 Graceful Cluster Switch (Micro–Outage)
2010-05-18 PUBLIC 61 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 62/68
Checking HADR Peer State :OK
Checking SAP DBSL feature prerequisites: :OK
Graceful Cluster Switch supported: :
OKChecking 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_TYPESAP_REPORT-------- ---------- --------- --------------- -------- --------- ------------ ----LONGRUNNER dw.sapHA5_DVEBMGS30 162 2010-03-04-10.58.21 14 DDIC DIASAPLSUGPLONGRUNNER db2jcc_application 163 2010-03-04-14.16.11 6350 - - -
2 record(s) selected.WARNING: Long running transactions are active which might be canceled (rolledback)!
****************************************************************************************Checking for Java Connections :WARNING******************* WARNING: Found Java Connections******************************SAPHA5DB db2jcc_applica 164 10.17.202.144.18077.10030413153 HA51SAPHA5DB db2jcc_applica 163 10.17.202.144.17821.10030413152 HA51SAPHA5DB db2jcc_applica 166 10.17.202.144.5291.100304131612 HA51WARNING: 3 Java connections exists (DB2 QUIESCE required)!********************************************************************************
**Enable micro outage feature of DBSL : OKClosing all database connections...Status: Open Connections 4Timeout Occured. The following Connections still exist:
List all open database connectionsAPPL_NAME AGENT_ID AUTHID UOW_START_TIME STATUS SAP_USER SAP_APPL_SERVERSAP_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 ptypeBTC RSPARAGENER8
Do you want to force failover (rollback of running transactions)? [Yes|No]: yesExecute DB2 QUIESCE for HA5 : OKExecute DB2 TAKEOVER :
OKDetermine HADR Roles :
OKExecute DB2 UNQUIESCE :
OKDisable micro outage feature of DBSL :
OKCluster Switch Start : Thu Mar 4 16:01:45 CET 2010
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
62 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 63/68
Cluster Switch End : Thu Mar 4 16:02:22 CET 2010Action finished. Press Enter to continue ...
A Appendix
A.4 Graceful Cluster Switch (Micro–Outage)
2010-05-18 PUBLIC 63 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 64/68
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>”.
Example
Example
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
documentationhttp://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, andnames 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
64 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 65/68
SAP AGDietmar-Hopp-Allee 16
69190 WalldorfGermany
T +49/18 05/34 34 34
F +49/18 05/34 34 20 www.sap.com
© Copyright 2010 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.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permissionof 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, and PowerPoint 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, System z9, z10,
z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,
PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,
BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA,
AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
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.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented
by Netscape.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, 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 in several other countries all over the world. 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 specificationsmay 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.
Disclaimer
Some 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.
2010-05-18 PUBLIC 65 /68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 66/68
Documentation in the SAP Service Marketplace
You can find this document at the following address: http://service.sap.com/instguides
66 /68 PUBLIC 2010-05-18
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 67/68
8/3/2019 IBM DB2 High Availability Solution%3a IBM Tivoli System Automation for Multi Platforms (03_2008)
http://slidepdf.com/reader/full/ibm-db2-high-availability-solution3a-ibm-tivoli-system-automation-for-multi 68/68
SAP AGDietmar-Hopp-Allee 1669190 WalldorfGermany T +49/18 05/34 34 34F +49/18 05/34 34 20
www.sap.com