Postupgrade Tasks for the Siebel Database

This chapter provides tasks to be completed within the Siebel database, and the Siebel File System following a successful upgrade and repository merge. This chapter includes the following topics:

Reapplying Schema Customizations in the Siebel Database

Environments: Development environment only.

In the current release, tables are obsolete or have been replaced by new tables. If you added extension columns or foreign key (FK) columns to tables that are obsolete in the current release, then you must reapply these changes to the new tables.

Reviewing Obsolete Tables

The upgrade process generates a report that you can review for information about tables that are either obsolete. This report, xtndobstbl.txt, lists the following:

Custom columns in obsolete tables
Custom foreign key columns pointing to obsolete tables
Siebel Enterprise Integration Manager mappings for custom foreign key columns to access-control related obsolete tables
Workflow columns by custom foreign key to obsolete tables
Customer denormalized columns on obsolete tables
Obsolete tables in the current release

Each obsolete table is listed with one of three codes:

Not Used. These tables are not used in the current release, but you can continue to use them. These tables are supported as is (for instance, with docking or Siebel Enterprise Integration Manager).
EOL (end of life). These tables are not used in the current release, and they are not supported in future releases.
Inactive. These tables have been discontinued, and are not supported in the current release. You must move extension columns and foreign key columns that reside on inactive tables to alternate tables.

If no tables are listed in xtndobstbl.txt, then no action is required.

If this file lists any tables, then reapply the custom extensions and foreign key columns to those tables in the current release using Siebel Tools. See Configuring Siebel Business Applications.

Migrating Address Data After a Direct SEA to SIA Upgrade

Upgrades from: SEA repository to SIA repository.

Platforms: Windows and UNIX only.

See the following table for a list of schema differences between the SEA and SIA repository along with recommended data migration approaches.

Schema Differences Between SEA and SIA Repositories

The following table displays schema differences between the SEA repository and the SIA repository.

Table Schema Differences Between SEA and SIA Repositories

SEA Repository	SIA Repository	SEA to SIA Migration Approach
Account Addresses are stored in the S_ADDR_ORG table. Other addresses are stored in the S_ADDR_PER table.	The S_ADDR_ORG table is obsolete. Address data is stored in the S_ADDR_PER table.	Data is converted automatically through upgrade scripts.
Organization Relationships are stored in the S_ORG_REL table. Other party relationships are stored in the S_PARTY_REL table.	All party relationships, including organizations, are stored in S_PARTY_REL. The S_ORG_REL table is obsolete.	Manual data migration required. For instructions see 476479.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 312.
Contact relationships are stored in the S_CONTACT_REL table. Other party relationships are stored in the S_PARTY_REL table.	All party relationships, including organizations, are stored in the S_PARTY_REL table. The S_CONTACT_REL table is obsolete.	Manual data migration required. For instructions see 476479.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 312.
Household relationships are stored in the S_PER_ORG_UNIT table.	Household relationships are stored in the S_PARTY_PER table.	Manual data migration required. For instructions see 476479.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 312.

Validating Dock Objects and Rule Definitions in the Siebel Database

Environments: Development, production test, production.

Platforms: Windows, UNIX, IBM z/OS.

Changes to visibility rules and dock objects require the assistance of Oracle Advanced Customer Services.

If you deploy Siebel Business Applications to mobile users with local databases, then you can run the DICTUTL utility to verify that all dock objects and rule definitions are correct. Dock objects allow mobile users to synchronize their local databases with the Siebel Server. Rules determine which data users synchronize. For more information about dock objects and rules, see Siebel Tools Online Help and Siebel Remote and Replication Manager Administration Guide.

To verify that all dock object and rule definitions are correct

Navigate to the following directory:
Windows: SIEBEL_ROOT\bin

UNIX: $SIEBEL_ROOT/bin

Type the following command using the parameters specified in the following table:

dictutl /C ODBC_DATASOURCE /U USERNAME /P PASSWORD /D TABLEOWNER /N "REPOSITORY_NAME" /A y 2> logfile.log

Table Command Line Flags for DICTUTL

Flag	Parameter	Description	Required
/C	ODBC_DATASOURCE	ODBC datasource name	Yes
/U	USERNAME	User name to log in to database	Yes
/P	PASSWORD	User password to log in to database	Yes
/D	TABLEOWNER	User name of tableowner	Yes
/N	"REPOSITORY_NAME"	Name of repository for dictionary (the parameter must be bounded within double quotes)	Yes
/A	y or n	Enter the y parameter to ignore the dictionary cache. Enter n if you do not want to ignore the dictionary cache.	Yes

Review the LOGFILE.log file:
1. Open the file in Microsoft Excel. If the file is too large for Excel to display the whole file, then break the file into two files and examine each separately.
2. Query for the word error.
3. If you locate errors, then write down the exact error text.
4. Query for the word syntax.
5. If you locate syntax errors, then write down the exact error text.
6. To determine whether the errors must be resolved, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
  The following types of entries indicate that no errors were found:
  - Errors: 0
  - Syntax OK

Verifying an Upgraded Oracle Database After a Siebel Upgrade

Environments: Development, production test, production.

Databases: Oracle only.

You can upgrade your RDBMS before or after upgrading to the current Siebel release.

If you upgrade your Oracle RDBMS after upgrading to the current Siebel release, then you must run the Siebel ddlimp utility to verify the schema layout of the upgraded database.

Note: The upgphys process might recreate descending (DESC) indexes as ascending (ASC) indexes. To recreate descending indexes, use the /9 option while running ddlimp.

This also converts the Siebel database to character-based length for char and varchar data. For additional information about the following procedure, see 477966.1 (Article ID) My Oracle Support.

To verify the upgraded Oracle Database

On the Siebel Server where the Siebel Database Server files are installed, navigate to the following location:
Windows: SIEBEL_ROOT\bin
UNIX: $SIEBEL_ROOT/bin
Run the following command:
```
ddlimp /u TableOwner /p TablePassword /c "ODBCDataSource" /f DBSRVR_ROOT/DatabasePlatform/schema.ddl /t y /i n /e n /B TableSpace /X IndexSpace /G SSE_ROLE
/R Y /l SiebelLogDir/ddlctl_verify_RDBMS.log
```
where:
- TableOwner is the Siebel table owner name, also called the schema qualifier name.
- TablePassword is the Siebel table owner password.
- ODBCDataSource is the ODBC name for connecting to the database. Enclose the name in quotes.
- DBSRVR_ROOT is the absolute path to the Siebel Database Server installation directory.
- DatabasePlatform is the Siebel Database Server directory for the Oracle Database.
- Tablespace is the Oracle tablespace name for the Siebel database.
- IndexSpace is the Oracle index space name for Siebel database.
- SiebelLogdir is the path to the directory where you want the output log placed (log output directory).
After the command completes, review the output log files for errors. If the log indicates there are errors, 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.

Setting Oracle Database Parameters After a Siebel Upgrade

Environments: Development, production test, production.

Databases: Oracle only.

After the Siebel database upgrade is complete, set the following parameters in init.ora:

optimizer_index_cost_adj. Set this parameter to 1.
Collecting statistics. To optimize SQL performance, use the PL/SQL package dbms_stats to manage statistics gathering. For additional information on optimizer settings, see 781927.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 582.
For a full list of recommended settings for your postupgrade production environment, see the chapter on configuring the RDBMS in Siebel Installation Guide.

15Postupgrade Tasks for the Siebel Database