New Database Schema Structure Since Siebel CRM Release 7.7.x
Upgrades from: Release 7.5.3 only.
The current database schema structure, referred to as the 1:1:1 model and introduced in Siebel CRM Release 7.7.x, 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. The current version of Siebel CRM 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 or 8.2 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.