Oracle CBO and Siebel Business Applications [ID 478028.

1] Modified 30-OCT-2009 Type BULLETIN Status PUBLISHED

In this Document Purpose Scope and Application Oracle CBO and Siebel Business Applications Preparing and Administrating the Siebel Database for CBO Changes Made in Siebel 7.7, Siebel 7.8 and Siebel 8.0 for Supporting CBO References

Applies to:
Siebel System Software - Version: 7.7.2 [18325] to 8.0 [20405] - Release: V7 to V8 Information in this document applies to any platform. Area(s):Installation, System Administration Release(s):V7 (Enterprise), V7 (Professional), V8 (Enterprise), V8 (Professional) Database(s):Oracle App Server OS(s):All Supported Platforms Latest release tested against:V8 (Enterprise) Keywords:CBO, RBO, tuning, performance, 9i, parameter, statistics, cost, choose, optimizer This document was previously published as Siebel Technical Note 582. IMPORTANT NOTE: This document is no longer being updated. Ultimate reference for Oracle performance and tuning for Siebel Application is the White paper: Performance Tuning Guide for Siebel CRM Application on Oracle (Doc ID 781927.1)

Purpose
Oracle Cost Based Optimizer (CBO) is supported for Siebel versions 7.7.x, 7.8.x, and 8.0 when deployed with Oracle RDBMS 9i and 10g. For Siebel version 7.5.x or earlier, the only optimizer mode supported is RULE for any of the database versions supported by the Siebel versions. Siebel Oracle RDBMS Version Version 7.5.x or higher 8.1.7.x (where x >= 3) 9.0.1.3 9.2.0.x (where x >= 2) 7.7.x or higher 8.1.7.x (where x >= 3) 9.2.0.x (where x >= 4) 7.7.2.5 or 10.1.0.x (where x>= 4), higher 10.2.0.x. 7.8.x or higher 9.2.0. x (where x>=4) Optimizer Mode RULE RULE RULE RULE COST COST COST Init.ora parameter OPTIMIZER_MODE RULE RULE RULE RULE CHOOSE * ALL_ROWS CHOOSE

8.0

10.1.0.x (where x>=3), 10.2.0.x. 10.2.0.2 and above

COST COST

ALL_ROWS
ALL_ROWS

(*) except during the Upgrade process on 9i, when the OPTIMIZER_MODE should be set to RULE as described in the Document 477789.1 document. The purpose of this document is to cover the main aspects of the Cost Based Optimizer mode and its relation with Siebel versions 7.7, 7.8, and 8.0.

Scope and Application

This document is informational and intended for any user.

Oracle CBO and Siebel Business Applications

A query optimizer determines the best Execution Path for performing each query. The Oracle Rule Based Optimization (RBO) method chooses its plans based on a set of fixed rules. While the Cost Based Optimization method leverages a costing model based on statistics, which evaluates all of the different access and join methods for the specific query and uses the most efficient one. RBO enumerates a deterministic, ordered (fixed rank) set of plans based on a pre-defined set of rules and always picks the first applicable plan in the order. For example, if you have a query of the form: SELECT * from EMP where EMPNO > 50 and if there is an index on column EMPNO, then one of the RBOs rules specifies that this query will always be executed using the index. The behavior of the RBO is entirely fixed; the execution plan for the sample query remains the same regardless of whether the EMP table has 10 rows or 10 million rows, and regardless of whether the EMPNO > 50 predicate will return 2 rows or 2 million rows. On the other hand, the cost-based optimization strategy generates multiple execution plans for a given query, with each having an estimated cost computed for each plan. The query optimizer chooses the plan with the most efficient cost (for example, the highest performance and lowest cost). The CBO requires accurate statistics in order to deliver good query performance. Hence, it is crucial that the statistics the CBO uses are available and accurately maintained.

Preparing and Administrating the Siebel Database for CBO

When using Oracles Cost Based Optimization with the Siebel database, there are some requirements that should be followed regarding the database parameters configuration and the Optimizer statistics generation on tables, columns and indexes, as specified below: Database Parameters For Oracle 10g, OPTIMIZER_MODE should be set to ALL_ROWS which is the default value. For Oracle 9i, OPTIMIZER_MODE should be set to CHOOSE unless you are performing an upgrade. Besides setting the OPTIMIZER_MODE to CHOOSE or ALL_ROWS, about 60 other parameters affect the generation of the query plan (46 of them are hidden parameters). Some of the visible parameters are listed below. The details of these parameters are not within the scope of this document; you may refer to the Oracle Database Reference Manual to get more information.

The following visible parameters must be set to their default values where applicable: Oracle Parameter HASH_JOIN_ENABLED OPTIMIZER_FEATURES_ENABLE OPTIMIZER_INDEX_CACHING OPTIMIZER_MODE PARTITION_VIEW_ENABLED QUERY_REWRITE_INTEGRITY STAR_TRANSFORMATION_ENABLED 9i Default Value True 9.2.0 0 CHOOSE False Enforced False 10g Default Value ** Obsolete 10.1.0 * 0 ALL_ROWS ** Obsolete Enforced False

* It is always a good idea to set the OPTIMIZER_FEATURES_ENABLE = <Oracle DB patch version being used> to get full benefit of a series of optimizer feature supported by Oracle DB version. Hence, if your db version is already 10.2.x, then you can set the OPTIMIZER_FEATURES_ENABLE=10.2.x. In addition, for the Siebel application to work effectively and efficiently, the following parameters need to be set to the recommended values other than default values. Oracle Parameter Description

9i Def Valu 1

OPTIMIZER_DYNAMIC_SAMPLING

This parameter controls the level of dynamic sampling performed by the optimizer. OPTIMIZER_MAX_PERMUTATIONS This parameter restricts the number of permutations of the tables the optimizer will consider in queries with joins. A higher value result in higher parse time, a lower value carries the possibility of overlooking a good plan. NOTE: Starting with Oracle Database 10g, this parameter has been made obsolete. Refer to the Oracle documentation for further information. Controls the access path selection to be more or less index friendly. Enable or disable query rewriting globally for the database

200

OPTIMIZER_INDEX_COST_ADJ QUERY_REWRITE_ENABLED

100 Fals

(**) Do not automatically alter the values of these parameters which have been deprecated to hidden parameters in 10g, based on the recommendations for visible parameters in version 9i. The parameters below should be set according to the information documented in the following Siebel Bookshelf references: Siebel Installation Guide for Microsoft Windows Version 8.0 > Configuring the RDBMS > Configuring an Oracle Database for Siebel Applications > Guidelines for Configuring Settings in the init.ora File. Siebel Installation Guide for UNIX Version 8.0 > Configuring the RDBMS > Configuring an Oracle Database for Siebel Applications > Guidelines for Configuring Settings in the init.ora File. Siebel Installation Guide for Microsoft Windows: Servers, Mobile Web Clients, Tools Version 7.8 > Configuring the RDBMS > Configuring Oracle for Siebel Applications > Guidelines for Configuring Settings in the init.ora File.

Siebel Installation Guide for UNIX: Servers, Mobile Web Clients, Tools Version 7.8 > Configuring the RDBMS > Configuring Oracle for Siebel Applications > Guidelines for Configuring Settings in the init.ora File. Siebel Installation Guide for Microsoft Windows: Servers, Mobile Web Clients, Tools Version 7.7 > Guidelines for Configuring the RDBMS > Configuring Oracle for Siebel Applications.

Siebel Installation Guide for UNIX: Servers, Mobile Web Clients, Tools Version 7.7 > Guidelines for Configuring the RDBMS > Configuring Oracle for Siebel Applications. Oracle Parameter Description

Recomme Valu DB_FILE_MULTIBLOCK_READ_COUNT The database buffer cache parameter For most implementations, this value dictates the number of data blocks read in 32 blocks and adjusted as necessary a single Oracle I/O operation during a table value of 32. scan. SORT_AREA_SIZE This value is specified in bytes, and may Set PGA_AGGREGATE_TARGET in be adjusted according to the number of PGA_AGGREGATE_TARGET - You users, the amount of RAM available, and of 1,000,000 (1 MB). Optimal perform the size of sorted queries. Dictionary Managed TEMP tablespac a multiple of the SORT_AREA_SIZE SORT_AREA_RETAINED_SIZE Specifies (in bytes) the maximum amount Set PGA_AGGREGATE_TARGET in of the user global area (UGA) memory PGA_AGGREGATE_TARGET - Der retained after a sort run completes. The retained size controls the size of the read buffer, which Oracle uses to maintain a portion of the sort in memory. The following related parameters should be set by a trained DBA and according to the information in the applicable Oracle database documentation and requirements for your implementation. General guidance on these related settings is provided below: Oracle Parameter Description PGA_AGGREGATE_TARGET Specifies the target aggregate PGA memory available to all server processes attached to the instance. STATISTICS_LEVEL

All the advisories in Oracle9i Release 2 including the Buffer Cache Advisor are controlled by a newly introduced parameter STATISTICS_LEVEL. HASH_AREA_SIZE Relevant to parallel execution operations and to the query Set PGA_AGGREGATE_TARGE portion of DML or DDL statements. It specifies the PGA_AGGREGATE_TARGET maximum amount of memory, in bytes, to be used for hash joins. WORKAREA_SIZE_POLICY Specifies the policy for sizing work areas. This parameter If PGA_AGGREGATE_TARGET controls the mode in which working areas are tuned. PGA_AGGREGATE_TARGET is Optimizer Statistics Optimizer statistics on tables, columns and indexes are the single most important factor that drives the generation of optimal query plans. As such, it is important to ensure that accurate optimizer statistics are collected and made available to the query optimizer. Collecting Optimizer Statistics

General G For most production implementa of users, this value should be set PGA target advisory views for ad TYPICAL in production and ALL

Oracle provides two ways for collecting optimizer statistics: 1. Using the ANALYZE command 2. Using a PL/SQL package DBMS_STATS Oracle Corporation highly recommends using the DBMS_STATS package for optimizer statistics maintenance. This package has several options for collecting optimizer statistics. Each one of them has advantages and disadvantages. However, it should be mentioned that the more accurate optimizer statistics that are maintained will typically result in better execution plans. The examples below are only to illustrate some usages of DBMS_STATS to collect and delete statistics; do not use it as a guideline. For more details, please refer to the Oracle Database Performance and Tuning Guide and Reference, and Supplied PL/SQL Packages and Types Reference manuals. Collects the optimizer statistics for the table, columns, indexes and histograms for all columns. Recommend this method when the initial optimizer statistics collection window is enough (depending on the table size it may take more time to complete) and space is not a constraint.

EXECUTE DBMS_STATS.GATHER_TABLE_STATS( ownname => '<table owner>', tabname => '<table name>', method_opt => 'FOR ALL COLUMNS SIZE AUTO', granularity => 'ALL', cascade => TRUE, degree => DBMS_STATS.DEFAULT_DEGREE) Collects the optimizer statistics for the table, indexed columns, indexes and histograms for all indexes columns:

EXECUTE DBMS_STATS.GATHER_TABLE_STATS( ownname => '<table owner>', tabname => '<table name>', method_opt => 'FOR ALL INDEXED COLUMNS', granularity => 'ALL', cascade => TRUE, degree => DBMS_STATS.DEFAULT_DEGREE) Collects the optimizer statistics for the table, columns, indexes and histograms for columns where the data shape is skewed. Only collects histograms for skewed column. In general it is slower to execute therefore it would not be suitable when the optimizer statistic collection window is short.

EXECUTE DBMS_STATS.GATHER_TABLE_STATS( ownname => '<table owner>', tabname => '<table name>', method_opt => 'FOR ALL COLUMNS SIZE SKEWONLY', granularity => 'ALL', cascade => TRUE, degree => DBMS_STATS.DEFAULT_DEGREE) Collects only the optimizer statistics for the index. Useful when you add a new index.

EXECUTE DBMS_STATS.GATHER_INDEX_STATS( ownname => '<index owner>', indname => '<index name>')

Deleting Optimizer Statistics Deletes the optimizer statistics collected for the tables, all columns, indexes associated with the table:

EXECUTE DBMS_STATS.DELETE_TABLE_STATS( ownname => '<table owner>', tabname => '<table name>'); Deletes the optimizer statistics collected for the index:

EXECUTE DBMS_STATS.DELETE_INDEX_STATS( ownname => '<index owner>, indname => <index name>); Verifying Optimizer Statistics The followings Optimizer statistics are used by the Cost-based Optimizer in Oracle RDBMS 9i and 10g. Please refer to the Oracle Database Performance and Tuning Guide and Reference for more information. Table (DBA_TABLES, ALL_TABLES, USER_TABLES) o Number of row o Number of blocks o Average row length Column (DBA_TAB_COLUMNS, ALL_TAB_COLUMNS, USER_TAB_COLUMNS, DBA_HISTOGRAMS, ALL_HISTOGRAMS, USER_HISTOGRAMS) o Number of distinct value o Number of NULL o Density o Data distribution (Histograms) Index (DBA_INDEXES, ALL_INDEXES, USER_INDEXES) o Number of leaf block o Distinct Key o Levels o Clustering factor

To verify the optimizer statistics, you may use the STAT.SQL script provided below: Attachment 478028.1:1 This script can be run from the Oracle SQL*Plus utility. You need to provide the table name after the file. The output lists the optimizer statistics and also let you know when it was last collected. This helps you to understand the execution plan of a SQL statement and decide whether it is time to re-gather the statistics again. Example: SQL> @stat s_party

Table .... TABNAME LAST_ANALYZED NUM_ROWS BLOCKS AVG_ROW_LEN SAMPLE_SIZE -------------------- ------------------- ---------- ---------- ----------- -----------

S_PARTY Columns(s) ....

01-23-2004 11:58:25

5360604

32602

100

5360604

COLUMN_NAME LAST_ANALYZED NUM_DISTINCT NUM_NULLS DENSITY NUM_BUCKETS ------------------------------ ------------------- ------------ ---------- --------------- ----------ROW_ID 01-23-2004 11:58:25 5360604 0 .00000019 75 CREATED CREATED_BY LAST_UPD LAST_UPD_BY MODIFICATION_NUM CONFLICT_ID 01-23-2004 11:58:25 67931 0 .00000019 1 PARTY_TYPE_CD 01-23-2004 11:58:25 9 0 .00000009 8 PARTY_UID 01-23-2004 11:58:25 5360604 0 .00000019 75 ROOT_PARTY_FLG 01-23-2004 11:58:26 2 0 .00000009 1 GROUP_TYPE_CD 01-23-2004 11:58:26 18 145776 .00000010 17 NAME 01-23-2004 11:58:26 4654599 138347 .00000111 75 PAR_PARTY_ID 01-23-2004 11:58:26 15906 5344562 .00007114 75 Index(s) .... INDNAME LAST_ANALYZED LFBLK DKEYS ALVLBLK AVGDBLK BLEVEL ------------------ ------------------- ---------- ---------- ---------- ---------- ---------- ---------S_PARTY_F1 01-23-2004 11:58:32 23 15906 1 1 1030 1 S_PARTY_M1 01-23-2004 11:58:38 4837 2 2418 18798 37597 S_PARTY_M2 01-23-2004 11:59:31 13232 4679585 1 1 5475889 S_PARTY_M3 01-23-2004 12:00:21 13716 4679801 1 1 5059433 S_PARTY_M4 01-23-2004 12:00:59 9387 4679568 1 1 5233052 S_PARTY_P1 01-23-2004 11:58:31 6570 5468509 1 1 254834 S_PARTY_U1 01-23-2004 12:01:04 11084 5460497 1 1 110498 To verify the histograms, you may use the COLDIST.SQL script provided below: Attachment 478028.1:2 This script can also be run from the SQL*Plus utility. You need to provide the table name and column name to get the histograms. The histograms partition the values of the columns into bands, so that all column values in a band fall within the same range. It is similar to the column distributions on DB2/UDB database. It helps the optimizer to choose a better plan only when the data is highly skewed and the SQL statement uses a literal. Example: SQL> @coldist S_PARTY.PARTY_TYPE_CD Histograms .... ENDPOINT_NUMBER ENDPOINT_VALUE --------------- -------------31 3.3952E+35 73803 3.7611E+35 CF

2 2 2 2 2

1843632 5309265 5360486 5360493 5360507 5360521 5360604

4.1251E+35 4.1744E+35 4.1764E+35 4.1770E+35 4.3334E+35 4.3334E+35 4.4369E+35

Changes Made in Siebel 7.7, Siebel 7.8 and Siebel 8.0 for Supporting CBO

Some changes were made in the Siebel application to support Oracle CBO in Siebel 7.7, Siebel 7.8 and Siebel 8.0. The changes were mainly for the first rows optimization for the client queries. Typically the client queries fetch a screen full of rows, keep the cursor open and fetch more rows when the user presses next record set or next record on the last row. This makes it important to optimize the query plan for returning the first few rows quickly. For better performance in Siebel versions 7.8 and 8.0 connecting to Oracle 10.1.x or 10.2.x, with optimizer mode set as CBO, it has been observed that SQL query performance is satisfactory with the following two parameter settings in the init.ora file: _b_tree_bitmap_plans = FALSE _no_or_expansion = FALSE

The Siebel database connector makes the following session level changes, when the SQL style is set to Oracle CBO: Sets the optimization mode to the first_rows_10: ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_10 Disables hash join: ALTER SESSION SET HASH_JOIN_ENABLED = FALSE, for Oracle 9i. ALTER SESSION SET _HASH_JOIN_ENABLED = FALSE, for Oracle 10g Disables sort-merge: ALTER SESSION SET _OPTIMIZER_SORTMERGE_JOIN_ENABLED = FALSE Enables sanity check for join using two columns. These are done by issuing the following command: ALTER SESSION SET _OPTIMIZER_JOIN_SEL_SANITY_CHECK = TRUE

Whenever the query fetches all rows, a hint /*+ all_row */ gets appended to the SQL statement after the SELECT clause, to change the optimization technique to all rows. NOTE: Parameter HASH_JOIN_ENABLED has been deprecated to the hidden parameter _HASH_JOIN_ENABLED in Oracle 10g, which causes the following message to appear in the database alert log file: 08:59:06 2005 ALTER SESSION SET hash_join_enabled specifies an obsolete parameter Change Request 12-R5WXCB has been logged to address this product defect by changing the parameter HASH_JOIN_ENABLED to the hidden parameter _HASH_JOIN_ENABLED preventing the alert log error message. The alert log message regarding the deprecated parameter can be safely ignored in situations where it is generated. The behavior has been fixed in Siebel versions 8.0, 7.8.2.2 and 7.7.2.5.

References

Below are some additional references: Document 476301.1 which documents that Siebel version 6.x applications only support Rule based optimizer on Oracle databases. Document 477789.1 which documents that when upgrading to Siebel version 7.7 applications on Oracle 9i, you must use the rule based optimizer during the upgrade. Document 477690.1 which documents that you may encounter slow performance behaviors when using Oracle database version 9.x with Siebel eBusiness Application versions prior to Siebel version 7.7. Document 478242.1 which documents that sub-optimal execution plan can be generated by the Oracle Optimizer if the statistics are generated on empty tables. Oracle Database Performance and Tuning Guide and Reference. Oracle Database Reference.

This document was previously published as Siebel Technical Note 582.

Attachments

technote582-1_stat.zip (727 B) technote582-2_coldist.zip (542 B) Related

Products

Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel System Software