Efficient DB2 database copies
Complaints about long running Unload/Load jobs for test data deployment are legend, “these jobs run for hours/days”. And a load is an expensive process with regard to resource consumption, because all the testing for compatibility and constraints have to be executed line by line. In some cases, the expenditure may be acceptable. However, it does not make sense to regularly copy DB2 data in this way. Not only, because those processes run very long, but also because of the unnecessarily huge waste of CPU-time and I/O.

Copying file-wise is faster, cheaper, and anything but new. DSN1COPY has been available since the first DB2 release. DSN1COPY works faster and more efficient, but is quite cumbersome in terms of use and inappropriate for the daily use by anyone other than experts. But, DSN1COPY can show a reduction of 50 to 90 percent of the CPU-time when compared to Unload/Load, a reduction to as little as one-tenth of the time. Shouldn’t that be enough reason to use this copy process? Usually with Unload/Load only the tables are moved, their indexes are rebuild afterwards, also a costly process, isn’t copying the data and indexes more efficient?

On the market today, there are more appropriate copy tools that deploy multi threading (parallel processing), hence achieve still higher copy speeds than DSN1COPY. Further, these products have the ease of use and automation to make wider use by a variety of staff possible. For an in-depth discussion see, Comparing BCV5 with DSN1COPY.

Quality Assurance needs current test data, pre-production testing is just that important. The statement that is often heard is that more frequent copying is not possible or affordable because of cost concerns. That statement stands on shaky ground when we still favor the most expensive procedure versus the cost effective copy capabilities available today. A ten hours unload/load process can easily be broken down to a less than one hour copy task, likewise the cpu usage is cut back in the same ballpark.