Copying productive objects is not a problem because the copy process doesn’t affect the copied objects. The difficulties originate from the fact that parallel updates against the copied object may result in inconsistency of the target object. There are three possible solutions. First off, we accept the possible inconsistency and seek to minimize them by scheduling the copy at times with low or for the nonce unimportant activities. Second, we set the source objects in read only mode – well, normally not feasible. Third, we rectify possible inconsistencies after the copy. That is, we read the log of the source DB2 and extract the changes that were made against the copied objects during the copy. And we reverse them against the just created target objects. In other words, we undo the changes against the copied objects. As a result, we get clean objects that reflect the point-in-time state of the source objects when the copy started, and, crucial, we avoid affect on the source objects (production). The start time can always precisely be chosen (for ex., end of day).

This process works with single DB2s as well as with DB2 Data Sharing Groups.