Db2 connection failover for ABAP instances

In this Guide and in other SAP Guides this failover solution is called in short form "CLI failover". The CLI driver reads the information from configuration file db2dsdriver.cfg, wherein failover sequences can be configured.

The CLI failover is fully supported by SAP tools as Software Provisioning Manager (SWPM), Software Upgrade Manager (SUM) and DBA Cockpit.

After the installation of a new SAP System, adaptations are required in the CLI failover configuration file db2dsdriver.cfg to achieve the wanted failover mechanism. An example of such a CLI failover configuration file is explained in Operating an SAP system under System Automation control.

Changes in the CLI configuration file can be done either by an editor on operating system level, or by the SAP provided Failover Configuration Tool in SAP transaction DBACOCKPIT. Also, refer to the following PDF for details on how to configure and manage CLI Failover in an SAP environment: http://ibm.biz/CLI_failover_V14.

These are the main advantages of CLI failover in a planned failover scenario:

• Active Db2 threads reconnect to another Db2 member as customized in the configuration file db2dsdriver.cfg, which is an XML file in the SAP global directory.
• Long-running SAP batch jobs or dialog steps can seamlessly fail over to another Db2 member at a commit point even before the end of the job or dialog step is reached.
• With DB2 Connect 11.1, the affinityFailbackInterval parameter in db2dsdriver.cfg allows for a seamless failback of database connections to the primary Db2 member when this member is restarted after a planned or unplanned outage. It is recommended to use dynamic DDF location alias together with this parameter. Then, connections will automatically fail back only after the dynamic location alias is restarted after maintenance.

  If you use Db2 DDF without dynamic location alias, it is recommended to switch off automatic failback (set affinityFailbackInterval = 0). The reason is: The IBM Data Server Driver checks in a loop automatically after the FailbackInterval, if it’s primary database member is reachable again. If yes, it reconnects to the DDF of the primary member regardless, if the maintenance had already started or was finished. In other words, the automatic failback highly likely intervenes with the maintenance activities. When the automatic failback is switched off you avoid such unwanted reconnects. You manage the reconnect to the primary member manually if you are sure that the maintenance is successfully finished.

For unplanned failures, SAP transactions, which are in read-only state at the time the Db2 member fails, are seamlessly switched over from the failed Db2 member to another available member. So these SAP transactions do not receive a negative SQL code and can continue processing. Refer to the subsection Recommended Usage in topic Setup of CLI Failover with the SAP Failover Configuration Tool of the Database Administration Guide for SAP on IBM Db2 for z/OS® for information about CLI timeout and about the recommended timeout parameter settings (ConnectionTimeout and tcpipConnectTimeout).

CLI failover provides an hourly Db2 thread recycle on the Db2 server side. (For details see the description in APAR PK69339). The thread recycling is triggered in order to free up resources on the Db2 server side. The thread recycling is transparent to SAP. It has no impact on SAP work processes or on SAP transactions.

DB2 Call 'SQLExecute'
Warning:  conHdl = 00 SQLCODE = 88888 : [IBM][CLI Driver]
CLI0212W
A seamless failover occurred during a connect or an execute request.
SQLSTATE=01000