|Bookshelf Home | Contents | Index | PDF|
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.
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:
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.
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.
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.
|Siebel Database Upgrade Guide for DB2 for z/OS||Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices.|