Building blocks for Db2 connection failover

Edit online

The contained information describes the basic building blocks that are needed for Db2 connection failover. It introduces the two major data sharing failover configurations for providing a highly available environment for an SAP database on Db2 for z/OS.

Two major data sharing failover configurations provide a highly available environment for an SAP database on Db2 for z/OS:

  • Active/Passive: Single Db2 member with passive (inactive) standby member
  • Active/Active: Two or more active Db2 members in active-standby mode

To enable a reuse of system resources during maintenance, both configurations can be enhanced with a passive standby member for each active member to allow for cascaded failover. Cascaded failover means that first the passive member is used for failover, which resides on the same CEC (primary passive). In case that the CEC is down, for maintenance, for example, the failover is done to either the secondary passive or the secondary active.

For more information about data sharing failover configurations, for example, cascaded failover to reuse the MIPS on the primary CEC, see Database Administration Guide for SAP on IBM Db2 for z/OS .

In the following Figure 1, HA1 is used as both the SAP system name (SID) and the Db2 group name.

Figure 1. SAP Db2 connection failover configuration: Active/Passive example
Graphic shows an example of SAP sysplex failover configuration: Active/passive

The sample introduces the notion of primary Db2 members and standby Db2 members. Primary Db2 members normally have application servers attached that are doing productive work. Standby Db2 members can run in hot standby mode with no attached application servers.

  • The primary Db2 member names are the Db2 group name plus a digit (for example, HA11).
  • The standby Db2 member names consist of the Db2 group name plus a digit (HA12).

In addition, Figure 1 above illustrates an implementation where each application server has a primary Db2 member in an LPAR (MVS1) and a standby Db2 member in a standby LPAR (MVS2).

To connect the ABAP or Java™ application servers to the standby Db2 member, the described IBM® Data Server Driver failover mechanisms use:

  • The Db2 location name,
  • The z/OS LPAR virtual IP hostname ,
  • The connection port.

In a planned or unplanned incident, the SAP Database Shared Library (DBSL) recognizes the need to fail over and triggers a database connection. The CLI driver then uses the information that is specified in the db2dsdriver.cfg file to connect to a standby Db2 member.