This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
� SIEBEL Applications is a business-critical large-scale application. Itsperformance should be kept as stable as possible
� SIEBEL Database Design is enterprise-wide� The same set of tables (~ 2500) and indexes (~15000) are used by all
SIEBEL modules (Call Center, Financials, HealthCare etc)� Therefore the generated SQL queries are pretty complex
� Usually 30-40 tables are joined� Up to 60-70 table joins are not unusual� Many outer joins - almost not tunable, since the table join order must be preserved
� SIEBEL Applications is a pretty interactive application� What counts to the end-user is how fast the first lines come on the screen
� SIEBEL Applications is confugured through a special SIEBEL Configuration Tool� Code must be kept as generic as possible to preserve the idea of database
independence� No knowledge of the Orace specialties (function-based indexes, bitmap
� As of 9i the official recommendation changed� CURSOR_SPACE_FOR_TIME=FALSE� Shared Pool management was vastly improved� Oracle splits Shared Pool in subheaps, if SHARED_POOL parameter is set
big enough� the number of subheaps depends on the size of SHARED_POOL and CPU count� each subheap is managed separately as if the subheap represents the whole
Shared Pool� separate latches („row cache objects“) for each subheap
� It is impossible to control to which subheap each SQL or PL/SQL code will beassigned� ORA-04031 still possible
� _KGHDSIDX_COUNT controls the number of subheaps� 2-3 subheaps are enough, but each subheap should be at least 400MB
� DB_CACHE_ADVICE = OFF reduces Shared Pool fragmentation further� DB_CACHE_ADVICE = READY and then could be changed online if needed
� SIEBEL Applications obeys „first records should come instantly“ principle� Almost all accesses are index-oriented� A couple of indexes of the central data model tables (like
S_CONTACT, S_EVT_ACT, S_PARTY, S_ORG_EXT) are used overand over again(concurrently)
� These indexes are ideal candidates for KEEP cache pool� Assumes static configuration of DEFALT database cache, and
SHARED_POOL� Some tables (S_CONTACT, for example) are read anyway entirely, but
over index� this is a consequence of the configuration
� The ultimate goal of database configuration is to deliver the first row on the users screen as fast as possible� This doesn‘t necessarily mean that the database resources should be used
in the most optimal way� CBO must be forced to
� use NESTED LOOPS for joins� force CBO to prefer index accesses
� Right after creation of each session SIEBEL Application Server issuesthe following SQL statements� Could not be overridden with database LOGON trigger
alter session set optimizer_mode = first_rows_10;alter session set hash_join_enabled = false;alter session set "_optimizer_sortmerge_join_enabled" = false;alter session set "_optimizer_join_sel_sanity_check" = true;
� Production SIEBEL databases are very sensitive about database statistics changes� too many session and instance level parameters skew the picture from CBO� Should not be gathered too frequently
� Every 2-6 months depending on the situation, releases� Should be saved first (with DBMS_STATS.EXPORT_SCHEMA_STATS, for
example) before refreshing them (Oracle 10g does this anyway)� Gathering statistics only on indexed columns (without histograms) is a good
start� Presence/absence of histograms on specific columns can determine the
performance of specific or whole class of SQL queries� For some tables (EIM_*) it is better NOT to have statistics� Oracle uses hard-coded defaults :AVG_ROW_LEN=100, CLUF =800
� OPTIMIZER_DYNAMIC_SAMPLING =1� Statistics on function-based indexes should be gathered explicitly� Manipulating NUM_DISTINCT column statistic is usually enough
� Some of session and instance level parameters constrain the optimizerchoices and skew the real picture of the data� Session parameters
� Instance parameters
� That is why sometimes additional changes need to be made� Create stored outlines� Manipulate statistics
SQL tuning
alter session set optimizer_mode = first_rows_10;alter session set hash_join_enabled = false;alter session set "_optimizer_sortmerge_join_enabled" = false;alter session set "_optimizer_join_sel_sanity_check" = true;
� The parameters make CBO to favour index access on tables in order to avoid SORT operation in the executon plan� „first row should be presented to user as fast as possible“ principle
� Table S_ORG_EXT seems attractive to CBO because� It has many predicated on it, although all of them are not selective (97% of
all table rows)� The presence of index on S_ORG_EXT(NAME, LOC) + ORDER BY on
� Quite often user wants to see last records of one of the main screens (Activities, Contacts, Accounts etc)� Tables S_EVT_ACT , S_CONTACT are usually big ( a couple of
million records)� SIEBEL Application Server sends SQL request to Oracle � Oracle gets all records from the main table (S_EVT_ACT, for
example), sorts them, so that that last records are presented to the user first, and sends to result to the Application Server
� The User scrolls a couple of pages down (each page is ~ 30 records), until he/she (eventually) finds the needed information
� User switches to another screen, thus using maximal first sorted 1000 records. The rest (a couple of million records) will be discarded and will never be used by the user� Only 4-5 of user sessions of this type could bring the whole database to
knees� The only remedy so far is to force index usage to avoid the monster sort
� Benefits� ResultSet is constrainted as early as possible (via predicate)� S_EVT_ACT could be partitioned (partition pruning)� No unnessary polution of cache with index blocks on
S_EVT_ACT.CREATED)� Stored outlines /SQL Profiles are not needed anymore
The “pacthed” SQL
SELECT T23.CONFLICT_ID,.... --- another ~ 250 columnsFROM
...SIEBEL.S_EVT_ACT T23
WHERE...
(T23.PRIV_FLG=:s3 OR T23.PRIV_FLG IS NULL AND(T21.CON_ID=:s5)AND T23.CREATED >= :s6ORDER BY T23.CREATED DESC;
Knowledge transfer is only the beginning. Knowledge application is what counts.
� Correctly configuring Oracle forSIEBEL is not an easy task� Can be pretty rewarding, though
� In-depth knowledge and understandingof Oracle and especially CBO isrequired to get optimal performance, especially if the application is heavilycustomized
� Knowledge is good, but the real poweris the combination of knowledge and experience