SAP Basis Tech Supports

Symptom

If you have configured more than one SAP JAVA instance and are running DB2 as data sharing group, then you might want to statically distribute their database connections to the available DB2 members. In order to achieve this, use the 3-step procedure described below. This is only an option that you might want to consider. It is not mandatory.

Other terms

MVS OS/390 HA JAVA z/OS System z DB2

Reason and Prerequisites

You are running multiple SAP Java instances and DB2 as a data sharing group.

Solution

To assign the database connections of different Java instances to different DB2 members of the same data sharing group, use the Java configtool and proceed as follows. To explain this approach, we use an example and assume the following parameters for DB2 Connect:
SAPSID JHA
LOCATION (*) DDFDHA
DDF PORT (*) 8188
Collection ID (**) SAPJJHADDFDHA (SAPJ++)
SCHEMA SAPJAVA
HOSTNAME of primary DB2 ha1host
HOSTNAMES of Secondary ha2host
CONNECTION USER SAPUSER
(*) Please note that for JDBC failover based on DB2 Connect 9.1, it is required to define a LOCATION ALIAS and PORT ALIAS in DDF (see note 1339644).
(**) Collection is set to + for NW 7.0 or higher and to SAPDRDA for NW 6.40. There is no need to change the values for currentPackageSet or currentSQLID to enable high availability for the Java Stack. Also keep the setting keepDynamic=yes.
1. Start the Java configtool, navigate to “secure store” and find the settings for the standard jdbc pool which should look similar to the following example which uses a SAPSID of JHA and a host name of ha1host to access the first DB2 member. In this example, an alternate server and port name is also specified to enable seamless and cascaded JDBC failover. Note that this is an option but not mandatory
jdbc/pool/JHA/ClassName com.ibm.db2.jcc.DB2Driver
jdbc/pool/JHA/Password **********
jdbc/pool/JHA/Url jdbc:db2://ha1host:8188/DDFDHA:
keepDynamic=yes;
currentPackageSet=SAPJJHADDFDHA;
currentSQLID=SAPJAVA;
enableSeamlessFailover=yes;
enableClientAffinitiesList=yes;
clientRerouteAlternateServerName=ha1host,
ha2host;
clientRerouteAlternatePortNumber=8188,8188;
jdbc/pool/JHA/User SAPUSER

Create a duplicate of this set for a JAVA instance that you want to direct to a another DB2 member. Choose the naming such that you can easily recognize to which DB2 member the new pool will be connecting to. The example uses JHA2 to designate the connection to the second member which is started on host ha2host.
jdbc/pool/JHA2/ClassName com.ibm.db2.jcc.DB2Driver
jdbc/pool/JHA2/Password **********
jdbc/pool/JHA2/Url jdbc:db2://ha2host:8188/DDFDHA:
keepDynamic=yes;
currentPackageSet=SAPJJHADDFDHA;
currentSQLID=SAPJAVA;
enableSeamlessFailover=yes;
enableClientAffinitiesList=yes;
clientRerouteAlternateServerName=ha2host,
ha1host;
clientRerouteAlternatePortNumber=8188,8188;
jdbc/pool/JHA2/User SAPUSER
2. Use Java configtool and navigate to the JAVA instance for which you want to change the database connection.a) navigate to:
dispatcher_IDXXXXXXXXX–>managers -> ConfigurationManager
to the the entry for the System DataStore which points to the global/default value:
Key Custom value Default value
sysDS.DBConnectInfo jdbc/pool/JHA

Set the ‘custom value’ for this property to the new pool that you defined in 1): Key Custom value Default value
sysDS.DBConnectInfo jdbc/pool/JHA2 jdbc/pool/JHA
b) navigate to
server_IDXXXXXXXXX–>managers -> ConfigurationManager
Change the the key sysDS.DBConnectInfo like above.c) navigate to
server_IDXXXXXXXXX –>services -> dbpool
Change the key sysDS.DBConnectInfo like above.3. In the bootstrap configuration of the Java instance :
/j2ee/cluster/bootstrap/bootstrap.properties
set: rdbms.connection=jdbc/pool/JHA2
Repeat Steps 1-3 for every JAVA instance that you want to direct to a different than the default DB2 member.

Remark: If you have distributed your JAVA instances to different DB2 members and you use seamless JDBC failover in a configuration with one active DB2 member as failover target for the connections of the other DBe member, you will notice that your Java instances will start to ‘cluster’ on a member.
For example, consider the case of two members M1 and M2 and two java instances JI1 and JI2. Let the configuration be that JI1 connects to (M1, M2) and JI2 to (M2, M1). With the notation (M1,M2,M3,..) we understand that an instance has been configured to connect to M1 as primary, M2 as secondary and so forth.
If JI1 fails over – either planned or unplanned – to M2 then both JI1 and JI2 will be connected to M2. Quiesing DDF on M2 will only make JI1 and JI2 both failover – seamlessly – to M1. You cannot get back to the original configuration without restarting JI1. Restarting of JI1 will of course result in JI1 connecting to its primary M1.
In order to be able to get back to the original configuration, you must have configured an extra passive data sharing member M3. It is not necessary that M3 is started – it can be quiesced as to minimize use of resources.
Configure your java instance JI1 to connect to (M1, M3, M2) and JI2 to connect to (M2, M3, M1).
If M3 is up – hot standby – JI1 will connect in case of an unplanned outage to M3. Stopping DDF on M3 will make JI1 fail back to M1.
If M3 is quiesced – cold or passive standby -
JI1 will connect in case of an unplanned outage of M1 first to M3 and as M3 is quiesced it will then connect to M2.
In order to move JI1 back to M1 you need to start M3 temporary. Then stop DDF on M2 which will cause JI1 to move to M1 and JI2 to M3. Start DDF on M2 again and stop DDF on M3 which will cause JI2 to connect back to M2. Now quiesce M3 again.