In Focus

Can BCV5 copy from Db2 V10 to V11?
Yes. Db2 version 11 introduced a new internal tablespace format that supports 10 byte RBA/LRSN values. When copying from V10 to V11, BCV5 automatically makes the required target catalog adjustments to make sure that the target Db2 will recognize the basic format. When copying within Db2 V11, it is also possible to copy an extended format tablespace to a basic format tablespace, provided that the current log RBA of the Db2 subsystem can still fit in 6 bytes.

Can BCV5 copy simple tablespaces?
Starting with Db2 V9, it is not possible to create new simple tablespaces anymore. However, BCV5 is still able to copy existing simple tablespace into newly created objects without using Unload/Load. All simple tablespaces are converted to segmented tablespaces on the fly during the copy process. There is no manual effort for the user and no performance overhead like with UNLOAD/LOAD.

Can BCV5 copy only the DDL?
Yes. The copy process of BCV5 is divides into different stages. If you like to copy only the DDL structure of a database to a target it is possible to submit only the first two stages. These two stages extract the DDL from the source and create the involved object in the target. After these two stages you have the same database structure like in the source, but the objects are empty.

Does BCV5 require advanced copy services like Flashcopy™?
Hardware based copy services are not required BCV5 has its own integrated copy facility, which is able to copy Db2 VSAM datasets directly on VSAM. Additionally BCV5 copies several datasets in parallel and also takes care of translating OBIDs and other internal values.
Hardware based copy services like Flashcopy™ or Snapshot™ are very fast, but due to the modifications that BCV5 needs to make during the copy (translate DBID/OBIDs, reset log RBAs and level IDs), the 1:1 copies that hardware based copy processes create are not directly usable by the target Db2. However, in an in-flight copy process, hardware based copy services can be used for the initial copy, which is always a 1:1 copy. Since in-flight tasks always post-process the target data sets in order to apply log records, using a hardware based copy for the initial copy results in performance advantages.

Does BCV5 copy real time statistics?
Yes. BVC5 copies the real time statistics for all involved objects (tablespaces, indexes, LOB and XML tablespaces) from the source catalog to the target catalog. Having accurate real time statistics is important because Db2 utilities such as REORG TABLESPACE or REBUILD INDEX can use the real time statistics to calculate the sizes of required sort work datasets. Inaccurate real time statistics in the target environment may cause these utilties to overallocate or underallocate sort work space.

Does BCV5 copy the RUNSTATS information?
Yes. If you copy into an existing environment or if you created an entire new environment the RUNSTATS information of the target is out of date. During a bind package or bind plan process the optimiser uses the RUNSTATS information to calculate the best access path. If the RUNSTATS are outdated this may result in a bad performance of your applications. BCV5 copies the RUNSTATS of the source to the target. It extracts all RUNSTATS information from the source that is used by the optimizer and inserts these RUNSTATS into the target environment. This has the advantage that the optimizer will use the copied RUNSTATS information to find the most efficient access path for your applications.

Does BCV5 ensure the compatibility of source and target?
Yes. When you copy into an existing target environment, BCV5 performs a compatibility check before the actual copy is done. This compatibility check ensures that the objects of the source and target have compatible attributes. For instance if you have a tablespace that is in the source located in a 4K bufferpool and in the target the tablespace is located in a 8K bufferpool it is not possible to copy the tablespace directly on VSAM level. In this case BCV5 switches automatically to UNLOAD/LOAD for the respective object to ensure that the object is copied anyway. This UNLOAD/LOAD process is also integrated in the BCV5 copy process.

Does BCV5 handle identity columns and sequences?
Yes. An identity column is a numeric column that generates a unique ID for each inserted row of a table. If you copy such a table from source to target you must consider the highest assigned value from the source table. In the case that the highest assigned value of the source is higher than the one of the target this could result in inconsistencies of Db2. Because if you copy the tablespace from source to target the highest assigned value of the target is not correct anymore. For the next INSERT into the target table Db2 would assign a duplicate value.
Sequence objects are similar to identitiy columns, but are not associated with exactly one table. BCV5 also adjusts the next value that a sequence obejct will return. This works for regular sequence objects as well as for implicit sequence objects that Db2 generates for XML columns.

Does BCV5 handle OBID translation?
Yes. Each table has a unique ID, called the OBID. This ID uniquely identifies the table within the respective database. Each record of the internal Db2 data pages contains this OBID, to identify which table is related to which row. Because the OBID of source and target differ in most cases it is required to translate the OBIDs for every row from the source value to the target value. Otherwise the target Db2 would refuse to work with the copied tablespace. BCV5 implicitly translates the OBIDs from source to target. It automatically gathers the OBIDs of the source and target tables and uses this information during the copy process to change the respective fields within each row.

How does BCV5 handle additional target indexes?
If the target environment already exists BCV5 performs a compatibility check. It checks the compatibility of all involved objects, but also recognizes that in the target may be additional indexes. In this BCV5 automatically generates a REBUILD index statement and performs that after the copy process is done. The REBUILD index is necessary because BCV5 replaces the existing data of the tablespace and Db2 is not involved in that process. So the data of the index is not valid anymore.

How does BCV5 handle LOBS/BLOBS/CLOBS?
BCV5 does not have a problem with copying lob tablespaces and auxiliary tables. BCV5 copies the data direct on VSAM level so this is not an issue like when using UNLOAD/LOAD. BCV5 copies the DDL of the lob tablespace and auxiliary tables as well as the data.

How does BCV5 handle XML tablespaces?
In many cases, BCV5 can copy XML tablespaces and the associated indexes directly. In some cases, the internal format of the XML tablespaces may differ between source and target (depending on the Db2 version). BCV5 detects this and can automatically switch to Unload/Load for the object in question and also exploit spanned Unload datasets for increased performance.

How is a BCV5 copy process organised?
Each copy process is represented by a BCV5 task. A BCV5 task contains the options of the copy processes, but also the objects that should be copied from source to target. It also contains the renaming of the objects.
A BCV5 task can be created in three different ways:
You can se the supplied workstation interface to setup a task. The workstation component runs on your PC and uses a server started task to communicate with the MVS system.
You can use the ISPF based interface to create a task.
You can use the integrated batch interface to create a task. With this method you can create a new BCV5 task using a JCL batch job.
After a BCV5 task has been created you can submit the job chain manually or integrate it into you scheduler.

Is it possible to integrate BCV5 into a scheduler?
Yes, it is. The complete BCV5 copy process consists of 6 JCL jobs. The JCL of the jobs is very fixed. Once the JCL has been generated it does not change anymore. This makes it really easy to integrate the BCV5 copy process into a scheduler to make regular copies of your Db2 data.

Are the source objects accessible during the copy process?
Yes. A regular BCV5 copy job starts the source objects for read-only acces. With the InflightOption you do not need to stop them for read-only access, however you will get a consistent copy of your data. All changes that have been done during the copy process will be backed out in the target using the Db2 log. As a result you will have a consistent copy of your data without influencing the accessibility your source objects.

Which copy rates can we expect?
The experience shows that you can expect copy rates from at least 100 MB/sec. up to 400 MB/sec. Most of our customers copy 1 TB / per hour.
These high rates can be achieved because the integrated copy utility of BCV5 works by default with several parallel threads. The actual copy rate that you can achieve depends on your environment. Also the other workload of the machine must be considered for this. To test which copy rates are possible in your environment contact your local distributor, or the UBS-Hainer Support directly.

Why is BCV5 so fast?
BCV5 has an integrated copy utility which is optimised for high speed Db2 copies. This utility works on physical dataset level. It copies the VSAM cluster of the involved tablespaces directly from source to target. During the copy process the program translates the object IDs (OBID) on the fly. This utility does not operate on row level like UNLOAD/LOAD works. Instead it copies the Db2 data pages directly from source to target. This saves a lot of CPU time. Additionally the program works with several copy threads. By default BCV5 copies 10 VSAM datasets in parallel, which reduces the elapsed up to 90%.
Another reason why BCV5 is so fast is that is does not need to rebuild the indexes in the target. BCV5 just copies this indexes from source to target. This makes an additional rebuild index obsolete.