News, views, and items of interest on IBM's Db2 database management system and mainframes.

Friday, August 25, 2017

The Db2 12 for z/OS Blog Series - Part 15: DSN1COPY and Data Validation Improvements

If you’ve worked with Db2 for z/OS for awhile (note to IBM: I still have a problem with that lower case "b" but I'm trying),
particularly as a DBA, you’ve almost certainly had the opportunity to use the
DSN1COPY offline utility, sometimes called the Offline
Copy utility.

DSN1COPY can be used in many helpful ways. For
example, it can be used to copy data sets or check the validity of table space
and index pages. Another use is to translate Db2 object identifiers for the
migration of objects between Db2 subsystems or to recover data from
accidentally dropped objects. DSN1COPY also can print hexadecimal dumps of Db2
table space and index data sets.

Its primary function, however, is to copy data
sets. DSN1COPY can be used to copy VSAM data sets to sequential data sets, and
vice versa. It also can copy VSAM data sets to other VSAM data sets and can
copy sequential data sets to other sequential data sets. As such, DSN1COPY can
be used to

Create a sequential data set copy of a Db2
table space or index data set.

Create a sequential data
set copy of another sequential data set copy produced by DSN1COPY.

Create a sequential data
set copy of an image copy data set produced using the Db2 COPY utility, except
for segmented table spaces. (The DB2 COPY utility skips empty pages, thereby
rendering the image copy data set incompatible with DSN1COPY.)

Restore a Db2 table space
or index using a sequential data set produced by DSN1COPY.

Restore a Db2 table space
using a full image copy data set produced using the Db2 COPY utility.

Move Db2 data sets from
one disk to another.

Move a Db2 table space or
index space from a smaller data set to a larger data set to eliminate extents.
Or move a Db2 table space or index space from a larger data set to a smaller
data set to eliminate wasted space.

Given such a wide array of useful
purposes you can see how DSN1COPY is an important arrow in a DBA’s quiver… But
remember, it is an offline utility, so Db2 is not aware of – or in control of
the data that is moving. So if you use it to change data in a production page
set data integrity issues can arise. For example, you may get mismatches
between the data page format and the description of the format in the Db2 Catalog.

In scenarios where DSN1COPY was not
used properly you can encounter invalid data, abends, and storage overlays. Not
good!

Thankfully, we get some help in Db2 12 for z/OS
though. Improvements to the REPAIR utility make it easier to detect and correct
data mismatches. You can use the REPAIR CATALOG utility to fix situations where
the column data type or length in the table space differs from the catalog definition
for the column. If Db2 can convert from the data type and length in the table
space to the data type and length in the column then the REPAIR CATALOG utility
enables conversion. The data type or length of the data in the table space will
be changed to match the definition in the Db2 Catalog the next time that the
data is accessed.

Additionally, we can use the REPAIR
CATALOG TEST utility to detect multiple types of data mismatches. All of the
following can be detected: