Refreshing your replication environment

Before replication begins, perform a refresh operation to load the contents of your target database and synchronize its contents with your data source.

Replication processing sends changes to a target database as they occur in near real time. Refresh processing, by contrast, synchronizes the entire contents of a source and target table so that replication processing can begin or resume with matching data.

In some cases, performing a refresh is preferable to resuming replication from a past restart position:
  • You discover errors or inconsistencies in the target database
  • Mass updates occurred at the data source that change most or all records
  • Replication has been inactive long enough that refreshing the data will take less time than replicating the historical changes

You initiate refresh processing at the subscription level, and then the subscription refreshes any tables that require it. After the subscription finishes refreshing all the tables, it resumes replication automatically.

Administer refresh processing by using Management Console and ensure that you synchronize your tables and maintain data consistency:
  • Perform refresh to synchronize your tables—Wherever possible, avoid using third-party utilities to load your target database. Management Console cannot ensure the accuracy of your data if you use an external load mechanism. If you must load the target data externally, be sure to perform the procedure in the correct sequence:
    1. Quiesce the data source.
    2. Set a log position to a point in time after the load.

      For VSAM, the source data set cannot be opened by any address space that will be logging updates when the log position is set.

    3. Reactivate the data source.
  • Protect data consistency when you refresh—Quiesce the data source during refresh processing to maintain the consistency between your source and target tables, even though adaptive apply processing at the target database can handle most situations if you do not.

    Replication for the subscription is inactive during refresh processing, although log reading can continue. The source server stores the change messages until replication resumes. Replication processing begins from the point in time where refresh processing started.

    Unless all log positions for replication mappings are more current than the bookmark for the subscription, the bookmark determines where log reading begins.

You might see messages that refer to the Classic call level interface (CLI). InfoSphere® Classic CDC for z/OS® uses a CLI driver internally to fetch data and send it to the target engine.