DB2 data sharing can provide the following advantages over other database architectures:

These advantages and an overview of the operational aspects of data sharing are described in detail in DB2 12 for z/OS Data Sharing: Planning and Administration, SC27-8849.

DB2 12 for z/OS offers a number of data sharing enhancements to provide improved availability, scalability, and performance:

This chapter describes the following enhancements to data sharing:

DB2 12 for z/OS introduces the concept of continuous delivery where enhancements are delivered continuously in the maintenance stream as they are available. Starting at release migration or new installation, a function level is used to identify the set of enhancements and capabilities available on the system. Similar to DB2 11 for z/OS where compatibility mode and new function mode are available modes for a data sharing group, a group with DB2 12 members can have the corresponding function level V12R1M100 or V12R1M500 respectively (or 100 and 500 for short). In DB2 12 for z/OS, the -DIS GROUP command no longer shows the mode. Instead, its output is changed to show the following function levels, which belong to the entire data sharing group (not individual member’s property):

This is the currently active function level for the data sharing group. The -ACTIVATE command is used to change the current function level.

This is the function level that was last activated before the current function level. The previous activate function level might be higher than or level with the current function level. If a previously activated function level is higher than the current function level, then the current function level can be displayed with an asterisk (*) at the end, which is also called star function level (similar to the star modes CM*, ENFM* in DB2 11 for z/OS).

This is the highest function level that is activated so far. The highest activated function level might be higher than or level with the current function level. If the highest activated function level is higher than the current function level, then the current function level can be displayed with an asterisk (*) at the end (as mentioned, this is similar to the star modes CM*, ENFM* in DB2 11 for z/OS).

Other useful information about the -DIS GROUP command is each DB2 member’s code level. The code level is shown with each member’s subsystem name, member ID, command prefix, and so on. The code level is the applied PTF that provides the capability on each member. All members must have at least the equivalent code level to the function level that is specified on the -ACTIVATE command. The individual member’s code level is shown in the format VVRMMM where VV is version, R is release, and MMM is the modification level. This differs from DB2 11 for z/OS where the DB2 code level is three characters in the format VVR where VV is version, and R is release.

For more information on the -DISPLAY GROUP command changes, see Chapter 2, “Continuous delivery” on page 7.

To use XA support with client applications communicating to a DB2 data sharing group, the user must set up dynamic virtual IP addresses. A dynamic IP address must be configured for the DB2 group, and one IP address must be set up for each DB2 member in the group. Prior to DB2 12, DB2 was restricted in terms of its transaction architecture. For example, multiple XA transactions using the same transaction ID (XID) or multiple branches of a global transaction may not share resources (locks) in a data sharing environment. When different XA resources on the same global XID connect to different members of the data sharing group (either intentionally or by Workload Manger), the queries running on the global transaction may experience contention against each other and time out. The same condition can occur when multiple XA transactions with different branches of the same global transaction connect to different DB2 members with Sysplex Workload Management enabled. This is because the DB2 server threads on different members are not able to share locks.

DB2 12 improves that situation where multiple connections on the same global transaction (global transaction ID and format ID but branch qualifier IDs are different) are serviced by different members of the data sharing group. A member is consider the owner of the global transaction when that member is the first member connected to by the first XA resource using an XA connection. That member writes an entry in the SCA structure with the global transaction ID, format ID, the owning member’s IP address and port. Then when a subsequent XA resource using an XA connection to connect to another member with the same global transaction, that other member queries the SCA structure to determine the owning member. A DRDA connect request is built and routed to the owning member using its IP address and port. In this way, the subsequent queries actually run on the same member and avoid a lock issue when branches of the global transaction connect to different members.

Figure 5-1 shows the interaction between two XA connections in the same global transaction and one is being rerouted.

Example 5-1 shows some Java code snippet that builds different branches of the same global transaction connecting to different DB2 data sharing members and issuing UPDATE statements on the same table.

Since the data sharing introduction in DB2 Version 4, customers have been using Automatic Restart Manager (ARM) or other external mechanisms to restart a member automatically when DB2 or the LPAR that DB2 is on fails. Many data sharing customers want DB2 to be able to restart another peer DB2 member in the same data sharing group in the event that a member fails. With this feature, customers no longer need to implement an external mechanism to perform the automatically recovery process for a failed DB2 and would address the DB2’s goal for reliability.

DB2 12 introduces an enhancement to restart a peer member automatically for retained lock recovery in case of LPAR failures without requiring ARM or external automation. A new DSNZPARM is introduced, PEER_RECOVERY, to specify whether this data sharing member is to participate in data sharing peer recovery.

These are the acceptable values:

This member is not involved in the peer recovery process. NONE is the default value.

This member should be recovered by a peer member in case this member fails.

This member is to assist to recovery another peer.

This is the combination of RECOVER and ASSIST options.

PEER_RECOVERY DSNZPARM can be specified on the installation panel DSNTIPK and is online-changeable.

Upon receiving the notification from z/OS that a peer member with a PEER_RECOVERY setting of RECOVER or BOTH has failed; all surviving members that have the PEER_RECOVERY setting of ASSIST or BOTH serializes the recovery process by obtaining a global lock. The first assisting member having the lock attempts to restart the failed peer DB2 by issuing the START DB2 command with the LIGHT(YES) option. The last DSNZPARM load module used by the failed peer is also used to automatically restart it. Light restart is requested because the goal is to handle retained locks only.

If this light restart results in a failure, another assisting member can retry the process to recover the same instance of the failed member. When all members have tried and the failed member still cannot be recovered, a manual intervention is needed to restart that DB2.

When a group buffer pool structure fails before data in the structure is written into DASD, the group buffer pool is put in the group buffer pool recovery pending (GRECP) state. The START DATABASE command must be issued to recover the data. DB2 also attempts to recover the GRECP state as soon as it occurs.

The logical page list (LPL) contains a list of pages (or a page range) that cannot be read or written for reasons such as the transient disk read and write problems, which can be fixed without redefining new disk tracks or volumes.

Specific to data sharing, the LPL also contains pages that cannot be read or written for “must-complete” operations, such as a commit or a restart, because of a problem with the coupling facility. For example, pages can be added if a channel failure occurs to the coupling facility or disk, or if locks are held by a failed subsystem, disallowing access to the needed page.

As soon as the pages are added to the logical page list, an automatic LPL recovery is attempted by DB2. Automatic LPL recovery is also performed when the user issues the START DATABASE command with ACCESS(RW) or ACCESS(RO) option for the table space, index, or partition.

Automatic recovery of GRECP and LPL was introduced in DB2 9. However, if these automatic recovery processes fail for some reason, then the object in the GRECP or LPL status remains as is, and the user must reinitiate the recovery process by issuing the START DATABASE command.

To improve availability, DB2 12 implements the retry logic for the GRECP and LPL recovery processes. This retry is initiated at three-minute intervals.

DB2 keeps track of the oldest write claim on a page set/partition and stores it as the system-level commit log record sequence number (LRSN). In a data sharing environment, for insert applications, the system-level commit LRSN is the key to better lock avoidance. To take the best advantage of avoiding locks or reusing deleted space, all applications that access data concurrently should issue COMMIT statements frequently. However, some applications cannot issue COMMIT often because application logic causes the system-level commit and read LRSN to remain old even though the majority of objects are already committed. This can cause other threads running other applications to experience an increase of lock requests because DB2 cannot exploit the lock avoidance logic.

In some cases, DB2 also keeps track of the read interest on a page set/partition and stores it as the system-level read LRSN. Read LRSN is used by DB2 space management scheme to determine if a deleted LOB space can be reused. In certain cases, with DB2 10, a deleted LOB space is not reused effectively and causes the LOB space to grow. You can define LOBs as inline LOBs to avoid the LOB space reuse problem, but this workaround leads to another problem which is the base table space reuse problem. You must then run REORG to reclaim the unused space.

DB2 12 improves both performance and space issues by providing greater granularity for commit LRSN and read LRSN. These values are kept at the object level (page set or partition) in each DB2 member’s memory. Each member can track a maximum of 500 object-level commit and read LRSN values. These are the oldest values for each object and are advanced at commit. When a page is accessed, the page’s LRSN will be compared to the object-level LRSN to determine whether a lock is needed. When the object is not in the track list, the highest LRSN value from the list will be used for comparison. This technique is also used in non-data sharing. In data sharing, each member also needs a global view of which other members are also using this object. Therefore, the object-level commit and read LRSN values are also stored in the SCA structure for each member.

Up through DB2 11, the DB2 lock structure managed by IMS Resource Lock Manager (IRLM) can be set up with system-managed duplexing for availability in case a coupling facility (CF) failure occurs. This feature is available with CF Level 11. System-managed duplexing for any coupling facility structure requires every structure update to occur in both primary and secondary structures at the same time. Two identical commands are sent to both structures with sequence numbers to be executed in parallel, and both must complete successfully before the update request is returned to IRLM as the exploiter. The drawback with this synchronous approach is performance overhead when the two structures are located further away from each other (such as distance greater than 10 kilometers). This overhead can be visible to a DB2 transaction making updates to the database and waiting for lock requests (both primary and secondary structure updates) to be completed.

With DB2 12, the new feature, asynchronous duplexing for lock structures, is introduced to address the performance issue while maintaining the availability advantage. Figure 5-2 shows the 2 DB2 data centers with larger distance and the system-managed duplexing group buffer pools, SCA and lock structures.

This feature, which uses the z/OS asynchronous duplexing support for lock structures in the coupling facility, has these requirements:

With asynchronous duplexing, the lock requests from a DB2 transaction will be sent to IRLM and the z/OS cross-system extended services (XES) to the primary lock structure only. XES will return a sequence number to IRLM and DB2 as soon as the primary structure's update is done. Meanwhile a request to update the secondary structure is sent by XES in the background. Each thread keeps track of the secondary structure’s update sequence number and the oldest is saved at the DB2 member level. When a forced log write is needed for the transaction (such as at COMMIT), DB2 and IRLM will check with XES that the oldest sequence number's request has been successfully written to the secondary structure. Most of the time, the secondary structure that was updated should have been completed because continuous requests have been submitted to it in the background. If not, DB2 log write process is suspended until updates to the secondary structure are done, and this suspend time is accounted in the DB2 log write suspend time.

This approach usually has performance result similar to the simplex lock structure because there is no waiting for dual structure updates in the mainline request to the primary structure. The continuous, asynchronous background updates to secondary structure ensures completion in a timely manner and achieves the duplexing functionality for availability in the case when the primary structure fails.

To exploit asynchronous duplexing, the CFRM couple data set (CDS) must be formatted with new ASYNCDUPLEX keyword, and the CFRM policy for DB2 lock structure must be updated with new ASYNCONLY keyword. After this CDS is in effect, a simple z/OS SET XCF,REALLOCATE command can start rebuilding the lock structure with asynchronous duplexing protocol, assuming all DB2 and IRLM members in the data sharing group have joined with the appropriate code level PTFs.

The z/OS DISPLAY XCF,STR command support can be used to check structure status with regard to the CFRM policy for duplexing (structures that are duplexed, or are in the process of establishing duplexing, or are in the process of falling out of duplexing).

Figure 5-3 shows the z/OS DISPLAY XCF command output, which displays the asynchronous duplexing status for the lock structure.

Upon restarting DB2 12, DB2 identifies to IRLM and if IRLM has the PTF for APAR PI68378, IRLM will request asynchronous duplexing protocol to XES. When the lock structure is reallocated with the CFRM couple data set and CFRM policy indicates asynchronous duplexing for the IRLM lock structure, the rebuild process begins as shown in the figure. From this point on, the lock structure is allocated with this protocol and a subsequent DB2 IRLM member restarting with the PTF for APAR PI68378 is needed. Otherwise (such as restarting of a coexisting DB2 11 member), XES will automatically rebuild the IRLM lock structure with simplex mode.

The z/OS messages listed in Example 5-2 will be issued to show that duplexing is no longer active.

When the coexisting DB2 11 is stopped, XES will rebuild the lock structure back to asynchronous duplexing mode because all members are in DB2 12 function level V12R1M100. Example 5-3 lists messages that are issued to show reduplexing.