3How the Siebel Database Upgrade Works
How the Siebel Database Upgrade Works
This chapter provides an overview of the Siebel database upgrade process and upgrade environments, and describes the utility used to perform the upgrade. Also review topics relevant to the z/OS database upgrade in the chapters in Siebel Database Upgrade Guide that provide an overview of the upgrade process. This chapter includes the following topics:
About Supported Siebel Upgrade Paths
Upgrades: All upgrades.
Environments: All environments.
Performing a database upgrade refers to migrating your Siebel custom repository and data schema from one release of Siebel CRM to a higher release. This guide describes how to upgrade the following types of installations:
A Siebel CRM 7.x installation to Siebel 2018.
In this version of the guide, Release 7.x refers collectively to all versions of Siebel CRM Release 7.8.2 (SIA) from which you can upgrade directly to Siebel Innovation Pack 2018..
A Siebel CRM 8.0 installation to Siebel 2018.
Note: If you are considering migrating your Siebel CRM 8.x z/OS database to Unicode format, be aware that you cannot upgrade to a later release of Siebel CRM using the standard upgrade procedure. If you migrate your Siebel z/OS database to Unicode format, you can upgrade to the latest Siebel update. However, Oracle will support Unicode database upgrades from one major release of Siebel CRM to another, or incremental Unicode upgrades, in future updates, if required.A Siebel CRM 8.1.1.x installation to Siebel 2018.
This guide does not cover the following specific upgrade paths or infrastructure changes. For help with these tasks, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance:
Direct upgrades to Siebel CRM version 8.1 from Siebel CRM versions earlier than 7.5.3 are not supported; you must first upgrade to Siebel CRM 7.8.2, or a later release.
Direct upgrades to Siebel CRM version 8.2.2.x are not supported.
Changing operating system type during an upgrade, for example changing from Windows to UNIX.
Changing database platform type during an upgrade, for example changing from Oracle 8i to IBM DB2.
Migrating to Unicode.
Migrating from Siebel Industry Solutions or Siebel Financial Services applications to Siebel Business Applications.
Upgrading from one base language to another. To achieve similar results, upgrade your existing base language and install the Siebel language pack for the desired language.
Supported Upgrade Paths for Siebel 2018
The following table lists supported upgrade paths for Siebel 2018 (Siebel CRM update 18.12) on the IBM DB2 for z/OS database platform. The repository for the current release is SIA in all cases.
Siebel Repository now consists of a Runtime Repository. This repository contains the compiled repository definition. This updated repository is available for all of the supported Siebel languages. Siebel clients and servers now read the compiled definition from the runtime repository stored in the database. The Runtime Repository is required for either of the following upgrade tasks summarized in this topic.
If you run incremental repository merge for an existing Siebel database.
If you perform a full database upgrade for an existing Siebel database.
You also require the Siebel Runtime Repository to run Siebel Business Applications after you install a new Siebel database for Siebel CRM update 18.12. For installation information, see Siebel Installation Guide for the operating system you are using.
Table Supported Upgrade Paths for Siebel 2018 on IBM DB2 for z/OS
| Current Version | Upgrade Version | Upgrade Approach | Upgrade Tasks |
|---|---|---|---|
Siebel 7.5.3 (SEA repository or SIA repository) and Siebel 7.7.2 (SEA repository or SIA repository) |
Siebel CRM update 18.12 |
|
You must perform a two-step repository upgrade:
Note: Use incremental repository merge for upgrades from Siebel CRM version 8.1.1 (SIA repository).
|
Siebel 7.8.2 (SIA repository and SEA repository) Siebel 8.0 (SIA repository and SEA repository) Siebel 8.1.1.0 through 8.1.1.7 (SEA repository) |
Siebel CRM update 18.12 |
|
|
Siebel 8.1.1.0 through 8.1.1.14 (SIA repository) |
Siebel CRM update 18.12 |
|
Note: This step is mandatory to be able to run Siebel Business Applications in the current release.
For more information on incremental repository merge, see Performing the Siebel Incremental Repository Merge. |
Siebel CRM version 8.2 (SIA repository) Siebel CRM version 8.2.1 (SIA repository) |
Siebel CRM update 18.12 |
|
|
Siebel CRM version 8.2.2.0 through version 8.2.2.14 (SIA repository) |
Siebel CRM update 18.12 |
|
|
Siebel CRM version 15.0 through 15.4 |
Siebel CRM update 18.12 |
|
|
Siebel CRM version 15.5 and later patchsets |
Siebel CRM update 18.12 |
|
|
Siebel CRM version 16.0 and later patchsets of version 16.0 |
Siebel CRM update 18.12 |
|
|
Siebel CRM version 17.0 and 18.x |
Siebel CRM update 18.12 |
Single-step repository upgrade. |
|
Types of Siebel Database Upgrades
This topic describes the different methods available to upgrade a Siebel Database. The approach you use is determined by your current version of Siebel CRM. Upgrades can be either:
Single-step or two-step repository upgrades
Full database upgrades or patch installations with incremental repository merge
Each of these upgrade methods is explained as follows.
Single-Step and Two-Step Siebel Repository Upgrades
Before 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. The Siebel Industry Applications (SIA) data model is physically a superset of the Siebel Enterprise Application (SEA) data model. The SIA data model has more tables, more columns in the same tables, and more indexes than the SEA data model, but it does not exclude any tables, columns or indexes from the SEA version.
Since Siebel CRM version 8.1.1, only the SIA repository is supported. On z/OS, an upgrade process enabling a direct, single-step upgrade from SEA to SIA repositories is available only from 8.1.1.x releases. Upgrades from Siebel CRM 7.5.3 (SEA) through Siebel CRM version 8.0 (SEA) require a two-step upgrade process. For additional information, see the topic about single-step repository upgrades in Siebel Database Upgrade Guide.
Patch Releases and Incremental Repository Merge
If you are upgrading from one major release of Siebel CRM to another, for example, from Siebel 8.0 to Siebel 8.2, then you must perform a full database upgrade. If you are upgrading within the same Siebel release, then you can upgrade by performing a patch release installation.
Siebel patch releases are applied onto existing patch releases, both of which are part of the same major Siebel CRM release. For example, you can install the Siebel 2018 as a patch release into an existing installation of Siebel CRM version 8.1.1 or 8.1.1.x. For more information on patch releases, see Siebel Installation Guide for the operating system you are using.
If you install the current release as a patch installation, then you must use the Incremental Repository Merge feature to update your Siebel database to the current release. Incremental Repository Merge is a mechanism which allows you to incrementally upgrade your custom repository data (including schema and seed data) from Siebel CRM version 8.1.1.x (SIA Fix Pack) to Siebel 2018 (SIA innovation pack). On the DB2 for z/OS platform, incremental repository merge functionality is not supported for upgrades to Siebel Release 8.2. For more information about the incremental repository merge process, see the chapter about performing an incremental repository merge in Siebel Database Upgrade Guide and Performing the Siebel Incremental Repository Merge.
About Using Oracle’s Advanced Customer Services
The Siebel CRM upgrade process on DB2 for z/OS is designed to run in all standard Siebel implementations. It is built on the assumption that data exists in all Siebel tables and that all this data must be migrated.
In reality, your implementation has probably been customized to suit your business so, for example, you might not use all of the Siebel tables shipped or they might contain varying amounts of data. To accommodate this fact, the upgrade process is customizable, for example, you can eliminate upgrade jobs that run on empty tables, or you can choose to run unload jobs simultaneously.
Global Customer Support provides support for all standard z/OS upgrades but it does not support customized upgrades. If you require help with a standard upgrade, create a service request (SR) on My Oracle Support. You can log service requests by accessing My Oracle Support (Service Request tab), or by using your existing phone support numbers to contact Oracle Global Customer Support.
Customizing the upgrade scripts is a complex process and, for this reason, if you want to customize the upgrade scripts, you must contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance.
This guide describes a number of upgrade customization tasks that you can perform where the assistance of Oracle’s Advanced Customer Services is required.
This guide also describes tasks where enlisting the help of Oracle’s Advanced Customer Services is recommended. Failure to contact Oracle’s Advanced Customer Services for help with these tasks does not have implications for continuing support.
Where a task requires the help of Oracle’s Advanced Customer Services, this requirement is indicated in the relevant topic.
About Unicode Support
Previous releases of Siebel Business Applications supported ASCII- and EBCDIC-based coded character set IDs (CCSIDs) on DB2 for z/OS. Since Siebel CRM 8.0, Unicode is also supported on DB2 for z/OS version 8 and later releases. For a list of supported languages and code pages, see the Certifications tab on My Oracle Support.
You can migrate your Siebel database from an EBCDIC or ASCII code page to a Unicode encoding system but this process is not part of the standard Siebel CRM upgrade procedure. A separate migration procedure for migrating to Unicode is performed on the DB2 host after you have upgraded to the current release of Siebel CRM. For information on migrating to Unicode, see Implementing Siebel Business Applications on DB2 for z/OS.
About Siebel Upgrade Environments
Upgrades: All upgrades.
Environments: All environments.
This guide describes how to upgrade three database environments:
Development environment
Production test environment
Production environment
Detailed information on each database environment is provided in the remainder of this topic. For an overview of the steps involved in upgrading each database environment, see the chapter in Siebel Database Upgrade Guide that provides an overview of the upgrade process.
Development Environment
The development environment is where developers use Siebel Tools to customize Siebel Business Applications. The development environment upgrade merges these customizations with the new Siebel release. The merged repository and schema definitions become inputs to the production upgrade.
A development environment contains the following elements:
Siebel Server
Siebel Gateway
Siebel Database Configuration Utilities installed on the same computer as the Siebel Server
RDBMS server and Siebel database
Siebel Application Interface
Siebel Tools installed on workstations running a supported Windows environment. This includes the local database running on developers’ Mobile Web Clients.
Siebel Business Applications and test data required to verify the basic function of a Siebel Runtime Repository.
Production Test Environment
The production test environment is where you test the upgraded release to validate its function and performance before deploying it to users. This is also where you tune the upgrade process to minimize the time required to perform your production upgrade.
By tuning the production upgrade scripts in a test environment, you can significantly reduce the time required to complete the production upgrade. For this reason, the production test environment database must contain the same data volume and topography as your production database.
This environment includes the following elements:
Siebel Enterprise Server, including at least one Siebel Server and an RDBMS server and Siebel database
Siebel Gateway
Siebel Database Configuration Utilities installed on the same computer as the Siebel Server
Siebel Application Interface
All the Siebel Business Applications currently installed in your production environment
A copy of the Siebel database installed in your production environment
You perform the following processes in the production test environment:
Test the upgraded release to validate its function and performance before deploying it to users.
Tune the upgrade process to minimize the time required to perform your production upgrade.
Tuning the upgrade scripts can significantly reduce the time required to complete the production upgrade.
Production Environment
The production environment is your live business environment, where your internal and external users interact with applications and generate actual business data. The production environment includes all your Siebel Enterprise Servers worldwide.
The upgrade process assumes all production environment databases are completely separate from the development environment and production test environment databases.
Oracle provides these tools to help you transition from production test to production:
Siebel Application Deployment Manager (ADM). This application migrates administrative data such as lists of values (LOVs) from the production test environment to the production environment. For further information about ADM, see Siebel Application Deployment Manager Guide.
Siebel Anywhere. This application builds distribution kits for remote users. For information about Siebel Anywhere, see Siebel Anywhere Administration Guide.
Mapping Your Environments
You might have more or fewer environments than those described About Siebel Upgrade Environments. The following table gives recommendations for mapping your environments to the ones described in this guide.
Table Mapping Your Environments to Siebel Upgrade Processes
| Environment Description | Recommended Upgrade |
|---|---|
The environment has the following characteristics:
|
Development environment upgrade. |
The environment has the following characteristics:
|
Production test environment upgrade. |
The environment is used for live business transactions by both local and remote users. |
Production environment upgrade. |
About the z/OS Upgrade
Historically, Siebel production environment upgrades were primarily performed on the z/OS host (mainframe-centric) but you could choose to upgrade your development environment using either a mainframe-centric or midtier-centric process. Since Siebel CRM 8.0, only mainframe-centric development environment upgrades are supported for DB2 for z/OS. In a mainframe-centric upgrade, all upgrade DDL statements (CREATE, DROP, ALTER, and GRANT) and DML (INSERT, UPDATE, DELETE, and SELECT) are executed on the mainframe host.
You initiate a Siebel database upgrade on DB2 for z/OS from a midtier platform (Windows or UNIX) using the Siebel Upgrade Wizard, which automatically generates the DDL and DML files necessary for the upgrade. The Siebel Upgrade Wizard is also run from the midtier to import seed data and the upgraded repository.
You must manually transfer the DDL and the data migration DML files generated on the midtier platform by the Upgrade Wizard to the DB2 host where they are unpacked and applied; this process is guided on the mainframe using REXX execs and ISPF panels. This manual portion of the upgrade, which runs directly on the z/OS host, allows you to tailor the upgrade process to suit your hardware environment and to minimize downtime. The following figure shows the In-Place Upgrade Main Menu on the z/OS host.
Each ISPF Upgrade panel has a bookmark label and message, indicating the last step completed or currently in progress. These bookmarks guide you through the upgrade process; you cannot rerun jobs that have completed successfully or run jobs out of sequence.
About the Staging Database
Upgrades: All upgrades.
Environments: All environments.
Previously, for recovery purposes, in-place upgrades were not supported for Siebel mainframe-centric upgrades (an in-place upgrade occurs when upgrade changes are made directly to the existing database). Instead, a target database was built for the new release and data was unloaded from the existing source database and migrated in the appropriate format to the upgraded target database. The source database was not upgraded, although minor modifications were made to it during the upgrade process.
Since Siebel CRM 8.0, the production database is upgraded in-place. However, to accommodate host customers requirements for high-system-availability, a staging database is first created which is used to generate all the z/OS upgrade components (for example, the JCL and SQL upgrade files). The staging database allows you to generate all the midtier upgrade files and to build the JCL in advance of the actual database upgrade; this removes these steps from the critical upgrade path and minimizes system downtime.
The manual parts of the upgrade are run against the staging database. The automatic parts of the upgrade are run directly against the development or production database being upgraded (the target database).
The staging database is created from the existing development or production database that is to be upgraded (the target database). The target database DDL, and the storage control file specifying the physical database layout, are extracted and then executed in a separate DB2 subsystem to create the staging database. The staging database therefore contains the same schema and tables as the database to be upgraded, but it does not contain data.
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 or altering a unique index on an existing table provided the CLUSTER attribute is not specified for the index.
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, or data that is statistically similar to the data in 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.
About the Siebel Database Upgrade Process
Upgrades: All upgrades.
Environments: All environments.
Upgrading to a new release involves two aspects:
The order in which to upgrade your environments
The flow of the upgrade process within each environment
Environment Upgrade Order
If you have a development environment, you must upgrade it first. During this phase, your customizations are merged with the new Siebel release. A merged repository file and database schema file are created and become inputs to the production test environment upgrade and production upgrade.
If you do not have a development environment or have not customized your repository, no repository merge is required. You can use the repository and schema definition files included in the new release to upgrade your production test environment and production environment.
Flow of the Upgrade Within an Environment
The basic flow of the upgrade process is shown in the following image.
Upgrade the Infrastructure
The first phase is to upgrade your hardware and software to meet system and implementation requirements, which includes upgrading the Siebel Enterprise Server to the new release. This action upgrades the Siebel Servers and provides the programs, scripts, input files, and other files required to merge the repository and upgrade the Siebel database. For information on how to upgrade the infrastructure, see Siebel Installation Guide for the operating system you are using.
Perform Preupgrade Tasks
This phase prepares the Siebel database for upgrade and includes such tasks as closing database connections, clearing pending workflow tasks, disabling customized triggers and editing and validating the storage control file.
Perform Upgrade Tasks (Development Environment)
This phase merges your customizations into the new release. This phase also upgrades the development environment database and includes these tasks:
Prepare application data. These tasks prepare test data for migration.
Upgrade database (upgrep). Run the Database Configuration Wizard in upgrep mode, selecting the zSeries Staging of Files for Upgrade option. This generates the files required to build the staging database and generate the upgrade files required to perform the in-place upgrade of the database.
Perform the in-place upgrade of the database. During this phase, a basic upgrade of the Siebel database schema is performed and repositories are loaded to prepare for the repository merge.
The upgrep mode makes the following changes:
Drops 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
Imports seed data
Imports the Prior Siebel Repository, the New Siebel Repository, and the New Customer Repository
Makes modifications to repository objects to prepare for the repository merge
Updates primary children foreign key references
Performs miscellaneous file actions
Merge repository. You use Siebel Tools to merge your existing repository with the repository in the new release. During the repository merge, objects from the Prior Siebel Repository, the Prior Customer Repository, and the New Siebel Repository are compared to identify the total set of object differences. The process also determines how conflicts between repository changes are resolved as they are merged into the New Customer Repository.
Run postmerge utilities. You use Siebel Tools to run a set of utilities that examine the merged repository. The utilities analyze your customizations to applets and views, and apply changes to them as required to conform to the user interface in the new release.
Upgrade database (upgphys). You run the Database Configuration Wizard in upgphys mode. It further upgrades the Siebel database with changes resulting from the repository merge and completes the database upgrade.
The Database Configuration Wizard also generates the customer repository definition file and logical schema definition file that are used as input to the production test environment and production upgrades.
Specifically, this mode performs the following tasks:
Synchronizes the Siebel database schema to the logical schema definition in the merged repository.
Note: During the synchronization process, custom columns in the Siebel Schema that are not in the Siebel Repository are not removed but custom indexes in the Siebel Schema that are not in the Siebel Repository are removed.Exports repository object definitions to a file, custrep.dat, and exports the logical schema definition to a file, schema.ddl
These two files are used as input to the production upgrades.
Renames the New Customer Repository to Siebel Repository
Updates the schema version in
S_APP_VER
Perform Upgrade Tasks (Production Test Environment)
This phase upgrades a production test environment Siebel database to the new release allowing you to test how customizations work with the new release and to tune the upgrade scripts.
This phase includes the following tasks:
Prepare application data. These tasks are about preparing application data for migration.
Prepare for Production Upgrade (Upgrades from 7.5.3 only): Run the Database Configuration Wizard in Prepare for Production Upgrade mode. This mode compares the repository schema and the physical database schema and generates a file, SCINDX.SQL, which is used to remove obsolete indexes. SCINDX.SQL lists indexes present in the physical schema that are not present in the repository schema.
Note: You must define an ODBC connection to the development environment database before performing this upgrade step.Upgrade database (upgrep + upgphys). Run the Database Configuration Wizard in upgrep + upgphys mode, selecting the zSeries Staging of Files for Upgrade option. This generates the files required to build the staging database and generate the upgrade files required to perform the in-place upgrade of the database. The additive and nonadditive schema upgrade files are generated separately.
(Optional) Apply the additive upgrade files to upgrade the database. This is a nondisruptive upgrade process.
Perform the in-place upgrade of the database. The following changes are made during this phase of the upgrade process:
Drops interface tables and database triggers
Populates columns that must change from NULL to NOT NULL
Uses the schema.ddl file 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
Updates primary children foreign key references
Performs miscellaneous file actions
Makes several administrative changes to table data, including updating the schema version in S_APP_VER.
Upgrade the repository and import seed data (upgrep + upgphys). Run the Database Configuration Wizard in upgrep + upgphys mode again, selecting the zSeries Seed/Repository Upgrade option to complete upgrade processing. During this step, the upgraded repository and seed data are imported.
Tune upgrade scripts (optional). You can improve the performance of the production environment upgrade by tuning the production upgrade scripts in the test environment.
Run several production upgrades against the test database. This allows you to understand the upgrade process before performing the production upgrade, to conduct performance testing, and to fine tune the upgrade scripts. After carrying out thorough performance testing, you can perform the live production upgrade using the tuned upgrade files.
Perform Upgrade Tasks (Production Environment)
This phase upgrades a production environment Siebel database to the new release and includes the following tasks:
Prepare Application Data. These tasks involve preparing application data in the production database for migration.
Upgrade database (upgrep + upgphys). Run the Database Configuration Wizard in upgrep + upgphys mode, selecting the zSeries Staging of Files for Upgrade option. This generates the files required to build the staging database and generate the upgrade files required to perform the in-place upgrade of the database. The additive and nonadditive schema upgrade files are generated separately.
Note: If you have tuned the upgrade scripts during a production test upgrade and want to use them during your production upgrade, you do not have to perform this step. Instead, change the production test environment values in the upgrade files to production environment values and then apply these files on the Z/OS host to upgrade the target database. For further information on this task, see Process of Upgrading a Siebel Production Environment.(Optional) Apply the additive upgrade files to upgrade the database. This is a nondisruptive upgrade process.
Perform the in-place upgrade of the database. The same changes are made during the in-place upgrade of the production environment as were made during the in-place upgrade of the production test environment.
Upgrade the repository and import seed data (upgrep + upgphys). Run the Database Configuration Wizard in upgrep + upgphys mode again, selecting the zSeries Seed/Repository Upgrade option to complete upgrade processing.
Perform Postupgrade Tasks
This phase is where you set up the environment, configure applications, and test the upgraded system as follows:
Set Up the Environment. These tasks set up the postupgrade environment, which includes extracting the developers’ databases and running database statistics.
Application Administration. These tasks set up applications and include such things as setting up user access and visibility of views and screens.
Application Configuration. These tasks prepare applications for testing, including data migration for specific applications.
Test the Upgraded System. These tasks test the upgraded system. For development environment upgrades, you perform basic unit tests to verify application function followed by a full suite of regression and stress tests to verify the upgraded system is ready for production.
About the Siebel Database Configuration Utilities and Database Configuration Wizard
Upgrades: All upgrades.
Environments: All environments.
The Database Configuration Utilities comprise a set of files that you install on a Siebel Server computer. These files are accessed when you run the Database Configuration Wizard and the Siebel Upgrade Wizard to install, configure, or upgrade the Siebel database on the DB2 host, or to perform other operations on the Siebel database after it is installed.
You can use any upgraded Siebel Server to perform an upgrade of the Siebel database. For best performance, however, install the Siebel Database Configuration Utilities files on the Siebel Server that you will use to perform the upgrade.
The Siebel Database Configuration Utilities files are installed at the same directory level as the Siebel Server in a directory called dbsrvr. For example, if the Siebel Server is installed in C:\sba81\siebsrvr (Windows), then the Siebel Database Configuration Utilities are installed in C:\sba81\dbsrvr. To edit and execute Siebel Database Configuration Utilities procedures and maintenance scripts, you must have READ-WRITE access to the Siebel Server bin directories in SIEBEL_ROOT (Windows), $SIEBEL_ROOT (UNIX).
The Database Configuration Wizard is part of the Siebel Configuration Wizard. It interactively gathers the information required to perform the following operations:
Install the Siebel database. This wizard sets up the Siebel database in the RDBMS as part of a first-time installation of Siebel Business Applications. It is also used to add a language to the Siebel Database Server installation.
Upgrade the Siebel database. This wizard upgrades the Siebel database to a new release in a development or production environment.
Import or export a Siebel repository. This wizard moves entire repositories between database environments with the same schema definition.
Migrate a Siebel repository. This wizard migrates repositories between databases and synchronizes the target database schema with the migrated repository schema definition.
Run database utilities. This group of wizards perform the following functions:
Synchronize a database schema with the Siebel Repository schema definition.
Convert existing Lists of Values (LOVs) to Multilingual Lists of Values (MLOVs).
Configure the database by extracting storage control files from the DB2 catalog and validating the extracted files.
Migrate the database from an EBCDIC or ASCII encoding format to a Unicode encoding format.
About Running the Upgrade Database Option
When you run the Upgrade the Siebel Database option on the Database Configuration Wizard, the wizard prompts you for the upgrade environment (development or production) and the upgrade phase (upgrep, upgphys, or Prepare for Production Upgrade). The Wizard then prompts you for the information it requires about the upgrade environment to perform the upgrade.
After collecting and confirming the information, the wizard creates an upgrade configuration file and calls a driver that uses the environment information to create the SQL files required to upgrade your database.
After you run the Database Configuration Wizard, you run the Siebel Upgrade Wizard. The Siebel Upgrade Wizard opens a driver file containing the steps for the upgrade and executes these steps.
To upgrade a development environment, production test environment, or production environment, you must run the Database Configuration Wizard (and Siebel Upgrade Wizard) several times, as shown in the following table.
Table Database Configuration Wizard Modes
| Upgrade Step | Select This Environment Type | Select This Upgrade Option(s) |
|---|---|---|
| Development environment upgrep | Development |
upgrep: zSeries Staging of Files for Upgrade |
| Development environmentupgrep | Development |
upgrep: zSeries Seed/Repository Upgrade |
| Development environment upgphys | Development |
upgphys |
| Production test environment prepare for production (7.5.3 Upgrades only) | Production |
Prepare for Production Upgrade |
| Production test environmentupgrep + upgphys | Production |
upgrep + upgphys: zSeries Staging of Files for Upgrade |
| Production test environmentupgrep + upgphys | Production |
upgrep + upgphys: zSeries Seed/Repository Upgrade |
| Production environmentupgrep + upgphys
Note: If you have completed a production test upgrade and have tuned the SQL and JCL upgrade files on the z/OS host, you can use these files to perform the target database upgrade in the production environment. In this case, you do not have to run this upgrade step.
|
Production |
upgrep + upgphys: zSeries Staging of Files for Upgrade |
| Production environmentupgrep + upgphys | Production |
upgrep + upgphys: zSeries Seed/Repository Upgrade |
The following figure shows how the Database Configuration Wizard (and Siebel Upgrade Wizard) work together with the Siebel Tools repository merge to upgrade your environments.
How the Upgrade Configuration File and SQL Files Are Created
When you run the Database Configuration Wizard, it does the following:
Collects configuration information.
Creates a master upgrade configuration file (UCF). This file maps the information you entered in the Database Configuration Wizard to environment variables. When the Siebel Upgrade Wizard is performing the steps in a driver file, it uses these variables to generate the command contained in each step.
Prompts you to start the Siebel Upgrade Wizard. The wizard forwards the information in the UCF file to an SQL generator that creates or populates SQL files on the midtier with the required commands to perform the upgrade. You then transfer these files to the z/OS host and apply them.
In some cases, you will have to modify the generated SQL files as required by Alerts, Bulletins, or Siebel Release Notes on My Oracle Support before you transfer the files to the z/OS host.
How to Locate Master Configuration Files
Master upgrade configuration files are stored in the following location:
Windows: DBSRVR_ROOT\DB2390\upgrade\Version
UNIX: $DBSRVR_ROOT/DB2390/upgrade/Version
where Version is the version from which you are upgrading
Master upgrade configuration files use the following naming convention:
master_UPGRADEOPTION_ENVIRONMENT_VERSION_MasterFileType.ucf
where:
-
UPGRADEOPTION is the upgrade process you are performing. This can be one of the following:
upgrep. Siebel database schema upgrade.upgphys. Custom database schema upgrade.upgrep. Siebel Database Upgrade (production).prepare_for_production_upgrade. Prepare for production upgrade; applies to 7.5.3 upgrades only.
ENVIRONMENT is the environment that you are upgrading. This can be one of the following:
dev. Development environment upgrades.prod. Production environment upgrades.
VERSION is the version from which you are upgrading. The following numbers are used for the Siebel version of the filename:
782
80
811
MasterFileType is the type of master file. This can be one of the following:
mf_m. Configuration files generated for the manual phase of the upgrep process (zSeries Staging of Files for Upgrade process).mf. Configuration files generated for the automatic phase of the upgrep process (zSeries Seed/Repository Upgrade process) and for the upgphys process.The automatic phases of the upgrade process are run after the manual phases are completed.
Example
If you are upgrading from Siebel CRM version 8.1.1, the UCF files generated from the development environment upgrade are as follows:
master_upgrep_dev_811_mf_m.ucf
master_upgrep_dev_811_mf.ucf
master_upgphys_dev_811_mf.ucf
The UCF file generated from the Prepare for Production Upgrade mode is as follows:
master_prepare_for_production_upgrade.ucf
About the Siebel Upgrade Wizard and Driver Files
Upgrades: All upgrades.
Environments: All environments.
The Upgrade Wizard generates the files required to perform the upgrade of the Siebel database on the z/OS host and also makes changes to the Siebel database directly. After the Siebel Upgrade Wizard starts, it executes this process:
Reads the upgrade configuration file (UCF) generated by the Database Configuration Wizard
Calls a driver
Passes the information in the UCF to the driver, which then passes UCF file information to, for instance:
the ddlimp utility, which executes ddl-type SQL commands
the dataimp utility, which executes data-related SQL commands
If ddlimp or dataimp (or any of the database utilities) encounter errors, they stop. When the errors have been corrected, you can launch the Siebel Upgrade Wizard, and the upgrade resumes from where it stopped.
The Siebel Upgrade Wizard pauses on four occasions during the upgrade file generation process. At each pause, you must transfer the files that the Upgrade Wizard has generated to the z/OS host and execute them before you resume the upgrade. Message text at each pause informs you of the tasks you must perform.
The files generated by the Upgrade Wizard are output by default to the DBSRVR_ROOT\DB2390\dboutput\upgrade directory (Windows) or DBSRVR_ROOT/DB2390/dboutput/upgrade directory (UNIX) or to the DDL Output Directory you specified when you ran the Database Configuration Wizard.
Driver Files
The Siebel Upgrade Wizard performs the upgrade by executing the commands and SQL scripts 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 Siebel Upgrade Wizard.
Driver files are provided for each of the major upgrade operations. Examples of development environment upgrade driver files are as follows:
driver_upgrep_dev_811_mf_m.ucf
driver_upgrep_dev_811_mf.ucf
driver_upgphys_dev_811_mf.ucf
Here is an excerpt from a driver file that controls a development environment upgrep from Siebel CRM version 8.1.1 to version Siebel Innovation Pack 2016 or later (driver_upgrep_dev_811_mf.ucf). The excerpt contains two steps:
[File Execute Entry 10] Type = FileExecute File Name = $SiebelRoot\bin\odbcsql Check Return Code = 1 Return Code Compliance = 0 16 Bit App = 0 Is Script = 0 Command Line = /s "$ODBCDataSource" /u $UserName /p $Password /separator / /a /c rem /q $DatabaseOwner /l $SiebelLogDir/upd_upgcomp.log $DbsrvrRoot/$DatabasePlatform/ upd_upgcomp.sql /v Number of 10 Second Wait Loops = 2000 Return Code = 0 Title = Update version component info Title Message Num = 0 Estimated Disk Space = 0 Backup Db = 0 Parallelizable Item = 0 Prompt User For Status = 0
[File Execute Entry 10] Type = FileExecute File Name = $SiebelRoot\bin\odbcsql Check Return Code = 1 Return Code Compliance = 0 16 Bit App = 0 Is Script = 0 Command Line = /a I /g $RepeatForLanguage /u $UserName /p $Password /c "$ODBCDataSource" /D $DatabaseOwner /M y /R "$AncestorRepName" /F $AncestorRepFile /l $SiebelLogDir/imprep_ps.log /z 1000 Number of 10 Second Wait Loops = 2000 Return Code = 0 Title = Import Common Ancestor Repository Title Message Num = 0 Estimated Disk Space = 0 Backup Db = 0Parallelizable Item = 0 Prompt User For Status = 0
How to Locate Upgrade Driver Files and SQL Scripts
Driver files are stored in the following location:
Windows: DBSRVR_ROOT\DB2390\UPGRADE\ VERSION
UNIX: DBSRVR_ROOT/DB2390/UPGRADE/ VERSION
where VERSION is the version from which you are upgrading, for example v8.1.1
For example, if you are upgrading from Siebel CRM 8.1.1, the driver files for the development environment upgrep are as follows:
driver_upgrep_dev_811_mf_m.ucf
driver_upgrep_dev_811_mf.ucf
Related Topic
About the Siebel Database Configuration Utilities and Database Configuration Wizard
Job Flow of a Production Database Upgrade
Upgrades: All upgrades.
Environments: Production environment only. Does not apply to production test environment.
This topic describes the major steps in a production database upgrade using the Database Configuration Wizard and Upgrade Wizard. This topic does not describe all the pre and postupgrade tasks you must complete for a production environment. See Process of Upgrading a Siebel Production Environment for a description of all the steps in upgrading a production environment.
The production environment upgrade job flow differs from a development environment upgrade job flow primarily in that a repository merge is not required. The repository (custrep.dat) and the logical schema (schema.ddl) are exported from the upgraded development environment and used in the production upgrade.
A production database upgrade job flow, as illustrated in the following figure, is largely the same as the job flow of the upgrep stage of a development database upgrade.
The main steps in the production upgrade illustrated in the previous figure are as follows:
Inputs to the Production Upgrade. The files required for the production upgrade are:
The storage control file (storage.ctl). This file specifies the storage layout of your upgraded database. Create and validate the storage.ctl before running a production upgrade.
The custrep.dat file (new customized repository) and the schema.ddl file (modified schema definition file). These files are generated during the development upgrade and must be copied to the appropriate upgrade directory before running a production upgrade.
Prepare for Production (7.5.3 Upgrades only): Run the Database Configuration Wizard on the midtier in Prepare for Production Upgrade mode.
Run upgrep + upgphys. Run the Database Configuration Wizard on the midtier:
Enter production environment information to create the production upgrade configuration file. Specify the following values:
Upgrade Option: Upgrade Siebel Database Schema (upgrep + upgphys)
Upgrade Process: zSeries Staging of Files for Upgrade
- Launch the Upgrade Wizard to generate the DDL files that will be used to build the staging database.
The Wizard generates the staging database schema files on the midtier and then stops (Pause #0).
Create the Staging Database. Transfer the staging DDL files from the midtier to the z/OS host and apply them. Create the staging database and prepare the z/OS host upgrade environment.
Generate Additive Schema Upgrade Files. Restart the Database Configuration Wizard on the midtier. The wizard generates files and then stops at Pause #1.
- Apply Pause #1 Files. The files generated by the Upgrade Wizard on the midtier up to pause #1 consist of JCL and SQL templates and REXX execs that are run on the z/OS host against the staging database. These jobs are used to perform preupgrade tasks for the staging database. Do the following:
FTP the files generated by the Upgrade Wizard from the midtier to the mainframe.
Receive the files, unpack the staging data sets into PDS format, and create JCL members to run the additive schema and PRET jobs against the staging database.
Apply additive schema changes to the staging database.
Run PRET jobs against the staging database.
Generate Nonadditive Schema Upgrade Files. Restart the Database Configuration Wizard on the midtier. The wizard generates files and then stops at Pause #2.
Apply Pause # 2 Files. The files generated by the Upgrade Wizard on the midtier up to pause #2 include nonadditive schema files, load control cards and JCL templates, and unload SQL and JCL templates. Use the files generated up to this point to perform the in-place upgrade of the staging database. Do the following:
FTP the files that have been generated from the midtier to the host.
Modify the load and unload data sets.
Run the unpack jobs to populate PDS members.
Customize the UNLOAD and LOAD jobs for target tables with CLOB columns.
Add jobcards and Siebel logging to the Load, Unload, and data migration jobs.
Apply the nonadditive schema changes to the staging database.
Create temporary tables and indexes for the data migration scripts.
Generate index rebuilds.
Generate the SCINDX Upgrade File. Restart the Database Configuration Wizard on the midtier. The wizard generates files and then stops at Pause #3.
Apply Pause # 3 Files. The SCINDX file generated at this point is used to rebuild indexes. Do the following:
FTP the SCINDX.SQL file from the midtier to the z/OS host.
Apply the SCINDX.SQL file to rebuild indexes.
This completes the file generation process
Perform Pre-Upgrade Tasks for the Target Database as follows:
On the z/OS host, build the JCL templates that will be used to perform the target database in-place upgrade by applying target database information to the JCL templates that were used to run the staging database in-place upgrade processes.
Create and load Siebel log tables.
(Optional) Apply additive schema changes.
Perform the In-Place Upgrade of the Target Database as follows:
Remove interface tables, triggers, and stored procedures from the database.
Run PRET jobs to prepare the target database for table creation during the upgrade.
Apply nonadditive schema changes to the target database.
Create, bind, and test the stored procedures.
Run the Data Migration jobs to migrate preexisting Siebel data to the current release.
There are optional data migration scripts for Household data and for Siebel Financial Services (FINS) applications.
Remove old indexes, create new indexes, and run index rebuild jobs.
Upgrade the Repository and Import Seed Data as follows:
Run the Database Configuration Wizard on the midtier.
Enter production environment information to create the production upgrade configuration file. Specify the following values:
Upgrade Option: Upgrade Siebel Database Schema (upgrep + upgphys)
Upgrade Process: zSeries Seed / Repository Upgrade
- Launch the Upgrade Wizard. The Upgrade Wizard automatically runs the remaining DML upgrade jobs from the midtier to perform a number of tasks, including the following:
Deletes the old license key.
Verifies the repository name and imports the New Customer Repository from the upgraded development environment.
Upgrades seed data to the new version.
The production database upgrade is now completed.
Key Members in the DSNHLQ.SIEBEL.EXEC
Members in the DSNHLQ.SIEBEL.EXEC contain useful information that you can refer to when performing your development and production upgrade. These key members are listed in the following table.
Table Key Members in the DSNHLQ.SIEBEL.EXEC
| Member Name | Description |
|---|---|
@JOBPRFX |
Shows details of the job prefixes chosen for the upgrade. |
@LASTJOB |
Lists the job name of the last job for each step of the upgrade, for example:
|
@STGTAR |
Lists details of the staging and target environments. |
@TBOSTG |
Provides staging tableowner details. |
@TBOTAR |
Provides target tableowner details. |
@UPGPATH |
Lists the upgrade path and the upgrade status, that is, the last step executed, for example: PAUSE=4 STEP=98- TARGET UPGISS DATA MIGRATION COMPLETE - UPGISS |
@UPGFLOW |
Contains details of all the steps in the upgrade. |
@UPGTYPE |
Shows the type of upgrade being run, for example, SIA 7.8.2 |
About the JCL Upgrade Jobs
This topic provides information about the JCL jobs you run to perform the upgrade on the z/OS host.
About Job Cards
The DSNHLQ.SIEBEL.EXEC data set contains base job cards for all the upgrade jobs. The upgrade process uses these job cards as a base for all jobs of a particular type, and then generates an individual job card for each job based on the information in the base card and in the @JOBPREFX member of the DSNHLQ.SIEBEL.EXEC data set.
For example, the base job card for PRESCHM jobs is JCPRES. An individual job card is created for each PRESCHM job based on information in both of the following:
DSNHLQ.SIEBEL.EXEC(@JOBPREFX)provides the job prefixDSNHLQ.SIEBEL.EXEC(JCPRES)provides the base job card
Once job cards have been generated, changing the information in the @JOBPREFX member does not cause job card details to change.
Job Dependencies
Some JCL jobs, for example, some Data Migration jobs, have dependencies on other jobs. These jobs are submitted in a specific order, with subsequent jobs only being submitted when the current job has completed successfully. The @DEPFLOW member in the relevant JCL data set shows the order in which the jobs are to be submitted, for example, see DSNHLQ.SIEBEL.PRESCHM.JCL(@DEPFLOW) for information about the submission sequence for PRESCHM jobs.
Load and Unload Jobs
Load and Unload job procedures are located in the DSNHLQ.SIEBEL.PROC data set.
About the Override File
Upgrades: All upgrades.
Environments: Development environment only.
The override.inp file allows you to override your existing database storage layout when you upgrade to the current release of Siebel CRM. When you create the storage control file to use in the upgrade, by adding the names of tables to the override.inp file, you indicate that you do not want to preserve the existing definitions for these tables. For additional information, see Extracting the Storage Control File.
Since Siebel CRM version 7.7, the Siebel database schema structure has the following characteristics:
One table in each table space
One table space in each database
This layout is referred to as the 1:1:1 model. See Planning Changes to the Physical Layout of the Schema for further information.
If you are upgrading from a pre 7.7 release of Siebel Business Applications, you might want to switch to the 1:1:1 model from your existing database schema structure because it is more efficient. There are three options available when upgrading to the current release:
Preserve the existing model of multiple tables for each table space and only build new tables with the 1:1:1 model.
To use this option, extract a storage control file and merge it with an existing template. All existing definitions are preserved and new tables are built according to the definitions supplied in the template storage control file.
Preserve the existing model for most tables but indicate that specific tables, are to use the 1:1:1 model by adding the table names to the override.inp file. For example, you might want to move populated tables to the 1:1:1 model. By default, the override.inp file has two table entries:
S_DOCK_TXN_LOGS_SERVICE_SCRPT
The existing definition for these two tables is not preserved during the upgrade. Therefore, these two tables can be built using the new model as specified in the template.
Move all tables from the current model to the 1:1:1 model.
To use this option, do not use the extract and merge process to create the storage control file. Instead, use the preconfigured storage control file. In the preconfigured storage control file, all tables are created using the 1:1:1 model. Therefore, each table is created in its own database or table space.
The use of the preconfigured storage control file allows you to use the 1:1:1 model for all tables other than obsolete tables and customer extended tables. The preconfigured storage control file does not apply to obsolete or customer extended tables so there are no entries for them. You cannot put these into the override.inp file since there is nothing to override and the tables are not in the storage control file. In this case, the existing schema is preserved.
The table spaces are not cleaned up unless they are empty. Some of the obsolete and customer extended tables are still in those table spaces so the upgrade process cannot just do a general cleanup.