1
Db2 for z/OS Data Sharing Overview
The data sharing feature of Db2 for z/OS enables multiple Db2 for z/OS subsystems to access (read/write) the same data concurrently. The Db2 for z/OS subsystems participating in this arrangement are effectively sharing data with each other, while the associated system components leveraged in this configuration assure basic tenets of data base management such as Isolation, Concurrency, Consistency, and Data Integrity.
This paper will explore the system configuration requirements necessary to enable data sharing in a Db2 for z/OS environment. The various z/OS operating system resources leveraged by Db2 for z/OS in data sharing will also be addressed. The paper will show how Db2 for z/OS uses these system resources to accommodate the sharing of data among multiple Db2 for z/OS subsystems. The paper will also discuss the advantages to an IT organization associated with the implementation of such a data sharing configuration. This paper is a mid-level technical discussion on Db2 for z/OS Data Sharing.
For the remainder of this discussion, the term Db2 will mean Db2 for z/OS (as opposed to Db2 LUW, etc.). This discussion is exclusively for Db2 for z/OS, where the term Db2 is concerned and used. References to z/OS are exclusively for those services and programs executing in a z/OS operating system.
DISCLAIMER: The following discussion is a personal interpretation of the IBM provided documentation on these topics. Because interpretations of technical documentation may vary from person to person, and are therefore subject to scrutiny, the user should always rely on IBM documentation for the definitive and authoritative explanation of each topic.
This paper is as of Db2 12 for z/OS and z/OS 2.2, and was written on Dec. 18, 2017 by:
Kurt Bohnert
Manager, Db2 Systems Programming
Rocket Software, Inc.
Db2 for z/OS includes a facility called Data Sharing (DS). The premise behind this feature is to allow multiple Db2 subsystems to share user data for the purposes of supporting business applications. Each Db2 subsystem participating in such a configuration is said to belong to a Db2 for z/OS “Data Sharing Group”. Each Db2 subsystem in the group is said to be a “member” of the data sharing group.
Before we proceed, let’s briefly visit a few basic definitions about Db2 data sharing:
· A collection of one or more Db2 subsystems that share Db2 data is called a data sharing group (DSG).
· Db2 subsystems required to access shared Db2 data must belong to a data sharing group.
· A Db2 subsystem that belongs to a data sharing group is a member of that group.
· Each member can belong to one, and only one data sharing group.
· All members of a data sharing group share the same Db2 Catalog and Directory, and all members must reside in the same Parallel Sysplex (there is much more discussion regarding Parallel Sysplex below).
· The maximum number of members in a data sharing group is 32.
· All members of a data sharing group can read/write the same Db2 data simultaneously. Therefore, all data accessed by the group must reside on shared DASD (Direct Access Storage Device).
A Db2 for z/OS Data Sharing Group (DSG) may be configured with up to a maximum of 32 members (32 Db2 subsystems). The members of the group not only share user data in support of the applications employing the data sharing group, they also share metadata (data about data) for the data base structures supported by the group. Perhaps a simpler way to say this is that the members of the data sharing group share the same Db2 Catalog and Directory. The Db2 Catalog and Directory is the data repository for the Db2 metadata employed in the management of the Db2 user data. It only makes sense that if the members of a data sharing group are sharing user data, then they must also share all the metadata stored by Db2 (i.e. stored in the shared Db2 Catalog and Directory) and employed by Db2 in the management of that user data.
Before we discuss the various components and configuration specifics for Db2 data sharing, let’s discuss the reasons and advantages associated with such a configuration.
It should first be noted that the implementation of Db2 data sharing carries with it some additional costs and resource requirements (e.g. CPU, memory/storage, DASD). The z/OS facilities leveraged in support of data sharing require some additional overhead. Suffice it to say for now that there are additional costs associated with the implementation of data sharing. In those cases where organizations have elected to implement data sharing, it was determined that the advantages of implementation were greater than the marginal costs associated with its implementation.
This paper recognizes four (4) primary advantages in the use of a data sharing configuration. They are identified below, and a brief discussion of each follows:
1. Improved data availability.
2. Extended processing capacity (i.e. scalability).
3. Configuration flexibility.
4. Higher Transaction rates.
Improved Data Availability
The existence of multiple data sharing members (Db2 subsystems) sharing the same data provides the application improved data availability. Because data sharing provides multiple paths to data (via multiple members), one member can be down and applications can still access the data through other members of the data sharing group.
Data sharing can aid in providing continuous availability for both planned and unplanned outages. Examples:
o Continuous Availability for unplanned outages: If one member abnormally terminates, work may continue via access to the other members.
o Continuous Availability for planned outages: Maintenance can usually be applied at the member level, allowing work to continue via one or more members while other members receive maintenance.
Extended Processing Capacity
As additional processing is added to a single Db2 subsystem, processing needs can exceed the capacity of that subsystem. Data sharing can help meet ever-increasing capacity needs. A data sharing configuration can provide the following processing capacity improvements:
· Data sharing can provide improved support for incremental growth of the applications it supports and the data it manages. Db2 data sharing leverages a z/OS feature called a Parallel Sysplex. A Parallel Sysplex can grow incrementally, allowing one to add processing power in granular units and in a non-disruptive manner. The coupling technology of a Parallel Sysplex and additional CPU results in more workload throughput for user applications. We will discuss the Parallel Sysplex and coupling technology in detail below.
· Data sharing can provide greater workload balancing such that when the workload increases one can add a new member to the group without the need to redistribute data or rewrite applications. When one adds a new Db2 subsystem (member) into a data sharing group, applications can access the same data through the new member just as easily as through the pre-existing members.
· Data sharing can provide capacity when needed. A data sharing configuration can handle peak workloads well, such as end-of-quarter processing. One can have data sharing members in reserve, bring them online to handle peak loads, and then stop them when the peak passes.
Configuration Flexibility
Data sharing allows for greater configuration flexibility as one configures the system environment to work with operational systems, decision support systems, and shared data management.
Example: There can be more than one data sharing group on the same Parallel Sysplex, using one group for testing and another group for production.
As the systems administrator becomes more familiar with the capabilities of data sharing, the various options in configuration flexibility become increasingly clear and increasingly valuable. Most notably, this configuration flexibility allows one to tailor different systems (members) specifically for a given user set, provide better control over storage contention, and provide greater predictability of service for each different user set. The IBM Db2 doc provides a great deal of information and examples on this flexibility.
Higher Transaction Rates
Data sharing provides opportunities to put more work through the system to produce higher transaction rates. The same application can be run on more than one member simultaneously, to achieve transaction rates that are higher than would be possible on a single (non-data sharing) Db2 subsystem.
Example: Different members of the same data sharing group, supporting the same applications and data, can reside in different logical partitions (LPAR’s) of a Parallel Sysplex. The resources (e.g. CPU, storage, etc.) committed to each LPAR are therefore available to the supported applications, enabling them to enjoy greater transaction rates, improved throughput, and improved performance.
It should be noted here that the advantages embodied in the use of Db2 data sharing do not jeopardize the primary responsibilities of a DBMS (Data Base Management System) pertaining to such basic tenets as transaction isolation, concurrency, data consistency, and data integrity. Db2 is configured to leverage certain z/OS resources (discussed below) to assure that all the while many members are accessing the same data for read/write (R/W) these basic DBMS tenets are not violated.
Following are some general notes on Db2 data sharing, and discussions pertaining to specific Db2 data sharing related topics.
General Notes on Db2 Data Sharing
A pre-existing Db2 non-data sharing subsystem cannot be merged into a pre-existing DS group. One can make a pre-existing non-data sharing subsystem the “originating member” (first member) of a new DS group. There is no way however, to merge >1 pre-existing non-data sharing Db2 subsystem into a single DS group.
When operating in DS, Db2 changes from using RBA (Relative Byte Address) in the log to using LRSN (Log Record Sequence Number) in the log. LRSN is used in place of Log RBA when Db2 is operating in Db2 Data Sharing. LRSN is derived by applying an ASM STORECLOCK instruction to a GMT timestamp. RBA and LRSN are both six (6) bytes until Db2 V11, when they can be expanded to ten (10) bytes. This is transparent to the applications accessing Db2 data.
A new concept called a “global deadlock” exists in Db2 data sharing. Global deadlock occurs when two or more DS members are involved in a deadlock scenario while attempting to access shared resources (usually shared user data). Db2 design includes special code called the “deadlock detection cycle”, which is periodically executed to detect and resolve such deadlocks. This detection cycle is controlled via a parameter in the subsystem IRLM started task JCL.
A data sharing group/member is assigned several different definitions. Below is a list of some of those definitions:
· Subsystem ID (SSID) is assigned to both DS and non-DS Db2 subsystems
· Data Sharing Group Name (GRPNAME)
· Data Sharing Member Name (MEMBNAME)
· Data Sharing Group Attach Name (GAN)
· Many others (some discussed below)
The table below identifies many of the definitions and resources assigned to a DSG/Member, and provides a summary on each. Db2 allows for some flexibility in these naming conventions, and the table below represents that which this paper considers a somewhat “standard” Db2 DS configuration.
Source is the location of the definition/resource.
Parameter is the actual parameter name in Db2 for z/OS.
Notes provide a summary on each definition/resource.
The color coded high-lighting is intended to aid in linking them to each other in this table, and in the examples which follow the table.
Source / Parameter / NotesZPARM / GRPNAME / A DSG is assigned a Group Name which is shared by all members of the group. It is identified in:
1) Each member’s ZPARM GRPNAME parm.
2) Each member’s BSDS (using DSNJU003 parm GROUPNAM).
3) Each member’s MSTR started task JCL procedure (using the parm GROUP).
ZPARM / MEMBNAME / Each member of the DSG is assigned a unique Member Name, identified in:
1) Each member’s ZPARM MEMBNAME parm.
2) Each member’s BSDS (using DSNJU003
parm GROUPMEM).
3) Each member’s MSTR started task JCL
procedure (using the parm MEMBER).
DSNHDECP / SSID
When in DS, the DSNHDECP parm SSID is the GAN, and is different from the subsystem ID SSID given to the subsystem.
When not in DS there is no GAN, and SSID and SSID are the same. / A DSG is assigned a Group Attach Name (GAN), which is identified in the DSNHDECP parm SSID, and in the z/OS IEFSSNxx SSI definition gan value (see below).
Summary:
o In DS, DECP parm SSID is the GAN and is different from the standard SSID.
o Not DS, DECP parm SSID is not a GAN, and is the same as the standard SSID.
See SSID and gan in DSNHDECP below.
See ssid and gan in IEFSSNxx below.
BSDS / LOCATION / Every member of a DSG shares the same LOCATION NAME, which is identified in each members BSDS (using DSNJU003 parm LOCATION).
BSDS / LUNAME / Each member of a DSG is assigned a unique VTAM APPLID (aka LUNAME), which is identified in the BSDS (using DSNJU003 parm LUNAME).
BSDS / PORT / Every member of the DSG shares (listens on) the same TCP/IP port, configured in the BSDS (using DSNJU003 parm PORT).
BSDS / RESPORT / Each member of the DSG is assigned a unique Resync PORT in the BSDS (using DSNJU003 parm RESPORT).
BSDS / GROUPNAM / See GRPNAME above.
BSDS / GROUPMEM / See MEMBNAME above.
MSTR / GROUP / See GRPNAME above.
MSTR / MEMBER / See MEMBNAME above.
IEFSSNxx / SSID / Each member of a DSG is assigned a unique subsystem ID (aka SSID). This should not be confused with the DSNHDECP SSID parm discussed above, which contains the GAN in DS or the SSID in non-DS. See SSID above for more detail.
IEFSSNxx / grp-attach-name (GAN) / See SSID above and IEFSSNxx below.
Install Job
DSNTIJTM / SORTWORK DB / Each member of a DSG has a private SORTWORK DB created on that members behalf. Only that member can write to that DB, but all members can read it.
ZPARM’s supporting data sharing (partial list, there are many others)