Data Sharing Requirements

 <  Day Day Up  >  

Data sharing consists of a complex combination of hardware and software. To share data, DB2 subsystems must belong to a predefined data sharing group. Each DB2 subsystem contained in the data sharing group is a member of that group . All members of the data sharing group access a common DB2 catalog and directory.

Each data sharing group is an OS/390 Cross-system Coupling Facility (XCF) group. The group services provided by XCF enable DB2 data sharing groups to be defined. In addition, XCF enables the data sharing environment to track all members contained in the data sharing group. A site may have multiple OS/390 Sysplexes, each consisting of one or more OS/390 systems. Each individual Sysplex can consist of multiple data sharing groups.

NOTE

XCF was introduced in MVS/SP 4.1 with the MVS Sysplex.


DB2 data sharing requires a Sysplex environment that consists of the following:

  • One or more central processor complexes (CPCs) that can attach to a coupling facility. A CPC is a collection of hardware consisting of main storage, one or more central processors, timers, and channels.

  • At least one coupling facility. The coupling facility is the component that manages the shared resources of the connected CPCs. DB2 uses the coupling facility to provide data sharing groups with coordinated locking, buffer pools and communication. MVS V5 is required to install a DB2 coupling facility.

  • At least one Sysplex timer. The Sysplex timer keeps the processor timestamps synchronized for all DB2s in the data sharing group.

  • Connection to shared DASD. The user data, system catalog and directory data, and MVS catalog data must all reside on shared DASD.

NOTE

The DB2 logs and boot strap data sets (BSDS) belong to each DB2 member individually. However, they too must reside on shared DASD.


Your shop also should have a security facility that supports security in a Parallel Sysplex environment before implementing DB2 data sharing.

NOTE

For IBM's RACF, Version 2 Release 1 functions in a Parallel Sysplex environment.


Refer to Figure 19.1 for an overview of a DB2 data sharing environment consisting of two DB2 subsystems connected using a coupling facility.

Figure 19.1. A DB2 data sharing environment.
graphics/19fig01.gif

DB2 Data Sharing Groups

Data sharing groups may span multiple MVS systems. A data sharing group consists of individual DB2 subsystems, called members. Data sharing group members must belong to the same MVS Sysplex. Data sharing group members can only belong to one data sharing group.

Up to 32 DB2 subsystems can be members of a DB2 data sharing group. Each DB2 subsystem of the data sharing group can access all of the data in each of the subsystems as if it were local. Any DB2 object (table space, index, table, and so on), in any of the DB2 subsystems in the data sharing group, is available to all members of the group. This includes the shared DB2 catalog and directory.

Data sharing is done within the members of the data sharing group; a request cannot span multiple groups.

Certain DB2 objects must be shared between members, whereas other objects are owned by members. Refer to Table 19.1 for a breakdown of the shared versus non-shared objects.

Table 19.1. Shared and Non-Shared Objects

Shared Objects

Non-Shared Objects

DB2 Catalog

BSDS

DB2 Directory

Archive and Active Logs

Coupling Facility Structures

DSNDB07

Lock Structures

Sort, RID, and EDM Pools

Group Buffer Pools

Local Buffer Pools

Shared Communication Area

Trace Data


Application Impact

No special programming is required for applications to access data in a DB2 data sharing environment. Each individual subsystem in the data sharing group uses the coupling facility to communicate with the other subsystems. The intersystem communication provided by DB2 data sharing provides a system image that resembles a single, standalone DB2 subsystem to the application.

No application programming changes are required. The only modifications that may need to be made to current application programs to run in a data sharing environment are to provide additional error checking for "data sharing" return codes.

There is a one-to-one relationship between OS/390 and data sharing transactions. The DB2 member where the transaction was initiated keeps all of the information related to that transaction that is needed to successfully execute it. Once a unit of work begins processing on a member, it is executed in its entirety on that member.

Impact on Attachment Interfaces

Likewise, DB2 data sharing has no impact on existing attachment interfaces. The DB2 subsystem name may still be used to attach to a particular DB2 subsystem. Application programs using the subsystem name will only be able to attach to those DB2 subsystems that reside on the same OS/390 system as they do.

TSO and CALL ATTACH support a GROUP ATTACH name. This generic name is created during the group's originating member installation. The GROUP ATTACH name allows TSO and batch jobs to connect to any DB2 in the group. This eliminates the need to know the DB2 subsystem name on local OS/390 systems.

IMS and CICS transaction managers are unable to take advantage of the group attach name. They must remain sensitive to a specific DB2 subsystem to be able to resolve any in-doubt units of recovery.

Impact on DCL and DDL

Because all members of the data sharing group share a common catalog, security grants, table definitions and program definitions only need to be executed once. DDL and DCL do not need to be rerun for each data sharing member.

Sysplex and Distributed Access

Distributed access requests, using both public and private DB2 protocols, can be made to a data sharing group. All members of the group have the same location name. This enables distributed requests to be made in a data sharing environment transparent to the application program.

Application Support

Even though the impact of data sharing on applications is minimal, the impact on application support is substantial. When DB2 subsystems are grouped together using data sharing, any application can access any database in any of the data sharing member subsystems. This can make debugging, supporting, and testing difficult.

Additionally, the software licensing impact of data sharing can also be quite problematic . Do not implement data sharing without first considering what supporting software is necessary. In a data sharing environment, software licenses that previously applied to a single machine only may have to be renegotiated for multiple machines (those in the Sysplex).

 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net