< Day Day Up > |
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 CreationTo 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 RecoveryEach 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 StatusesIn 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
Subsystem AvailabilityDB2 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
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.
Monitoring Data Sharing GroupsThe 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 CommandDSN7100I -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 RecoveryAlthough 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. |
< Day Day Up > |