PRODUKTE FALLSTUDIEN LEISTUNGEN JOBS KONTAKT IMPRESSUM MEETINGS
DE  |  ENGLISH       
DB2 - Produkte System / z/OS Anwendungsentwicklung Rechenzentrum

 
BCV6
 

BCV6 - Copying DB2 Data “in-flight”

Today's business environment demands greater performance and reliability from IT systems. Progress and development of your IT systems impact day to day reliability and availability of operational systems. It is imperative that the best tools and processes are applied to minimize risk and increase overall business productivity. The BCV6 product offers significant benefits to business using DB2 database systems. 

Corporations maintain large amounts of data in DB2 databases. Many are running 24x7 environments and cannot afford to stop their mission critical applications. BCV6 copies DB2 data without impacting applications which work concurrently with the copied data, and at the same time, BCV6 guarantees that only committed data is copied.

 

BCV6, an extension of BCV5

BCV5 and BCV6 provide extraordinarily fast migration and copying of DB2 tables or databases. The tools copy both data and structure (DDL), within the same DB2 subsystem or to another. Whereas  BCV5 issues a STOP command before, and START command after the copy, BCV6 is unique in allowing continuous production operation during the copy process whilst working concurrently to other operations.

BCV6 ensures that clean data, that is committed data, is delivered to the target DB2 system. As soon as the BCV6 copy program ends, an Archive Log is sent to the source DB2 subsystem. BCV6 searches the log datasets for updates which occurred against the copied objects and removes any uncommitted changes from the copied tablespaces. An optional Quiesce can be issued at the start of the copy. In that case the copied data will be cleanly truncated to the Quiesce point. If a Quiesce is not feasible (times out), then BCV6 still ensures that in flight uncommitted transactions are removed from the target copy. In either case (with or without Quiesce) the copied tablespaces and indexspaces contain only committed data - committed before the copy process began.

BCV6 contains all of the functions of BCV5 and in addition has the ability to copy DB2 data “in-flight”. Therefore the DBA’s interface (ISPF panels and/or workstation interface) are identical between BCV5 and BCV6 with the exception of 2 addition fields for BCV6. The additional BCV6 fields are:
- APPLY LOG: YES/NO
- SET QUIESCE: YES/NO.

Continuous availability of DB2 databases is essential in today's business environment. BCV6 offers a unique solution to copy only committed data by eliminating the need to stop DB2 objects.

Functions

BCV6 provides for fast, efficient and comfortable copying of DB2 data. Compared with other methods based on UNLOAD/RELOAD or DSN1COPY, BCV6 works ten times faster. Thereby it requires only 10% of the resources consumed by conventional procedures, measured in CPU-Time or SRU. To put it in a nutshell: BCV6 saves 90% of the copy time and 90% of the computer resources.

BCV6 is capable to copy or migrate DATABASES, TABLES, and INDICES, as well as the corresponding RUNSTATS rows, and related objects like GRANTS, BINDS, VIEWS, TRIGGERS, FUNCTIONS. There are some restrictions with the latter. Thus BCV6 copies "DB2 data", that means, it cares about both, the data definition stored in DB2's catalog and the data itself, i.e. the pagesets of table- and indexspaces. BCV6 is able to copy directly from tablespaces or to copy from image copies. It handles all kind of tablespace without user intervention, including LOBs. Instead of deploying a number of tools for the various steps to migrate a set of databases, a BCV6 user just selects the objects to be copied and specifies renaming rules. BCV6 then generates self-acting the jobs to

  • extract the object definitions from the catalogue of the source system,

  • transfer the definitions to the target system, rename the objects as specified, and apply them at the target DB2 system (CREATE, or DROP and CREATE) or,

  • compare the source definitions with already existing target objects for compatibility,

  • copy all involved pagesets from source to target DB2 system,

  • translate object-ids, if requested,

  • adapt RBA or LRSN and to apply the log excerpts to the copied pagesets.

BCV6 comes with it's own internal copy programs based on LDS CIs. These programs are due to their multi-thread design very fast and they are capable to translate object-ids. However BCV6 optionally deploys advanced copy services like Flashcopy Version 2, Snapshot, or the like - with the restriction of not allowing OBIDXLAT.

Copying DB2 data with BCV6 requires to define a BCV6 TASK. This is accomplished either with BCV6' easy to handle ISPF interface or with it's unique workstation interface. Once defined a BCV6 TASK may be repeatedly executed at any time as an integrated and automated process, controlled by BCV6, through a scheduler, or manually.
Thus BCV6 saves not only computer resources and copy time, first of all it helps to save the most valuable resource. Highly qualified manpower should be dedicated to supervision and administration rather than to the attendance of cumbersome tools.

Concept of this product

This product is intended to be a tool for DB2 data movement under z/OS. The main design goals were to offer 

  • an integrated process for "copying", in the way that the user only specifies what is to be copied and whereto, and the tool then cares about all aspects of that task;

  • a product which is fast enough to copy bulk data in a shortest amount of time, and efficient enough in the sense of saving computer resources during copying;

  • a tool which is easy to handle and to adapt to varying environments;

  • a copy service for 24x7 environment.

The product is equipped with two user interfaces. One is based on ISPF the other is a workstation program written in JAVA. Both allow to define copy tasks, edit the specifications of tasks, and allow to submit tasks.

Image


See "Apply after Copy"  and "Set Quiesce after Copy"

To define a copy task a user basically specifies

  • the involved DB2 subsystems, the source system and the target system (which may be the same).

  • the objects, i. e. the databases or tables to be copied,

  • the renaming rules to be applied for the objects to be copied,

  • whether the task shall recreate the indexes at the target side,

  • whether the internal OBJECT IDs (OBIDS) should be translated,

  • whether the related RUNSTATS data should also be transferred to the catalog of the target system,

  • whether other related objects like GRANTS, BINDS, VIEWS etc. should be transferred as well.

  • whether the source objects shall be stopped during the copy process or

  • whether the fuzzy copies shall be adjusted to Qiesce Point via the log of the source DB2 (BCV6 only).

 

Once a task is defined it may be executed at any time under the control of the product itself or under control of a scheduler or manually stage by stage.


The Stages

For each execution of a COPY TASK the product generates a number of jobs. Executed in the right order, see Figure “BCV6 Workflow”, they accomplish roughly the following:


Image

Figure: BCV6 Workflow

 

  • Stage 1 retrieves the definition of the objects to be copied from the catalog of the source DB2 system and writes this information into an intermediate storage, see WD - WORK DATASET.

  • Stage 2 creates the ’same’ objects in the target DB2 subsystem. These are usual, or standard DB2 CREATES. The objects created may have, according to the renaming rules the user specified for this task, other name attributes than the original objects of the source DB2 system.

  • Stage 3 transfers the data, i. e. it copies the tablespaces and optionally as well the indexspaces from the source location to the target destination. Before the copy process begins, there is either a STOP comand issued or a FORCE CHECKPOINT command. With BCV5 only the STOP command is available. If required, the copy program will do OBID translation. When the copy process is finished, either a quiesce point is set and the active log is archived or the stopped objects will be restarted. With BCV5 only the restart is available. BCV6 will search the active logs for updates to the objects copied during the copy process. The changes found will then be used in Stage 4 to synchronize the affected tablespaces to the QUIESCE POINT set before or to a user specified timestamp or RBA.

Where BCV can help:

  • When test data are to be refreshed at regular intervals

  • When the schooling department needs further schooling zones

  • When the programming team requires a new base for the development

  • When development teams have to be provided regularly with data

  • When an additional information system for peak workload times is required

  • When after LOAD the Runstat-Utility requires too much time

  • When copy and migration requests are very time consuming.

  • When the Batch Window is too small.

  • When due to the length of the copy time, copies are only possible during a few weekends.

  • When a status has to be recreated with Image Copies.

  • When integration or performance test series are pending and repeatedly large amounts of data have to be copied.

  • When complex selections have to be moved regularly

  • When DSN1COPY is simply not the appropriate tool

  • When the selection of objects to be copied, the transport of data or the alignment of DDL have to be integrated in one process.

  • When Flashcopy2 or Snapshot have easily to be used for DB2-migration works.

  • When the requirement of the source system availability is rising, and the Quiesce and Stop timeframe must be shortened.

  • When the costs for migration and copy processes have become too high.


sales@ubs-hainer.com

 

Copying DB2 Data "in-flight"

Presentation_2007-04-26


more

Präsentation (engl.)
 

 DB2 Data Migration and Fast Copying with BCV5 (1) 

 
 
 
 
 

 
 
Go to Top