Db2 policy

Learn how the *SAPSRV add-on policy and the *Db2 add-on policy work together.

In its SAP<SID>_X group, the SA z/OS® *SAPSRV add-on policy contains a reference to a DB2_X group. The definition of this group is in fact contained in the SA z/OS *Db2 add-on policy. The SAP HA wizard adapts the resources that are contained in the SA z/OS *Db2 add-on policy to the actual SAP system by replacing occurrences of the Db2 string in the resource definitions with the 3-character SID of your actual SAP system, if the *Db2 add-on policy is part of the wizard's source PDB.

The *Db2 add-on policy in SA z/OS 4.1 and 4.2 contains additional DB2xADMT resources for the Db2 administrative task scheduler. Since this address space is in most cases not required for SAP, it is not shown in Figure 1. If you do not require the administrative task scheduler, you should remove the ADMT resources from the HA wizard's source PDB before generating a new SAP policy.

Figure 1 shows an example of what the Db2 part of the policy looks like if your SID is HA1 and for a data sharing system with three members.

Artwork for zoscluster2b — Figure 1. Db2 ***Best Practice Policy*** – adapted for SAP system HA1

In the sample shown in Figure 1, the following three Db2 members are defined for the sample SAP system HA1:

HA11 running on LPAR COH1
HA12 running on LPAR COH2
HA13 running on LPAR COH3

Each of these members is represented by a SYSPLEX/MOVE named HA1<n>_X. This in turn contains a SYSTEM/BASIC group, which again contains the standard Db2 address space resources as members.

The failure of a Db2 member requires a LIGHT restart of that member on another LPAR, such that Db2 is able to clean up its locks. This LIGHT restart capability is implemented in the *Db2 add-on policy in form of the SYSPLEX/MOVE groups HA1<n>_LITE_X. For a more detailed explanation of the relationships mechanisms inside the *Db2 add-on policy, refer to the SA z/OS documentation.

Note: The *Db2 add-on policy that is shipped with SA z/OS 3.5 and higher uses a value of CSONLY for the Status Determination field in the HA1<n>_X and the HA1<n>_X groups definitions. Therefore, the COMPOUND status of the HA1_X group then shows the worst COMPOUND status of any contained member resource, making it easier to detect problems with any of the Db2DB2® address spaces.

You may consider using a value of CSONLY for the Status Determination field in the HA1_X and the HA1<n>_X groups definitions. The COMPOUND status of the HA1_X group then shows the worst compound status of any contained member resource, making it easier to detect problems with any of the Db2 address spaces.

Note: The SA z/OS *Db2 add-on policy that is shipped with SA z/OS 3.5 or higher has CSONLY set for these groups.

Note: SAP needs the Distributed Data Facility (DDF) of Db2. DDF is implemented by the DIST address space, which is automatically started by the Db2 MSTR. If DDF starts, it needs a running VTAM. If VTAM is not available for any reason, then the DIST address space becomes available, but the DDF ends up in a stopped state.

If you issue a DISPLAY DDF command, then you see a message like:

DSNL080I -HA11 DSNLTDDF DISPLAY DDF PEPORT FOLLOWS: DSNL0811 STATUS=STOPDF

As the DIST address space is running, SA z/OS does not notice that the DDF component is not started and does not trigger any recovery.

The *Db2 add-on policy models the Db2 data sharing group as a SYSPLEX SERVER group with availability target *ALL. Consequently, the group goes into DEGRADED status if one of the Db2 members could not be started. If you model your SAP application servers as proxy resources as described in SAP application servers as proxy resources, then these proxy resources have a MakeAvailable/ WhenAvailable relationship to the Db2 sysplex group. Therefore, the application server resources are not started if the Db2 group is in DEGRADED status. If you configure Db2 connection failover for your application servers (see Db2 connection failover), then it may be sufficient that one Db2 data sharing member is available - allowing all application servers to be started. In order to enable this in the SA z/OS policy, you may consider changing the satisfactory target of your Db2 SERVER group from *ALL to a different value, which is smaller than the number of Db2 data sharing members, for example 1.

If you do not use the SAP HA wizard, you must adapt the Db2 group and resource names to your own SAP system and your environment. However, you should also take account of the naming conventions that are described in Naming conventions.

Note: The SAP add-on policies that are shipped with SA z/OS contain a reference to the DB2_X group. If you do not use the SAP HA wizard to generate the policy for your SAP system, you must ensure that your top-level Db2 group is correctly referenced and included in the SAP group SAP<SID>_X.