Configuring the RDBMS

This chapter provides guidelines for configuring the third-party RDBMS and creating the database instance that you will use for the Siebel database. It includes the following topics:

Overview of Database Configuration

This chapter is intended for use by database administrators (DBAs) and by others who can perform the tasks for configuring the third-party RDBMS and creating the database instance that you will use for the Siebel database.

Follow the general steps for your supported RDBMS platform, as described in this chapter. For more information, see your third-party vendor documentation, the guidelines presented in this chapter for each RDBMS, and other applicable parts of this guide.

For the third-party RDBMS product versions supported for this release of Siebel CRM, see the Certifications tab on My Oracle Support.

For Siebel CRM language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.

Caution: Do not perform any of the tasks mentioned in this chapter in an upgrade environment (or in another environment where you have an existing Siebel database). In particular, you do not create the database instance on the RDBMS. However, after the upgrade is complete, you might have to modify database parameters for your RDBMS platform to match settings described in this chapter. For more information, see About Installing in Upgrade Environments and Roadmap for Installing Siebel CRM in an Upgrade Case (Existing Database).

For nonupgrade deployments (where there is no existing Siebel database), after creating the database instance and installing Siebel CRM software, you use scripts and utilities that are provided with the Database Configuration Utilities installation to create the Siebel database. Creating the Siebel database loads the Siebel schema and seed data into the database instance. For more information, see Installing the Siebel Database on the RDBMS.

In this guide, DBSRVR_ROOT refers to the installation directory of the Siebel Database Configuration Utilities. For more information, see File and Directory Naming Conventions.

Note: In general, it is easier to configure and administer a Siebel database that does not share a database instance with other applications. This approach is considered a best practice. However, some customers might decide to include multiple applications in a single database instance. The implications of this choice might differ by RDBMS type: for example, the term database instance has a different meaning for an Oracle Database than it does for IBM DB2. The shared database instance must be configured according to the requirements described in this chapter.

After you have completed configuring your database as described in this chapter, you can perform all of the Siebel installation and configuration tasks, including those described in:

Overview of Configuring the Database

The overall process of configuring the RDBMS and installing the Siebel database is outlined as follows. The exact process depends on your deployment requirements.

Install the RDBMS software:
- Install the RDBMS server software on the appropriate server computers.
- Install the RDBMS client software on computers where you will install Siebel Server, Siebel Tools, or other modules that directly connect to the Siebel database.
Create the database instance.
Configure the parameters for the database instance.
(IBM DB2) Create the database, and configure the parameters for the database.
Configure storage settings, log space, and other elements for the Siebel database.

Note: After you perform these tasks, you install the Siebel Enterprise Server software, including Siebel Gateway, Siebel Database Configuration Utilities, and Siebel Server. You must install Database Configuration Utilities and Siebel Server on the computer where you run the Siebel Gateway; it is optional to configure and deploy this installed Siebel Server. Then you configure the Siebel Gateway, the Siebel Enterprise, and the Siebel Application Interface profile.
On the computer where you installed the Database Configuration Utilities, run the Database Configuration Wizard. Perform the task to install the Siebel database (schema) in the database instance.
This step creates the Siebel objects (tables and indexes) in the Siebel database, imports seed data for the primary language, and adds the Siebel Repository for the primary language. Also perform the other applicable tasks for the Siebel database. For more information, see Installing the Siebel Database on the RDBMS.

Note: After you perform these tasks, you configure the Siebel Server, install and configure the Siebel Application Interface, and perform additional configuration tasks that are required for your deployment.

About Using Sample Scripts for Creating Siebel Database Objects

Sample scripts that are provided with the Database Configuration Utilities installation can optionally be used to create the Siebel database. These scripts are for testing purposes in small, nonproduction environments only. If you intend to use such a script, then first perform the tasks listed previously, through Step 6, but omit Step 4 and Step 5.

Configuring an Oracle Database for Siebel CRM

This topic contains guidelines for obtaining optimum performance from an Oracle Database. These guidelines will be useful to a broad segment of customers. Choose values for the parameters that are described in this guide that reflect the conditions in your particular environment. For more information, see Oracle Database technical documentation.

Note: When scripts from the Siebel Database Configuration Utilities installation are executed in an Oracle Database, as described in Installing the Siebel Database on the RDBMS, sequences are generated with the CACHE option. Do not drop these sequences and regenerate them with the NOCACHE option, or else performance might be adversely affected and database contention might occur. If you require additional Oracle Database sequence objects, then you must create them manually, and you must grant SELECT on these objects to sse_role.

Collect statistics for the tables, indexes, and histograms for the columns where the data shape is skewed. Recollect these statistics whenever a large amount of data has been updated, deleted, or inserted. For more information about how to collect statistics, see the Oracle Database administration manuals.

For performance reasons, do not collect statistics for an empty table. For more information, see 478242.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Alert 1162.

Guidelines for Configuring an Oracle Database

Various kinds of guidelines are presented for configuring an Oracle Database:

Guidelines for Selecting a Language for Oracle Database

When creating your database, you must specify the character set at the database level. You specify other language characteristics at the database client level.

This topic is part of Configuring an Oracle Database for Siebel CRM.

To specify the character set of your database

Execute the following command to specify the character set for your database:
```
CREATE DATABASE INSTANCE_NAME CHARACTER SET CHARACTER_SET_NAME
```
where:
- INSTANCE_NAME is the name of your Oracle Database instance; for example, SIEBCRM.
- CHARACTER_SET_NAME is the textual name of the character set that you want to run; for example, WE8MSWIN1252 or AL32UTF8.

National Character Set

Siebel CRM does not use the three data types that store Unicode data using the national character set (NCHAR, NVARCHAR2, NCLOB). The default national character set, AL16UTF16, is acceptable.

Sort Order and Date Format

Follow the documented Oracle Database guidelines for client-level settings for the NLS_SORT and NLS_DATE_FORMAT parameters.

Guidelines for Configuring Settings in the init.ora File

The init.ora file contains parameters that have a major effect on the performance of Siebel CRM using Oracle Database.

Use the following settings as guidelines for your initial configuration. Your final settings will vary depending on the hardware configuration, the number of users, and the type of workload.

In the init.ora file, default parameter values are provided for small, medium, and large database deployments. Unless the configuration parameters are specified in the following settings, set them to the large database values. For detailed descriptions of each of the parameters and their effects on database performance and system resource utilization, see Oracle Database documentation.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Brief descriptions follow for several parameters for which you might have to adjust values:

CURSOR_SHARING. This parameter is set to EXACT by default and must not be changed.

Caution: Changing this value might lead to failure of some Siebel Server components.
DB_FILE_MULTIBLOCK_READ_COUNT. The database buffer cache parameter dictates the number of data blocks that are read in a single Oracle Database I/O operation during a table scan. For most implementations, set this parameter to an initial value of 32. If you are using NAS storage (such as a NetApp Filer), then set the value to 8 to reduce potential network traffic problems.
FILESYSTEMIO_OPTION. It is recommended to set this parameter to SETALL, for all operating systems. Performance issues have been observed with other settings.
MEMORY_TARGET. This parameter specifies the Oracle Database system-wide usable memory. A common recommendation is to set it to a value equalling the physical memory minus 1 GB. For example, if the Oracle Database server has 16 GB of memory, then set MEMORY_TARGET to 15 GB.
NLS_DATE_FORMAT. Set this parameter as needed. The default setting is DD-MON-YY. For information about the supported formats, see Oracle Database documentation and see Specifying the Locale for Siebel CRM.
NLS_SORT. The sort order is specified during the initial installation of a database and defines the way in which the database sorts character data. Sort order support depends on both the code page of the database and whether it will be used in a development or a production environment. For more information, see Specifying the Locale for Siebel CRM.
Considerations for development and production environments are as follows:
- Development environment databases. The repository object names in your development environment database must sort using a binary sort order, because Siebel Tools uses this sort order internally. Specify the same sort order at the database client level, so that output there does not have to be resorted. Customers are responsible for making sure their data is backed up and restored correctly.
  
  Note: Binary sort order is the simplest and fastest sort order to perform in the database. Binary sorting is case-sensitive and is based on the numeric values (for example, 0 through 255 for an 8-bit character set) of the characters in the installed character set.
- Production environment databases. For information about production environment database restrictions, see the Certifications tab on My Oracle Support. See also Oracle Database documentation.
OPEN_CURSORS. This parameter controls the amount of spaces that are reserved for the maximum number of cursors (a cursor being the same as an open query). The minimum open cursor requirement for Oracle Database is 1000 and the maximum is 2000. Within these limits, this parameter can be adjusted according to observed usage patterns.
OPTIMIZER_FEATURES_ENABLE. This is an umbrella parameter for enabling a series of optimizer features that are based on an Oracle Database release number. For example, set this parameter to a value corresponding to the current release level of your Oracle Database. For more information, see Oracle Database documentation. For more information about performance tuning for Siebel CRM with an Oracle Database, see 781927.1 (Article ID) on My Oracle Support.
OPTIMIZER_INDEX_COST_ADJ. It is recommended that you set this parameter to 1. Use this parameter to tune the optimizer to use index access path over a full table scan. However, depending on the data shape for your Siebel database, how statistics are gathered, and the nature of your Siebel configuration changes, other values might provide better results.
OPTIMIZER_MODE. Set this parameter to ALL_ROWS (the default) for the Cost-Based Optimizer (CBO).

Note: For more information about performance tuning for Siebel CRM with an Oracle Database, see 781927.1 (Article ID) on My Oracle Support. See also Siebel Database Upgrade Guide.

Guidelines for Sizing Redo Logs for an Oracle Database

If redo logs are too small, then frequent log switches occur, creating resource-intensive Oracle Database check-pointing in which all of the dirty buffers are flushed. A range of 10 to 15 minutes or longer for log switching is preferable under a normal OLTP (Online Transaction Processing) load. However, during periods of heavy DML (data manipulation language) activity, such as during large Siebel EIM loads or upgrades, the logs might switch more frequently than every two minutes. When this occurs, overall database performance suffers as a result.

You can check the frequency of this operation either in the alert log or by querying v$loghist. It is best to use verification when there is the greatest activity and the heaviest load on the database.

If this activity occurs too frequently, then drop and recreate individual redo log groups with larger sizes. A suggested minimum size is 300 MB.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Creating Oracle Database Tablespaces

The initial (minimum) tablespace allocation recommendations are as follows:

Data: 5 GB
Index: 5 GB
Temp: 2 GB
System: 2 GB
Sysaux: 1 GB

This allocation is enough for a fresh installation of Oracle Database (Unicode-enabled or non-Unicode-enabled).

The following additional guidelines will help you in creating tablespaces:

To improve performance on your production system, create at least two tablespaces for a Siebel implementation: one for indexes and one for data.
Distribute objects that you anticipate to be large or points of contention by creating additional separate tablespaces (preferably on separate disk devices).
Be sure that you, or whoever is responsible for setting up permissions, grant the Siebel table owner account the privilege and sufficient quota to create tables and indexes in these tablespaces.
Besides the table owner, the database user ID used for Siebel Marketing also requires additional rights at the database level within the OLTP schema. You must grant DROP TABLE, DROP INDEX, CREATE TABLE, and CREATE INDEX rights to this user. For more information, see Siebel Marketing Installation and Administration Guide.
Set storage parameters for your data and index tablespaces. The Siebel database installation procedure does not set storage parameters for the objects it creates. The storage configuration for each object follows the default storage parameters of its tablespace. It is recommended that you create locally managed tablespaces by using the following syntax:
```
extent management local autoallocate segment space management auto;
```
In a development or test environment, multiple Siebel CRM installations can coexist on one Oracle Database instance. Install each Siebel database under a separate table owner, so that each schema owner is unique.
Function-based indexes based on expressions that require QUERY_REWRITE_ENABLED to equal TRUE are not supported. However, DESC (descending) indexes are supported, as in a standard schema.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Sizing the Oracle Database

Monitor object growth and fragmentation carefully and alter the database storage parameters as required. Also use the following guidelines for initial sizing of your Oracle Database. (If you use EXTENT MANAGEMENT LOCAL AUTOALLOCATE for CREATE DATABASE, then these guidelines do not apply.)

Set the initial extent to a very small size (the minimum is one database block), so that empty tables and indexes do not consume large amounts of space. For example, start with either two or four blocks (in other words, 16 KB or 32 KB with an 8-KB block size). This allocation promotes less fragmentation.
Even if you have as many 10,000 objects, this number of objects uses only 312 MB, which is far less space required than for some standard office software packages.
Set the default next extent for your data and index tablespaces to a minimum of 100 KB.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Creating Temporary Oracle Database Tablespaces

Modify all of the user temporary tablespace definitions from the default of SYSTEM to the name of the temporary tablespace; for example, TEMP.

To find out which users are assigned to which temporary tablespaces, query the TEMPORARY_TABLESPACE column of DBA_USERS. If any users are assigned to a tablespace other than the one allocated for temporary sort-type operations, then correct the situation.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Overriding Oracle Database Default Tablespaces for Database Objects

Siebel CRM provides the option of overriding the default storage parameters for the tablespaces in which specific tables or indexes are created. You created these tablespaces by using the instructions in Guidelines for Creating Oracle Database Tablespaces. To override these parameters, edit the ddl.ctl file located in the DBSRVR_ROOT/oracle directory.

Note: The ddl.ctl file must not be modified except by a qualified DBA.

For each Siebel object (table or index), you can specify a tablespace by using the Table Space parameter. In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.

This topic is part of Configuring an Oracle Database for Siebel CRM.

As provided by Siebel CRM, the .ctl file does not set storage parameters for the objects it creates, so that they default to the parameters of the tablespaces in which they are created. However, the Table Space parameter works only under the following conditions:

When the table does not yet exist (for example, when you are performing a new database installation).
When the table must be rebuilt. In other words, when schema changes are made to the table such that an ALTER TABLE command is insufficient to implement the schema changes. In this case, the table must be dropped and recreated.

The following example illustrates the use of the Table Space parameter to set storage values for specific tables:

[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_ID VARCHAR(15) NOTNULL
Column 2 = CREATED TIMESTAMP NOTNULL DEFAULT %NOW%
Column 3 = CREATED_BY VARCHAR(15) NOTNULL
Column 4 = LAST UPD TIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BY VARCHAR(15) NOTNULL
Column 6 = DCKING_NUM NUMERIC(22,7) DEFAULT 0
Column 7 = MODIFICATION_NUM NUMERIC(10,0) NOTNULL DEFAULT 0
Column 8 = CONFLICT_ID VARCHAR(15) NOTNULL DEFAULT '0'
Column 9 = NAME VARCHAR(50) NOTNULL
Column 10 = DESC_TEXT VARCHAR(255)
Column 11 = LOCAL_ACCESS_FLG CHAR(1)
Table Space = data1

If you use locally managed tablespaces and want to change the storage parameters, then see Oracle Database technical documentation.

For an example (IBM DB2) of overriding the defaults for specific tables and indexes, see Guidelines for Overriding IBM DB2 Default Tablespaces for Database Objects.

Guidelines for Creating Oracle Database Objects

Siebel CRM provides sample scripts (CrBlankOracleSiebelDEMO.sql and CrBlankOracleSiebelDEMOPostCrDB.sql), located in the DBSRVR_ROOT/Oracle directory. Use these scripts as a reference to help you create your own scripts for creating a blank Siebel database, based on the requirements for your deployment.

Use the settings in the script as guidelines for your initial configuration. Your final settings will vary depending on the server hardware configuration, the number of users, and the type of workload. Use a small, nonproduction environment for testing purposes.

Before using these scripts, read the file CrBlankOracleSiebelDEMOReadMe.txt. See also Overview of Database Configuration.

After you install the Database Configuration Utilities on the Siebel Server computer, as described in Installing Siebel CRM Server Modules, you can modify the database table and index creation scripts to specify the tablespace names that you created for Siebel tables and indexes. For more information, see Guidelines for Overriding Oracle Database Default Tablespaces for Database Objects.

Additional information about Oracle Database configuration and tuning options is available from Oracle, your hardware vendor, and other sources.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Ongoing Oracle Database Administration

After your Siebel CRM installation is up and running, monitor the following areas on a regular basis:

Insertion rates on tables. You probably will want to set the INI_TRANS value for tables with high insertion rates to a value higher than 1; a typical setting is 4.
This parameter determines how many simultaneous inserts can occur on the database blocks that store data for those tables and, therefore, can affect performance in an intensive data-entry environment. Use multiple freelists for the table S_DOCK_TXN_LOG, because this table receives numerous inserts.
SGA cache hits. Determine whether SGA parameters have to be adjusted for your system.
The extents used by each object. A large number of extents on a table or index creates response time degradation for transactions that access the table or index.
Siebel tables that are subject to frequent INSERT and DELETE operations. This transaction mixture can cause some database tables to become fragmented over time.
If you are using Siebel Remote, then your DBA must monitor space utilization and fragmentation of the following tables, and perform regular database maintenance procedures as recommended for an Oracle Database. Monitor the following tables in particular, because they will have frequent changes when transaction logging is enabled:
- S_SRM_REQUEST
- S_DOCK_TXN_LOG
- S_DOCK_TXN_LOGT
- S_DOCK_TXN_SET
- S_DOCK_TXN_SETT
- S_DOCK_INST
- S_DOCK_INIT_ITEM
Your DBA might also choose to monitor all of the tables and indexes in the Siebel schema, reorganizing them when required.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Using Real Application Clusters for an Oracle Database

Siebel CRM supports Oracle Real Application Clusters (RAC) failover configurations for Oracle Database. Both active-passive and active-active RAC configurations are supported.

For more information, see:

473859.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 635.
478215.1 (Article ID) on My Oracle Support. This document was previously published as Siebel FAQ 2220.
Certifications tab on My Oracle Support.
Concepts documentation for Oracle Real Application Clusters software on Oracle Technology Network.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Guidelines for Installing the Siebel Database in a Pluggable Database

You can install the Siebel database in a multitenant environment with versions of Oracle Database that support this feature. To do so, first create a pluggable database within the container database. Then create a corresponding entry for the pluggable database in tnsnames.ora. This entry must specify the service you will use to connect to the pluggable database.

When you run grantusr.sql, you do so in the pluggable database rather than in the container database. Database settings you specify in the Siebel Management Console must be those for the pluggable database and you must create the Siebel schema within the pluggable database.

For more information about creating a pluggable database and about managing a multitenant environment, see Oracle Database documentation on Oracle Help Center, particularly the guides listed.

This topic is part of Configuring an Oracle Database for Siebel CRM.

Related Books

Oracle Database SQL Language Reference

Oracle Database Administrator’s Guide

Configuring an IBM DB2 Database for Siebel CRM

This topic contains guidelines for obtaining optimal performance from an IBM DB2 Database for use with Siebel CRM. These guidelines will be useful to a broad segment of customers. Choose values for the parameters described in this guide that reflect conditions in your particular environment. For more information, see IBM DB2 technical documentation.

Note: In this guide, the terms IBM DB2 or DB2 are often used to refer to the database platform IBM DB2 for Linux, UNIX, and Windows.

When you use IBM DB2, the IBM Data Server Client must be installed on the Siebel Server computer. Verify that the IBM Data Server Client is installed before proceeding. For details, see Siebel Database Upgrade Guide. In addition, the IBM Data Server Runtime Client must be installed on the Siebel Server computer. For IBM DB2 version information, see the Certifications tab on My Oracle Support.

Note: If your database is IBM DB2 for z/OS, then see Implementing Siebel Business Applications on DB2 for z/OS instead of this chapter. See also the relevant information in Planning RDBMS Installation and Configuration.

Guidelines for Configuring an IBM DB2 Database

Various kinds of guidelines are presented for configuring an IBM DB2 database:

Guidelines for Setting IBM DB2 Database Manager Configuration Parameters

You can set the IBM DB2 database configuration parameters by using the update database manager configuration command of the DB2 command line processor. For more information about modifying these configuration parameters, see IBM DB2 technical documentation.

The following table describes IBM DB2 database manager configuration parameters that differ from the default settings. Set these parameters for each DB2 instance. Use the configuration information in the following table for the listed parameters. For parameters not listed in this table, accept the default settings.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Table IBM DB2 Database Manager Configuration Parameters

Parameter	Explanation	Setting or Comment
SHEAPTHRES	Sort heap threshold (4 KB)	`200000` Deployments with 3,000 or more concurrent users and using over 5 GB of RAM can increase this to `300000`. If you are using automatic management, then set this parameter to 0.
DIR_CACHE	Directory cache support	`YES`
ASLHEAPSZ	Application support layer heap size	`15`
RQRIOBLK	Maximum requester I/O block size (bytes)	`65535`
MON_HEAP_SZ	Database monitor heap size (4 KB)	`128` (minimum)
KEEPFENCED	Keep Fenced process	`YES`
NUM_INITAGENTS	Initial number agents in pool	`10`
NUM_POOLAGENTS	Number of agents in the agent pool kept active at all times	`80`
MAX_COORDAGENTS	Maximum number coordinating agents	`automatic`
INDEXREC	Index recreation time	`RESTART`
INTRA_PARALLEL	Enable intra-partition parallelism	`NO`
INSTANCE_MEMORY	Amount of memory to be reserved for instance management	`automatic`

DB2set Parameters

Use the db2set command to set the parameters (for example, db2set DB2_HASH_JOIN = NO) referenced in the following table.

Table DB2set Parameters

Parameter	Explanation	Setting
EXTSHM	(AIX only) Use this parameter only when you have the Siebel database and the Siebel Server on the same AIX computer. EXTSHM must be set when the IBM DB2 database is created and must be included in the script that starts it. The parameter also must appear in the `sqllib/db2profile` file for the DB2 server. Include this parameter in the script that starts the DB2 client. After changing any of these settings, you must perform a `db2stop`, then `db2start`, to implement the changes in your DB2 database.	`ON`
DB2ENVLIST	(AIX only) When starting an IBM DB2 server and running EXTSHM, EXTSHM must be part of the DB2 environment. This parameter must be set when the database is created.	`EXTSHM`
DB2MEMDISCLAIM	(AIX only) When set to YES, IBM DB2 disclaims some or all of the freed memory, depending on the value of DB2MEMMAXFREE.	`YES`
DB2_MMAP_READ	(AIX only) Recommended setting only; evaluate this setting for your particular configuration and environment.	`OFF`
DB2_MMAP_WRITE	(AIX only) Recommended setting only; evaluate this setting for your particular configuration and environment.	`OFF`
DB2_PARALLEL_IO	Useful when using RAID devices. For more information, see IBM DB2 documentation.	`*` (asterisk)
DB2_REDUCED_OPTIMIZATION	Controls optimization techniques used at specific optimization levels.	`YES`

Guidelines for Selecting a Language for IBM DB2

As part of database creation, you must set the language characteristics of your database, even if you deploy in only one language.

To do this, you must know in which of the Siebel-supported languages your database runs, the codeset your database uses, the territory for your language, and the sort order (also known as the collation sequence) that your users prefer.

For an IBM DB2 production environment database, you can use any sort order. For a development environment database, you must use binary (identity) sort order.

Setting the language characteristics of the database is part of the sample script in the DBSRVR_ROOT/DB2UDB directory.

For Siebel CRM language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Codeset

IBM DB2 distinguishes between a code page (also known as a character set) and a codeset. A codeset is defined as a textual string that describes the character encoding standard used for the database, whereas a code page is a numeric representation of the same standard.

Territory

The territory, or region, is a combination of the language and the locale; for example, French would be a language example, while Canada or France would be locales in which French is used with regional differences. So, an example of a territory is Canadian French.

Sort Order

The sort order is specified during the initial installation of a database and defines the way in which the database sorts character data. Sort order support depends on both the code page of the database and whether it will be used in a development or a production environment.

For more information about supported sort orders, see the Certifications tab on My Oracle Support.

Development environment databases. The repository object names in your development environment database must sort in the same order that they would under the UTF-16 binary sort order, because Siebel Tools uses this sort order internally.

Note: Binary sort order is the simplest and fastest sort order to perform in the database. Binary sorting is case-sensitive and is based on the numeric values (for example, 0 through 255 for an 8-bit character set) of the characters in the installed character set.
Customers are responsible for making sure that their data is backed up and restored correctly.
Production environment databases. For information about production environment database restrictions, see the Certifications tab on My Oracle Support. See also IBM DB2 documentation.

Guidelines for Creating the IBM DB2 Database

If you are installing a database that is to be enabled for Unicode, then you must specify UTF-8 as the codeset (including the hyphen). UTF-8 is the parameter used for Unicode implementations on IBM DB2, although the processing will use UCS-2. When you specify UTF-8 as the encoding for the VARCHAR type, the encoding for the VARGRAPHIC type is automatically set to UCS-2, even though UCS-2 is not specified as the parameter.

Verify that your data is exported and imported correctly.

For Siebel CRM language support, Unicode support, and legacy code page support, see 1513102.1 (Article ID) on My Oracle Support.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

To create the IBM DB2 database

Locate the primary (base) language that your database will use, the territory for your language, and the applicable codeset.
Using the DB2 command line processor, enter the following command:
```
db2 create database dbname using codeset territory collate using identity
```
where:
- dbname is the alias for your database
- codeset is the textual representation of your code page
- territory is the territory for the language that your database runs in, under that codeset

Guidelines for Setting IBM DB2 Configuration Parameters

The database configuration parameters can be set by using the update database configuration command of the DB2 command line processor.

For more information about modifying these configuration parameters, see IBM DB2 technical documentation.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

The following table describes IBM DB2 database configuration parameters that differ from the default settings. However, these descriptions are guidelines only. Set these parameters for each database within an instance on which you run your Siebel application. For other parameters, accept the default settings.

Table IBM DB2 Configuration Parameters

Parameter	Explanation	Setting
DFT_DEGREE	Degree of parallelism (the value 1 turns query parallelism off).	`1`
DFT_QUERYOPT	Default query optimization class. This parameter only takes effect on the database server and affects the Siebel Server components, such as Siebel EIM or Siebel Remote. Queries run through the UI are not affected by this setting. They take the value of the Siebel system preference DB2: Default Opt Level, or you can override them at the business component level by using Siebel Tools.	`3`
DBHEAP	Database heap (4 KB).	Automatic.
CATALOGCACHE_SZ	Catalog cache size (4 KB).	`10000`
LOGBUFSZ	Log buffer size (4 KB).	`512`
LOCKLIST	Maximum storage for lock list (4 KB).	Automatic.
SORTHEAP	Sort list heap (4 KB). Use lower values for development environments; use higher values for production. However, increasing this value can lead to insufficient memory on the database server. Also, this parameter might have to be set below the recommended range if you have a high number of Siebel users. Always monitor database server memory and performance to find the best setting for your environment.	Automatic.
STMTHEAP	Minimum setting. If necessary, increment this parameter in 1048 blocks of 4 KB.	Automatic or a fixed value. For example, you might update the parameter setting using a command like this: DB2 UPDATE DB CFG FOR SAMPLE USING STMTHEAP 8192 AUTOMATIC This value specifies 8192 times 4 KB (or 32 MB) for dynamic join enumeration and unlimited for greedy join enumeration.
STAT_HEAP_SZ	Statistics heap size (4 KB).	Automatic.
MAXLOCKS	Percentage of lock lists for each application.	Automatic.
LOCKTIMEOUT	Lock time out (seconds).	`300`
CHNGPGS_THRESH	Changed pages threshold.	`60`
NUM_IOCLEANERS	Number of asynchronous page cleaners.	Automatic.
SEQDETECT	Sequential detect flag.	`YES`
DFT_PREFETCH_SZ	Default prefetch size (4 KB).	`32`
MAXAPPLS	Maximum number of active applications.	Automatic.
AVG_APPLS	Average number of active applications.	Automatic.
MAXFILOP	Maximum DB files open for each application.	`500`
LOGFILSIZ	Log file size (in 4 KB increments).	`65535`
LOGPRIMARY	Number of primary log files.	`25` to `50` The value of LOGPRIMARY and LOGSECOND together must not exceed 256.
LOGSECOND	Number of secondary log files.	Up to `103` The value of LOGPRIMARY and LOGSECOND together must not exceed 256.
SOFTMAX	Percent log file reclaimed before soft checkpoint.	`80`
APPLHEAPSZ	Default application heap (4 KB).	Automatic.
PCKCACHESZ	Package cache size (4 KB).	Automatic.
NUM_IOSERVERS	Number of disks on which the database resides.	Automatic.

Guidelines for Setting Up IBM DB2 Buffer Pools

A buffer pool is an area of main system memory that is used for holding pages of data that have been fetched from the tablespace. In IBM DB2, each tablespace is associated with a buffer pool. Adding more space to a buffer pool enhances the performance of the database.

You must have at least three buffer pools for the Siebel tablespaces. You can use the default buffer pool to buffer data pages from all of the Siebel 4-KB tablespaces.

You must also create additional buffer pools with 16-KB and 32-KB page sizes for sorting and other SQL processing. A sample configuration is shown in the following table.

Table Sample Buffer Pool Configuration

Buffer Pool	Suggested Buffer Pool Size	Page Size
BUF4K	50% of available memory	4 KB
BUF16K	25% of available memory	16 KB
BUF32K	32 MB	32 KB

Different operating systems support different maximum amounts of IBM DB2 addressable memory. Depending on the memory configuration of a given server, the suggested pool sizes for BUF4K and BUF16K buffer pools might exceed these maximums, requiring you to allocate a smaller percentage. To determine the optimal buffer pool sizes, use IBM DB2 monitoring features.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

About Buffer Pools and the Full Publish Process

When the Full Publish process runs to generate Siebel Runtime Repository data from the Design Repository (including during the upgrade process for the development database), it makes intensive use of workspace queries, which results in a higher usage of buffer pools. If you encounter errors similar to the following during the Full Publish process, increase the buffer pool sizes above the values shown in the preceding table and try again.

DBCLog DBCLogError 1 000000025c1eca2c:0 2018-12-22 04:50:04 SQLError:
sqlstate 57011: [IBM][CLI Driver][DB2/AIX64] SQL1218N  There are no pages
currently available in bufferpool "4".  SQLSTATE=57011

For more information about the Full Publish process, see Using Siebel Tools and Siebel Database Upgrade Guide.

Guidelines for Creating IBM DB2 Tablespaces

The Siebel database installation process described in Installing the Siebel Database on the RDBMS specifies the tablespaces in which to store your Siebel tables and indexes.

A Siebel database on IBM DB2 requires at least four tablespaces using database-managed space (DMS). Each tablespace can have one or more tablespace containers to store the data. Create a minimum of four DB2 tablespaces to hold your tables and indexes: a 4-KB, a 16-KB, and a 32-KB tablespace, for your various sized tables, and an additional tablespace to hold your indexes. The tablespaces must be created as database-managed space. Use a small, nonproduction environment for testing purposes.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Observe the following guidelines when creating tablespaces:

Create at least three IBM DB2 tablespaces for tables of various sizes, as shown in the table that follows this list. Using the default tablespace names is recommended.
Create additional tablespaces as required for individual tables, such as S_DOCK_TXN_LOG. If you expect to have large, heavily used tables, then put these in their own tablespace.
In addition, for performance reasons it is highly recommended that you create a separate tablespace for indexes. For example, you might create a tablespace named SIEBEL_IDX and using buffer pool BUF16K, with a page size of 16 KB, and with 3 GB allocated for this tablespace.
Create at least 4-KB, 16-KB, and 32-KB temporary tablespaces to use for sorting and other SQL processing as described in the following topics. If you do not create them, then your database will experience serious performance and stability problems. Use system-managed space (SMS) for all of the temporary tablespaces. Make sure that these temporary tablespaces are expandable to 2 GB for storage purposes.
If you intend to use the DB2 Load utility to populate EIM tables, then this method makes the tablespace in which EIM tables resides unavailable for the duration of the load. Placing the EIM tables in one or more separate tablespaces allows concurrent activity on the database while the load utility is running.
To override default storage parameters, such as the tablespace definitions, see Guidelines for Overriding IBM DB2 Default Tablespaces for Database Objects.
Record the tablespace names in Siebel Deployment Planning Worksheet.

Table IBM DB2 Tablespace Values for Non-Unicode and Unicode-Enabled Databases

DB2 Tablespace Name	Buffer Pool Name	Recommended Value	Description
Non-Unicode Database
SIEBEL_4K	BUF4K	2 GB	Tablespace name for tables with row sizes less than 4006 bytes.
SIEBEL_16K	BUF16K	300 MB	Tablespace name for tables with row sizes from 4006 bytes through 16,293 bytes.
SIEBEL_32K	BUF32K	100 MB	Tablespace name for tables with row sizes greater than 16,293 bytes.
Unicode-Enabled Database
SIEBEL_4K	BUF4K	4 GB	Tablespace name for tables with row sizes less than 4006 bytes.
SIEBEL_16K	BUF16K	700 MB	Tablespace name for tables with row sizes from 4006 bytes through 16,293 bytes.
SIEBEL_32K	BUF32K	100 MB	Tablespace name for tables with row sizes greater than 16,293 bytes.

Guidelines for Overriding IBM DB2 Default Tablespaces for Database Objects

Siebel CRM provides the option of overriding the default storage parameters for the tablespaces in which specific tables or indexes are created. You created these tablespaces by using the instructions in Guidelines for Creating IBM DB2 Tablespaces. To override these defaults, edit the ddl.ctl file located in the DBSRVR_ROOT/DB2UDB directory.

Note: The ddl.ctl file must not be modified except by a qualified DBA.

For each Siebel table, you can specify a tablespace by using the Table Space parameter. In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.

As provided, the .ctl file does not set storage parameters for the objects it creates, so they default to the parameter settings of the tablespaces in which they are created. However, the Table Space parameter works only under the following conditions:

When the table does not yet exist (for example, when you are performing a new database installation).
When the table must be rebuilt. In other words, when schema changes are made to the table such that an ALTER TABLE command is insufficient to implement the schema changes. In this case, the table must be dropped and recreated.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

As shown in the following example, you can use the Table Space parameter to set storage parameters for specific tables:

[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_ID VARCHAR(15) NOTNULL
Column 2 = CREATED TIMESTAMP NOTNULL DEFAULT %NOW%
Column 3 = CREATED_BY VARCHAR(15) NOTNULL
Column 4 = LAST_UPD TIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BY VARCHAR(15) NOTNULL
Column 6 = DCKING_NUM NUMERIC(22,7) DEFAULT 0
Column 7 = MODIFICATION_NUM NUMERIC(10,0) NOTNULL DEFAULT 0
Column 8 = CONFLICT_ID VARCHAR(15) NOTNULL DEFAULT '0'
Column 9 = NAME VARCHAR(50) NOTNULL
Column 10 = DESC_TEXT VARCHAR(255)
Column 11 = LOCAL_ACCESS_FLG CHAR(1)
Table Space = data1

The following example illustrates how to override the defaults for specific tables and indexes:

[Object 7135]
Type = Table
Name = S_EVT_ACT
Group = Activity-1
Append Mode = Yes
Column 1 = ROW_ID WVARCHAR(15) NOTNULL
Column 2 = CREATED TIMESTAMP NOTNULL DEFAULT %NOW%
Column 3 = CREATED_BY WVARCHAR(15) NOTNULL
Column 4 = LAST_UPD TIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BY WVARCHAR(15) NOTNULL
Column 6 = DCKING_NUM NUMERIC(22,7) DEFAULT 0
Column 7 = MODIFICATION_NUM NUMERIC(10,0) NOTNULL DEFAULT 0
Column 8 = CONFLICT_ID WVARCHAR(15) NOTNULL DEFAULT '0'
Column 9 = ACTIVITY_UID WVARCHAR(30) NOTNULL DEFAULT 'x'
...
Column 166 = TODO_CD WVARCHAR(30)
Column 167 = USER_MSG_ID WVARCHAR(15)
Column 168 = WC_START_VIEW WVARCHAR(250)
Column 169 = WC_TYPE_CD WVARCHAR(30)

[Object 7136]
Type = Index
Name = S_EVT_ACT_F1
Table = S_EVT_ACT
Column 1 = CON_PRDINT_ID ASC
Index Space = S_EVT_ACT_TBS_IDX

[Object 7137]
Type = Index
Name = S_EVT_ACT_F10
Table = S_EVT_ACT
Allow Reverse Scans = Yes
Column 1 = TARGET_OU_ID ASC
Column 2 = APPT_START_DT DESC
Column 3 = ROW_ID ASC

[Object 7138]
Type = Index
Name = S_EVT_ACT_F11
Table = S_EVT_ACT
Column 1 = PAR_EVT_ID ASC
Index Space = S_EVT_ACT_TBS_IDX

Guidelines for Preventing IBM DB2 from Running Out of ODBC Statement Handles

IBM DB2 can quickly run out of ODBC statement handles, depending on the number of business objects your enterprise uses. Because it is difficult to know how many business objects your users use, increase this number automatically each time that you install the DB2 Client, or when you rebind database utilities. You can increase the number of CLI packages with the CLIPKG option for the bind command.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

To rebind the CLI packages

Navigate to sqllib/bnd in the IBM DB2 instance home directory, by using a method appropriate to your operating system.
Connect to the DB2 database, and enter a command similar to the following example, which sets the number of CLI packages to 30:
```
db2 bind @db2cli.lst blocking all grant public clipkg 30
```
Specify a value for CLIPKG that is sufficient to run your applications. For more information about the DB2 bind command and the CLIPKG option, see IBM DB2 documentation.

Guidelines for Increasing the Number of IBM DB2 User Processes Under AIX

When you reach about 400 concurrent database users running under AIX, the connection to IBM DB2 might fail. To avoid this problem, reset the parameter controlling the maximum number of user processes on your AIX server.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

To reset the parameter

Log on to the server as the AIX system administrator.
Navigate to $SIEBEL_HOME (the Siebel Server root directory) and source environment variables, by using one of the following commands, depending on the type of shell that you use:
C shell
```
source siebenv.csh
```
Bourne or Korn shell
```
. ./siebenv.sh
```
Note: Make sure that there is a space between the initial period and ./siebenv.sh.
Execute the following command to review the options:
```
smitty chgsys
```
Select Maximum Number of Processes and reset the default (512) to a larger number; for example, specify a value like 10,000 to avoid imposing an upper limit on the number of processes that a single user can spawn.

Guidelines for Determining IBM DB2 Log Space

You must create database transaction log files large enough to support various large transactions used by Siebel CRM. On IBM DB2, three parameters affect the amount of log file space reserved:

LOGFILSIZ. The size of the log file.
LOGPRIMARY. The number of log files to preallocate and use.
LOGSECOND. Extra log files that are allocated only if they are needed for a large transaction.

For a large system, allocate 4 to 8 GB of total log file space, as needed. Create 25 to 50 primary log files of 160 MB each, by setting the LOGFILSIZ database configuration parameter to 40000 and the LOGPRIMARY parameter to a value between 25 to 50. To support very large transactions, set the LOGSECOND parameter to 128 minus the value of LOGPRIMARY. Smaller systems can use less log file space.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Guidelines for Creating IBM DB2 Database Objects

Siebel CRM provides a sample script (CrBlankDB2UDBSiebelDEMO.sql), located in the DBSRVR_ROOT/DB2UDB directory. Use this script as a reference to help you create your own scripts for creating a blank Siebel database based on the requirements for your deployment.

Use the settings in the script as guidelines for your initial configuration. Your final settings will vary depending on the server hardware configuration, the number of users, and the type of workload. Use a small, nonproduction environment for testing purposes.

Before using this script, read the file CrBlankDB2UDBSiebelDEMOReadMe.txt. See also Overview of Database Configuration.

After you install the Database Configuration Utilities on the Siebel Server computer, as described in Installing Siebel CRM Server Modules, you can modify the database table and index creation scripts to specify the tablespace names that you created for Siebel tables and indexes. For more information, see Guidelines for Overriding IBM DB2 Default Tablespaces for Database Objects.

Additional information about IBM DB2 configuration and tuning options is available from IBM, your hardware vendor, and other sources.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Guidelines for Managing IBM DB2 Fragmentation

No strict guidelines can be offered as to which tables and indexes might be fragmented, because of the variety in application and customer operation variables at any given customer site. However, DBAs must pay attention to the status of large or heavily used tables, because fragmentation of these tables can affect performance significantly. For a list of these Siebel tables, see Siebel Deployment Planning Guide.

Note: Do not reorganize S_ESCL_LOG, S_DOCK_INIT_ITEM, S_ESCL_ACTN_REQ, S_APSRVR_REQ, and all tables named S_DOCK_INITM_ %% (in this table name, % is a digit), because these tables are defined to be in append mode.

This topic is part of Configuring an IBM DB2 Database for Siebel CRM.

Use the following strategy to manage table fragmentation:

Reorganize any tables, as needed, by running REORG TABLE. For details on how to reorganize tables or indexes, see the following:
- 477378.1 (Article ID) on My Oracle Support. This document was previously published as Siebel FAQ 2072.
- 477402.1 (Article ID) on My Oracle Support. This document was previously published as Siebel FAQ 2073.
- After reorganizing tables, update statistics by using the runstats utility on any reorganized tables with the following minimum parameters:
```
runstats on table tablename with distribution and detailed indexes all shrlevel change
```
You might add other parameters as required, but use the shrlevel change parameter to allow concurrent access to your tables while runstats executes.
Caution: The runstats utility overwrites statistics loaded by Siebel CRM. If you use runstats, then always execute loadstats.sql afterwards, by using either the DB2 command line processor or odbcsql. Otherwise, valuable statistics will be lost.
To run loadstats.sql by using odbcsql, use the following command:
```
odbcsql /s DATASOURCE_NAME /u username /p password /v separator siebel_root/dbsrvr/db2udb/loadstats.sql TABLEOWNER_NAME
```

Configuring Siebel Server Connectivity to the Siebel Database

Review this topic to configure connectivity to the Siebel database from the computer where you will install Siebel Server.

The database will already have been created, as described in this chapter.

For database connectivity software requirements, see the Certifications tab on My Oracle Support.

Oracle Database

Verify that the Oracle Database connectivity software is installed on each computer, according to the Oracle Database documentation.

Siebel Server connections to the Oracle Database are made through dedicated server processes rather than through Oracle MTS; the use of MTS might negatively affect performance.

Use Oracle’s Easy Configuration utility to define a database alias with the proper connection information for your Siebel database. Record the connect string in Siebel Deployment Planning Worksheet. You specify this connect string when configuring the Siebel Enterprise.

Note: Siebel CRM supports the Oracle 32-bit client. Therefore, if you have installed the Oracle 64-bit client on your Siebel Server, then you must include $ORACLE_HOME/lib32 in your definition for the LIBPATH (AIX), SHLIB_PATH (HP-UX), or LD_LIBRARY_PATH (Linux or Oracle Solaris) environment variable. (If you require $ORACLE_HOME/lib for non-Siebel applications, then make sure that $ORACLE_HOME/lib32 is placed in front of $ORACLE_HOME/lib.)

IBM DB2

Define a database alias with the proper connection information for your Siebel database. Record the connect string in Siebel Deployment Planning Worksheet. You specify this connect string when configuring the Siebel Enterprise.

You can use the DB2 command line processor to define your database alias. For more information, see IBM DB2 documentation.

IBM DB2 for z/OS

For information about configuring database connectivity for IBM DB2 for z/OS, see Implementing Siebel Business Applications on DB2 for z/OS.