Resource consumption (Data Replication for VSAM)

Forward Recovery and Data Replication for VSAM share a log stream. This shared log stream is also referred to as the replication log in the product information for Data Replication for VSAM. The log is only common when the data set is defined for both forward recovery and replication logging. You do not need to use forward recovery to get a replication log.

Data Replication for VSAM relies upon replication log records. They provide more detailed information than a log record that you use for forward recovery.

You must specify the LOGREPLICATE attribute to activate replication logging for each VSAM data set. This attribute enables before images, after images, and commit records to be written to the log stream. These replication log records are generated in addition to any records generated by forward recovery logging.

The log reader retrieves changes from this log. Batch applications that use CICS VSAM Recovery (CICS VR) also write log records to the replication log, and you can share the log stream with an online CICS system.

You must manage the retention of the replication logs so that they exist for as long as you need them for processing historical changes after planned or unplanned outages. The longer retention period can increase storage utilization.

CPU time increases measurably compared with processing the same workload without change capture. If the impact of adding Data Replication for VSAM is a concern, evaluate additional CPU usage in another environment before activating production. For example, you might want to evaluate the cost of replication logging in a test environment before altering production data sets to include LOGREPLICATE.

Data Replication for VSAM uses significant network bandwidth, and requires TCP/IP links between the source and target servers to operate effectively at high speeds. All replicated data and the control messages necessary to maintain replication flow over the network connection.

Data Replication for VSAM must run in high-priority service classes to maintain low latency. Use a workload manager (WLM) service class to give the Classic data servers the resources that they require to synchronize source and target databases in near-real time. Define service classes and assign the Classic data servers to these classes. Give the Classic data servers a higher priority to allocate sufficient cycles for the workload.

Typically, you give the target server a higher relative dispatching priority than the source server so that it can offload work as fast as (or faster than) the source server sends it.

Both the source and target data servers consume system memory.

Source servers have a capture cache per subscription that can require up to 3 GB of memory. The memory required for the source server can grow as subscriptions increase because more subscription capture caches will be created.

Target servers use above-the-bar memory for transaction storage which is limited to 2 GB per subscription.

Target servers also use above-the-bar memory for dependency analysis. Each target server contains one area for dependency analysis.

Subscriptions use two caches that you configure independently to accommodate differences in the speed of the source and target servers. These subscription-level caches can improve performance when replication errors require your Classic data servers to catch up to current processing.

You can configure the caches by using the Subscription wizard in the Classic Data Architect (CDA).