BCV5 copies, refreshes and replicates Db2 objects quickly and efficiently
BCV5 copies Db2 tablespaces and indexes between different Db2 subsystems, or within the same subsystem. It comes with a built-in copy tool that works directly on VSAM level and is much faster than UNLOAD/LOAD.
When measured against conventional copying methods, BCV5 saves approximately 90% on elapsed copy time as well as resource consumption. One customer even cut their copy process time down from ten hours to 45 minutes by switching from UNLOAD/LOAD to BCV5.
BCV5 is a faster, more efficient and more manageable way to copy Db2 data. BCV5 not only copies the physical Db2 data fast, it also takes care of all the structures. This includes all the basic objects – your databases, tablespaces, tables and indexes – and also DDL features such as views, triggers, aliases, synonyms, constraints, and many more. If your target objects already exist, it will check them for compatibility. It automatically generates and executes jobs that will:
Once a copy task is defined, it can be executed at any time, either manually or using a job scheduler for periodic execution.
Need to provide Db2 data from last week, last month or last year? Want an automated and efficient method to recreate DDL and data in record time?
IB takes snapshots on demand and allows you to restore the objects whenever you need them into any environment. You can use the original names or rename the objects.
BCV5‘s Icebox component compares structural information from the backup with current structures, and it can either restore old data into the current tables or drop and recreate the tables so that they look exactly like they did when the backup was created.
Some production systems are physically isolated to such an extent that it is extremely difficult to migrate data efficiently to test systems. They may be located on a separate LPAR or even on a separate CEC, and sometimes not even shared DASD is available.
The RC component of BCV5 makes data transfer between isolated systems simple. RC uses TCP/IP to transfer structures and data from one system to another. The entire copy process is automated and just as easy to set up and execute as a local copy.
BI provides a powerful definition language for creating, modifying and deleting BCV5 copy tasks entirely through batch jobs. It allows you to easily integrate BCV5 with other processes.
You can supply the processing options and rule sets of a copy task in a job rather than interactively. When you have multiple BCV5 installations on different systems, the batch interface is also a convenient way to transfer complete task definitions between the installations.
Our BCV5 fast copy tool now comes with a new feature called “Partition Level Refresh” that allows users to make fast VSAM-to-VSAM copies of only some partitions of a table. Finally, you can select only the partitions that have changed since you did your last copy instead of having to copy all the partitions in the tablespace.
Anyone who has ever made copies of especially large tablespaces knows how much time you can save if you only refresh the partitions that have changed. No other fast copy tool on the market offers this unique feature.
Usage Tracker can store persistent information about task executions, which helps you to track and report on your organization’s Db2 data movement, such as which Db2 objects were copied, by whom, how long the process took, and other details. This can provide valuable insights for DBAs, storage administrators, and stewards for data governance.
The mechanism that BCV5 uses to move data is based on copying the VSAM clusters that Db2 uses to store tablespace and indexspace data. There is a Db2 utility that works in a similar way: DSN1COPY.
The speed of DSN1COPY and the built-in copy utility of BCV5 are comparable if you copy a single cluster. When you want to copy an entire database or even multiple databases with all associated tablespaces and indexspaces, the copy utility of BCV5 has the advantage of integrated parallel processing with a user-definable number of threads. To emulate this parallelism with DSN1COPY, you need to create an elaborate job chain and execute it under the control of a job scheduler. When the number of data sets becomes larger, you must also take other limitations like the maximum number of steps in a job into consideration when using DSN1COPY.
The main problem with DSN1COPY, however, is the extremely low extent of automation that is built into this utility. Before the utility can be used, you must do a manual comparison of the source and target object structure in order to ensure that all attributes of all involved objects match. Some of these attributes need to be passed to the program in the form of invocation parameters to achieve usable results. The values that you need to look up are scattered over many catalog tables and need to be retrieved using multiple queries. In addition, you sometimes have to define some of the clusters in the target environment by yourself because DSN1COPY requires that all target clusters already be present.
First of all, you need to determine which datasets to copy. Let’s say you want to copy a single tablespace with all its tables and indexes. If the tablespace is partitioned, it consists of more than one dataset. Each partition may have been subject to a fast switch operation, which changes the dataset name of the corresponding VSAM cluster. Also, the indexspaces can have a mangled name that is derived from the actual index name. Indexes, of course, may be partitioned as well. To illustrate the complexity of this seemingly simple task, here’s a query that can be used to give you the name of all datasets that belong to the tablespace DB000001.TS000001 and its indexes. Note that you have to insert the database name and tablespace name in both parts of the UNION when you want to use this query.
Join our Newsletter