Data Sharing for DB2 UDB for z/OS

Use

You can use DB2 Data Sharing and SAP Sysplex Failover Support as a high availability solution to protect the database of your SAP system against failure.

This section is a schematic description. For more information, see SAP Web Application Server Installation on <operating system>: IBM DB2 Universal Database for z/OS, which you can find on SAP Service Marketplace at:

service.sap.com/instguides

Features

To increase availability and scalability, you can set up DB2 UDB for z/OS as a parallel database, known as DB2 data sharing. With this setup, multiple DB2 subsystems share the same SAP database. Each subsystem is called a data sharing member, and the set of subsystems is referred to as a data sharing group. All members of the group use the same shared DB2 catalog and directory. This setup is shown in the following graphic:

DB2 Data Sharing

SAP Sysplex Failover Support is the implementation of DB reconnect for DB2 UDB for z/OS. It uses DB2 Connect as the connectivity software. It allows each application server to recognize more than one database server, that is, a primary database server that is used normally and one or more standby database servers that are used in the event that the application server can no longer work with the primary database server. This can be caused by failure in any of the following:

·        DB2 subsystem and Distributed Data Facility (DDF)

·        z/OS system

·        Entire zSeries hardware

·        Network

SAP Sysplex Failover Support is configured by a profile that provides a list of database connections for each application server or group of application servers. This list is cataloged to the DB2 Connect instance of each application server. For more information, see SAP Note 402078.

SAP Sysplex failover support is supported by transaction DB2 in the SAP system, with which you can do the following:

·        Active DB connections shows you the DB2 database servers currently connected

·        DB connection list lets you switch between the DB2 database servers

You can use Sysplex Failover Support in the following scenarios.

Scenario 1: Failover into Surviving DB2 Member

Each DB2 data sharing member runs on a separate z/OS system. It is used as the primary database server for one application server and as standby for another application server.

If DB2A fails, the SAP work processes of AS1 reconnect to DB2B. If that reconnection fails, AS1 reconnects to DB2C. Then DB2B or DB2C has to handle the workload of the application servers AS2 and AS1. Using this option requires that the data sharing members DB2B and DB2C have enough free DB2 capacity and z/OS capacity to handle the additional workload of the failed subsystem DB2A.

Scenario 2: Failover to Hot Standby DB2 in Same LPAR as Surviving DB2s

This failover scenario should be implemented if a data sharing member cannot handle the additional workload of a failed over application server because not enough DB2 capacity, such as virtual memory, is available. In this scenario each DB2 subsystem is used either as primary database server or standby database server but not as both. The standby DB2 subsystem is running on an z/OS system where primary DB2 subsystems are running as well.

If DB2A fails, the SAP work processes of AS1 reconnect to DB2E. Then DB2E only has to handle the workload of application server AS1. Using this option requires that the z/OS system SB has enough capacity, such as CPU and memory, to handle the workload of both data sharing members.

This scenario requires slightly more memory and CPU than Scenario 1 because of the additional DB2 subsystem. For a sizing of the additional memory and CPU requirements, contact your IBM ERP Competence Center or your SAP/IBM support group.

Scenario 3: Failover to Hot Standby DB2 in Hot Standby LPAR

This failover scenario should be implemented if problems could occur because not enough  z/OS capacity (such as CPU and memory) is available. Each data sharing member is on a separate z/OS system and is used either as primary database server or standby database server but not as both.

If DB2A fails, the SAP work processes of AS1 reconnect to DB2E on SD. If that reconnect fails, they reconnect to DB2F on SF. DB2E or DB2F only has to handle the workload of application server AS1.

This scenario requires more memory and CPU than Scenario 2 because of the additional z/OS system. For a sizing of the additional memory and CPU requirements, contact your IBM ERP Competence Center or your SAP/IBM support group.

Integration

You can fully integrate DB2 Data Sharing and SAP Sysplex Failover Support with your SAP system.

Activities

The way in which an SAP system using Data Sharing for DB2 UDB for z/OS recovers, differs according to the type of failure.

Failure of DB2 Subsystem or Distributed Data Facility

...

       1.      The application servers that were connected to the failed database server automatically reconnect to their standby database servers and continue working. SAP transactions might be rolled back, depending on the context of the SAP user.

       2.      The failed DB2 subsystem is automatically restarted and performs restart processing by using the recovery log. Non-committed transactions are rolled back and locks are released. After that, the DB2 subsystem is again ready for work.

       3.      You can now switch the failed over application servers back to their primary database server.

Failure of Entire z/OS System or Entire zSeries Hardware

...

       1.      The application servers that were connected to the failed database server automatically reconnect to their standby database servers and continue working. SAP transactions might be rolled back, depending on the context of the SAP user.

       2.      The DB2 subsystem that went down because of the failure is automatically restarted on another z/OS system. The DB2 subsystem performs restart processing by using the recovery log. Non-committed transactions are rolled back and locks are released.

       3.      Once restart processing of the recovered DB2 subsystem has finished, the database server is available for work again, now running on another z/OS system.

       4.      You can now switch the failed over application servers back to their primary database server.

Network Failure

The best protection against network failures is duplication of network adapters. For more information about the z/OS specific recommendations on how to set up a high availability network, see chapter 5 in the IBM documentation High Availability for SAP on zSeries Using Autonomic Computing Technologies (SC33-8206).

If it is not possible to duplicate the network adapters, the application servers still attempt to fail over. Depending on where the network failure was, they might even get through to their standby database server.

Failover with Application Server on z/OS

If your application server is running on z/OS, then only failover to a Hot Standby DB2 in the same LPAR is possible.

Automation and High Availability Solution on z/OS

For more information about automation and high availability solutions on z/OS, see the Internet address:

www.ibm.com/servers/eserver/zseries/software/sa