Siebel Database Upgrade Planning

This chapter provides information on planning your Siebel database upgrade. It includes the following topics:

Note: For a detailed overview of the upgrade process and related tasks, see Overview of Performing a Siebel Database Upgrade

About Siebel Upgrade Planning Resources

This topic lists important publications and resources for performing an upgrade. Review these as part of the upgrade planning process.

Product Documentation

Oracle’s Siebel CRM documentation is collectively called the Siebel Bookshelf. The Siebel Bookshelf is available on Oracle Technology Network (OTN) and Oracle Software Delivery Cloud. It might also be installed locally on your intranet or on a network location.

Siebel Installation and Deployment Documentation

The following publications are meant to be used in concert with installation or deployment of the Siebel application and can be found on the Siebel Bookshelf:

Siebel Deployment Planning Guide
Siebel Installation Guide for Microsoft Windows
Siebel Installation Guide for UNIX
Siebel System Administration Guide. Provides details on how to administer, maintain, and expand your Siebel Servers.
Siebel Security Guide. Provides information on the Siebel Party data model and other important security topics.
Siebel Application Deployment Manager Guide
Siebel Performance Tuning Guide
Configuring Siebel Business Applications. Provides information about configuring Siebel Business Applications in Siebel Tools. Additionally, this guide provides information on the Siebel Party data model.
Siebel Data Model Reference. The DMR describes in detail the Siebel database schema for a release. It also lists certain types of schema changes. Use the DMR during upgrade planning to evaluate how data will be stored in the new release. Consider obtaining a DMR for both the release you are upgrading from and the release you are upgrading to. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services for information on ordering DMRs.

Oracle Technology Network

This site contains the following:

Siebel Bookshelf. A searchable collection of Oracle’s Siebel CRM documentation.
Siebel System Requirements and Supported Platforms on Oracle Technology Network.

Note: For releases prior to Siebel CRM version 8.1.1.9 or version 8.2.2.2, Siebel System Requirements and Supported Platforms on Oracle Technology Network is the definitive list of system requirements and supported third-party products. For all subsequent releases, the system requirements and supported platform certifications are available from the Certifications tab on My Oracle Support. For information about the Certifications application, see article 1492194.1 (Article ID) on My Oracle Support.

My Oracle Support

This site provides the Certifications tab and provides search access to articles, Release Notes, and various other kinds of documentation relevant to Siebel CRM:

Release Notes. Siebel Release Notes on My Oracle Support might contain late-breaking information that the Siebel Database Upgrade Guide does not yet include.
The Certifications tab on My Oracle Support. This application is the definitive list of system requirements and supported third-party products. For more information, see article 1492194.1 (Article ID) on My Oracle Support.
Articles. Articles provide important information on specific upgrade issues. Many articles related to upgrade issues are located on My Oracle Support.
477833.1 (Article ID) on My Oracle Support (previously published as Siebel Alert 1002) and 478177.1 (Article ID) on My Oracle Support (previously published as Siebel Alert 1179) are particularly important to all upgrades. References to these and other articles are integrated throughout Siebel Database Upgrade Guide.
For Siebel language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.
Troubleshooting. Troubleshooting documents contain information about how to troubleshoot common upgrade issues such as error messages encountered during the upgrade process, and other unwanted behavior in Oracle’s Siebel Business Applications. Troubleshooting documents can be found for a variety of upgrade issues, including error messages found in upgrade logs. For more information browse Troubleshooting content on My Oracle Support.
Siebel Patchset releases. Siebel Patchset releases and documentation are provided on My Oracle Support.
For the readme documents for Siebel Patchset releases, see Siebel Patchset Installation Guide for Siebel CRM, 1614310.1 (Article ID) on My Oracle Support. For more information about Siebel Patchset releases, see 1600520.1 (Article ID) on My Oracle Support.
Siebel Maintenance Release Guide on My Oracle Support.
For each Siebel CRM version 8.1.1.x and version 8.2.2.x release, through Siebel CRM version 8.1.1.11 and version 8.2.2.4 (Siebel Innovation Pack 2013), Siebel Maintenance Release Guide on My Oracle Support was provided. This guide contained important information about updates to Siebel Business Applications. These guides are no longer provided for current releases. The versions of this guide for applicable releases are provided here:
- Version 8.1.1.x Siebel Maintenance Release Guide on My Oracle Support, 880452.1 (Article ID)
- Version 8.2.2.x Siebel Maintenance Release Guide on My Oracle Support, 1441523.1 (Article ID)

Oracle Software Delivery Cloud

This site provides access to Siebel CRM software, including the current release of Siebel CRM. For more information about types of Siebel CRM releases, see the Siebel Installation Guide.

Oracle Advanced Customer Services

Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services. These services offer detailed implementation planning and technical consulting services as well as rapid response and resolution for critical technical issues affecting Siebel deployments.

Contact your Oracle sales representative for Oracle Advanced Customer Services for important information in the following areas:

Migrating from Siebel Industry Solutions or Siebel Financial Services to Siebel Business Applications during upgrade
Migrating to Unicode code page support during upgrade
Changing operating system type during upgrade

Guidelines for Planning Your Siebel Database Upgrade

This topic provides an overview of the recommended guidelines for planning upgrade resources, estimating the upgrade timeline, and managing the data migration process.

Use the following steps to help plan your upgrade.

Determine your upgrade path. Upgrade requirements and tasks differ based on the specific upgrade path involved. For example, when you install Siebel 2018 as a migration from an earlier version of Siebel CRM, such as version 8.1.1 or 8.1.1.x, version 8.2.2 or 8.2.2.x, version 15.0 or 15.x, or version 16.0 or 16.x, then you run incremental repository merge, which is a relatively new upgrade technique. Supported upgrade paths from earlier Siebel CRM versions involve traditional upgrade techniques. For more information, see Supported Upgrade Paths for Siebel 2018.
Evaluate the complexity of the upgrade. Determine the complexity of the upgrade effort based on the Siebel CRM modules implemented, the number of integration points, the number of interfaces, the total number of scripts, and the number of user interface scripts.
Assess the current Siebel environment and evaluate the existing implementation. Perform a detailed assessment of the current Siebel environment to determine how the implementation will be affected by the upgrade. Evaluate the current implementation in comparison with the architecture of the current release. The assessment will help you to identify areas where you can take advantage of new functionality to meet business requirements.
Estimate the level of effort to upgrade. Determine the metrics and cost associated with each aspect of the upgrade. Determine the effort required to upgrade based on the results of your complexity evaluation, current environment assessment, and new functionality review. This will help you to estimate resources, time line, and costs.
Establish the upgrade team. Assemble a cross-functional upgrade team that understands Siebel product architecture and performance guidelines. Include IT professionals, executives, and users to ensure a broad base of experience in technical, business, and Siebel-specific skills.
Review interface migration tasks. Determine the effort to migrate modified applets and views. This includes associating applets with Web template items and mapping them to Web template controls.
Plan for upgrade tuning. Tuning your production upgrade scripts can significantly reduce downtime during the final stages of your upgrade. Examples of upgrade tuning include eliminating SQL statements that do not affect any data, executing long-running SQL statements in parallel, and executing table creation, table rebuilds, and index creation in parallel.
Identify data migration tasks. After the upgrade, there might be data migration and repository configuration tasks that must be performed manually. These tasks frequently involve customizations made in prior releases.
Plan for end-user training. Analyze the impact of change on the users, and develop a plan for end-user training and adoption.

The upgrade of your application requires several key factors to be successful:

A detailed understanding of customizations made to your current deployment
Analysis and definition of the components within your enterprise
Analysis of how to use new functionality provided by Oracle’s Siebel software
Strict adherence to industry best practices and guidelines identified in this guide

The upgrade planning process will produce a roadmap for the entire upgrade project that outlines infrastructure, deployment, and training requirements.

Use the results of this process to develop a project plan that identifies required skills and resources for developing and deploying the upgraded application. This will help you with advance budgeting of resources, time, and training.

Upgrade Planning Guidelines

Here are important guidelines to follow when planning an upgrade:

Review the Certifications tab on My Oracle Support, Siebel Release Notes on My Oracle Support, Siebel Installation Guide, and other relevant documentation. Also review the content of this guide, Siebel Database Upgrade Guide.
Gather all relevant documentation that describes the current implementation, for example, requirements documents, design documents, and architecture context diagrams.
Implement a change management program. For example, communicate rollout dates to users, schedule training, allow adequate time for users to adjust to the enhancements, and provide a process for end users to provide feedback to the project team.
User adoption is critical to a successful upgrade. Provide access to a test environment that allows users to become familiar with the new version of the application, and provide end-user training on the upgraded application.

Database Planning Guidelines

Here are important guidelines to follow when planning the upgrade of your database:

Analyze the impact of the upgrade on table customizations that you have made. Determine whether preupgrade data migration is required. Determine what postupgrade schema changes are required.
Consider database layout in your planning. Plan to tune the database and database server for the upgrade, because settings and parameters for upgrade differ from those required for Online Transaction Processing (OLTP).
If you are migrating multiple languages from a prior version, then plan extra time (one to two weeks) for the repository merge process. The expected merge time might increase with the number of languages in the repository. You also might need to plan for additional installation-related tasks.
If your locale specific language values have changed over time, then you must make changes in the upglocale.language_code file to trigger correct data migrations. For example, in a previous German language release, the German value Einzelperson mapped to the ENU value of Individual. In the new release Individuell and not Einzelperson maps to the ENU value Individual. Prior to running the upgrade utility, review the upglocale.language_code files from your present release to that of the upgrade release, to validate, and verify your language strings and to make any necessary changes. Upglocale.language_code files are located at SIEBEL_ROOT/dbsrvr/language_code folder in the new release’s installation directory.
For IBM DB2, consider increasing the size of your tablespaces before going live. Make sure that your custom tablespaces are large enough for upgraded tables. See Analyzing IBM DB2 Custom Tablespace Requirements for a Siebel Upgrade.

Production Database Upgrade Guidelines

Both the Prepare for Production step and the upgrade tuning process modify the SQL scripts used to perform the upgrade in the production test environment. In addition, it is common to further modify these scripts to meet local requirements.

The recommended way to perform the production upgrade is to use the SQL scripts that you have generated and modified for the production test upgrade. The steps in the production environment upgrade process are as follows:

Run the Database Configuration Utilities in the production environment.
In the utilities, enter the information for the production environment instead of the production test environment. For example, you enter the ODBC connection for the production environment.
This configures the driver file to run against the production database rather than the production test database. The utilities also configure the driver file to use the upgrade SQL files you generated for the production test upgrade.
Run the Upgrade Wizard. The Upgrade Wizard uses the SQL files in the production test environment to upgrade the database in the production environment.

This approach has several advantages:

You do not have to generate upgrade SQL files in the production environment and then manually transfer customizations to them from the production test environment.
You do not lose any changes to the SQL files that were made by Siebel Upgrade Tuner in the production test environment.
You do not have to run the Database Configuration Utilities in Prepare for Production mode again.
With some exceptions, you do not have to perform database-related configuration tasks required Articles or Siebel Release Notes on My Oracle Support.

If your network configuration prevents creating an ODBC connection to your production database from inside your production test environment, and you cannot complete your production upgrade, then create a service request (SR) on My Oracle Support. Alternatively, you can phone Global Customer Support directly to create a service request or get a status update on your current SR. Support phone numbers remain the same and are listed on My Oracle Support.

About Upgrading Your RDBMS in the Siebel Environment

Environments: Development, production test, production.

If your currently installed RDBMS version is not supported in the new release, then you must upgrade your RDBMS before performing the Siebel database upgrade. For information on supported RDBMS versions, see the Certifications tab on My Oracle Support.

If your currently installed RDBMS version is supported in the new release, and you plan to upgrade your RDBMS, then you can do so before or after upgrading your Siebel database.

The following guidelines and requirements are for planning your RDBMS upgrade.

Note: When you upgrade the RDBMS, also be sure to upgrade your client database connectivity software. See the Certifications tab on My Oracle Support.

Oracle Database

The following guidelines and requirements are for planning your upgrade on Oracle Database.

See Article ID 477966.1 on My Oracle Support (previously published as Siebel Alert 1053) for planning information on upgrading an Oracle RDBMS. If you upgrade the Siebel database and then upgrade the Oracle RDBMS, then you must validate the Siebel database schema after the upgrade. See Verifying an Upgraded Oracle Database After a Siebel Upgrade.
Development, production test, and production upgrades on Oracle Database 11g, can be run in CBO mode.
If you plan to upgrade your Oracle Database, then see 781927.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 582. This document provides information on setting up Oracle Database for use with Oracle Cost-based optimizer (CBO) and on doing other performance tuning for Oracle Database. Using Oracle’s Cost Based Optimization with a Siebel database entails certain requirements for database parameter configuration and for the Optimizer’s statistics generation on tables, columns and indexes.

IBM DB2

The following guidelines and requirements are for planning your upgrade on IBM DB2.

After upgrading your IBM DB2 RDBMS, you must upgrade the database instance.
The IBM DB2 database must have 4-KB, 16-KB, and 32-KB tablespaces defined on it. Otherwise, your upgrade will not complete successfully.

About Database Sort Order in the Siebel Environment

Environments: Development, production test, production.

Sort order (also called collation sequence) is specified during the initial installation of a database and defines the way in which the database sorts character data when executing queries. Sort order support depends on both the code page of the database and whether it is used in a development or a production environment:

Development environments. For development databases, you must use a binary sort order due to the functional limitations of databases that use a nonbinary sort order.
Production environments. For production databases, it is strongly recommended that you use binary sort order to prevent possible performance degradation.

The settings for binary sort order are unique for each database platform. For Siebel language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.

Sort Order Considerations for Siebel Databases

If your deployment requires that you use a nonbinary sort order (for example, if your local language does not use binary sort order), then you must consider several functional limitations that particularly affect development environment upgrades. If these limitations are unacceptable, then consider re-creating your database to use binary sort order. However, be aware of these considerations:

You cannot use Siebel Tools to create or update a Siebel Runtime Repository on a database that uses a nonbinary sort order.
You cannot perform a repository merge on a database that uses a nonbinary sort order.
Databases that use nonbinary sort order might perform slower than databases that use binary sort order.

For Siebel language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.

About the Siebel Database Configuration Wizard Utilities

Environments: Development, production test, production.

The Database Configuration Utilities are part of the Siebel Database Configuration Wizard. The Database Configuration Utilities interactively gather the information required to perform the following operations:

Install the Siebel Database. These wizards set up the Siebel database in the RDBMS as part of a first-time installation of Siebel Business Applications. They can also add a language to the Siebel Database Server installation.
Upgrade the Siebel Database. These wizards upgrade the Siebel database to a new release in a development environment, production test environment, or production environment.
Import or export a Siebel repository. These wizards move entire repositories between database environments with the same schema definition. A wizard that adds installed languages to a Siebel Tools repository is also provided.
Apply Additive Schema Changes. As part of upgrading to a new release, this wizard generates a SQL script. The script contains schema changes that you can make to the production database without taking it offline. This reduces the production database downtime required for the upgrade.
Run database utilities. This group of wizards perform the following functions:
- Synchronize a database schema with the Siebel Repository schema definition.
- Convert existing time-keeping management to UTC.
- Convert existing Lists of Values (LOVs) to Multilingual Lists of Values (MLOVs).

About the Upgrade the Siebel Database Function

When you run the Upgrade the Database function of the Database Configuration Wizard, the wizard prompts you for the upgrade environment (development or production) and the upgrade phase (upgrep or upgphys). The wizard then prompts you for the information required to perform the upgrade.

After collecting and confirming the information, the wizard creates an upgrade configuration file and calls a driver that uses the file to set up the SQL scripts required to upgrade your database.

After you run the Database Configuration Wizard, you run the Upgrade Wizard. The Upgrade Wizard opens a state file containing the steps for the upgrade. These steps execute the SQL scripts created after you ran the Database Configuration Wizard.

To upgrade a development environment, production test environment, and production environment, you run the Database Configuration Wizard (and Upgrade Wizard) several times, as listed in the following table.

Table Database Configuration Utilities Modes

Upgrade Step	Select This Environment Type	Select This Upgrade Option
Development environment upgrep	Development	upgrep
Development environment upgphys	Development	upgphys
Production test environment prepare for production	Production	Prepare for Production
Production test environment upgrep and upgphys	Production	upgrep and upgphys
Apply Additive Schema Changes	Production	Apply Additive Schema Changes
Production environment upgrep and upgphys	Production	upgrep and upgphys

The following figure shows how the Database Configuration Wizard (and Upgrade Wizard) work together with the Siebel Tools repository merge to upgrade your environments.

Development Environment Upgrades

For a development environment upgrade, you run the utility twice, once in each of the following modes:

upgrep. This mode makes the following changes:
- Removes interface tables and database triggers.
- Populates columns that must change from NULL to NOT NULL.
- Creates new tables. Merges existing tables.
- Prepares for index creation. Verifies that there are no unique key violations.
- Creates indexes.
  
  Note: Indexes that have been previously deactivated will be recreated during the upgrep phase. Check to determine whether these indexes are required following the development upgrade. If they are not, then they might be deactivated again. To deactivate indexes, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
- Imports seed data.
- Imports the Prior Siebel Repository, New Siebel Repository, and New Customer Repository.
- Makes modifications to repository objects to prepare for the repository merge.
- Updates primary children foreign key references.
- Performs miscellaneous file actions.
upgphys. This mode makes the following changes:
- Synchronizes the Siebel database schema to the logical schema definition in the merged repository.
- Deduplicates intersection tables.
- Exports repository object definitions to a file, custrep.dat.
- Exports the logical schema definition to a file, schema.ddl.
  These two files are used as input to the production test environment and production environment upgrades.
- Renames the New Customer Repository to Siebel Repository.
- Updates the schema version in S_APP_VER.

Production Test Environment Upgrades

For a production test environment upgrade, you run the utility three times:

Prepare for production.

Note: This topic is only applicable for upgrades from Siebel CRM release 7.5.3. For upgrades from later releases, you do not have to perform this step.
This mode does the following in the production test database:
- Examines the development environment database and generates SQL that deduplicates intersection tables and sets up support for database aggregation.
  In the production test environment, you must define an ODBC connection to the development environment database before performing this upgrade step.
- Compares the repository schema and the physical database schema. Generates a file that lists indexes present in the physical schema that are not present in the repository schema. You can decide whether to remove these indexes.
upgrep. This mode makes the following changes:
- Removes interface tables and database triggers
- Populates columns that must change from NULL to NOT NULL
- Uses the custrep.dat and schema.ddl files from the development environment upgrade to create new tables and merge existing tables
- Prepares for index creation. Verifies that there are no unique key violations.
- Creates indexes
- Imports seed data
- Updates primary children foreign key references
- Performs miscellaneous file actions
- The upgphys portion runs automatically. It makes several administrative changes to table data, including updating the schema version in S_APP_VER.
Upgrade Tuning. These steps are optional. You can use the Logparse utility to tune the SQL generated for the upgrade. Logparse identifies SQL commands that are not used, or that can be run in parallel. This reduces the time required to perform the production database upgrade.

You can also test the Additive Schema Changes script to verify that it does not adversely affect the operation of the application. Additive Schema Changes allows you to run part of the schema upgrade without taking the database offline. This reduces production database downtime.

Production Environment Upgrades

After you have completed testing applications and have tuned the upgrade SQL commands, you perform the production upgrade. The production upgrade uses the SQL commands generated in the production test environment. In the production test environment, you perform the following steps to upgrade your production environment Siebel database:

ODBC Connection. Define an ODBC connection to the production environment Siebel database
Apply Additive Schema Changes. This step is optional and is run in the production environment. You can run this mode of the Database Configuration Utilities without taking the database offline. This mode makes schema changes that do not affect the operation of the application. This reduces the amount of time the production database must be offline to perform the upgrade.
Prepare for Production. This step is not required. You ran it as part of the production test environment upgrade. The required changes have already been made to the upgrade SQL commands.
upgrep. Run the Database Configuration Utilities in the production test environment. Enter information for the production environment (not the production test environment), including the new ODBC definition.
The Database Configuration Utilities update the upgrade configuration file with production environment information. A lock file that was set when you ran the utility previously, prevents new SQL from being generated. This preserves the SQL you have revised and tuned.
When you run the Upgrade Wizard, it reads the production environment information from the configuration file and uses the production test environment SQL commands to upgrade the production environment Siebel database.
The upgrep step makes the same changes as when it ran in the production test environment. This includes automatically running the production upgphys portion of the upgrade.

How the Upgrade Configuration File and SQL Files Are Created

When you run the Database Configuration Utilities, the following actions are performed:

Collect configuration information.
Create a master upgrade configuration file (UCF). This file maps the information you entered in the Database Configuration Utilities to environment variables.
Forward the information to an SQL generator that creates or populates SQL files with the required commands. The SQL generator extracts these commands from an intermediate XML file containing all the SQL commands required for an upgrade.
Prompt you to start the Upgrade Wizard.

In some cases, you must modify the generated SQL files as required by Articles, or Siebel Release Notes on My Oracle Support before you run the Upgrade Wizard. To do this, answer No when prompted to run the Upgrade Wizard. Then, edit the SQL files and manually launch the Upgrade Wizard.

How to Locate Master Configuration Files

Master upgrade configuration files are stored in the following location:

Windows: SIEBEL_ROOT\bin

UNIX: $SIEBEL_ROOT/bin

Master upgrade configuration files use the following naming convention:

master_UPGRADEOPTION_ENVIRONMENT_VERSION.ucf

where:

UPGRADEOPTION indicates the upgrade process you are performing
- upgrep indicates Siebel database schema upgrade
- upgphys indicates Custom database schema upgrade
- prepare_for_production_upgrade indicates Prepare for Production upgrade
ENVIRONMENT indicates the environment that you are upgrading
- dev upgrades Development environment
- prod upgrades Production environment
VERSION indicates the version from which you are upgrading

For example, if you are upgrading from Siebel CRM version 8.1.1, then the master configuration file generated from the development environment upgrep is as follows:

master_upgrep_dev_811.ucf

The master configuration file generated from the Prepare for Production mode is as follows:

master_prepare_for_production_upgrade.ucf

About the Siebel Upgrade Wizard and Driver Files

Environments: Development, production test, production.

The Upgrade Wizard performs the upgrade. It uses the information collected by the Database Configuration Utilities to execute commands and SQL scripts. These commands and SQL scripts are contained in driver files. Driver files are in ASCII text format and are organized into steps. The Upgrade Wizard reads the steps in the driver files and performs the commands contained in each step.

In a driver file, steps are separated by a blank line, and each step begins with a File Execute Entry number. The key part of each step is the command or script to be executed. When an SQL script is specified, you can review the script and see what changes it will make to the Siebel database before running the Upgrade Wizard.

Driver files are provided for each of the major upgrade operations. Examples of driver files are as follows:

driver_upgrep_dev_811.ucf
driver_upgphys_dev_811.ucf
driver_upgrep_prod_811.ucf

Here is an excerpt from a driver file that controls a development environment upgrep from Siebel CRM version number on Oracle Database. The excerpt contains three steps:

[Sql File Entry 0]
Type = DbSql
File Name = rename_existing_repositories.sql
Use Table Owner = 1
Use System Admin = 0
IgnoreAllDDLErrors = 0
IgnoreAllDMLErrors = 0
Argument 0 = $SiebelVersion
Title = Verify Repository Name
Title Message Num = 0
Estimated Disk Space = 0
Backup Db = 0
Parallelizable Item = 0
Prompt User For Status = 0
[File Execute Entry 1]

Type = FileExecute
File Name = $SiebelRoot\bin\odbcsql
Check Return Code = 1
Return Code Compliance = 0
16 Bit App = 0
Command Line = /s "$ODBCDataSource" /u $TableOwner /p $TablePassword /separator / /
a /c rem /l $SiebelLogDir/dropif-db.log $DbsrvrRoot/$DatabasePlatform/dropif-db.sql 
/v
Number of 10 Second Wait Loops = 2000
Return Code = 0
Title = Drop  interface tables
Title Message Num = 0
Estimated Disk Space = 0
Backup Db = 0
Parallelizable Item = 0
Prompt User For Status = 0
[File Execute Entry 2]

Type = FileExecute
File Name = $SiebelRoot\bin\odbcsql
Check Return Code = 1
Return Code Compliance = 0
16 Bit App = 0
Command Line = /s "$ODBCDataSource" /u $TableOwner /p $TablePassword /separator / /
a /c rem /l $SiebelLogDir/trigdrop-db.log $DbsrvrRoot/$DatabasePlatform/trigdrop-
db.sql /v
Number of 10 Second Wait Loops = 2000
Return Code = 0
Title = Drop  triggers
Title Message Num = 0
Estimated Disk Space = 0
Backup Db = 0
Parallelizable Item = 0
Prompt User For Status = 0

[File Execute Entry 2]

How to Locate Upgrade Driver Files and SQL Scripts

Driver files are stored in the following location:

Windows: DBSRVR_ROOT\PLATFORM\UPGRADE\Version_Number
UNIX: DBSRVR_ROOT/bin/PLATFORM/UPGRADE/Version_Number

where:

PLATFORM indicates the database type, for example ORACLE
VERSION indicates the version from which you are upgrading

For example, if you are upgrading from Siebel CRM version 8.1.1, then the driver file for the development environment upgrep will be:

driver_upgrep_dev_811.ucf

Most of the SQL scripts generated or populated for the upgrade are stored in the same directory as the driver file. The remaining SQL scripts are stored in the PLATFORM directory.

About Siebel Additive Schema Changes Mode

Environments: Production test, production.

As of Siebel CRM 8.0, Apply Additive Schema Changes mode is part of the Database Configuration Utilities. The purpose of Additive Schema Changes is to reduce the downtime required for the production database upgrade.

Additive Schema Changes generates an SQL script. You run the script on the live production database before you take it offline to perform the production upgrep. The script performs certain upgrade steps that are normally part of the production upgrep. This reduces the number of steps the upgrep must perform while the database is offline, and thus reduces database downtime.

Running the SQL script is optional. If you do not run it, then the regular production upgrep performs the steps in the SQL script.

Types of Changes

Additive Schema Changes 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.
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.
Revising a not-null column to null.
Revising data type from char to varchar.

Implementation of Additive Schema Changes

You generate the Additive Schema Changes script by starting the Database Configuration Utilities and choosing Apply Additive Schema Changes. A wizard prompts you for environment information similar to other upgrade modes.

After you review and confirm your entries, the wizard populates the file platform\driver_additive_gen.ucf. In this path, platform is the database type (DB2, MSSQL, or Oracle).

The Upgrade Wizard then performs the following steps:

Reads the master_additive_gen.ucf file to obtain environment information and the name of the driver file.
Reads the driver_additive_gen.ucf file and executes the ddlimp2 command it contains.
The ddlimp2 command performs the following steps:
- Reads the tables and indexes from the schema.ddl file.
- Connects to the specified database and reads the existing schema and indexes.
- Identifies the upgrade schema changes that can be made with the database online.
- Writes these upgrade changes to the schema.additive.sql script.
- Writes all actions to schema.additive.log.

The Upgrade Wizard does not execute schema.additive.sql against the database.

How to Use Additive Schema Changes

Use the following workflow to implement Additive Schema Changes:

In the production test environment, complete all development and upgrade testing. The schema.ddl file must be in its final form.
As part of running the Tuning Upgrade Performance process, restore the production test environment database to its original, unupgraded state.
Run the Database Configuration Utilities in Apply Additive Schema Changes mode, and generate the schema.additive.sql script.
Windows. You will not be prompted whether you want to run the Upgrade Wizard. Instead, the Upgrade Wizard starts automatically, and creates the schema.additive.sql script. The Upgrade Wizard does not run the script against the database.
UNIX. After the Database Configuration Utilities exit, run the Upgrade Wizard to generate the schema.additive.sql script. The Upgrade Wizard does not run the script against the database.
Review the schema.additive.log file. Verify that the script was created successfully.
Review the schema.additive.sql script. Verify that it will not make changes that conflict with customizations. Edit the script as required.
Use an SQL editor to apply the schema.additive.sql script to the database.
Verify that applications function normally. If necessary, revise schema.additive.sql and reapply it to the database.
Complete the remainder of the Tuning Upgrade Performance process. See Process of Tuning Siebel Upgrade Performance.
When you are ready to upgrade the production database, run the schema.additive.sql script against the production database before doing the production upgrep.
There is no need to then run database statistics. The schema changes are not useful for optimizing applications function before the upgrade.

The steps in this workflow have been incorporated into the process you use to perform both upgrade tuning and the production environment upgrade.

About the Siebel Database Upgrade Log Files

Environments: Development, production test, production.

Platforms: Windows and UNIX only. Does not apply to IBM z/OS.

The Upgrade Wizard writes log files that provide detailed information on the upgrade processes, for example development-environment upgrep and upgphys. These log files provide detailed information on the upgrade steps, and they also list all errors. The Logparse utility analyzes and summarizes these log files.

Upgrade Wizard Log Files

The Upgrade Wizard writes the log files for a process to the following directory:

Windows: SIEBEL_ROOT\log\PROCESS
UNIX: $SIEBEL_ROOT/log/PROCESS

In these paths, PROCESS specifies UPGRADEOPTION_ENVIRONMENT_VERSION by default.

For example, the log files for a Siebel development environment upgrep process appear in the following locations:

Windows: SIEBEL_ROOT\log\upgrep_dev_versionnumber
UNIX: $SIEBEL_ROOT/log/upgrep_dev_versionnumber

You can select a different directory for the log files, by specifying a value for the Log Output Directory option in the Database Configuration Wizard. This option is for specifying a different subdirectory, under the log directory, in which to create the log files.

Each subdirectory in the log directory contains the following files:

output. This subdirectory contains the Upgrade Wizard log files.
- upgwiz.log (srvrupgwiz.log on UNIX). The Upgrade Wizard log for the process. This log contains detailed information on how the Upgrade Wizard ran. If you run the process more than once, the log name increments, for example upgwiz2.log or srvrupgwiz2.log.
- Windows only. Log files with the name upgwizn(nnn) can be ignored. For example, upgwiz1(001).log, upgwiz1(002).log, and so on.
- Windows only. Log files with the name sw_cfg_xxx can be ignored. (These are located in the log directory.)
- UNIX only. Log files with the name srvrupgwizn_nnn can be ignored. For example, srvrupgwiz1_01.log, srvrupgwiz1_02.log, and so on.
- Log files with the name siebel.log can be ignored.
Tip: Each upgrade process, for example, a development upgrep, has a driver file located in DBSRVR_ROOT\platform\upgrade\version. An example of a driver file: driver_upgrep_dev_811ucf. The Upgrade Wizard performs the steps in the driver file. If a step calls a utility, such as ddlimp or dataimp, then the /l option in the command syntax specifies the name of the log file. Unless you modified the output location for the log file, it is located at siebsrvr\log\process.
state. This subdirectory contains the state.log file.
- state.log. The state.log file lists each step in the upgrade process and whether the step completed successfully.
  The output and state log file directories are automatically archived on subsequent runs of a process that completes successfully. (The names of subsequent log directories are appended with _1, _2, and so on.) To preserve disk space, periodically delete or save log directories to another location.
- summary. This subdirectory is generated by the Logparse utility. The Logparse utility also generates a report that summarizes the upgrade, summary.html. The summary.html file contains links to the html pages in the summary subdirectory.
- summary.html. This HTML file is created by the Logparse utility. It summarizes the log files in the outputdirectory. Use this file to verify that all upgrade steps completed successfully and to determine whether there were any errors.
- summary.txt. This text file is created by the Logparse utility. This file contains the same information as summary.html.
  Note: If a browser is not installed on the computer you are using, then review summary.txt instead of summary.html.
- summary.xml. This file is produced by the Logparse utility during production upgrades and used by the Siebel Upgrade Tuner to parallelize table creation and index creation and to inactivate SQLs that affect no rows. (Development upgrades do not produce a summary.xml file.)
- upgtuner_ftp_get.txt. (UNIX Only). This file is produced by the Logparse utility during production upgrades. You can use this file to transfer the upgrade scripts from your UNIX computer to a Windows temporary directory to perform upgrade tuning. (Development upgrades do not produce upgtuner_ftp_get.txt.)
- upgtuner_ftp_put.txt. (UNIX Only). This file is produced by the Logparse utility during production upgrades. After you tune your production upgrade scripts, you can use this file to transfer the upgrade scripts from the temporary directory on your Windows computer back to your UNIX environment. (Development upgrades do not produce upgtuner_ftp_put.txt.)

The Logparse Utility

For each upgrade process, the Logparse utility analyzes the log files in siebsrvr\log\process. It then summarizes the log files and provides several reports. The Logparse reports provide the following information.

Parameters Report

The Parameters report lists the total time required for the upgrade process. It also lists environment variables and input files used by the upgrade process. Use this report to verify that the upgrade was set up correctly.

Step/Error Summary

The Step/Error Summary lists each step in the upgrade process and whether it completed successfully. It also provides a link to a detailed step summary for each step.

The detailed step summary lists database errors returned by the Upgrade Wizard, SQL scripts, and errors returned by the upgrade utilities called by the driver files, such as ddlimp, and dataimp.

For Oracle Database and IBM DB2, the detailed step summary lists only unacceptable errors that must be corrected. The summary does not list benign errors.

For Microsoft SQL Server, the detailed step summary lists all errors, including benign errors. An errors file (errors.xls and errors.rtf) is provided that lists benign errors for each database type. When you find an error in the summary.html file, you must compare it with the error file to determine whether it is benign.

Performance Report

The performance report provides a list of the longest running SQL scripts and a list of SQL scripts returning no rows. The lists include a link to each script. Upgrade Tuner uses this information as input to help you tune upgrade performance.

The report also provides two lists of DDL commands executed during the upgrade process. The DDL Summary lists the tables that were created, altered, or deleted by the ddlimp utility. The Native DDL Summary lists tables that were created, altered, or deleted by SQL scripts and includes a link to each script.

About the Siebel Case Insensitivity Wizard

Environments: Development environment only.

Platforms: Windows, UNIX, IBM z/OS.

Databases: All databases.

As of Siebel CRM 8.0, query features were enhanced to provide indexes that directly support case and accent insensitive (CIAI) queries on eligible text columns. The Siebel Case Insensitivity Wizard configures specified columns for CIAI queries by defining CIAI columns and CIAI indexes in the repository. The wizard also sets the Default Insensitivity property for these columns to DB Case & Accent.

The purpose of the enhanced CIAI features is to improve query effectiveness and performance. Running the Case Insensitivity Wizard is optional.

Note: Before performing an upgrade or incremental repository merge, you must drop any CIAI indexes and CIAI columns. Run the Case Insensitivity Wizard again after completing the upgrade or incremental repository merge.

Related Book

Configuring Siebel Business Applications

About the Siebel Repository Merge

Environments: Development environment only.

Platforms: Windows, UNIX, IBM z/OS.

Repositories are located in tables in the Siebel database. These tables store the definitions of the objects used to build Siebel Business Applications. These tables also store Siebel schema definitions. When you display objects in the Siebel Tools Object List Explorer, you are displaying records from these tables.

The repository tables contain three types of records:

Object definitions used to create Siebel Business Applications, such as business components, applets, controls, and the relationships between them.
Definitions of the tables in the Siebel database (metadata). These records define the logical schema of the Siebel database. Later in the upgrade process, you will synchronize the physical schema of the Siebel database with the logical schema as defined by these records.
Runtime Repository tables. The runtime repository tables usually begin with S_RR prefix and store the compiled definitions of the repository objects.

Repository records include a repository ID that identifies the repository to which the record belongs. The repository ID forms part of the user index for records and allows several repositories to be stored in the same set of tables.

The Siebel Repository is the deployed, active Siebel Tools repository. You use this repository to customize applications.

The development upgrep adds three additional repositories to the Siebel database, as listed in the following table. These repositories are required for the repository merge.

Table Development Database Repositories

Repository Name	Added During Upgrade?	Siebel Tools Name	Description
Prior Customer Repository	No	Prior Customized	This is your current Siebel Repository, before upgrading. It contains any changes you have made. You renamed it Prior Customer Repository before doing the initial database upgrade.
Prior Siebel Repository	Yes	Prior Standard	The standard Siebel Repository for your installed release (the release you are upgrading from). Is called the common ancestor repository in the upgrade SQL scripts.
New Siebel Repository	Yes	New Standard	The Siebel Repository for the release to which you are upgrading. This repository defines the new release.
New Customer Repository	Yes	New Customized	A second copy of the New Siebel Repository. Your customizations from the Prior Customer Repository are merged into this repository. After the upgrade, this becomes the Siebel Repository.

What Happens During a Repository Merge?

The repository merge process identifies differences between the repository in your old release (Prior Customer Repository) and the repository in the new release (New Siebel Repository). The merge process then merges these differences into the New Customer Repository. The merge process searches for the following types of objects in the Prior Customer Repository: customer-created, customer-deleted, and customer-modified.

Customer-Created Objects

Customer-created objects are high-level (or first-level) objects, such as screens, applets, and business components, that you have created in the Prior Customer Repository. If an object is present in the Prior Customer Repository but not in the Prior Siebel Repository, then it is customer-created. The merge process copies customer-created objects intact to the New Customer Repository.

Customer-Deleted Objects

Customer-deleted objects are high-level objects you have deleted in the Prior Customer Repository. If an object is absent in the Prior Customer Repository but present in the Prior Siebel Repository, then it is customer-deleted.

If you delete a high-level object in the Prior Customer Repository and it is present in the New Customer Repository, then the merge process does not delete the object from the New Customer Repository. After the merge, you must review these objects and remove them as desired.

If you delete a high-level object from the Prior Customer Repository, and it is obsolete (inactive) in the New Customer Repository, then the object will be present and inactive in the New Customer Repository.

Customer-Modified Objects

A customer-modified object has the following characteristics:

It is a high-level object, such as screen, applet, or business component.
The object exists in the Prior Siebel Repository and the Prior Customer Repository. (The object is not customer-created or customer-deleted.)
The properties of the object in the Prior Customer Repository and Prior Siebel Repository are not the same. (You have modified the object.)

If the object properties are also different between the Prior Siebel Repository and New Siebel Repository, then the object has changed in the new release, and a conflict exists. The merge process logs the conflict and resolves it. After the merge, you must review how these conflicts were resolved and change the resolutions as desired.

For customer-modified objects where no conflict exists, the merge process copies the modifications to the object to the New Customer Repository.

If you modify a high-level object by deleting any of its child objects, then the merge process does not delete these child objects in the New Customer Repository. After the merge, you must review child objects and remove them as desired.

Some of the child objects of Applet are an exception. If you delete the following child objects of Applet from the Prior Customer Repository, then the merge process deletes these objects from the applet in the New Customer Repository:

Control
List Column
Page Tab
Chart
Applet Web Template Item
View Web Template Item

For example, if you delete a button from Applet-A in the Prior Customer Repository. The merge process deletes this button from Applet-A in the New Customer Repository.

The following table shows how a regular merge handles both customer-modified and customer-created objects. The columns list the status of a repository object:

Standard. The object appears in the Prior Standard Repository, and in the New Siebel Repository, and is not customer-modified.
Deleted. You have deleted the object from the Prior Customer Repository (customer-deleted).
Customized. You have modified the object in the Prior Customer Repository (customer-modified).
Revised. The object has changed in the new release (New Siebel Repository).
New. You have created the object in the Prior Customer Repository (customer-created), or the object is new in the new release (New Siebel Repository).
Inactive. The object is present in the New Siebel Repository and New Customer Repository but is inactive and not used in the new release. The object is obsolete.

The first three columns list the status of the object in the three repositories that the merge process compares during the merge. The last column, Merged New Customer Repository, lists the status of all high-level repository object types after the repository merge is complete and the postmerge utilities have run.

Table How the Merge Handles Repository Objects

Prior Standard Repository (PSR)	Prior Customer Repository (PCR)	New Siebel Repository (NSR)	Merged New Customer Repository
Standard	Standard	Standard	Standard
Standard	Standard	Revised	Revised
Standard	Standard	Standard, or Inactive	Standard, or Inactive
Standard	Customized	Customized	Customized
Standard	Customized	Customized, or Inactive	Customized, or Inactive
Standard	Customized	Revised (conflict)	Revised (conflict)
Not applicable	New	New	New
Not applicable	Not applicable	New	New
Standard	Deleted	Standard	Standard
Standard	Deleted	Not applicable	Not applicable
Standard	Deleted	Not applicable	Not applicable

Upgrade Ancestor Property

You can link repository objects together so that one object inherits the upgrade behavior of another. You do this by specifying an upgrade ancestor for an object. You can specify upgrade ancestors for the following object types:

Applets
Business Components
Integration Objects
Reports

For example, you create Applet-B by copying Oracle standard Applet-A. In Applet-B you specify Applet-A as the upgrade ancestor. In the New Siebel Repository, Applet-A has a new button. Because Applet-B is a descendant of Applet-A, the merge process adds the new button to both Applet-A and Applet-B.

If you had not specified Applet-A as an upgrade ancestor of Applet-B, then Applet-B would not have received the new button.

Postmerge Utilities

The postmerge utilities run after the repository merge completes. The utilities make changes to objects in the New Customer Repository. The purpose of the postmerge utilities is to reduce the configuration changes required as part of reviewing applications and user interfaces after the merge.

About Single-Step Repository Upgrade

Prior to the release of Siebel CRM version 8.1.1, two Siebel repositories supported Siebel applications: Siebel Business Applications (SEA) repository and Siebel Industry Applications (SIA) repository. Deploying applications from outside either group was not possible through a direct, single-step upgrade process.

Going forward from the release of Siebel CRM version 8.1.1, a single repository is supported (SIA), and an upgrade process is available that enables a direct, single-step upgrade from SEA to SIA repositories. After running database configuration utilities, you can perform direct upgrades from an SEA deployment to a higher version SIA repository through a single-step process, for certain supported upgrade paths. For example, you can directly upgrade to the current release from Siebel CRM version 7.8 SEA or SIA, or from version 8.0 SEA or SIA, using a single-step upgrade method.

The following table describes examples of different methods for upgrades to the current release, including upgrade paths that use the single-step repository upgrade. The repository for the current release is SIA in all cases. For more information, see Supported Upgrade Paths for Siebel 2018.

Table Upgrade Methods for Different Upgrade Paths

Current Siebel Version	Target Upgrade Update	Upgrade Method
Siebel CRM version 7.5.3 or version 7.7.2 (SEA or SIA repository)	Siebel CRM update 18.12	Two-step repository upgrade. Upgrade to Siebel CRM version 8.1.1 (SEA or SIA repository), then to Siebel CRM update 18.12.
Siebel CRM version 7.8 or version 8.0 (SEA or SIA repository)	Siebel CRM update 18.12	Single-step repository upgrade.
Siebel CRM version 8.1.1 or later (SEA repository)	Siebel CRM update 18.12	Single-step repository upgrade.
Siebel CRM version 8.1.1 or later (SIA repository)	Siebel CRM update 18.12	Incremental repository merge.
Siebel CRM version 8.2.2 or later (SIA repository)	Siebel CRM update 18.12	Incremental repository merge.
Siebel CRM version 15.0 through version 15.4	Siebel CRM update 18.12	Incremental repository merge.
Siebel CRM version 15.5 or later Patchsets	Siebel CRM update 18.12	Incremental repository merge.
Siebel CRM version 16.0 or later Patchsets of version 16	Siebel CRM update 18.12	Incremental repository merge.
Siebel CRM version 17.0 or later Patchsets of version 17	Siebel CRM update 18.12	Single-step repository upgrade.
Siebel CRM 2018 or later update	Siebel CRM update 18.12	Single-step repository upgrade.

Data Model Changes for Single-Step Repository Upgrade

Due to data model changes around Address objects between the SEA and SIA repositories, the migration from the SEA repository to the SIA repository will result in some SEA objects being made obsolete. You must reconfigure all Address-related business components that are in use. In general, the same development upgrade process needs to be applied for the SEA to SIA migration on the same version. Migrating from SEA to SIA on the same version requires less effort then upgrading from one version to a higher version. For more information, see Migrating Address Data After a Direct SEA to SIA Upgrade.

About Inheriting Upgrade Behavior in a Siebel Upgrade

Environments: Development environment only.

Platforms: Windows, UNIX, IBM z/OS.

You can link objects together so that one object inherits the upgrade behavior of another. You do this by specifying an upgrade ancestor for an object.

Use standard objects as upgrade ancestors. A standard object is an uncustomized repository object provided by Oracle.

A common customization strategy is to create new objects by making a copy of a standard object and then modifying the copy, called the descendant.

For descendants that are for the following object types, you can specify an upgrade ancestor:

Applets
Business Components
Integration Objects
Reports

You specify the upgrade ancestor in the descendant’s Upgrade Ancestor field in Siebel Tools. During the repository merge, the descendant is upgraded in the same way as the upgrade ancestor. (Upgrade ancestors of applets are ignored in an ICL merge.)

For example, you create Applet-B by copying standard Applet-A. In Applet-B you specify Applet-A as the upgrade ancestor. In the New Siebel Repository, Applet-A has a new button.

After a regular merge, both Applet-A and Applet-B will have the new button.

After an ICL merge, Applet-B will have the new button, but Applet-A will not:

During the regular merge, Applet-B receives the new button because it is a descendant of Applet-A.
During the ICL merge portion, the Web template configuration of Applet-A is copied from the Prior Customer Repository to the New Customer Repository. This Web template configuration does not contain the new button. This removes the new button from Applet-A.
Since the ICL merge portion ignores the Upgrade Ancestor property, this change is not propagated to Applet-B. Applet-B retains the new button.

Limitations on the Upgrade Ancestor Property

The Upgrade Ancestor property is considered only during repository merges as part of application upgrades under these conditions:

If an upgrade ancestor is inactive in the New Siebel Repository, then it is obsolete, and its upgrade behavior is not propagated to descendants.
If an ancestor object is obsolete in the New Siebel Repository, then its descendants are not also obsolete.
If an upgrade ancestor is not present in the New Siebel Repository, then error messages display during the repository merge and are written to the merge log file. These errors are acceptable and do not mean the merge has failed.
The Upgrade Ancestor property is not considered during repository imports. However, imported objects can specify an upgrade ancestor. When the next application upgrade is done, the Upgrade Ancestor property is taken into account.
The setting of the Upgrade Ancestor property is not considered when applying application patches. If the upgrade ancestor is modified by the patch, then descendants are not modified.
Use caution when specifying upgrade ancestors. For regular merges, setting the Upgrade Ancestor property on applets propagates merge problems from standard-object applets to descendant applets.
Specifying an upgrade ancestor for objects slows the repository merge.

Upgrade Ancestor Picklist

When you click in the Upgrade Ancestor field, a picklist displays. The following criteria are used to populate the picklist:

Applets

Table is the same as the current applet buscomp
Class is the same as the current applet class
Upgrade Ancestor is null
Applet is a standard object

Reports

Buscomp is the same as the current report buscomp
Class is the same as the current report class
Upgrade Ancestor is null
Report is a standard object

Business Components

Bus Comp is the same as the current business component
Class is the same as the current business component
Upgrade Ancestor is null
Business component is a standard object

Integration Objects

Base Object Type is the same as the current Base Object Type
Business Object is the same as the current business object
Upgrade Ancestor is null
Integration object is a standard object

Propagating Changes to Objects After the Merge

If you do not select an upgrade ancestor for an object, then changes to the upgrade ancestor are not propagated to the descendant during the repository merge.

You can manually propagate changes to descendants after the merge by using the Siebel Tools object comparison and synchronization features. These features enable you to compare any two objects and propagate differences to one or both of the objects. For more information, see Configuring Siebel Business Applications.

About the Siebel Postmerge Utilities

Environments: Development environment only.

Platforms: Windows, UNIX, IBM z/OS.

You run the postmerge utilities after the repository merge completes.

The postmerge utilities make revisions to objects in the New Customer Repository. The utilities are useful for identifying problems with user interface customizations.

The postmerge utilities are implemented as a framework. Each utility in the framework is a business service and is listed in reputility.xml:

Windows: SIEBEL_TOOLS_ROOT\reppatch\reputility.xml

The postmerge utilities are as follows:

CSSGridRepPatch. Converts customized applet controls to grid-based layout.
CSSUINavUpgradeReposPrep. Converts customized screens to the Siebel CRM version 7.7 user interface navigation scheme.
CSSMVGUpgradePatch77. Enables the shuttle feature in customized MVGs.
CSSUIUpgradeReports. Lists unresolved problems in converting customized screens and views to the Siebel CRM version 7.7 user interface navigation scheme.
CSSWebTemplatePatch. For ICL upgrades, the utility copies Web templates into Siebel Tools that support the release you are upgrading from.
CSSWFRepPatch. For workflows, this utility changes step references from row-id references to name references for child objects of steps.

CSSGridRepPatch

The layout of form applets is grid-based, rather than flow-based. Applet Form Web templates have several new properties: Grid Property, Row Span, and Col Span. In addition, the item identifier syntax changes to xxyyy, where xx is the grid row and yyy is the grid column where the control is located.

Regular merge. The utility identifies both customer-created and customer-modified applets and adjusts the properties of controls in them as follows:

If you have modified the location of an existing control, then the utility restores the control to its original location. If you have modified other properties of the control, then these changes are preserved. You must move the control and label to the desired location.
If you have added a new control, it does not display after the merge. To display the control, the utility assigns an item identifier that places the control in the lower portion of the applet. The utility creates a Grid Property, Row Span, and Col Span property for the item. The utility also creates a Label control. You must move the new control and label to the desired location.
The utility does not change property settings for controls that are unmodified.

ICL merge. (Applies only to applets where Upgrade Behavior is not set to Admin.) The utility does not convert these applets to grid-based. New and modified controls display in the correct locations. For upgrades from Siebel CRM version 7.7 or later, the utility makes no changes.

The utility generates output to the reputility.log section called Invalid Applet Web Template Item Mapping Cleanup.

CSSUINavUpgradeReposPrep

At Siebel CRM version 7.7, a declarative model for associating views with screens was introduced. The relationship between views and screens for all levels of navigation must be explicitly declared. Several new object properties for screens and views are introduced to support this.

The new navigation scheme is applied to all screens and views for both regular and ICL merges. The utility runs after the repository merge in all upgrades. However, it is intended primarily for upgrades from releases prior to Siebel CRM version 7.7.

After a regular or ICL merge, screens and views display as follows:

Regular merge:
- Unmodified screens display normally.
- The views in customer-created screens do not display.
- Views added to existing screens do not display.
ICL merge:
- Unmodified screens with Upgrade Behavior property set to Admin display normally.
- Views in unmodified screens with Upgrade Behavior set to Preserve or NULL do not display.
- Views in customer-created screens do not display.
- Views added to existing screens do not display, regardless of Upgrade Behavior setting.

The utility scans all screen view definitions looking for orphaned views. It groups orphaned views under existing Categories. If no Category exists, then the utility creates one. This causes the orphaned views to display.

For a regular merge, you must review customer-created and customer-modified screens and views to verify that views are correctly associated with screens.

For an ICL merge, you must also review these screens and views. In addition, you must review all screens and views where Upgrade Behavior is set to Preserve or NULL.

The utility generates output to the reputility.log section called User Interface Navigation Upgrade.

CSSMVGUpgradePatch77

MVG applets with an M:M relationship to the underlying business component are configured as shuttle applets by default. The utility scans these MVG applets in the New Customer Repository and reconfigures them to display as shuttle applets:

Regular merge. After the merge, customer-created and customer-modified MVGs are not shuttle-enabled. The utility reconfigures these MVGs so they display as shuttle applets.
ICL merge. After an ICL merge, the utility reconfigures MVGs as follows:
- Customer-created and customer-modified MVGs are not shuttle-enabled. The utility reconfigures these MVGs so they display as shuttle applets.
- Unmodified MVGs that have Upgrade Behavior set to Preserve or NULL are copied to the New Customer Repository during the merge and replace MVGs that are shuttle-enabled. The copied-in MVGs might not be configured as shuttle applets. The utility reconfigures the copied-in MVGs so they display as shuttle applets.
- Unmodified MVGs that have Upgrade Behavior set to Admin are not deactivated in the New Customer Repository and so display as shuttle applets.

The utility generates output to the reputility.log section called Multi Value Group Shuttle Applet Upgrade.

CSSUIUpgradeReports

This utility makes no changes to the New Customer Repository. Instead, it scans user interface objects in the repository and lists problems that could not be resolved by the CSSUINavUpgradeReposPrep utility.

The CSSUIUpgradeReports utility writes the report to reputility.log. You must manually correct problems listed in the report. The report is located in the POST MERGE USER INTERFACE REPORTING UTILITY section of the log.

The report has the following sections:

Issue 1: Rich Text Control (RTC) that needs to have User Properties Reconfigured
Issue 2: New Aggregate Category Records that must be renamed
Issue 3: Views that need an applet in View Web Template Item Id 1
Issue 4: Chart Views Needing Migration to Aggregate Type
Issue 5: Explorer Views Needing Migration to Aggregate Type
Issue 6: Categories where parent applets are missing drilldowns to a Detail View

CSSWebTemplatePatch

This utility runs after an ICL merge. It does not run after a regular merge. The utility performs the following steps in the installation directory of the Siebel Tools instance that you used to perform the merge:

The utility moves the Web template files for the new release from webtempl to \temp\webtempl.
The utility copies Web template files from a subdirectory of reppatch\web_templates to \webtempl.

These Web template files support the user interface of the release you are upgrading from. They are very similar but not identical to the Web template files included in that release.

For example, if you selected the 7.8.2 and the Label on Top ICL options, then the utility copies Web template files from the 782 and TopLabel subdirectories of reppatch.

The utility generates output to the reputility.log section called Web Template PCL Patch Rule.

CSSWFRepPatch

This utility changes workflow step references from row-id references to name references for child objects of steps. This completes the process of migrating workflows to the repository at Siebel CRM version 7.7. This utility primarily affects upgrades from releases prior to Siebel CRM version 7.7.

This utility does not write to the reputility.log.

How the Postmerge Utilities Work the Upgrade Behavior Property

The postmerge utilities ignore the Upgrade Behavior property. They make changes to user interface objects based on the object’s characteristics rather than Upgrade Behavior setting.

About Tuning Siebel Production Upgrade Files

Environments: Production test environment only. Does not apply to production environment.

Platforms: Windows and UNIX only.

The Upgrade Tuner allows you to tune the upgrade files generated by the Siebel Database Configuration Utilities. Tuning the production upgrep files can significantly reduce database downtime when performing a production environment upgrade.

Upgrade Tuner displays the following information and provides the following options:

Table creation times. You can place tables with long creation times in parallel threads.
Index creation times. You can assign index creation to run in parallel threads.
Zero-Row SQL commands. You can review and inactivate SQL statements that do not affect any table rows.

The scripts used to upgrade your Siebel database are generic. They update your Siebel database to support all Siebel Business Applications functionality. You can use this option to eliminate SQL statements that are not needed for your applications.

Operating System and RDBMS Support

Upgrade Tuner supports parallel threads for table and index creation for the combinations of operating system and RDBMS show in the following table.

Table Upgrade Tuner Support for Parallel Table and Index Threads

Operating System	Oracle Database	IBM DB2	Microsoft SQL Server
Windows	Yes	No	No
UNIX	Yes	No	No

Upgrade Tuner is not supported for IBM z/OS. Upgrade Tuner supports zero-row SQL command deactivation for the combinations of operating system and RDBMS shown in the following table.

Table Upgrade Tuner Support for Zero-Row SQL Deactivation

Operating System	Oracle Database	IBM DB2	Microsoft SQL Server
Windows	Yes	Yes	Yes
UNIX	Yes	Yes	No
z/OS	Not applicable	No	Not applicable

For information on which versions and releases of the operating systems and RDBMS products that Oracle supports for Siebel products, see the Certifications tab on My Oracle Support.

Upgrade Tuner is part of the Siebel Server and runs only under Microsoft Windows. Upgrade Tuner does not run on UNIX. To tune UNIX production upgrade files, you must copy them to a Windows computer, tune them, and move them back to the UNIX computer. Scripts are provided to move the files.

If you are a UNIX customer and do not have a Siebel Server for Windows, then contact your account manager or Oracle Global Customer Support to obtain one.

When to Use Upgrade Tuner

Use Upgrade Tuner in the production test environment to tune the upgrade files that perform the production upgrep. There is no need to tune the upgrade files that perform the production upgphys. You also do not need to tune the upgrade files that perform the development environment upgrep or upgphys.

Upgrade Tuner Modes

When you start Upgrade Tuner it displays four tabs:

Process Information
Parallelize Table Creation
Parallelize Index Creation
Deactivate 0-Row SQLs

Process Information Tab

This page displays the information sources that Upgrade Tuner is using. These sources include the Logparse summary.xml file, the master .ucf file, and the driver .ucf file.

You cannot edit the information on this page. Upgrade Tuner obtains the information by reading the summary.xml file.

Parallelize Table Creation and Parallelize Index Creation Tabs

The Parallelize Table Creation page and the Parallelize Index Creation page both have the same layout. These pages allow you to do the following:

Parallelize Table Creation tab. This page displays the time required to create tables and allows you to assign table creation to parallel threads. Adding a table to a parallel thread does not add index creation for that table to the thread. Table and index creation are handled as separate steps during the upgrade.
Parallelize Index Creation tab. This page displays the time required to create table indexes and allows you to assign index creation to parallel threads.

Creating parallel threads improves upgrade performance by reducing the total time to create tables and indexes. You can create up to nine parallel threads. Tables or indexes not assigned to a parallel thread remain in the serial thread.

When you run the Upgrade Tuner, the Number of Threads parameter is automatically set, based on a log analysis, to the value effectively required to run the upgrade. In most cases this value is set at 4. This value, which can be changed in the master upgrep file, drives the maximum number of threads for each single Siebel upgrep task, such as ddlimp executions concurrently running for this process. When setting this value you must consider the system resources of the computer from which the upgrep phase was initiated. These changes must be tested on a copy of the Siebel production database environment, prior to rolling these out for the actual Siebel production upgrade downtime window.

Deactivate 0-Row SQLs

This page allows you to activate or deactivate the SQL statements that do not affect any table rows and therefore any data. This capability improves the upgrade performance by eliminating SQL statements that might not apply to your data. This page lists only the SQL files that are executed natively by the RDBMS. It does not list SQL files that are executed using odbcsql.

Files Required to Run Upgrade Tuner

Upgrade Tuner requires the following files. The location of the files is the same on both Windows and UNIX hosts. The following table displays these files.

Table Files Required to Run Upgrade Tuner

File	Location on a Windows Host
`summary.xml`	`SIEBEL_ROOT\log\upgrep_prod_VERSION` For example, `SIEBEL_ROOT\log\upgrep_prod_version\summary.xml`
`master_upgrep_prod_VERSION.ucf`	`SIEBEL_ROOT\bin` For example, `SIEBEL_ROOT\bin\master_upgrep_prod_version.ucf`
`schema*.ddl`	DBSRVR_ROOT\DBPLATFORM For example, `DBSRVR_ROOT\Oracle\schema.ddl, schema_i1.ddl, schema_t1.ddl`
`driver_upgrep_prod_VERSION.ucf`	`\DBSRVR_ROOT\DBPLATFORM\upgrade\VERSION` For example, `DBSRVR_ROOT\Oracle\upgrade\version\driver_upgrep_prod_version.ucf`
`*.sql`	`DBSRVR_ROOT\DBPLATFORM\upgrade\VERSION` For example, `DBSRVR_ROOT\Oracle\upgrade\version\pret.sql, preschm.sql`

How Upgrade Tuner Modifies Files

When you save your changes, Upgrade Tuner modifies the upgrade files. These are the files the Upgrade Wizard uses to upgrade the database. These files are as follows:

Driver Configuration File
Schema.ddl File
SQL Files

Driver Configuration File

When you add or remove parallel threads and save your changes, Upgrade Tuner modifies the driver configuration file, for example driver_upgrep_version.ucf. The driver configuration file is a text file that contains a series of steps. The steps specify the commands that control the production upgrep. When you run the Upgrade Wizard to upgrade your database, it executes the steps in the driver configuration file.

The following actions are examples of steps that can appear in the driver configuration file:

Making schema changes using the ddlimp utility and schema.ddl
Making schema and data changes by executing SQL scripts

Upgrade Tuner manages the driver configuration file as follows:

When you save your changes after the first session, Upgrade Tuner makes a copy of the file and appends .orig to the file name. It then modifies the file. For example, Upgrade Tuner copies driver_upgrep_version.ucf to driver_upgrep_version.ucf.orig. It then makes changes to driver_upgrep_version.ucf.
When you save your changes after the second session, Upgrade Tuner makes a copy of the file and appends .old to the file name. It then modifies the driver file. For example, Upgrade Tuner copies driver_upgrep_version.ucf to driver_upgrep_version.ucf.old. It then makes changes to driver_upgrep_version.ucf.
When you save your changes after the third session and all following sessions, Upgrade Tuner saves the driver file to .old again and then updates the driver file.

This file management strategy preserves the previous set of revisions to the file. It also preserves the original version of the file.

Schema.ddl File

When you run the Upgrade Wizard after the production upgrep it reads the driver file. The driver file contains steps that call the ddlimp utility. This utility uses schema.ddl as input to upgrade your database schema.

In the Parallelize Table Creation and Parallelize Index Creation pages, Upgrade Tuner displays the creation times for the tables and indexes in the schema.ddl file.

When you create parallel threads, Upgrade Tuner creates thread-files that have the same format as schema.ddl but contain only the table or index creation steps in the thread. Upgrade Tuner then adds steps to the driver file. These steps call the ddlimp utility, and specify the thread-files as input.

Upgrade Tuner manages schema.ddl and thread-files as follows:

When you create a new thread and click Save and Exit, Upgrade Tuner creates a schema.ddl thread-file for the new thread.
For example, you do not have any parallel threads, and then create two new threads for table creation. When you exit, Upgrade Tuner creates a schema_t1.ddl and a schema_t2.ddl file. Upgrade Tuner also inserts steps in the driver file to execute the thread-files.

The t1 thread-file contains the table creation information for the tables in Parallel Thread 1. Parallel thread 2 information is contained in the t2 thread-file, and so on.

When you create new threads in the Parallelize Index Creation page, the thread-files are named i1, i2, and so on. For example, the information for Parallel Thread 1 for index creation is contained in schema_i1.ddl.
If you run Upgrade Tuner and change the tables or indexes assigned to a thread, then Upgrade Tuner updates the thread-file for that thread. Upgrade Tuner does not create .orig or .old files for thread-files. Also, Upgrade Tuner does not change the step that executes the thread-file in the driver file.
Upgrade Tuner does not revise the content of the main schema.ddl file (the serial thread) when you create thread-files. The thread-files duplicate the content in schema.ddl.

In the driver file, the order of execution of steps for schema.ddl and the thread-files is as follows:

Table thread files beginning with file t1 (ddlimp in table creation mode)
schema.ddl (ddlimp in table creation mode)
Index thread files beginning with i1 (ddlimp in index creation mode)
schema.ddl in index creation mode (ddlimp in index creation mode)

For both table and index creation, the parallel threads are executed first followed by the serial thread (schema.ddl).

Tip: To locate thread-file steps in the file driver_upgrep_prod_version.ucf, query for “schema_.

SQL Files

When you make changes in the Deactivate 0-Row SQLs page, Upgrade Tuner makes changes to the SQL file containing the SQL command. Because the SQL file is already a step in the driver file, Upgrade Tuner does not modify the driver file.

Upgrade Tuner manages the SQL files as follows:

When you first change an SQL file, Upgrade Tuner saves a copy of the SQL file and appends .orig to its file name. Upgrade Tuner then updates the SQL file.
The next time you change the SQL file in Upgrade Tuner, it saves a copy of the SQL file and appends .old to the file name. Upgrade Tuner then updates the SQL file.
Thereafter, when you modify the SQL file, Upgrade Tuner saves the SQL file to .old again and then updates the SQL file.

This file management strategy preserves the previous set of revisions to the file. It also preserves the original version of the file.