Siebel Installation Guide for UNIX: Servers, Mobile Web Clients, Tools > Guidelines for Configuring the RDBMS >

Configuring Oracle for Siebel Applications


This section contains guidelines for obtaining optimum performance from an Oracle database. Refer to your Oracle technical documentation for additional information.

NOTE:  When Siebel Database Server scripts are executed in an Oracle database, sequences are generated with the CACHE option. Do not drop these sequences and regenerate them with the NOCACHE option, or performance may be adversely affected and database contention may occur.

Configuring Settings in init.ora File

The init.ora file contains parameters that have a major impact on the performance of Siebel applications.

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

CAUTION:  Never make changes to your Siebel Database schema unless instructed on how to do so for a specific purpose by Siebel eBusiness Applications documentation. Otherwise, you may corrupt your entire system and thereby render it unsupportable.

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

Brief descriptions of these parameters follow:

  • OPTIMIZER_MODE. Select the appropriate optimizer by setting this parameter.
    • For Oracle 9i installations, only the Cost-Based Optimizer (CBO) is supported. Set OPTIMIZER_MODE to CHOOSE.
    • For Oracle 8i installations, only the Rule-Based Optimizer (RBO) is supported. Set OPTIMIZER_MODE to RULE.

      NOTE:  When upgrading your Siebel eBusiness Applications to version 7.7 on Oracle, RBO mode must be used in all cases. For Oracle 9i installations, you set the optimizer to RBO for the upgrade, then set it back to CBO after the upgrade. See the Upgrade Guide.

  • OPTIMIZER_MAX_PERMUTATIONS. Applies to Oracle 9i. Set this parameter to 100. This parameter restricts the number of permutations of the tables the optimizer considers in queries with joins.
  • OPTIMIZER_INDEX_COST_ADJ. Applies to Oracle 9i. Set this parameter to 1. Use it to tune the optimizer to use index access path over a full table scan.
  • DB_BLOCK_BUFFERS(8i) or DB_CACHE_SIZE(9i). The minimum recommended value is 10,000 blocks (assuming a block size of 8 KB). This yields 80 MB of block buffers. If significant I/O activity occurs, you can increase this value, if enough RAM is available.

    In a production system, it is recommended that you assign this parameter a minimum value of 400 MB. Also, your system should have a minimum of 1 GB RAM.

  • SHARED_POOL_SIZE. Start with a minimum value of 200 MB in your production environment. A DBA should adjust this value upward based on the available physical memory of the hardware and performance.

    Siebel eBusiness Applications make heavy demands on the dictionary cache for columns. In Oracle, you cannot explicitly set the size of the column cache. Instead, column cache is set as a fixed percentage of the shared pool size. By setting a large shared_pool_size, you set a large column cache size.

    The number of repositories active in your Siebel schema also adds to dictionary overhead because Siebel eBusiness Applications maintains a record for each column in each table for each repository. As a result, if you have six active repositories, the Siebel dictionary is six times larger than it needs to be.

  • DB_FILE_MULTIBLOCK_READ_COUNT. The database buffer cache parameter dictates the number of data blocks read in a single Oracle I/O operation during a table scan.

    For most implementations, this value should be set between 16 and 32 blocks and adjusted as necessary. You may want to set an initial value of 32. To reduce I/O overhead, this parameter should ideally be between 64 and 256 KB, depending on the tables undergoing scanning, the number of disk drives and devices, the tablespace structure, and other variables.

    To optimize performance during upgrades, this value should be set higher than for installation or daily operation and the parameter ARCHIVE_LOGGING should be switched off.

  • SORT_AREA_SIZE. This value is specified in bytes, and may be adjusted according to the number of users, the amount of RAM available, and the size of sorted queries. You should start with an initial value of 1,000,000 (1 MB).Optimal performance can be achieved for the Dictionary Managed TEMP tablespaces if the extents are uniform and a multiple of the SORT_AREA_SIZE.
  • SORT_AREA_RETAINED_SIZE. Use the default recommended by Oracle. See Oracle documentation for details.
  • CURSOR_SHARING. This parameter is set to EXACT by default and you should not change it unless directed by Siebel Technical Support.
  • OPEN_CURSORS. This parameter controls the amount of spaces that should be reserved for the maximum number of cursors (a cursor being the same as an open query). The minimum open cursor requirement for Oracle support is 1000 and the maximum is 2000. This parameter may be adjusted according to observed usage patterns.

    Setting this number higher than 2000 commits more memory for the database server, thereby affecting performance. Setting it lower than 1000 can cause an error that prevents you from continuing.

  • DB_BLOCK_SIZE. Small block size leads to high levels of row chaining and large numbers of levels in B*tree indexes, creating serious performance problems. Set the block size to a minimum of 8 KB to prevent excessive row chaining and performance degradation with EIM.
  • 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.
    • Development environment databases. Repository object names in your development database must sort using binary sort order. Siebel Tools uses this sort order internally. Otherwise, repository merges during future upgrades of the Siebel Database will fail.
    • Production environment databases. Refer to Oracle documentation for guidelines on setting this parameter for production databases. For information on production environment database restrictions, see System Requirements and Supported Platforms on Siebel SupportWeb.

      You should specify the same sort order at the database client level, so that output there does not need to be resorted.

      Customers are responsible for verifying that their data is exported and imported correctly.

  • NLS_DATE_FORMAT. Set the NLS_DATE_FORMAT parameter as needed. (The default setting is DD-MON-YY.) For information about the formats supported, consult your Oracle documentation.
Siebel Installation Guide for UNIX: Servers, Mobile Web Clients, Tools