Potential configuration changes when you consolidate data sharing members

Although the process of consolidating members requires only a couple of steps, you should spend time planning for this change. You might want to change various settings and configurations. If you are also consolidating the number of z/OS® LPARs, you need to do additional planning.

When you consolidate data sharing members, consider making changes in the following areas:

  • Subsystem parameters: If you plan to run more concurrent active threads for each member after consolidation, you might need to adjust certain subsystem parameter settings to accommodate the larger number of threads. For example, you might need to increase certain in-memory cache sizes, certain limit settings, or both.

    Consider adjusting the following subsystem parameters:

  • Active log data sets: To accommodate the new consolidated member configuration, consider increasing the size and quantity of active log data sets.

    When more threads execute concurrently on each Db2 member, more Db2 logging is likely to occur on each member. Before consolidation, this logging was spread out over the active logs of multiple members.

    Making sure that you have enough active log space helps performance. Reads from the active log are faster than those from the archive log, especially if archives are on tape.

    You can dynamically add the active log data sets that you need while Db2 is operational. For instructions on how to add active log data sets, see Adding an active log data set to the active log inventory with the SET LOG command.

  • Buffer pools: If you plan to run more concurrent active threads for each member after consolidation, consider increasing the buffer pool sizes that are defined for each member. Also, consider adding new buffer pools.

    For example, suppose that member_1 had previously been running with a maximum of 400 concurrent active threads and a total buffer pool space allocation of 5 GB. Assume that after you consolidate your data sharing members, you increase the maximum number of threads for member_1 to 1200. In this case, the 5 GB of buffer pool space might no longer be sufficient, and threads might start to suffer I/O delays. In this case, you probably need to increase the 5 GB of buffer pool space to a larger size. The increase depends on whether the new threads predominantly access the same tables and indexes as the pre-existing threads. If the new threads predominantly access the same database objects, you probably do not need to increase the size of the buffer pools that much. If the new threads predominantly access different database objects, you probably need to increase the size of the buffer pools more.

    After you consolidate to fewer members, the total amount of buffer pool space that is allocated for all members is likely to be less than the amount of space that was allocated before consolidation.

    For more information about determining the appropriate buffer pool sizes, see Tuning database buffer pools.

  • Work file data sets: If the number of concurrent active threads increases on a given subsystem after consolidation, consider allocating more temporary database storage. To create this extra space, create additional table spaces within the work file database.

    To find temporary space usage statistics, look at data section 4 of statistics record IFCID 2. You can use these statistics to determine existing consumption and to help project future usage.

    Also, consider the value of the MAXTEMPS_RID subsystem parameter. This parameter determines the amount of temporary storage in the work file database that can be used for RID overflow. If this parameter is set to a value other than NONE, more work file space might be used for each thread and therefore, you might need to define more work file space.

    You can use the MAXTEMPS subsystem parameter to regulate temporary space for each thread. You might need to increase the value of MAXTEMPS if MAXTEMPS_RID is set to a value other than NONE.

    Recommendation: If you need additional space, consider adding 32 KB work file data sets. Since DB2® 9 became available, Db2 exploits 32 KB work file data sets more aggressively than in earlier releases.
  • SQA and CSA: If you plan to run more concurrent active threads for each member after consolidation, consider increasing the sizes of the SQA (system queue area) and CSA (common service area). After you consolidate members, carefully monitor the CSA subpools and SQA subpools to determine the amount of extra space, if any, that you need.

    For example, a typical configuration might have a single Db2 subsystem on an LPAR that has 300 to 500 threads that are attached to Db2. Because of the advances in virtual storage constraint relief in DB2 10, you can run 10 or more times the number of threads in a single LPAR. To handle this extra demand, depending on how many threads are running, you might need to increase the size of the SQA and CSA on the LPAR. This increase could be quite significant depending on several factors. For example, in the typical configuration described here, the size might need to increase to 50 MB. You need to consider your own configuration and monitor it carefully to determine an appropriate SQA and CSA size for your situation.

  • Real storage: When Db2 members are consolidated, the demands on real storage can increase. For example, increases in buffer pools and the number of threads can increase the demands on real storage. Make sure that your consolidated system has enough real storage to prevent paging.

    To estimate how much real storage you need, look at the IFCID 225 records for the existing members prior to consolidation. Subtract the buffer pool and EDM pool numbers from the real storage number in IFCID 225. (This calculation assumes no auxiliary storage.) The resulting value approximates the amount of real storage that the threads are using. You can then use this amount to calculate the new value for the LPAR that is to contain the consolidated members.

  • Number of LPARs and central processors (CPs): After you consolidate data sharing members, consider consolidating the number of LPARs and releasing the CPs from the LPARs that are being deleted. Reconfigure the surviving LPARs to use the additional processors. When deciding whether and how to consolidate LPARs, consider availability and failover.
  • CICS® attachment facility: You can configure the CICS attachment facility to attach to a group or to attach to a specific member. If you have this facility configured to attach to a specific member, you might need to change many different CICS regions to point to the one of the members of the new consolidated data sharing group.

    Group attachment has the advantage of easy movement of the CICS region around the sysplex. However, this method has the disadvantage of possibly allowing a Db2 member to be overloaded in DB2 version 8 and DB2 9 if a CICS region attaches to a member that is does not have enough available storage. Attaching to specific member can guarantee improved availability.

  • DDF aliases: When you consolidate data sharing members, you need to remove deleted members from any defined aliases.

    A data sharing group can have multiple location names, or aliases. Each alias can identify a subset of the members for remote connection to the data sharing group.

    Use the DSNJU004 utility to verify the DDF alias configuration. Then use the DSNJU003 utility to modify the DDF alias configuration to contain the remaining consolidated Db2 members that are needed for each alias.

  • TCP/IP addresses: When members are removed from a data sharing group, review the TCP/IP configuration information for the remaining members to determine if you need to make any of the following changes:
    • Remove the IP address of any members that you are removing from the group.
    • Remove the resync port for any members that you are removing from the group.
    You need to consider both ports that are reserved in the TCPPARMS data set and ports in the DVIPA configuration.

    For instructions on how to customize the TCPPARMS data set, see Customizing the TCP/IP data sets or files. For instructions on how to customize the DVIPA configuration, see Supported methods for specifying DVIPAs.

  • Client CDB: When you consolidate data sharing members, you might need to modify the configurations of remote clients that reference that data sharing group. If the client uses a DVIPA to access the data sharing group and its members, you do not need make changes. However, if the client uses IP addresses to access members of the data sharing group, you need to make changes. In this case, you need to remove from the client configuration the IP addresses of the members that are being deleted.
  • RBA rollover: When you consolidate data sharing members, consider that you might need to reset the RBA on the consolidated members sooner than expected.

    When you run more work on a single member, that member writes log records at a higher rate. Therefore, its end-of-log RBA value increases at a higher rate. For Db2 members that log at very high rates, their log RBA can eventually hit the maximum value. The maximum value is X'FFFFFFFFFFFF' for basic format with 6-byte RBA or LRSN values or X'FFFFFFFFFFFFFFFFFFFF' for extended format with 10-byte RBA or LRSN values. When this limit is approached, you need to shut down that member and reset its RBA value.