Using FlashCopy Version 2 for DB2 UDB for OS/390 & z/OS Object-Level Migration

by Daniel L. Luksetich
August 1, 2004

ACCESS(UT)

Use the DB2 REPAIR utility to adjust the internal object identifiers from their source object values to the target object values, as well as the LEVELIDs. Since the REPAIR utility needs only to touch the header pages, this process is quick. Remember, only the DBID, PSID, and ISOBID in the header pages need to be updated since the OBID of the target tables are set at object definition time and the index OBIDs are ignored. Figure 4 shows the DB2 REPAIR utilities issued for our example.

 

Once the internal object identifiers are adjusted, the target objects can be started for full access. The command is:

-START DB(YLADB02) SP(YLATS01,YLAIX01)

The copy process may still be active inside the DASD subsystem, but the operating system and DB2 are oblivious to that.

 

FlashCopy V2 DB2 Object Level Migration Performance

Please note that times listed in the following performance information are approximate; your performance may vary significantly.

A small-scale performance test was conducted using a single large DB2 table. This was followed by a large-scale test involving several large DB2 tables. During all performance tests, queries were run against the target tables to confirm that the data at the target was available and accurate. The only technique used during performance testing was technique #3.

 

Single, large DB2 table: A partitioned tablespace with a single partitioning index was copied from the one database to another database in the same subsystem. The DB2 pagesets involved encompassed 508 data sets. The combined size of all these data sets was approximately 66GB. The time taken to perform the copy process was about 25 minutes.

 

Six large DB2 tables: Six large DB2 tables were copied from one database to another database in the same subsystem. All tables were partitioned, and some had secondary indexes (NPIs) as well as partitioning indexes. The DB2 pagesets involved encompassed nearly 3,000 data sets. The combined size of all these data sets was approximately 1.1TB. The time taken to perform the entire copy process for all objects was about 46 minutes and 336.55 seconds of CPU time.

 

Performance vs. Traditional Methods

The tests were conducted on an IBM zSeries 900 computer with four available processors. Since the FlashCopy process didn’t consume much CPU, the number of concurrent processes could scale up nicely. This isn’t possible with the more traditional techniques of unload/load or DSN1COPY, as they consume significantly more operating system resources and have to compete with other processes running on the machine.