BCV5 has a unique feature that can speed up the copy process of some of your partitioned tablespaces considerably. In many environments, there are tables that are used as “transaction tables”, and they are virtually always located in partitioned tablespaces. These tables are used in a special way: It is only allowed to add new rows to the end of such a table, but existing rows are never updated or deleted. The only exception is a scenario where, due to partition rotation, the partition that currently stores the oldest rows is archived and then cleared and reused as a partition for the newest rows. It is also possible that such a table is located in a PBG. Typically, each partition hold a day’s or a week’s worth of data, and these tablespaces are among the largest objects in your entire Db2.

When your production Db2 contains one or more of these tables, and you periodically copy them from production to test, you will notice that the vast majority of the data is already in your test environment. Essentially, if the last copy was one week ago, you alreay have all the data except for the last seven days in your test environment. Yet, since tablespaces are usually copied completely, several hundred or several thousand partitions in your test system are replaced with identical copies. This is redundant and it increases the run time and the CPU consumption of the copy process.

BCV5 solves this problem with the feature “Partition Level Refresh”. You can configure BCV5 so that some, but not all, of the partitions of such a tablespace are copied. BCV5 will check the compatibility of the source and target tablespaces and automatically adjust critical versioning information so that the target Db2 will accept the partial replacement of the partitions of the target tablespace. BCV5 can even detect if partition rotation has taken place, determine the number of times the source has been rotated, and then perform the missing rotations against your target tablespace.

By intelligently copying only those partitions that have changed since the last refresh, you can reduce the total copy time and CPU consumption to a fraction of what they used to be, and still end up with the same result in your test system.