Data Sharing Administration

One of the benefits of data sharing is that the entire environment can be administered from a single MVS console. The DB2 command prefix, which can be up to eight characters long, is used to differentiate between the different members of a data sharing group .

NOTE

Individual data sharing group member names can be used as command prefixes.

In a sysplex environment administrative DB2 commands can be routed to any DB2 member from a single console. This eliminates the need to know the MVS system name to send DB2 commands. In addition, there is no need to use ROUTE DB2 commands in this environment (see Figure 19.3).

Figure 19.3. Administering the DB2 data sharing environment.

Data Sharing Group Creation

To enable data sharing, a common DB2 catalog is required. IBM does not provide an automated mechanism for merging data from multiple existing DB2 subsystems. The process of merging systems is complex and should not be undertaken lightly. Merging subsystems is not solely a physical data movement problem but includes other administrative issues including the creation and enforcement of naming standards, DB2 security and authorization, backup and recovery, utility execution, data distribution, and on and on. Indeed, the decision to merge subsystems into a data sharing group will impact almost every aspect of database administration for the subsystems involved.

If you are still interested in merging pre-existing DB2 subsystems into a data sharing, an exhaustive 16 step process for merging data from individual DB2 subsystems is available in the IBM manual Data Sharing: Planning and Administration (SC26-9935).

CAUTION

Watch for duplicate object names when merging multiple DB2 catalogs into the shared DB2 catalog for the data sharing group. Because the objects were originally created in isolation from one another, it is likely that duplicate object names (for example, databases, tablespaces, indexes, and so on) may be encountered when catalogs are merged.

Backup and Recovery

Each DB2 member still maintains its own recovery logs and BSDS data sets. Each DB2 member must be able to read the logs of every other data sharing group member. This is required because logs from multiple members may be required to do media recovery for a single member. If logs are required from multiple members, the multiple logs are merged together during the recovery process.

Log Record Sequence Numbers (LRSN) are used to provide common log record sequencing across members. The LRSNs are used to control "redo"/"undo" for data sharing environments and are identified by a 6 byte value derived from the DB2 timestamp. The RBA is still used during non-data sharing recoveries .

Data Sharing Database Statuses

In a data sharing environment, there are two new page set statuses that can occur ” GRECP and LPL . These statuses can appear on the output of the -DISPLAY DATABASE command.

The GRECP status stands for "Group buffer pool recovery pending." It indicates that the group buffer pool was lost. This means that there are changes recorded in the log that need to be applied to the page set.

DB2 will automatically recover GRECP page sets when the group buffer pool is defined with AUTOREC(YES) and at least one member was connected when the failure occurred.

The LPL status stands for "Logical page list." It indicates that some pages were not read from or written to the group buffer pool. An LPL status can be caused by a disk failure, a channel failure (between the group buffer pool and the processor), or some other transient disk problem.

Improved LPL Recovery

Through DB2 V7, you had to manually recover pages that DB2 put into the LPL. DB2 V8 adds automatic recovery of LPL pages. When pages are added to the LPL, DB2 issues error message DSNB250E , which includes the reason the pages were added to the LPL . Then, DB2 will attempt automatic recovery, except for disk I/O error, during DB2 restart or end restart, group buffer pool structure failures, or a complete loss of connection to the group buffer pool.

Subsystem Availability

DB2 data sharing improves data availability by providing redundant failover capabilities. In the event of a DB2 data sharing group member failure, the remaining members are used to process the data requests . The workload is spread across the remaining DB2 members.

Uncommitted locks held by the failed member are retained. No member is permitted to obtain a lock that is not compatible with the retained locks. All other (non-locked) data is still accessible to the remaining DB2 members. Retained locks are purged during the restart process for the failed member.

The failed DB2 member can restart on the same or different z/OS system.

Restart Light

DB2 Version 7 introduced a new feature of the START DB2 command allowing a DB2 member to be restarted specifying restart light . The LIGHT(YES) parameter of the START command is used to select this feature. The restart light basically allows a DB2 data sharing member to be restarted simply to free retained locks. With the restart light the data sharing member is brought up with a minimal storage footprint, and then terminates normally after DB2 frees all retained locks.

The restart light simplifies data sharing administration. Because the storage required is significantly reduced, the restart light can potentially start up a system with minimal resources that would not be able to be started and stopped in normal mode.

If you experience a system failure in a Parallel Sysplex, the automated restart in light mode removes retained locks with minimum disruption.

DB2 V8 further improves restart light capability by allowing indoubt units of recovery (UR) to be handled. If indoubt URs exist after a restart recovery, DB2 will continue running so that the indoubt URs can be resolved. After all the indoubt URs have been resolved, the DB2 member that is running in light mode will shut down and can be restarted normally.

Monitoring Data Sharing Groups

The DISPLAY GROUP command can be issued from any active member of a group to determine information about all members of a data sharing group. An example of issuing a DISPLAY GROUP command follows :

 -DB1G DISPLAY GROUP 

The results of this command will be a listing of the group members, the status of all members in the group, SCA and lock structure sizes and percentages in use. The maximum number of lock and list entries possible with the number of entries in use are shown. An example of the information returned by DISPLAY GROUP is depicted in Listing 19.1.

Listing 19.1. Results of the DISPLAY GROUP Command

 DSN7100I -DB1G DSN7GCMD *** BEGIN DISPLAY OF GROUP(DSNDB0G) ---------------------------------------------------------------- DB2                                    SYSTEM    IRLM MEMBER   ID  SUBSYS CMDPREF   STATUS   NAME      SUBSYS IRLMPROC -------- --- ----   --------  -------  --------  ----   -------- DB1G       1 DB1G   -DB1G     ACTIVE   MVS1      DJ1G   DB1GIRLM DB2G       2 DB2G   -DB2G     ACTIVE   MVS2      DJ2G   DB2GIRLM DB3G       3 DB3G   -DB3G     ACTIVE   MVS3      DJ3G   DB3GIRLM DB4G       4 DB4G   -DB4G     ACTIVE   MVS4      DJ4G   DB4GIRLM ---------------------------------------------------------------- SCA   STRUCTURE SIZE:  2560 KB, STATUS= AC,  SCA IN USE:    48 % LOCK1 STRUCTURE SIZE: 16384 KB,            LOCK1 IN USE:     1 % NUMBER LOCK ENTRIES:   4194304, LOCK ENTRIES IN USE:       981 NUMBER LIST ENTRIES:     59770, LIST ENTRIES IN USE:       719 *** END DISPLAY OF GROUP(DSNDB0G ) DSN9022I -DB1G DSN7GCMD 'DISPLAY GROUP ' NORMAL COMPLETION 

Coupling Facility Recovery

Although unlikely , it is possible for the coupling facility to fail causing its structures to be lost. A dynamic rebuild of the coupling facility structures (lock, SCA) is executed during coupling facility recovery. However, if the dynamic rebuild fails, and the structures cannot be rebuilt on another coupling facility, all DB2 members contained in the data sharing group are brought down.

To recover from this scenario, a group restart is required. Group restart rebuilds the information that was lost from the SCA and/or lock structure using the logs of the DB2 group members. All of the logs for every data sharing group member must be available during the group restart process.

NOTE

Group restart does not necessarily mean that all DB2s in the group start up again, but information from all DB2s must be used to rebuild the lock structure or SCA.