Consolidating data sharing members

Consider consolidating your data sharing groups so that they have fewer members. Especially consider consolidation if you originally added data sharing members to provide virtual storage constraint relief.

About this task

For DB2® 10 and later releases, nearly all thread-related storage is above the bar in the database services address space (ssnmDBM1), which can provide significant virtual storage constraint relief.

Because of this location of the thread storage, you can potentially run more concurrent active threads for each Db2 subsystem or member. For data sharing configurations, this change might provide the opportunity to consolidate to fewer members.

For example, suppose that you have eight data sharing members, each of which is running 500 active threads, as shown in the following figure.

You might be able to consolidate to 4 members, each of which is running 2500 active threads, as shown in the following figure.

Recommendations:

• In configuring for high availability, ensure that enough spare capacity (such as CPU and memory) is available to absorb the work in case of a member outage (planned or unplanned). To accomplish this goal, one common method is to configure a four-way data sharing group with 2 central processor complexes (CPCs) and 2 LPARs per CPC.
• Keep the members spread across more than one LPAR.
• To help with workload balancing, consider removing the same number of members from each LPAR. For example, suppose that you have four LPARs, each with two members, and you want to consolidate to fewer members. Ideally in this situation, you would remove one member from each LPAR (instead of changing LPAR 2 and LPAR 4 to have one member and leaving the other LPARs with two members). Such a symmetrical reduction can help you with real storage and CPU planning. Otherwise, more time planning is probably required to achieve the correct workload balance.

To consolidate data sharing members:

1. Consider potential configuration changes that you might need to make when you consolidate data sharing members, and plan for these changes.
2. Redistribute the group workload:
   1. Move the work from one of the members that you plan to delete to one or more of the members that you plan to keep.
   2. After you move the work, monitor all members.
      If no issues arise, proceed to the next step. Otherwise, route any work back to the member that originally had that work, and handle any issues that arose during monitoring.
   3. Repeat steps a and b until all work is moved from the members that plan to delete to the members that you plan to keep.
   For example, suppose that you have 8 members (member_1 through member_8) and you are consolidating to 4 members. In this scenario, assume that you plan to keep member_1 through member_4 and remove member_5 through member_8. First, move the work from member_5 to member_1 through member_4. Monitor all members. If any issues arise, route the work back to member_5 and address the issues. Otherwise, if no issues arise, move the work from member_6 to member_1 through member_4 and monitor all members. Repeat these same steps for member_7 and member_8.
3. Shut down all members of the group and run DSNJU003 to deactivate the members that you plan to delete.

   You can skip this step of deactivating members, if you are certain that those members are no longer needed.

   When you shut down all members of the data sharing group, make sure that all members shut down cleanly. Make sure that none of the members have incomplete units of recovery or outstanding utility jobs, and that none of the members have QC status.

   After you deactivate members, if you later determine that you need to bring back one of these members, you can reactivate those members.

4. When you are certain that the members that you deactivated are no longer needed, shut down all members in the group and run DSNJU003 to destroy the members that you want to delete from your data sharing group.

   When you shut down all members of the data sharing group, make sure that all members shut down cleanly. Make sure that none of the members have incomplete units of recovery or outstanding utility jobs, and that none of the members have QC status.

   After a member is destroyed, you can no longer reactivate it. That member no longer exists. If you later decide that you need an additional member, you need to add a new member.

5. Implement any configuration changes that you planned for in step 1.