Upgrade Guide for DB2 UDB for z/OS > How the Upgrade Works >

About the Repository Merge


Upgrades: All upgrades.

Environments: Development environment only.

The Siebel Repository consists of records stored in a group of tables in the Siebel Database. There are two types of records:

  • Object definitions used to create Siebel 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.

Think of the Siebel Repository as these two types of records, rather than the tables that store the records. Repository records include a repository ID that lists the ID of the repository to which each record belongs. The repository ID forms part of the user index for these records and allows several repositories to be stored in the same set of tables.

List-Applets in Siebel Tools display the information in the repository records.

Upgrading the Siebel Database adds new records to the tables that store the repository records. These new records make up three repositories, as shown in Table 11.

Table 11. Development Database Repositories
Repository Name
Siebel Tools Name
Description
Added During Upgrade?

Prior V7.x Siebel Repository

Prior Standard

The standard Siebel Repository for your installed release (the one you are upgrading from).

Yes

Prior Customer Repository

Prior Customized

This is your current Siebel Repository. It contains any changes you have made. You renamed it Prior Customer Repository before doing the initial database upgrade.

No

New Siebel Repository

New Standard

The Siebel Repository for the Siebel release to which you are upgrading. This repository defines the new Siebel release.

Yes

New Customer Repository

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.

Yes

How the Merge Works When You Are Upgrading from Siebel 7.x

The repository merge does the following things:

  • Identifies customizations you have made in the Prior Customer Repository and uses decision criteria to merge them into the New Customer Repository
  • Identifies logical schema changes you have made in the Prior Customer Repository and tries to include them in the logical schema in the New Customer Repository
  • Upgrades both the base repository and all locales
  • Writes a log describing actions, conflicts, and errors
  • After the merge is complete, launches postmerge utilities that perform further upgrades to layout objects such as Web templates and controls

The merge process makes numerous record comparisons and inserts. As a result, the merge is resource-intensive and typically takes twelve to eighteen hours to complete. The time required varies depending on the complexity of customizations and amount of computing power.

How the Merge Works When You Are Upgrading from Siebel 6.2.1 FINS

The repository merge does the following things:

  • Identifies customizations you have made in the Prior Customer Repository and uses decision criteria to merge them into the New Customer Repository
  • Identifies logical schema changes you have made in the Prior Customer Repository and tries to include them in the logical schema in the New Customer Repository
  • Upgrades both the base repository and all locales
  • Writes a log describing actions, conflicts, and errors
  • After the merge is complete, launches postmerge utilities that perform further upgrades to layout objects such as Web templates and controls

The merge process makes numerous record comparisons and inserts. As a result, the merge is resource-intensive and typically takes five to seven hours to complete. The time required varies depending on the complexity of customizations and amount of computing power.

How the Merge Handles Your Customizations

The repository merge handles customizations in the Prior Customer Repository as follows:

  • If an object has not changed in the New Siebel Repository but was customized in the Prior Customer Repository, the customization is added to the object in the New Customer Repository.
  • If a new object was created in the Prior Customer Repository, it is added to the New Customer Repository.
  • If an object is present in the Prior Standard Repository and Prior Customer Repository, but is not present in the New Siebel Repository, the object is obsolete and is not used in the New Customer Repository.
  • If an object attribute has changed in the New Siebel Repository and also has changed in the Prior Customer Repository, a conflict occurs. An alternative definition for conflicts is that the attribute value is different in all three repositories: Prior Standard, Prior Customer, and New Siebel.

    The merge resolves about 90% of conflicts by using the object attribute as it is defined in the New Siebel Repository.

  • If an object was deleted from the Prior Customer Repository, it is added to the New Customer Repository. The following objects are exceptions. If they were deleted from the Prior Customer Repository, they are not added to the New Customer Repository:
    • Control
    • List Column
    • Page Tab
    • Chart
    • Applet Web Template Item
    • View Web Template Item
Upgrade Guide for DB2 UDB for z/OS