DB2 FOR LUW / DB2FORLUW / A50 - DB2

In an automated HADR environment with TSA as the cluster 
manager, two types of resource dependency relationships are 
created by db2haicu: 
1) Dependency relationship between the HADR resource and the 
public network equivalency. 
2) Dependency relationship between the DB2 instance resource and 
the public network equivalency. 
 
As part of this APAR fix, the dependency relationship between 
the DB2 instance resource and the public network equivalency 
will be removed as it causes incorrect behavior in the case of a 
public adapter failure on the standby HADR server. In the case 
of a public adapter failure on the standby HADR server, the DB2 
instance is stopped and started back up once the public adapter 
failure is resolved. This is incorrect behavior. No automation 
action should take place in this scenario. Removing the 
dependency relationship from the DB2 instance resource to the 
public network equivalency achieves this desired behavior. 
 
For example, in an automated HADR environment which contains one 
HADR database "HADRDB", the following three dependency 
relationships are created by db2haicu: 
 
$ lsrel -Ab Name 
Displaying Managed Relationship Information: 
 
Managed Relationship 1: 
	Name                        = 
db2_db2inst1_host01_0-rs_DependsOn_db2_public_network_0-rel 
	Class:Resource:Node[Source] = 
IBM.Application:db2_db2inst1_host01_0-rs 
 
Managed Relationship 2: 
	Name                        = 
db2_db2inst1_host02_0-rs_DependsOn_db2_public_network_0-rel 
	Class:Resource:Node[Source] = 
IBM.Application:db2_db2inst1_host02_0-rs 
 
Managed Relationship 3: 
	Name                        = 
db2_db2inst1_db2inst1_HADRDB-rs_DependsOn_db2_public_network_0-r 
el 
	Class:Resource:Node[Source] = 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
 
With this APAR fix, only the third dependency relationship 
"db2_db2inst1_db2inst1_HADRDB-rs_DependsOn_db2_public_network_0- 
rel" will be created.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All Platforms                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* See SYSROUTE APARs to see where this APAR is addressed       * 
****************************************************************

Based on the above "lsrel" command output, the dependency 
relationships can be manually deleted by running the following 
as root: 
 
export CT_MANAGEMENT_SCOPE=2 
rgreq -o lock db2_db2inst1_host01_0-rg 
rgreq -o lock db2_db2inst1_host02_0-rg 
rmrsrc 
db2_db2inst1_host01_0-rs_DependsOn_db2_public_network_0-rel 
rmrsrc 
db2_db2inst1_host02_0-rs_DependsOn_db2_public_network_0-rel 
rgreq -o unlock db2_db2inst1_host01_0-rg 
rgreq -o unlock db2_db2inst1_host02_0-rg

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

19.06.2015
09.05.2017
09.05.2017