Preparing for Siebel Database Upgrade

This chapter provides initial preparatory information for the Siebel database upgrade. This chapter includes the following topics:

Verifying Siebel Database Connectivity

Environments: Development, production test, production.

From the production test environment, you must be able to make ODBC connections to both the Siebel database in the development environment and the Siebel database in the production environment. Verify that you can define these ODBC connections in the production test environment.

If you cannot connect to these databases from the production test environment, then create a service request (SR) on My Oracle Support, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

In the production environment, you do not have to define an ODBC connection to the development environment Siebel database or the production test environment Siebel database.

Preparing Siebel Tables and Views for Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

To prepare tables and views for upgrade

Drop temporary tables and non-Siebel tables.
If the upgrade process detects a column with a datatype not acceptable for Siebel tables, then the upgrade will fail.
Disable customized triggers.
You must re-create them after the upgrade.
Drop defined database views on Siebel tables.
You must re-create them after the upgrade.
Export interface table data that you want to preserve.
Interface tables are dropped and then re-created during upgrade. You can import the data after the upgrade.

Preparing Siebel Custom Indexes for Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

Consider the following guidelines when preparing custom indexes for upgrade:

Custom indexes against extension columns on obsolete tables. If you have created custom indexes that use extension columns on obsolete tables, then you must migrate the data to new extension columns before upgrading the Siebel database. For assistance, create a service request (SR) on My Oracle Support, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
Custom indexes that were not defined through Siebel Tools. Custom indexes created without using Siebel Tools are not included in the schema definition in the Siebel Repository. These indexes are dropped during the database upgrade. To preserve these indexes, add them to the Siebel Repository using Siebel Tools.
Custom indexes on interface tables. Custom indexes on interface tables are not re-created during the upgrade. You must re-create them after the upgrade is complete.
Custom indexes on base tables. The upgrade automatically removes and re-creates custom indexes on base tables.
Custom indexes might need to be changed to reflect schema changes. Reevaluate custom indexes for applicability in the new release. They might no longer be needed due to schema changes in the new release.

For more information about custom indexes, see Configuring Siebel Business Applications. For information on schema changes in a release, see Siebel Data Model Reference.

Exporting Siebel Interface Table Data

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

During the upgrade process, your interface tables are dropped and then re-created. To retain data in your interface tables, use the appropriate tools for your RDBMS to export data before the upgrade and then import the data after you have completed the upgrade.

During the upgrade, all custom indexes on interface tables are dropped from both logical and physical schema.

Archiving Unneeded Siebel Repositories

Environments: Development, production test, production.

Perform this task before running the Database Configuration Utilities in upgrep mode for the first time in an environment.

The upgrep mode scripts expect only the Siebel Repository to be present. If you have multiple repositories, then you must export them to archive files and then delete them from the database.

Because the upgrade changes the schema of the database, in most cases you cannot import these archived repositories into the upgraded database. If you want to access the archived repositories, then you must import them into a database that has the same schema as the one from which they were exported.

To archive unneeded repositories

Export all repositories.
Place exported repository files in a safe location.
In the Siebel database, delete all repositories except the Siebel Repository.

For information on exporting and deleting repositories, see Using Siebel Tools.

Preserving Siebel Dock Objects and Visibility Rules

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

Modified visibility rules are dropped during a development environment upgrade. Manually record any changes to dock object visibility rules, so you can evaluate whether you must reapply the changes after the upgrade is complete.

Dock objects and visibility rules created by using Docking Wizard are preserved unless they become invalid after the upgrade. Manually record any changes that you made through the Docking Wizard so that you can evaluate whether you must reapply the changes after the upgrade is complete.

Changing the definition of dock objects requires the assistance of Oracle Advanced Customer Services. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

Securing AIX Memory Allocation Segment Space for the Siebel Database

Environments: Development, production test, production.

Databases: All databases.(Exception: this topic does not apply to Microsoft SQL Server.)

Platforms: UNIX only.

Before you run an upgrade on AIX, set the following environment variable on the AIX computer that you are using for the upgrade:

setenv LDR_CNTRL LOADPUBLIC@MAXDATA=0x60000000

This will prevent a shortage of memory allocation segment space that might occur on the computer where both the Siebel Database Server and Siebel Server are installed. After a successful upgrade, reset this parameter to the original value.

Preparing for a Multilingual Upgrade

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

As of Siebel CRM 8.0, the upgrade process upgrades both the primary (base) language and all deployed languages.

The Database Configuration Utilities validate deployed languages by comparing the status of the language packs installed on the Siebel File System with the language IDs of records in the S_LST_OF_VAL table. If there are language IDs in S_LST_OF_VAL but no corresponding deployed language on the Siebel File System, then the validation fails and you cannot continue the upgrade.

Before doing an upgrep, use Siebel Tools to remove or deactivate any records in S_LST_OF_VAL for undeployed languages.

To prepare for a multilingual upgrade

Make a list of your deployed languages.
A deployed language is one where you have installed the language pack, imported the user interface strings into the Siebel Repository, imported the seed data into the database, activated the seed data records added to S_LST_OF_VAL, and configured the records for MLOVs.
In Siebel Tools, navigate to Screens, System Administration, and then List of Values.
Locate the Language Name field, and verify that no languages appear that are not currently deployed.
Even if you do not have English installed, then some records will have the Language Name value equal English-American. You can ignore these system records.
For records where you do not have the corresponding language pack deployed, investigate why these records are present and take one of the following actions:
- If the record is not needed, delete it.
- If you are not sure whether the record is needed, remove the check-mark from the Active field. This deactivates the record and prevents it from being included in the validation check performed by the Database Configuration Utilities.
  
  Caution: Do not deactivate or delete records where the Language Name equals English-American, even if you do not have English-American deployed. These records are needed by the system. The validation process ignores these records.