Overview of IMS Replication

You can use IMS Replication to produce copies of your IMS databases and maintain current data in near-real time, typically on geographically-dispersed IMS subsystems.

Purpose

IBM® InfoSphere® IMSReplication for z/OS® addresses your organizational requirements for reliable and available data:

  • High availability and disaster recovery (HADR)
  • Workload distribution
  • Business intelligence
  • Site/database maintenance
  • Data backup
High availability and disaster recovery (HADR)
Data center downtime is a significant interruption that affects productivity, revenue, and trust. For example, a global banking enterprise lost its secondary data centers in the aftermath of a terrorist attack because they were too close to the primary sites. The ATM network was down for days, at incalculable cost to the company and its customers. Extreme weather events, such as hurricanes or other natural disasters, can have similar consequences.

IMS Replication supports your data availability strategy by helping you to ensure the availability of your data from secondary or backup instances. It offers the following advantages for your HADR solution:

  • No geographic restrictions on the distance between the primary and secondary sites
  • Quicker recovery from failures compared to hardware-based solutions
Workload distribution
IMS Replication supports conflict detection and exit-based conflict resolution capabilities that can be used to force synchronization of your application databases between sites. When used with partitioning routing algorithms, this capabilitly allows you to distribute incoming workload between sites based on synchronization state information that is provided by the conflict exit.
Business intelligence
IMS Replication also supports scenarios that distribute your business intelligence workload to a secondary, read-only platform where analysts can run queries.
Site/database maintenance
Use a replica of your production databases for active processing while you perform scheduled maintenance of your source databases and applications. When the source upgrade process is complete, use IMS Replication to reintegrate the changes that were made while the source site was unavailable with the new versions of the databases at the source site.
Data backup
Create synchronized backups of mission critical data in near-real time.

How IMS Replication works

The illustration shows how IMS Replication maintains synchronized replicas in high-volume IMS subsystems that undergo rapid rates of change:

Figure 1. Classic data servers capture changes from IMS log streams and apply those changes to target databases
An illustration that depicts the basic flow of change data in IMS Replication.

A Classic source server uses a log reader to process IMS log data and capture changes to a source database. Capture processing then packages these changes as change messages that describe insert, update, and delete operations on the data. The source server sends the change messages to a target server at a different site that applies the changes to a replica of the source database.

IMS Replication is unidirectional, which means that you send changes from one site to another instead of in both directions at once. You use IMS Replication with target databases that you do not update actively so that you can maintain synchronization of your data between the source and target.

Technical capabilities

IMS Replication can capture changes from a single DB/DC or DBCTL subsystem. It can also capture changes from hundreds or thousands of shared databases in an IMS data-sharing environment. You can capture updates from multiple IMS DL/I batch jobs, DB/DC subsystems or DBCTL subsystems in a sysplex. IMS Replication also supports high availability environments that implement FDBR (Fast Database Recovery) regions.

IMS Replication has the following key components and capabilities:

  • Subscriptions
  • Transactional consistency
  • Replicating historical changes
  • Monitoring and reporting
Subscriptions

You organize the databases that support a given application by mapping them to their target databases within a subscription, a unique combination of source databases, memory caches, and communication paths. Because of its autonomous structure, you can start, stop, and maintain replication for a subscription independently of other subscriptions. Stopping replication for one subscription has no effect on the operations of others.

Transactional consistency

IMS Replication can manage transaction processing across multiple logical partitions and databases. A subscription maintains the sequence of transactions as they occur at the source by applying changes to a given record in the correct order.

Replicating historical changes

Planned or unplanned outages can cause target databases to fall behind current processing and to go out of synchronization. IMS Replication can automatically catch up with unprocessed changes that occurred in the past, whether replication stopped due to replication or memory errors, link loss, or apply errors.

IMS Replication maintains bookmark information that specifies where the log reader begins again in the event of an outage. The change data that the source server maintains in caches can reduce the time that it takes to catch up to current processing.

Monitoring and reporting

You can review current and accurate metrics in the Classic Data Architect, a supplied graphical user interface. Using this tool, you can measure resource consumption, latency, throughput, and memory usage, enabling you to evaluate the replication process and optimize your environment.

IMS Replication can also be configured to push Event Integration Facility (EIF) events to an event server and to receive requests from Network Management Interface (NMI). This configuration can be set up by using GDPS® Continuous Availability components or a site can develop its own custom interfaces.

You can also use automation to periodically issue master terminal operation (MTO) commands to display latency and throughput information.

IMS Replication can also write user log records in the target IMS logs that can be used for auditing and performance analysis. A custom log print formatter is also provided for simple reporting purposes.

Operations
You can use a graphical user interface, MTO interface, or z/OS batch command processor utility to administer your replication environment. Status and error information is displayed on the console and written to log streams that can be accessed from Classic Data Architect.

These capabilities allow you to use your existing automation software to monitor and control your IMS Replication environment.

Replication models

IMS Replication has two different operational models: continuous replication and site transition replication.

Continuous replication
This model is used in high availability, workload partitioning, business intelligence and data backup environments. These are all some form of GDPS environment that IMS Replication is designed to support. The other GDPS components are not required for you to use IMS Replication and an organization can use other tools to manage and control its replication environment.

In these kinds of environments, the IMS Replication software runs almost continuously and is typically set up to allow data to be replicated bidirectionally between two or more sites by using paired subscriptions and source and target servers that are deployed at each site.

This kind of deployment typically takes considerable effort to set up and manage but provides the most business value and allows for higher utilization of your z/OS investment than other solutions. Extensive testing, tuning, and operational preparation is required because the software must run all the time with a goal of low-latency replication.

Site transition replication
This mode is used when performing site maintenance operations. Replication runs only briefly and changes flow one way in preparation for transferring control from one site to the other. This mode of replication works most effectively by using flash copy technology to seed the database environment at a site.

From an IMS Replication perspective, this environment is easier to set up, test, and monitor than continuous replication. Replication is always one way and only runs for a brief period of time, processing mainly historical changes and transitioning to real-time during periods where application updates are low.

Organizing your application databases so that they can quickly be copied from one site to the next can take some effort, but if it is used in conjunction with disk mirroring this method allows an organization to be more responsive to unplanned outages. When used in conjunction with IMS Replication for planned outages and application upgrades, this solution enables an organization to be more responsive to business change and opportunities while significantly reducing outage time and risk of operational failures if something goes wrong during an upgrade.