Siebel Database Upgrade Guide for DB2 for z/OS > Planning a Siebel Database 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 have to change the layout for the upgrade to Siebel CRM 8.1. Also consider database space requirements and whether or not you have to move table spaces. These issues are discussed in this topic.

New Database Schema Structure Since Siebel CRM Release 7.7.x

Upgrades: Release 7.5.3 only.

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

• One table in each table space
• One table space in each database

Prior to Siebel CRM Release 7.7.x, the database schema was built using approximately 20 databases, each of which contained multiple table spaces. Each of these table spaces (if nonpartitioned) contained multiple tables. Siebel CRM version 8.1 contains thousands of databases. For example, an SIA installation has approximately 2700 databases. Each database has one table space and each table space 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 the Siebel application 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 Siebel CRM Release 7.7.x means that if you are upgrading from Siebel CRM version 7.5.3, 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 8.1 tables are created in the 1:1:1 model and the storage control file supplied with Siebel Business Applications is used for the upgrade.

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

  The following scenarios arise if you select this latter option:

  • Some existing tables have to be moved to incorporate the addition of new columns.
  • Some existing tables have to be moved because they have been extended and the addition of new columns causes the table's LRECL to exceed that of the table space. 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 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. For information on preparing a storage control file, see Preparing the Storage Layout of the Schema.

About Moving Table Spaces

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

For example, if you are making changes to an existing table space that is using BP1 or a 4 KB bufferpool and these changes cause you to receive a warning from ddlimp that the table must now be in a 16 KB bufferpool, do not just change the bufferpool designation in the storage control file from BP1 to BP16K1. Doing so can cause any LONG VARCHAR column in the table to be bigger than is necessary, resulting in performance problems.