Table of Contents

Search

  1. Preface
  2. Part 1: PowerExchange Change Data Capture Introduction
  3. Part 2: CDC Components Configuration and Management
  4. Part 3: CDC Sources Configuration and Management
  5. Part 4: Change Data Extraction
  6. Part 5: Monitoring and Tuning
  7. Appendix A: CDC for z/OS Troubleshooting
  8. Appendix B: DTL__CAPXTIMESTAMP Time Stamps

Recovery from z/OS System Failures

Recovery from z/OS System Failures

If a z/OS system fails, all PowerExchange components on the system are unavailable. After you IPL the z/OS system, normal operation usually resumes. In certain circumstances, you might need to move the PowerExchange CDC components from the failed z/OS system to another z/OS system, called the destination z/OS system.
To quickly reestablish the ability to perform change data extractions, you can move the PowerExchange components that relate to extraction to another z/OS system in the sysplex. If you also want to capture new change data, you must move all of PowerExchange CDC components and usually the source database system or region. For example, to move the PowerExchange CICS/VSAM capture environment to another system, you must also move CICS region in which the CICS/VSAM ECCR runs.
The following table describes considerations for moving extraction components in a Post-Log Merge environment to another z/OS system in the sysplex:
Component
Considerations
PowerExchange Listener
  • If a PowerExchange Listener runs on the destination z/OS system and uses the same PowerExchange CDC environment, edit the NODE statement that points to the failed z/OS system in the dbmover.cfg file on the Integration Service machine to point to the PowerExchange Listener on the destination z/OS system.
  • If you move the PowerExchange Listener from the failed system, you must either redirect network traffic for the failed z/OS system to the destination z/OS system or edit the NODE statement for the failed z/OS system in the dbmover.cfg file on the Integration Service machine to point to the destination z/OS system.
  • To restart extraction CDC sessions, you must also move the Post-Log Merge job.
Post-Log Merge Job
  • The Post-Log Merge job can be restarted on any z/OS system in the sysplex, including systems that do not currently run a member Logger.
  • Move the PowerExchange Agent if there is not one running on the destination z/OS system.
  • To restart extraction CDC sessions, you must either move the PowerExchange Listener and redirect network traffic for that PowerExchange Listener or change the NODE statement in the dbmover.cfg file on the Integration Service machine to point to a PowerExchange Listener that runs on the destination z/OS system.
The following table describes considerations for moving capture components in a Post-Log Merge environment to another z/OS system in the sysplex:
Component
Considerations
ECCR
  • Only move a synchronous ECCR to another z/OS system if the source database region or workload moves. In this case, a PowerExchange Agent and a member Logger must be available on the destination z/OS system. If a member Logger of the same Post-Log Merge group runs on the destination z/OS system, do not move the PowerExchange Agent and PowerExchange Logger from the failed system.
  • For the Adabas, Datacom table-based, IDMS log-based, and IMS log-based ECCRs, the PowerExchange Agent and PowerExchange Logger from the failed z/OS system must be moved to the destination z/OS system. The destination system cannot run another PowerExchange Logger that has the same Logger name or is part of the same Post-Log Merge group. The destination z/OS system must also run the Post-Log Merge job and the PowerExchange Listener used for change data extraction.
  • For a DB2 ECCR that attaches to a data sharing group, you can only move the ECCR to a destination z/OS system that does not have a member Logger that is a part of the same Post-Log Merge group. Then move the member Logger from the failed system. The destination system must also have a DB2 subsystem that is a member of the same data sharing group. This DB2 subsystem can be the subsystem that is moved from the failed system or the one that normally runs on the destination system.
  • For a DB2 subsystem that attaches to a non-data sharing DB2 subsystem, the related PowerExchange Agent and PowerExchange Logger must be available on the destination z/OS system. The destination z/OS system cannot run another PowerExchange Logger that has the same Logger name or is part of the same Post-Log Merge group. You must also move the DB2 subsystem to the destination system.
PowerExchange Agent
None
PowerExchange Condense
  • A PowerExchange Logger that is part of the Post-Log Merge group must run on the destination z/OS system.
  • The destination z/OS system must also run the Post-Log Merge job.
PowerExchange Logger
  • If no PowerExchange Logger runs on the destination z/OS system, you must also move the related PowerExchange Agent from the failed z/OS system.
  • If a member Logger in the same Post-Log Merge group runs on the destination z/OS system, do not move another member Logger to that system.
PowerExchange Listener
If you use the PowerExchange Listener on the failed z/OS system to extract change data, also move the Post-Log Merge job to the destination z/OS system.

0 COMMENTS

We’d like to hear from you!