DB2 FOR LUW / DB2FORLUW / A10 - DB2

In a TSA-MP managed HADR environment, if the public network 
cable is unplugged from the HADR primary server, the HADR 
database is unable to failover to the standby server. 
 
See the following example for more details: 
 
- lssam output prior to unplugging the network cable: 
 
Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg 
Nominal=Online 
        |- Online 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
                |- Online 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:node01 
                '- Offline 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:node02 
        '- Online IBM.ServiceIP:db2ip_10_10_3_111-rs 
                |- Online 
IBM.ServiceIP:db2ip_10_10_3_111-rs:node01 
                '- Offline 
IBM.ServiceIP:db2ip_10_10_3_111-rs:node02 
Online IBM.ResourceGroup:db2_db2inst1_node01_0-rg Nominal=Online 
        '- Online IBM.Application:db2_db2inst1_node01_0-rs 
                '- Online 
IBM.Application:db2_db2inst1_hostA_0-rs:node01 
Online IBM.ResourceGroup:db2_db2inst1_node02_0-rg Nominal=Online 
        '- Online IBM.Application:db2_db2inst1_node02_0-rs 
                '- Online 
IBM.Application:db2_db2inst1_node02_0-rs:node02 
Online IBM.Equivalency:db2_db2inst1_db2inst1_HADRDB-rg_group-equ 
        |- Online IBM.PeerNode:node01:node01 
        '- Online IBM.PeerNode:node02:node02 
Online IBM.Equivalency:db2_db2inst1_node01_0-rg_group-equ 
        '- Online IBM.PeerNode:node01:node01 
Online IBM.Equivalency:db2_db2inst1_node02_0-rg_group-equ 
        '- Online IBM.PeerNode:node02:node02 
Online IBM.Equivalency:db2_private_network_0 
        |- Online IBM.NetworkInterface:en1:node01 
        '- Online IBM.NetworkInterface:en1:node02 
Online IBM.Equivalency:db2_public_network_0 
        |- Online IBM.NetworkInterface:en2:node02 
        '- Online IBM.NetworkInterface:en2:node01 
 
 
- lssam output after the network cable is unplugged: 
 
Pending Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg 
Request=Lock Nominal=Online 
        |- Offline 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
Control=StartInhibitedBecauseSuspended 
                |- Offline 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:node01 
                '- Offline 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:node02 
        '- Online IBM.ServiceIP:db2ip_10_10_3_111-rs 
                |- Online 
IBM.ServiceIP:db2ip_10_10_3_111-rs:node01 
                '- Offline 
IBM.ServiceIP:db2ip_10_10_3_111-rs:node02 
Failed offline IBM.ResourceGroup:db2_db2inst1_node01_0-rg 
Binding=Sacrificed Nominal=Online 
        '- Offline IBM.Application:db2_db2inst1_node01_0-rs 
                '- Offline 
IBM.Application:db2_db2inst1_hostA_0-rs:node01 
Online IBM.ResourceGroup:db2_db2inst1_node02_0-rg Nominal=Online 
        '- Online IBM.Application:db2_db2inst1_node02_0-rs 
                '- Online 
IBM.Application:db2_db2inst1_node02_0-rs:node02 
Online IBM.Equivalency:db2_db2inst1_db2inst1_HADRDB-rg_group-equ 
        |- Online IBM.PeerNode:node01:node01 
        '- Online IBM.PeerNode:node02:node02 
Online IBM.Equivalency:db2_db2inst1_node01_0-rg_group-equ 
        '- Online IBM.PeerNode:node01:node01 
Online IBM.Equivalency:db2_db2inst1_node02_0-rg_group-equ 
        '- Online IBM.PeerNode:node02:node02 
Online IBM.Equivalency:db2_private_network_0 
        |- Online IBM.NetworkInterface:en1:node01 
        '- Online IBM.NetworkInterface:en1:node02 
Online IBM.Equivalency:db2_public_network_0 
        |- Online IBM.NetworkInterface:en2:node02 
        '- Offline IBM.NetworkInterface:en2:node01 
 
As displayed in the above lssam output, HADR is stopped 
(resource is set to "Offline") on the original primary (node01), 
but node02 does not takeover the primary HADR role, i.e. the 
HADR resource for node02 is also set as "Offline". 
 
In addition to this, the virtual IP address (IBM.ServiceIP 
resource) still binds to the original primary server. (node01) 
 
---------------------------------------------------------------- 
 
 
In the above scenario, whereby the public network cable is 
unplugged, the IBM.ServiceIP resource is not brought offline by 
TSA on the primary node(node01). There needs to be an additional 
dependency created from the HADR resource to the public network 
equivalency which will allow the HADR failover process to be 
initiated in the case of a public network cable pull. With this 
additional dependency in place, the HADR resource will be able 
to successfully failover from the primary to the standby in the 
event of a public network cable pull.

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.1 Fix Pack 3.                      * 
****************************************************************

Verify if there exists a dependency from the HADR resource to 
the public network by issuing the 'lsrel -Ab' command as the DB2 
instance owner. If the dependency exists, here is how it would 
be displayed: 
 
Managed Relationship 1: 
        Class:Resource:Node[Source] = 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
        Class:Resource:Node[Target] = 
{IBM.Equivalency:db2_public_network_0} 
        Relationship                = DependsOn 
        Conditional                 = NoCondition 
        Name                        = 
db2_db2inst1_db2inst1_HADRDB-rs_DependsOn_db2_public_network_0-r 
el 
        ActivePeerDomain            = hadr_dom 
        ConfigValidity              = 
 
If this dependency does not exist, then create it as follows: 
 
1) Bring the cluster into maintenance mode by running the 
"db2haicu -disable" command as the DB2 instance owner. 
 
2) As root from either node, run the following: 
"export CT_MANAGEMENT_SCOPE=2" 
"mkrel -p dependson -S 
IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs -G 
IBM.Equivalency:db2_public_network_0 
db2_db2inst1_db2inst1_HADRDB-rs_DependsOn_db2_public_network_0-r 
el" 
 
3) Verify that the dependency is now created via the "lsrel -Ab" 
command. 
 
4) Once verified that the dependency exists, exit cluster 
maintenance mode by running the "db2haicu" command as the DB2 
instance owner.

DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

First fixed in Version 10.1 Fix Pack 3.

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC94057 IC94071 IC95313 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

22.04.2013
22.10.2013
22.10.2013