1. Enhancing SIEBEL Application
Performance – DB Perspective
- T.Mohan Reddy

2. ©Company confidential 2
Context
Application Performance

3. ©Company confidential 3
Types
 Major Types of Poor Performance
 Entire Application response is slow
 Specific Task or Processes perform poorly
 Certain views take a longtime to load
 Batch interface takes hours to execute
 Particular Tasks are Cumbersome

4. ©Company confidential 4
Objective
 Key Factors Influencing Application Response
 Database Configuration Guidelines for Siebel CRM
 Detect and Diagnose
 Real Life Experiences

5. ©Company confidential 5
Key Factors Influencing Performance
 Operating System Settings
 Network Topology and throughput
 Server Hardware Configuration
 Database Server Configuration settings
 Queries/Tasks from Other Applications

6. ©Company confidential 6
Database Configuration Guidelines
 Setting right values to oracle DB Parameters
 Gathering Statistics
 SIEBEL OM Session Parameters
 Peeking User Binds
6

7. ©Company confidential 7
DB Parameters
 More than 60 Oracle database parameters affect the generation of query
plans and execution of SQL statements
 OPTIMIZER_FEATURES_ENABLE
 It is always a good idea to set the this parameter to a value corresponding to the Oracle
Database patch version being used
 OPTIMIZER_INDEX_COST_ADJ
 It is Strongly recommended to set this parameter to 1 because in-house tuning of Siebel CRM
application was performed with OPTIMIZER_INDEX_COST_ADJ = 1 setting
 OPTIMIZER_DYNAMIC_SAMPLING
 It is recommended to set this parameter value to 1 and follow the instructions pertaining to
the collection of Optimizer statistics for Siebel CRM data tables
 STATISTICS_LEVEL
 It is recommended to set this value to TYPICAL level
7

8. ©Company confidential 8
Gathering Statistics
 Deleting Optimizer Statistics
 Locking Optimizer Statistics
 Collecting Optimizer Statistics
 Frequency of Updating Statistics
 Recommended Script to Collect Optimizer Scripts
8

9. ©Company confidential 9
SIEBEL Hard-Coded Session Parameters
 Beginning with Siebel 7.7 and 7.8 on Oracle Database 9i, the
Siebel database connector was modified to make a few ALTER
SESSION statements for OLTP operations
 The same functionality has been built into the Siebel database
connectors for Oracle 10g and 11g.
 Each Siebel Application Object Manager session automatically
sets the following session parameters
 ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_10
 ALTER SESSION SET HASH_JOIN_ENABLED = FALSE (_hash_join_enabled)
 ALTER SESSION SET _OPTIMIZER_SORTMERGE_JOIN_ENABLED = FALSE
 ALTER SESSION SET _OPTIMIZER_JOIN_SEL_SANITY_CHECK = TRUE
9

10. ©Company confidential 10
Peeking of User Binds in Siebel
 Siebel Application Object Manager (AOM) generates SQL
statements with the syntax :n in the WHERE clause, for example
 select LAST_NAME from S_CONTACT where TIMEZONE_ID=:n;
 SIEBEL AOM substitutes the real values for the placeholder(s) to
seek a better query plan. This is called “peeking of user binds” or
simply “bind peek”
 SIEBEL relies on the operating system environment variable
SIEBEL_ORA_BIND_PEEK, The default value is Set to FALSE
10

11. ©Company confidential 11
Detect & Diagnose
 Capture Long running SQLs Using Oracle EM
 Detection of columns requiring index
 Analyze Explain Plan
 Stored Outlines
 Governor Tool
11

12. ©Company confidential 12
Long running SQL’s
12
 Look for Long running SQL’s (Including the other system queries
on SIEBEL DB)

13. ©Company confidential 13
Columns requiring Index
13
 Using the Siebel Profiling SQL, detect the Columns requiring Index

14. ©Company confidential 14
Example Query Plan
14
 Query which was running for almost 3 hrs
 The same tuned Query running in less than 10 Mins

15. ©Company confidential 15
Stored Outlines
 A stored outline is a collection of hints associated with a specific SQL statement that allows a standard
execution plan to be maintained
 Collect the Long running SQL’s (from shared pool)
 Create an outline on the original SQL
 Create an outline for the hinted SQL
 Update the OUTLN.OL$HINTS table to replace the outline of ORIGINAL SQL with the HINTED SQL
 Drop the Outline with the Hinted SQL
 When the same SQL is issued to the DB , now the DB is forced to use the Hinted SQL instead of the Original one
15
insert into SIEBEL.S_DOCK_INITM_1
(PR_TBL_ROW_ID, DOCK_NAME, NODE_ID,
VIS_STRENGTH)
select DISTINCT T1.SHIP_OU_ID PR_TBL_ROW_ID_T,
'PTY-O' DOCK_NAME_T,
di.NODE_ID NODE_ID_T, 50 VIS_STRENGTH_T
from SIEBEL.S_ORDER_ITEM T1,
SIEBEL.S_DOCK_INITM_1 di
where di.NODE_ID = :v1
and di.DOCK_NAME = 'Z40'
and di.PR_TBL_ROW_ID = T1.ORDER_ID
and di.VIS_STRENGTH >= 100
and T1.SHIP_OU_ID is not null
and T1.SHIP_OU_ID <> 'No Match Row Id'
and not exists
(select 'X'
from SIEBEL.S_DOCK_INITM_1 di2
where di2.NODE_ID = :v2
and di2.DOCK_NAME = 'PTY-O'
and di2.PR_TBL_ROW_ID = T1.SHIP_OU_ID)
insert into SIEBEL.S_DOCK_INITM_1
(PR_TBL_ROW_ID, DOCK_NAME, NODE_ID,
VIS_STRENGTH)
select /*+ PARALLEL ( T1 2) PARALLEL ( di 2) USE_HASH( di
t1) */ DISTINCT T1.SHIP_OU_ID PR_TBL_ROW_ID_T, 'PTY-O'
DOCK_NAME_T,
di.NODE_ID NODE_ID_T, 50 VIS_STRENGTH_T
from SIEBEL.S_ORDER_ITEM T1,
SIEBEL.S_DOCK_INITM_1 di
where di.NODE_ID = :v1
and di.DOCK_NAME = 'Z40'
and di.PR_TBL_ROW_ID = T1.ORDER_ID
and di.VIS_STRENGTH >= 100
and T1.SHIP_OU_ID is not null
and T1.SHIP_OU_ID <> 'No Match Row Id'
and not exists
(select 'X'
from SIEBEL.S_DOCK_INITM_1 di2
where di2.NODE_ID = :v2
and di2.DOCK_NAME = 'PTY-O'
and di2.PR_TBL_ROW_ID = T1.SHIP_OU_ID)
ORIGINAL SQL HINTED SQL

16. ©Company confidential 16
Live Scenario 1
Scenario :
 Four Dedicated SIEBEL Remote Servers(Production) with very good
Configuration
 Total number Mobile Clients to Extract is 400
 Mobile Extracts were taking 3 days in every cycle
 Collected all the Long Running SQL’s and Tuned During Mobile Extract
 Created Stored Outlines for the original and tuned (Hinted) SQL’s
 Swapped the original and hinted outlines
 Started the Mobile Extracts
16

17. ©Company confidential 17
Live Scenario 1 - Results
The entire operation now gets completed in
12 Hours
17

18. ©Company confidential 18
Live Scenario 2
Scenario :
 Two Load balanced SIEBEL Servers(Production) with very good
Configuration
 Oracle Standard Gather Statistics Job (comes with Oracle 10g & 11g)
 Live with 50 routes out of 400 (One Distribution Center)
 Expanded one more Distribution Center
 HH Synchronization timings increased drastically and started failing, which
became a show stopper
 Implemented the Gather Statistics Job recommended by the Oracle
 Deleted the statistics and locked the tables which has rows less than or equal
to 15 rows
 Set the DB Parameters according to the reccomendations
18

19. ©Company confidential 19
Live Scenario 2- Results
Each HH Synchronization completes in
10 to 12 Minutes
19

20. ©Company confidential 20
Governor Tool
 Mandatory to have a Governor Tool/ Tasks
 Monitoring
 Services & Components
 Storage
 Long Running SQL’s & ETL Jobs
 Alert the specific users for specific tasks
 Kill the Long Running SQL’s before it affects the other users

21. ©Company confidential 21
Governor Tool
 Web Based Governor Tool

22. ©Company confidential 22
Governor Tool – Sample Alert

23. ©Company confidential 23
Thank you