Chapter 4. Merging SAP components without moving data 55
The procedure DUPLICDB finds any clashes and tries to resolve them by
regenerating the last three characters of the database name to new random
values. It tries this up to 20 times for each clash, and if it cannot resolve the
clash, it reports this. If this error occurs, then you will need to change the value of
the target database name in the migration tables to a unique value. This action is
very unlikely, and all clashes should be resolved.
The JCL to move the metadata from the source to the target, the procedure
DUPLICDB, as well as the JCL to submit it, are included in “Working with
metadata tables” on page 182.
4.4.6 Source and Target: Define source objects in target system
In order to merge the tables from the source to the target system, the definitions
of the source objects need to be added into the target DB2 catalog.
We use a mix of methods for generating the DDL to create the source objects in
the target system:
For generating the DDL for creating stogroups and views, we extract the data
out of the DB2 catalog tables directly using SQL statements and REXX
For generating the DDL for databases, tablespaces, tables, and indexes, we
use the reverse engineering functionality of DB2 Admin. Output from DB2
Admin is tailored using REXX procedures.
We assume that the only objects in the system are those in a typical SAP
installation. Therefore, we only generate DDL for stogroups, databases,
tablespaces, tables, indexes, and views. Objects, such as synonyms, aliases,
comments, relationships, and triggers, are not expected to exist in the system, so
these are not included in our generation procedures.
We chose to write SQL queries and REXX procedures for creating stogroups and
views rather than using DB2 Admin. DB2 Admin generates objects for a given
database, and, as views and stogroups may be associated with more than one
database, duplicate stogroups and views would have been created.
Important: A fundamental requirement of the merge in place procedure is to
retain the OBIDs of the tables when they are merged from the source to target
systems. When the OBID is retained, only the header pages of the tablespace
must be REPAIRed. If the OBID of the table is changed, then every single
page of the table must be REPAIRed, and this is not feasible.