Siebel Database Upgrade Guide for DB2 for z/OS > How the Siebel Database Upgrade Works >

About Siebel Additive Schema Upgrade Changes

Upgrades: All upgrades.

Environments: Production test, production.

Since Siebel CRM 8.0, you can apply additive and nonadditive schema changes separately to the production database in order to reduce the downtime for the in-place upgrade.

Nonadditive schema changes impact the running application data model and require shutting down the production database. Additive schema changes are nondisruptive; these changes do not impact Siebel application usage. Therefore, you can apply additive schema changes to the live production database before you perform the in-place upgrade. This reduces the number of steps that must be performed when the database is offline and this reduces database downtime.

This is an optional process; if you do not apply the additive schema changes before you perform the production database in-place upgrade, they are applied in one step with the nonadditive upgrade changes.

Types of Changes

The additive schema files generated by the Upgrade Wizard make the following types of schema changes to support the new release. These changes do not adversely affect data integrity or database normalization:

• Creating new tables.
• Adding columns to an existing table. The column must either be specified as null, or if the column is not null, it must have a specified default value.
• Creating nonunique indexes on new tables.
• Creating a unique index on an existing table.
• Altering a unique index on an existing table.
• Increasing column sizes for numeric or varchar columns. The column must not be the basis for a picklist. Also, the resultant cumulative row size must not be larger than the data page size.
• Changing a not-null column to null.
• Changing a data type from char to varchar.

About Index Creation During the Additive Upgrade Process

Although additive schema changes are generally nondisruptive, index creation during the additive upgrade process can impact Siebel application usage if both of the following conditions exist:

• Indexes are specified with the DEFINE parameter set to YES
• The DEFER YES parameter is not specified for the index

If data exists in a table for which an index is being created, DB2 changes the DEFINE parameter value from NO to YES, and issues a warning message. If the DEFER YES parameter is not also specified for the index, the index is populated while it is being created, and locks are placed on the associated table until the process is completed, preventing updates being made to the table.

In these cases, change the index definition to DEFINE YES, DEFER YES; this ensures the index is not populated while it is being created, so the associated table is not locked. You can run the IBM DB2 REBUILD INDEX utility (DSNUTILB) to populate the index at a later time when performing regularly scheduled maintenance. For additional information on applying additive index changes to the target database, see Applying the Additive Changes in One Job.

Implementation of Additive Changes

The additive and nonadditive schema upgrade files are generated separately by the Upgrade Wizard in the output directory you specify when you run the Database Configuration Wizard. Additive schema filenames include the .additive identifier. Review these files to determine the schema changes that are applied by the additive schema process and edit them as necessary, for example, verify that they do not make changes that conflict with customizations.

Additive schema changes must first be applied in a production test environment which has the same data as the production environment. After generating and applying the additive schema files to the production test database, make sure users in the test environment can enter, query and delete records to check that applying additive schema changes to the database does not affect the way in which the existing version of the Siebel application works.