Upgrade Guide for DB2 UDB for z/OS > Database and UI Upgrade Planning > Planning Your Upgrade >

Planning Changes to the Physical Layout of the Schema

In planning your upgrade, you must understand the existing physical layout of your schema and determine whether or not you need to change this for the upgrade to Siebel 7.8. You should also consider database space requirements and whether or not you need to move tablespaces. These issues are discussed in this topic.

New Database Schema Structure Since Release 7.7

In Release 7.7, Siebel introduced the current database schema structure, referred to as the 1:1:1 model. It has the following characteristics:

• One table in each tablespace
• One tablespace in each database

Prior to Release 7.7, the database schema was built using approximately 20 databases, each of which contained multiple tablespaces. Each of these tablespaces (if non-partitioned) contained multiple tables. Release 7.8 contains thousands of databases. For example, an SIA installation has approximately 2700 databases. Each database has one tablespace and each tablespace has one table.

This model meets IBM recommendations and prevents database descriptor (DBD) locking and logging. These issues arise due to the increasing intensity of DB2 DML and DDL operations and the interaction of these operations with the DBD. The DBD is locked when information about the DB2 objects contained by the DBD is requested and accessed. In general, the more objects a DBD contains, the more probable that a DBD lock will be requested when information about a child object of the DBD is accessed.

Locks are acquired on the DBD table space (DBD01) if a DBD is not in memory (EDM pool). If the DBD is in the EDM pool, no lock is acquired on it if the SQL being run is static. However, most SQL executed by Siebel applications is dynamic; this means locks are acquired on the DBD. For more information on DBD locking, refer to the relevant IBM documentation.

The adoption of the 1:1:1 model since Release 7.7.x means that you must decide how much of this model to deploy. You have the following options:

• Create all tables in the 1:1:1 model.

  New 7.8 tables are created in the 1:1:1 model and the Siebel supplied storage control file is used for the upgrade.

• Create new tables in the 1:1:1 model and maintain existing tables in their current tablespace if possible.

  The following scenarios arise if you select this latter option:

  • Some existing tables need to be moved to incorporate the addition of new columns.
  • Some existing tables need to be moved, because they have been extended and the addition of new columns causes the table's LRECL to exceed that of the tablespace. This necessitates the use of the extract and merge methodology to create the storage control file. For more information on this methodology, see Extracting the Storage Control File.
  • Tables that are to retain the existing format are merged into the template control file which employs the 1:1:1 model.

For both options, enter existing tables that are to be migrated to the 1:1:1 model in the file override.inp. See About the Override File for further information.

For more information on using storage control files, see Implementing Siebel Business Applications on DB2 UDB for z/OS.

Preparing a Storage Control File

A key task for a successful upgrade is the building of a suitable storage control file for both the development and production upgrade. You must consider space requirements. This is particularly important for the development upgrade, because three new repositories are imported into the database (one extra repository is imported during the production upgrade). Some repository tables will increase significantly in size, so you must provide sufficient space for expected database growth. See Preparing the Storage Layout of the Schema for more information.

About Moving Tablespaces

If you want to move tables from one tablespace to another, you need to recreate the tables in the new tablespace and then drop the existing tablespace. You cannot change the bufferpool designation in the storage control file to move tables because the page size is associated with the tablespace.

For example, if you are making changes to an existing tablespace that is using BP1 or a 4K bufferpool and these changes cause you to receive a warning from ddlimp that the table will now need to be in a 16K bufferpool, you cannot just change the bufferpool designation in the storage control file from BP1 to BP16K1. If you change the bufferpool designation, ddlimp will generate the following statement:

ALTER TABLESPACE <NAME> BUFFERPOOL PB16K1

This command will fail when executed because it is not permissible to alter the bufferpool associated with the tablespace unless the new bufferpool designation is the same size as the existing bufferpool designation.