Performing the Siebel Repository Merge

This chapter lists the steps involved in performing a repository merge during a development environment upgrade which are specific to DB2 for z/OS upgrades. You also have to perform the relevant tasks in the chapter in Siebel Database Upgrade Guide that describes how to perform the Siebel Repository merge. This chapter includes the following topics:

About Backing Up the New Customer Repository or Database Schema

Upgrades: All upgrades.

Environments: Development environment only.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

The process of merging repositories to create the final customized repository used in the upgrade is time-intensive and resource-intensive. As a result, a merge might sometimes fail because of environmental factors, for example, space constraints. When this happens, the merge process continues, even if there is a fatal database error, and the errors might not be detected for some time.

If the merge fails, you must restore the database environment to its premerge state and run the merge again. There are two methods you can use to preserve the premerge environment so that you can restart the merge again if necessary:

Back up the entire database. Prior to the merge, back up the entire database, then, if the merge fails, you can restore the database to its premerge state and rerun the merge operation. This is the recommended method of recovering from a failed merge.
Export the New Customer Repository. Prior to the merge, export the New Customer Repository to create a backup copy; this preserves existing workflows. If the merge fails, you can delete the failed repository, then import the backup copy of the New Customer Repository. If you use this method of recovering from a failed merge, you also have to truncate the following merge log tables: S_MERGE_LOG, S_MERGE_LOG_OBJ, and S_MERGE_LOG_ATTR. See Using Siebel Tools for information on exporting and importing repositories using the Database Configuration Wizard.

About Reorganizing Tables Before the Repository Merge

Upgrades: All upgrades.

Environments: Development environment only.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

During the repository merge process, objects from four separate repositories are read and compared. Because this is a memory-intensive process, it is recommended that you execute the REORG utility on certain tables before performing the repository merge to improve performance.

Note: Before executing the REORG utility, delete extra repositories from the database using Siebel Tools. Running the repository merge on a database with more than the four repositories which are required for the repository merge degrades repository merge performance. Before deleting extra repositories, make backups. Deletion of extra repositories can take a few hours.

The following tables receive a large number of inserts during each repository import; running REORGs on each of the following table’s ROW_ID column will significantly increase the performance of the merge:

S_APPLET
S_APPLET_INTL
S_APPLET_METH_MI
S_APPL_WEB_TMPL
S_APPL_WTMPL_IT
S_BOCOMP
S_BUSCOMP_UPROP
S_COLUMN
S_CONTROL
S_CONTROL_INTL
S_CONTROL_UPROP
S_DDOWN_OBJECT
S_EIM_FK_MAPCOL
S_FIELD
S_INDEX
S_INDEX_COLUMN
S_INTFLD_UPROP
S_INT_CKEY_FLD
S_INT_COMP
S_INT_FIELD
S_JOIN
S_JOIN_SPEC
S_LIST
S_LIST_COL_INTL
S_LIST_COLUMN
S_PICKMAP
S_SCREEN_VIEW
S_UK_ATTJOIN
S_USER_KEY_ATT
S_VIEW_WTMPL_IT
S_EIM_ATT_MAP

Note: After you reorganize tables, it is recommended that you run the RUNSTATS utility to update DB2 catalog statistics.

Performing a Siebel Repository Merge

Upgrades: All upgrades.

Environments: Development environment only.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

During the repository merge, objects from the Prior Siebel Repository, Prior Customer Repository, and New Siebel Repository are compared by name 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. There are three basic categories of object differences:

New
Deleted
Modified

The repository merge executes the following processing steps to identify object differences:

New or deleted objects. Identify objects that the customer has added by comparing their names in the Prior Customer Repository with the Prior Siebel Repository.

All new customer objects are carried over from the Prior Customer Repository to the New Customer Repository. The repository merge typically avoids deletion of objects. Most of the objects that are deleted in the Prior Customer Repository reappear after the merge. The merge does this to avoid accidental deletion of objects which might be required. It does, however, allow deletion of specific types of objects. Such objects are deleted from the New Customer Repository during the merge.

Objects of the following types are deleted from the New Customer Repository:

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

Objects with altered attributes. Identifies objects that exist in both the Prior Customer Repository and the New Siebel Repository, and compares the attributes of each object to determine if they have been modified. Attribute comparisons are of interest only for those attributes which were changed by the customer.
If an object attribute was altered in the Prior Customer Repository, but not in the New Siebel Repository, the customer’s attribute value is merged into the New Customer Repository.
A conflict occurs, however, if an object attribute was altered in both the Prior Customer Repository and the New Siebel Repository, in which case the values in all three repositories would be different. In this event, the repository merge process uses the setting of the object attribute’s StandardWins flag to determine how to resolve the conflict. If this is set to Y, the attribute value from the New Siebel Repository is used; if this is set to N, the attribute value from the Prior Customer Repository is used. Conflict resolutions can be overridden for each object attribute in the New Customer Repository. For additional information, see the chapter about performing the Siebel Repository merge in Siebel Database Upgrade Guide that describes Siebel repository object property conflicts and how to merge the repository.

About the Repository Merge

The configuration utility that you ran while upgrading your development environment loaded two standard repositories. You must now use Siebel Tools to merge your existing custom configuration into one of these new repositories, creating a custom configuration that includes all of your previous configuration changes.

The four repositories that currently exist in your development database are listed in the following table.

Table Repositories in the Development Database

Repository Name	Description
Prior Siebel Repository	Standard repository, depending on the version from which you are upgrading.
Prior Customer Repository	Customized repository, depending on the version from which you are upgrading.
New Siebel Repository	Newly loaded standard repository.
New Customer Repository	Newly loaded repository into which your custom configuration is merged.

Follow the guidelines provided in Optimizing Performance of the Repository Merge and Optimizing Foreground Performance of the Repository Merge to improve performance of the repository merge.

The repository merge is a memory-intensive process that fails if insufficient memory is available on the Siebel Tools workstation. Before beginning a repository merge, make sure that the following preparations have been completed on the developer workstation. Make sure that the developer workstation on which Siebel Tools is running has been upgraded to the newest available version.

The method you use to perform a repository merge depends on whether your database uses an ASCII or EBCDIC encoding scheme:

For ASCII databases, perform the procedure, Merging the Repositories for an ASCII Database.
For EBCDIC databases, perform the procedure, Merging Repositories for an EBCDIC Database.

Optimizing Performance of the Repository Merge

There are several ways in which you can reduce the time required to complete the repository merge.

Optimize the computer on which you are running the repository merge as follows:
- Use a workstation with a minimum of 512 megabytes (MB) of RAM.
- Allocate at least 2 GB of virtual memory, and a 2 GB page file. If the amount of virtual memory on the computer on which you are running the repository merge is too low, performance degrades significantly.
- If necessary, increase the swap space, using the Control Panel System applet, and then restart the development workstation before proceeding.
- Allocate plenty of 32K work space for the Sort utility.
- Make sure you have a high-performing network connection.
  
  Note: A slow network connection significantly increases the time required for the repository merge.
- Close all other applications.
- Close all Siebel services.
Defragment the disk. Fragmentation significantly affects system performance.
On the workstation, check that the environment variable SIEBEL_LOG_EVENTS is set to zero. To check, enter the following command at the MS DOS prompt:
```
echo %SIEBEL_LOG_EVENTS% 
```
If the command returns a value other than zero, you must set the SIEBEL_LOG_EVENTS variable to zero by performing the following steps:
- Close Siebel Tools and any other Siebel client applications.
- From the Start menu, select Settings, Control Panel, System, and then Environment.
- In the Environment dialog box, in the System Variables box, select SIEBEL_LOG_EVENTS. Enter 0 in the Value box, and click Set. Click OK.
- Relaunch Siebel Tools. The new setting becomes active.
  
  Note: The steps required to set this variable can vary depending on the operating system you are using.
Optimize your database, because database performance can cause the repository merge to slow down considerably. Check the following:
- Make sure that temporary table space has enough space allocated.
- Make sure the database has enough space allocated.
- Make sure that the topmost logging applet in tools has no extra rows from previous repository merge runs when starting the repository merge.
- Make sure that the database is not loaded with users when the repository merge is run; no other users must be connected.

Optimizing Foreground Performance of the Repository Merge

To improve the foreground performance of the repository merge, use the following procedure.

To increase the foreground performance of the repository merge

From the Start menu, choose Control Panel, and then the System menu option.
Select the Advanced tab.
Select the Performance Options button.
In the Application Response box, click the Applications radio button and click OK.
While the repository merge process is running, click on the title bar of the Siebel Tools application to verify that the Siebel Tools application is the foreground application on the computer.

Note: After the repository merge process has finished, set the Performance setting back to its former value.

Merging the Repositories for an ASCII Database

Perform the following task to merge the development repositories for an ASCII database.

Caution: This procedure does not support EBCDIC databases. If you are upgrading a DB2 database that uses an EBCDIC encoding scheme, see Merging Repositories for an EBCDIC Database.

To merge the repository for an ASCII database

Log in to Siebel Tools.
From the Tools menu, choose View, Options, and then the Language Settings menu option.
Verify that the language mode setting is set as desired.
Choose File, and then Open Repository to open the Prior Customer Repository.

Note: Open the Prior Customer Repository, not another repository. Later steps in the repository merge process fail if you open the wrong repository.
Choose Tools, Upgrade, and then Upgrade Application.
The Merge Repositories dialog box appears.
The Merge Repositories dialog box provides the following options:
- Merge. This button merges the repositories you specify to produce a New Customer Repository.
- Cancel. This button cancels the repository merge and exits the Merge Repositories dialog box.
- Advanced. This button opens the Merge Options dialog box described in Step 8.

In the Merge Repositories dialog box, choose the appropriate repository name from each picklist, using the repository names listed in the following table.

Drop–Down List Item	Value to Choose
Prior Standard Repository	Prior 7.x or 8.0 Siebel Repository, as appropriate for the version from which you are upgrading
Prior Customized Repository	Prior Customer Repository
New Standard Repository	New Siebel Repository
New Customized Repository	New Customer Repository

Review the settings in the Merge Repositories dialog box, then click Advanced.
The Merge Options dialog box appears.
In the Merge Options dialog box, click the following check boxes as appropriate:
- Abort merge if more than n errors occur.
  This option aborts the repository merge automatically if more than a designated number of errors occur.
  
  Note: The typical repository merge generates many benign errors. If you select this option, set the number of errors to a large value. This will help prevent the repository merge from aborting due to benign errors.
- Incorporate Custom Layout.
  Activate this option to help preserve field and button placement on prior custom or modified forms, views, and screens. Select a prior release and style for label placement.
  The Prior Release is the release you are upgrading from. The Placement of Labels controls where labels are placed in forms. As of Siebel CRM version 7.7, label alignment of fields changed. Label vertical alignment changed from top (where labels align to the upper part of a cell) to middle (where labels align to the centre of a cell), font weight changed from bold to normal, and text alignment changed from left (where text aligns to the near margin) to right (where text aligns to the far margin). Select Labels on Top and Labels on Left to preserve the look and feel of releases prior to Siebel CRM version 7.7.
To continue, click OK.
Click Merge on the Merge Repositories dialog box.
The Upgrade Check List dialog box appears.
In the Upgrade Check List dialog box, you must confirm that your environment meets the requirements for a successful repository merge. Review each requirement and select the check box if your configuration meets or exceeds the requirement.
To continue, click Continue. The merge process begins.
The repository merge process can take eight hours or more to complete. Timings can vary greatly depending on the kind of computer, the hardware configuration, virtual memory allocation, the use of the upgrade inheritance feature, and the level of customizations in the customer repository, such as new records or changed attributes. In addition to merging the base repository, all locales are merged. Additional time must be planned for each language, including the base language.
Customizations are moved to the New Customer Repository, which results in a large number of database operations (inserts and updates). For each of these operations, logging records are created, and these log records also affect performance. If the repository is large, or the database setup is not optimal, this might take much longer.
After the merge completes, a dialog displays requesting that you make a backup of the New Customer Repository. Back up the New Customer Repository, then click OK in the dialog box.

To determine if the repository merge was successful, review the merge log files. You can then run the Siebel Postmerge Utilities. For information on both of these tasks, see the chapter in Siebel Database Upgrade Guide that describes how to perform a Siebel Repository merge.

Merging Repositories for an EBCDIC Database

Perform the following task to complete a repository merge for an EBCDIC database.

To perform a repository merge for an EBCDIC database

Use the Import/Export Repository option in the Database Configuration Wizard to export the following repositories from your prior EBCDIC database:
- Prior Standard Repository
- Prior Customized Repository
- New Standard Repository
- New Customer Repository
See Using Siebel Tools for information on exporting repositories using the Database Configuration Wizard.
Prepare a new Siebel CRM ASCII database on which you will perform the repository merge. In the storage control file, the following tables must be defined with CLOBS set to Yes:
- S_SCHMST_DBSCPT
- S_BITMAP_DATA
- S_SERVICE_SCRPT
Use the Import/Export Repository option in the Database Configuration Wizard to import the repositories exported from the EBCDIC database in step 1 into the ASCII database prepared in step 2.

Note: Make sure you select the Import Custom Repository option to import all languages used.
See Using Siebel Tools for information on importing repositories using the Database Configuration Wizard.
Launch Siebel Tools against the ASCII database.
Run the repository merge using the procedure, Merging the Repositories for an ASCII Database.
Generate Siebel EIM temporary columns. This task is described in the chapter in Siebel Database Upgrade Guide that describes how to perform the Siebel Repository merge.
Review the repository merge results to determine if the merge was successful. This task is described in the chapter in Siebel Database Upgrade Guide that describes how to perform the Siebel Repository merge. Verify that the repository merge was successful, and that all reported validation messages are either acceptable or fixed.
Use the Database Configuration Wizard to export the merged repository (the New Customer Repository) from the ASCII database.
Rename the existing New Customer Repository in the EBCDIC database.
Use the Database Configuration Wizard to import the merged New Customer Repository back into the EBCDIC database.
From the Tools application, pointing to the ASCII database, click Repository in the Object Explorer and copy the value against the Comments column for the New Customer Repository.

Connect to the EBCDIC database through the DB2 command line and update the Comments column with the copied value on the table S_REPOSITORY for the following value:

name= "New Customer Repository"

For example, if you copied a Comments value of:

APPLIED_PATCHES:Grid,UINavUpgrade,MVGUpgPatch77,UINavUpgrade,PCLWebTemplSwap,WFD,PM8.1;UpgEimCol,

Then, execute the following command against the EBCDIC database:

Update s_repository set comments='APPLIED_PATCHES:Grid, UINavUpgrade,MVGUpgPatch77,UINavUpgrade,PCLWebTemplSwap,WFD,PM8.1;UpgEimCol'
Where name=New Customer Repository'

Regenerating the Siebel Repository Definition Files

Upgrades: All upgrades.

Environments: Development environment only.

Platforms: All platforms.

This topic is part of an upgrade process. See How to Perform a Siebel Database Upgrade.

If you have modified repository objects after the development environment upgrade (upgphys) and before upgrading the production test environment, you must regenerate the schema.ddl and custrep.dat files. These files were created during the upgphys process:

Schema.ddl. This file contains the logical definition of the Siebel database.
Custrep.dat. This file contains the definition of repository objects.

These files are used as input to the production test and production environment upgrades.These files contain only the Runtime Repository and required design-time Repository which is required for production environments. There is an additional custrep_dev.dat that contains the entire development Repository. This can be created for backup. If you modify the object definitions or the schema definitions in the repository after these files have been created, you must regenerate the files.

Regenerating the schema.ddl File

Use this procedure to regenerate the schema.ddl file.

To regenerate the schema.ddl file

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:
```
ddldict /u DatabaseOwner /p Password /c "ODBCDataSource" /d TableOwner /f DBSRVR_ROOT\DatabasePlatform\schema.ddl /e y /a y /l SiebelLogDir\sch_dict.log /n “Siebel Repository" /t dcir
```
where:
- DatabaseOwner is the Siebel database Administrator account name.
- Password is the Siebel database Administrator account password.
- ODBCDataSource is the ODBC name for connecting to the database. Enclose the name in quotes.
- TableOwner is the Siebel table owner name.
- DBSRVR_ROOT is the absolute path to the Siebel Database Configuration Utilities installation directory.
- DatabasePlatform is the Siebel Database Configuration Utilities directory name for the database, that is, DB2390. The example shows Windows path syntax. On UNIX systems, use UNIX path syntax.
- SiebelLogdir is the path to the directory where you want the output log placed (log output directory). The example shows Windows path syntax. On UNIX systems, use UNIX path syntax.
After the command completes, review the output logs for errors. If the log indicates there are errors, 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.

Regenerating the custrep.dat File

Use this procedure to regenerate the custrep.dat file.

To regenerate the custrep.dat file

On the Siebel Server where the Siebel Database Configuration Utilities files are installed, navigate to the following location:
Windows: SIEBEL_ROOT\bin
UNIX: $SIEBEL ROOT/bin
Run the following command:
```
repimexp /a e /u DatabaseOwner /p Password /c "ODBCDataSource" /d TableOwner /r “New Customer Repository /f DBSRVR_ROOT\DatabasePlatform\custrep.dat /l SiebelLogDir\exprep.log 
```
where:
- DatabaseOwner is the Siebel database Administrator account name.
- Password is the Siebel database Administrator account password.
- ODBCDataSource is the ODBC name for connecting to the database. Enclose the name in quotes.
- TableOwner is the Siebel table owner name.
- DBSRVR_ROOT is the absolute path to the Siebel Database Configuration Utilities installation directory. The example shows Windows path syntax. On UNIX systems, use UNIX path syntax.
- DatabasePlatform is the Siebel Database Configuration Utilities directory name for the database, that is, DB2390.
- SiebelLogdir is the path to the directory where you want the output log placed. The example shows Windows path syntax. On UNIX systems, use UNIX path syntax.
After the command completes, review the output logs for errors. If the log indicates there are errors, 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.

Generating the Runtime Repository Data

Upgrades: All upgrades.

Environments: Development environment only.

Once the Incremental Repository merge is complete and after all merge conflicts have been resolved and before starting upgphys you must generate the Siebel Runtime Repository data. To generate the Siebel Runtime Repository data, you must execute the Full Publish command in Siebel Tools. For more information about executing the Full Publish command in Siebel Tools, see Using Siebel Tools.

Full publish has to be executed against the New Customer Repository. Make sure to change the DockRepositoryName in tools.cfg to New Customer Repository and verify that Siebel tools launches against the correct Repository

Note: This is a mandatory step and not executing this successfully will have consequences in the further steps of upgrade.

The full Publish command is the following:

siebdev /c tools.cfg /TL ENU /d ServerDataSrc /u <username> /p <password> /
FullPublish

The TL <lang_code> parameter is a mandatory argument for Full Publish because it specifies the published languages for the database. You can add multiple languages separated by a comma. For example:

TL ENU,DEU,JPN

Depending on the number of the languages specified, the Full Publish process spans the number of Siebdev processes to compile objects in the specified language and write the data to the database.

Siebdev silently closes after completion of a Full Publish, which indicates there are no errors. If there are errors during the Full Publish process, the Siebdev process throws errors and stops.

In the log file, Failure Reported For indicates an error with an object. The log file lists the object name and type for Failure Reported For errors. Any Workflow Process errors in the log file can be ignored.