Start of change

Modifying Db2 for the GDPS Continuous Availability with zero data loss solution

If you are using the GDPS Continuous Availability with zero data loss solution with Db2 for the first time, you need to modify your Db2 data sharing groups.

About this task

You need to make a number of changes to your Db2 environment if one of the following situations is true:

  • You are using the original release of the GDPS Continuous Availability with zero data loss solution, and you are ready to upgrade to the GDPS Continuous Availability with zero data loss (GDPS Continuous Availability with zero data loss) solution.
  • You have not used the GDPS Continuous Availability with zero data loss solution before, and you are installing the GDPS Continuous Availability with zero data loss (GDPS Continuous Availability with zero data loss) solution.
GDPS Continuous Availability with zero data loss solution terminology: A GDPS Continuous Availability with zero data loss solution that includes Db2 requires three data sharing environments. The solution includes a source Db2 data sharing group, a proxy Db2 data sharing group, and a target Db2 data sharing group. The proxy group uses a capture program to capture changes to tables on the source group. The proxy group then uses a replication program to replicate the changes to the target group. A VSAM key-sequenced data set, called the compression dictionary data set (CDDS), must be defined in the source group. It holds the following items for use in capture and replication:
  • The expansion dictionaries for Db2 tables whose changes are captured

    Currently, the CDDS contains a maximum of three versions of the expansion dictionaries.

  • System status information that the proxy group uses to find the log data sets and to determine the status of the source group members

Procedure

To prepare Db2 data sharing groups to use the GDPS Continuous Availability with zero data loss solution, follow these steps:

  1. Convert all members of your source and proxy data sharing groups to Db2 11 new-function mode.
  2. Convert the BSDS data sets to extended 10-byte format by running the DSNTIJCB job on all members of your source and proxy data sharing groups.
  3. Choose a member of the source data sharing group that is not running a capture program to be the first member to be upgraded. Create the CDDS on that member.

    To minimize the possibility of an out-of-space condition, you should define an SMS data class for the CDDS with the following attributes enabled:

    • Extended addressability
    • Extended format
    • Extent constraint relief
    • CA reclaim

    Define the CDDS with a DEFINE CLUSTER command like the one below. In your DEFINE CLUSTER command, you need to specify the same values that are shown in the example for these parameters:

    • KEYS
    • RECORDSIZE
    • SPANNED
    • SHAREOPTIONS
    • CONTROLINTERVALSIZE
    Start of change
    
DEFINE CLUSTER                       -
       ( NAME(prefix.CDDS)           - 
         KEYS(8 0)                   - 
         RECORDSIZE(66560 66560)     - 
         SPANNED                     - 
         SHAREOPTIONS(3 3))          - 
   DATA                              -
       ( CYLINDERS(1000 1000)        - 
         CONTROLINTERVALSIZE(16384)) - 
   INDEX                             -
       ( CYLINDERS(20 20)            - 
         CONTROLINTERVALSIZE(2048))
    End of change

    The CDDS name must be of the form prefix.CDDS.

  4. Stop Db2 on the first source member that is being upgraded.
  5. On the first source member that is being upgraded, apply all Db2 PTFs that provide GDPS Continuous Availability with zero data loss support.
  6. On the first source member that is being upgraded, set the following subsystem parameters:
    • Set subsystem parameter CDDS_MODE to SOURCE.
    • Set subsystem parameter CDDS_PREFIX to the prefix value that you specified when you created the CDDS.
  7. Start Db2 on the first source member that is being upgraded.
  8. Upgrade each of the remaining members of the source group, one at a time. To do that, follow these steps.
    Important: If a member of the data sharing group is running a capture program, upgrade that member last. If no capture programs are running, you can upgrade the members in any order.
    1. Stop Db2 on the source member that is being upgraded.
    2. On the source member that is being upgraded, apply all Db2 PTFs that provide GDPS Continuous Availability with zero data loss support.
    3. On the source member that is being upgraded, set the following subsystem parameters:
      • Set subsystem parameter CDDS_MODE to SOURCE.
      • Set subsystem parameter CDDS_PREFIX to the prefix value that you specified when you created the CDDS.
    4. Start Db2 on the source member that is being upgraded.
  9. After Db2 is started on the last member of the source group, run REORG TABLESPACE with the INITCDDS option to populate the CDDS.
  10. Enable peer-to-peer remote recovery (PPRC) to mirror the BSDS data sets, active logs, archive logs, and the CDDS from the source group to the read-only volumes in the proxy group.
  11. Upgrade the members of the proxy data sharing group, one at a time. To do that, follow these steps.
    1. Stop Db2 on the proxy member that is being upgraded.
    2. On the proxy member that is being upgraded, apply all Db2 PTFs that provide GDPS Continuous Availability with zero data loss support.
    3. On the proxy member that is being upgraded, set the following subsystem parameters:
      • Set subsystem parameter CDDS_MODE to PROXY.
      • Set subsystem parameter CDDS_PREFIX to the prefix value that you specified when you created the CDDS on the first source member.
    4. Start Db2 on the proxy member that is being upgraded.
  12. Set the Sysplex Timer on the Sysplex for the source data sharing group and the Sysplex for the proxy data sharing group to the same value.
    Important: This step is essential to ensure zero data loss, and to avoid extended data replication latency.
End of change