Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Summary: Microsoft SQL Server 2008 offers best-of breed performance for Siebel.
This paper describes the capabilities of SQL Server 2008, how to maximize database
performance for Siebel, and how to resolve common issues encountered by customers.
Copyright
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it
should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement
from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
Microsoft, Visual Basic, Visual Studio, Win32, Windows, and Windows Server are either registered trademarks
or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
Contents
Executive Summary ...........................................................................................1
Siebel Architecture ............................................................................................2
SQL Server 2008 Features .................................................................................4
Scale and Performance .................................................................................... 4
Data Compression ...................................................................................... 4
Enhanced Lock Escalation ............................................................................ 5
Predictable Query Performance .................................................................... 6
Plan Freezing ............................................................................................. 7
Resource Governor ..................................................................................... 8
Enhanced High Availability ............................................................................... 9
Enhanced Database Mirroring ...................................................................... 9
Geographically-dispersed Cluster Services ..................................................... 9
Mirrored Backup Set ................................................................................... 9
Backup Compression ................................................................................ 10
Powerful Monitoring and Tools ........................................................................ 10
Performance Data Collection ...................................................................... 10
Policy-based Management ......................................................................... 12
Enhanced Security and Compliance ................................................................. 12
Transparent Data Encryption ..................................................................... 12
Extensible Key Management ...................................................................... 13
Auditing .................................................................................................. 13
Configuration Management .............................................................................14
Configuration Parameter – Max Degree of Parallelism ........................................ 14
Configure Memory ......................................................................................... 15
Configure Data and Log Files .......................................................................... 16
Configure TempDB ........................................................................................ 17
Configure Network Packet Size ....................................................................... 18
Ongoing Maintenance and Monitoring .............................................................19
Defragmenting Tables and Updating Statistics .................................................. 19
Significant events necessitating Maintenance .................................................... 20
After initial creation of the Siebel Database ................................................. 21
After a Repository migration ...................................................................... 21
After mass data changes ........................................................................... 21
After a Siebel product upgrade................................................................... 21
Ongoing in the Siebel Development environment ......................................... 21
Performance Monitor ..................................................................................... 21
Performance Tuning ........................................................................................23
Identifying and Tuning resource-intensive SQL statements ................................. 23
SQL Server Profiler ........................................................................................ 24
Data Management Views (DMVs)..................................................................... 26
Database Engine Tuning Advisor ..................................................................... 27
Common Questions .........................................................................................28
Case-insensitive Search ................................................................................. 28
Change Database Collation ............................................................................. 29
Dropping Indexes .......................................................................................... 30
Reporting against a mirror Database ............................................................... 31
Partitioned Tables ......................................................................................... 32
EIM Performance ........................................................................................... 34
No mixed workload, EIM involving low-volume Tables ................................... 35
No mixed workload, EIM involving moderate/high-volume Tables ................... 35
Mixed workload, EIM involving low-volume Tables ........................................ 36
Mixed workload, EIM involving moderate/high-volume Tables ........................ 36
Appendix 1 – REINDEX Script ..........................................................................37
Appendix 2 – Maintenance Plans .....................................................................40
Appendix 3 – Traced SQL statement ................................................................41
Appendix 4 - Identify and resolve a suboptimal Execution Plan ......................43
Message and Audience
This paper focuses on the capabilities of SQL Server 2008, the advantages of using SQL
Server 2008 with Siebel CRM Applications, provides guidance for maximizing
performance, discusses common questions, and provides solutions to some common
problems.
In order to fully comprehend the concepts covered in this paper, the reader should have
a general understanding of databases, SQL Server, and Siebel. We also assume the
reader is or will be using the referenced databases on their preferred hardware
platforms.
Executive Summary
Microsoft SQL Server 2008 offers many improvements and new capabilities for Siebel.
Several SQL Server 2008 features offer immediate benefit and require minor projects to
implement:
Monitoring, Troubleshooting, and Tuning. The Database Administrator can
implement a comprehensive database-monitoring solution using Performance
Data Collection and the Management Data Warehouse.
Backup Compression. The on-disk footprint for backups of the Siebel database
can be immediately reduced by as much as 75%. Moreover, the elapsed time
for backups may be reduced as much as 43%.
Data Compression. The on-disk footprint for the Siebel database may be
reduced by as much as 45%. Moreover, runtime performance of Siebel may
improve by as much as 25% since compressed data is being retrieved from the
I/O subsystem.
Take advantage of SQL Server 2008’s industry-leading performance and scalability for
real-world database workloads with the lowest cost of operation, as verified by
Microsoft partners and industry-standard Transaction Processing Performance Council’s
TPC benchmarks.
Oracle has certified SQL Server 2008 for Siebel 7.8, Siebel 8.0, and Siebel 8.1.
Siebel Architecture
The following diagram illustrates a sample Siebel deployment (diagram from Oracle’s
Siebel Performance Tuning Guide v8.0).
The actual topology, components, and number of servers for a Siebel deployment will
be influenced by any of the following considerations:
Desired business functionality, and Siebel components in use.
Business expectations for Siebel availability.
Planned workload, including concurrent users and asynchronous processes such
as Workflow or integration (EAI).
The processor, memory, and storage capacity for SQL Server 2008 must be aligned
with these considerations.
SQL Server 2008 Features
A HP, Microsoft, and Oracle benchmark demonstrated that SQL Server 2008 could scale
to 12,000 concurrent users with almost 1.5 million daily transactions.
Data Compression
SQL Server 2008 allows the Database Administrator to selectively compress tables
using two levels of compression (ROW or PAGE). Data compression is transparent to
Siebel, and may be selectively enabled or disabled during off-peak hours or
maintenance windows using the ALTER INDEX command with the DATA_COMPRESSION
parameter. The Database Administrator might choose to initially compress historic or
mostly read-only Tables, and then compress all Tables.
SQL Server 2008 has the ability to compress data for selected tables, indexes, or
partitions. Data compression provides relief for the common problem of the I/O
bottleneck for many Siebel implementations.
The Database Administrator can create and retain maintenance scripts and Maintenance
Plans that assume all Tables are (or will be) compressed in the Siebel database. If the
Database Administrator prefers to selectively implement ROW compression then
consider that Tables, Indexes, or Partitions should be selected for compression when
the subsequent reduction in I/O will be greater than the subsequent increase in
processor consumption. For simplicity of management, if there is a desire to
implement ROW compression then it may be best to do so for all Tables.
Alternatively, the Database Administrator must carefully track which Table has which
type of compression (if any) enabled for it.
For the Siebel database, Siebel does not support the option DATA_COMPRESSION in its
data-definition language (DDL) statements, so the Database Administrator must
implement compression using the ALTER TABLE or ALTER INDEX statement with a
REBUILD clause. The option DATA_COMPRESSION may be set to NONE, ROW, or
PAGE. Please see an example in Appendix 1 of the document.
Most Tables may be changed to NONE, ROW, or PAGE compression and remain in an
online mode. However, partitions of a Partitioned Table can only change their
compression setting in an offline mode.
Please be aware that if the definition of an Index changes (e.g. a custom Index or a
Siebel product upgrade) in the Siebel Repository and that Index was selectively created
using compression, then Siebel’s Database Utility (formerly called DDLSYNC) will drop
and recreate the Index without compression.
the logical unit of work (LUW) contains more than 5,000 records
the LUW processes (INSERT, UPDATE, or DELETE) more than 20% of the records
in the Table.
Lock Escalation on Partitioned Tables is isolated to the individual Partition, and will not
escalate to the entire Table. This is an improvement with SQL Server 2008.
The Execution Plan includes the sequence each Table will be accessed, the amount of
parallel processing, the Index used to access each Table, any interim result sets, the
type of Joins used between Tables and interim result sets, and so on. SQL Server
evaluates dynamic factors such as statistics for each Table and Index, and any
parameters in the SQL statement.
The cached Execution Plan then resides in memory until an event occurs that may flush
it from the cache. For example:
Time to live (TTL), and level of reuse. SQL Server will drop an Execution Plan
that has been cached for a period of time. The exact amount of time is
influenced by the level of reuse of that cached Execution Plan, memory pressure
on SQL Server, and so on.
Revised statistics generated for a Table. Manually-generated statistics or
automatically-generated statistics for a Table will cause SQL Server to drop all
cached Execution Plans involving that Table.
Data Definition Language (DDL) statements exist in the logical unit of work.
Note that this does not occur in normal Siebel operations, but it is called out in
the document for the sake of completeness. One example is the creation of
temporary Tables (local or global) in a Stored Procedure.
Stop SQL Server. All cached Execution Plans are dropped.
Plan Freezing
SQL Server 2005 introduced Plan Guides and the USE PLAN hint. SQL Server 2008
introduces Plan Freezing for Plan Guides. Plan Freezing builds on the Plan Guides
framework by introducing an easier method to create Plan Guides. With Plan Freezing,
it is now possible to create a Plan Guide based on data already available in the SQL
Server plan cache (using it’s corresponding plan handle, etc.).
-- Create a plan guide for the query by specifying the query plan in the
plan cache.
DECLARE @plan_handle varbinary(64);
DECLARE @offset int;
SELECT @plan_handle = plan_handle, @offset = qs.statement_start_offset
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS st
CROSS APPLY sys.dm_exec_text_query_plan(qs.plan_handle,
qs.statement_start_offset, qs.statement_end_offset) AS qp
WHERE text LIKE N'SELECT WorkOrderID, p.Name, OrderQty, DueDate%';
EXECUTE sp_create_plan_guide_from_handle
@name = N'Guide1',
@plan_handle = @plan_handle,
@statement_start_offset = @offset;
GO
Resource Governor
Control resource utilization to prioritize key workloads with Resource Governor. Ensure
that mission-critical database workloads are not adversely affected by other database
activity. Resource Governor allows the Siebel Administrator to effectively manage
system resources between batch workloads (e.g. EAI or EIM) and online/user workload
(e.g. Call Center), and adjust workload resource allowance for different hours of the day
according to business requirements.
Resource Governor allows the Database Administrator to control and set limits on
resource consumption for an incoming request. The limits are specified for processor or
memory consumption. Resource Governor may be beneficial for any of the following
scenarios:
Unpredictable workload execution.
Prioritization of work.
Tests of backup compression showed as much as a 75% savings on disk space (for the
backups). These results will vary between Siebel implementations, but backup
compression may result in substantial savings. The backup operation may also
complete as much as 43% faster, which is important for Siebel implementations with
small outage windows or 24x7 operations.
Implementation is easily and relatively quick. Backup compression will default to the
server setting but can be enabled by using the COMPRESSION parameter
(NO_COMPRESSION for no compression) or by selecting the option in SQL Server
Management Studio. Note that you cannot blend compressed and uncompressed
backups to the same back media. For example:
1. Open SQL Server Management Studio.
2. Connect to SQL Server.
3. Right-click on the siebeldb database and select Tasks -> Back Up.
4. Click on the Options page, and set backup compression to Compress Backup.
5. Set other desired options.
6. Click on OK to create the compressed backup.
Data Collectors for each SQL Server instance submit their data to the Management Data
Warehouse (MDW). The Database Administrator may choose to implement a MDW on
each SQL Server instance, or a central MDW.
The System Data Collection Sets include predefined properties such as collection mode
and frequency, upload frequency, and retention period. You may change these values
using SQL Server Management Studio (right-click on the Collection Set and select
Properties). The three System Data Collection Sets include:
Disk Usage.
Query Statistics. This is of immense value to Siebel Administrators and
Database Administrators since it is now easier to identify resource-intensive SQL
statements. Right-click on Data Collection and select Reports -> Query
Statistics History. SQL statements can be ranked (sorted) by CPU, Duration,
Total I/O, Physical Reads, and Logical Writes.
Server Activity. The report Server Activity History presents a dashboard of
metrics for the Database Administrator, including % CPU, Memory Usage, Disk
I/O Usage, Network Usage, SQL Server Waits, and SQL Server Activity.
Once collecting data, the Database Administrator can easily obtain symptoms and
trends on the health of the Siebel database.
Policy-based Management
Policy-based Management is a framework for managing one or more instances of SQL
Server 2008. Database Administrators can use this framework to ensure the overall
system configuration is in compliance with best practices, monitor and prevent changes
to the system that violate best practices, and reduce total cost of ownership by
simplifying administration tasks.
For example, the Database Administrator can implement a Policy that periodically
checks many items in the configuration, including the parameter Max Degree of
Parallelism.
For example, the Database Administrator can encrypt the entire Siebel database with
no changes needed on the Siebel Server(s), Siebel Tools, Mobile Web Clients, and so
on. Note that encryption may be enabled for the entire database, but not for selective
tables or columns.
The database pages are decrypted once read into SQL Server memory, and encrypted
any time a page is written to disk. Moreover, backups are fully encrypted once
encryption is enabled on the Siebel database.
There is a slight cost to initially enable encryption an existing Siebel database. The
enabling of encryption may be done while Siebel is online, but this decision is at the
discretion of the Database Administrator. There is also a slight cost for the ongoing
encryption and decryption events during normal operations of Siebel, but this cost
should be negligible.
Auditing
Create and manage auditing via DDL while simplifying compliance by providing more
comprehensive data auditing. This enables organizations to answer common questions
such as “Who accessed our customer data?”.
The Siebel Administrator may choose to augment Siebel’s audit capabilities with SQL
Server’s audit features. For example, the Audit Trail feature in Siebel 7.8 does not
audit read (SELECT) events.
Configuration Management
Microsoft wants you to maximize your success with Siebel and SQL Server 2008.
Please consider these changes for your Siebel implementation(s) to mitigate the risk of
a performance problem due to a default or poorly-configured SQL Server environment.
For example:
A value of zero (0) means SQL Server may create an Execution Plan (for a SQL
statement) that concurrently utilizes up to the total number of processors
available to SQL Server.
A value of one (1) means SQL Server may create an Execution Plan (for a SQL
statement) that concurrently utilizes one and only one processor.
A value of two (2) means SQL Server may create an Execution Plan (for a SQL
statement) that concurrently utilizes up to two (2) processors available to SQL
Server.
Change this parameter to a value of one (1) in all of your Siebel environments.
This guidance is also documented in Siebel Bookshelf. Oracle conducts all Siebel-
related functional and performance tests with this parameter set to one (1). Use of a
different value may cause unpredictable results.
Use the command sp_configure to review the value for the parameter.
Use SQL Server Management Studio and a sequence of commands (below) to change
the parameter to one (1):
use siebeldb
go
sp_configure 'max degree of parallelism', 1
go
reconfigure with override
go
5. Click on Execute or press F5.
Setting MAXDOP to one (1) does not constrain the Database Administrator from using a
different value for many operations. For example:
The default value for MAXDOP can be overridden at the query level or batch
level using the MAXDOP hint. The hint may be specified in the query or
indirectly via a Plan Guide for the query.
MAXDOP can be specified in commands such as ALTER INDEX REBUILD, ALTER
TABLE, CREATE INDEX, DBCC CHECKTABLE, and DBCC CHECKDB.
For further information from Microsoft's Siebel Resource Center, please see:
Tech Note 32 - SQL Server Parallelism and Siebel
For further information from Oracle/Siebel, please see the relevant version of Siebel
Bookshelf, and specifically the section Configuring the RDBMS in the Installation
Guide.
Configure Memory
SQL Server 2008 offers excellent management of the allocated memory resources and
requires minimal configuration by the Database Administrator.
The two primary parameters to review or change are Minimum Server Memory and
Maximum server memory. The minimum amount of memory should be set to a
value such that SQL Server is still guaranteed some amount of memory in case of
memory pressure across the operating system. The maximum amount of memory
should be capped such that there is still memory available to the operating system and
other services running on the same server.
For SQL Server 2008, check to ensure the values are defined as expected:
5. Adjust the Minimum server memory value (in MB). Set to a value that
guarantees some amount of memory, and is less than Maximum server
memory.
6. Adjust the Maximum server memory value (in MB). Ensure that this
maximum still leaves memory for the operating system, and possibly other
services or applications running on the same operating system. For 32-bit
systems, see TechNote 21 (link is below). For 64-bit systems, a general rule of
thumb is to leave 2 GB for every 16 GB on the machine.
For further information from Microsoft's Siebel Resource Center and additional
resources, please see:
TechNote 21 - Memory Configuration for SQL Server 2000
SQL Server 2008 Books Online - Memory Architecture
3. Right-click on the siebeldb database (your database name may vary) and select
Properties.
5. Adjust the Initial Size values of the Data and Log Files as needed for each
Siebel environment (Development, Test, etc.). It is recommended that the
Initial Size of the Data File be at least 2048 MB and the Initial Size of the Log
File be at least 100 MB for all Siebel environments.
6. Adjust the Autogrowth values of the Data and Log Files. It is recommended
that the file be set to grown in MB (and not as a percentage of the Initial Size).
It is further recommended that the Data file be set to grow in at least 10 MB
increments. The optimal value for Autogrowth will be influenced by the speed
and isolation of the I/O subsystem hosting the TempDB Data file(s) – attempting
to auto-grow the Data file by a large amount (e.g. 100 MB) on a slow or busy
I/O subsystem may temporarily cause slowness in SQL Server.
8. Ensure that Auto Shrink is False. This prevents SQL Server from attempting to
automatically shrink the Data and Log files, especially during significant activity
in the database.
Configure TempDB
Ensure the data file(s) for TempDB reside on a fast I/O subsystem (ie., treat TempDB
just like your Data files). Ideally, ensure that the data file(s) for TempDB are on an
isolated I/O subsystem (not used by any other SQL Server data files, not used by the
operating system for its files, and so on).
3. Expand the Databases folder and then the System databases folder.
Right-click on TempDB and select Properties.
5. Consider adding more Data files. The rule of thumb is to have one Data
file for every two processors/CPUs. For example, utilize four Data files if
there are eight processors on the hardware.
6. Increase the Initial Size of each Data file. The recommended minimum
is 500 MB. Increase to the size of the largest Table if that Table is more
than 500 MB. Note that the REINDEX script in Appendix 1 specifies that
sort activity (when rebuilding Indexes) should occur in TempDB.
The SQL Server parameter Network Packet Size controls the network packet size on
SQL Server. The array-fetch data buffer of the Siebel data connector is set to 8192
bytes on every Siebel Server and is used by the Components on the Siebel Server, so
the SQL Server parameter may be set to the same value to minimize the number of
network round trips (and therefore improve performance).
Developers using Siebel Tools may experience better performance in the Siebel
Development environment if the Network Packet Size is left at the default
value of 4096 on the SQL Server instance hosting the Development Siebel
database. Siebel Tools does not use the Siebel data connector to communicate
with the Siebel database, and instead connects directly using an ODBC driver.
Use the command sp_configure to review the value for the parameter.
Use SQL Server Management Studio and a sequence of commands (below) to change
the parameter to 8192:
use siebeldb
go
sp_configure 'network packet size (B)', 8192
go
reconfigure with override
go
5. Click on Execute or press F5.
Ongoing Maintenance and Monitoring
Microsoft wants you to maximize your success with Siebel and SQL Server 2008.
Please consider these maintenance activities for your Siebel implementation(s) to
mitigate the risk of a performance problem.
Number of distinct values in a Column, and the number of rows matching each
distinct value in that Column
SQL Server has the ability to automatically create and update statistics. SQL Server
will choose when to automatically update the statistics for a Table – the decision criteria
is based on the number of rows or percentage of rows inserted, updated, or deleted
from a Table.
The parameters Auto Create Statistics and Auto Update Statistics are enabled by
default. Check to ensure the parameters are defined as expected:
3. Right-click on the siebeldb database (your database name may vary) and select
Properties.
5. Ensure that Auto Create Statistics is True, and Auto Update Statistics is
True.
6. Ensure that Auto Update Statistics Asynchronously is False. This was a new
feature in SQL Server 2005 and is available in SQL Server 2008, but additional
testing is still pending from Oracle relative to its use with Siebel. Expect future
guidance on if and when to enable this feature.
The ability to auto-update statistics is a strength of SQL Server, but this feature is
frequently misunderstood by Database Administrators. The creation (or recreation) of
statistics involves a full pass of a Table. The updating of statistics involves a sampling
of a subset of the rows in a Table.
Do not assume that the auto-update statistics feature alleviates the need for
periodic database maintenance. As a Table grows, the default sampling rate may
be insufficient for auto-update statistics. A long-term reliance on auto-update
(sampling) statistics for quickly-growing, active, or large Tables may ultimately result in
non-representative statistics, which will provide inaccurate information to the Optimizer
and thus result in suboptimal Execution Plans. Suboptimal Execution Plans will rapidly
degrade the performance of SQL Server and Siebel.
Even though a Siebel schema contains thousands of Tables, the time to defragment and
recreate statistics for most Tables is insignificant since the majority of Tables have less
than 10,000 rows. A Siebel Development environment with one Repository and low
data volumes would probably conclude in five to 15 minutes. This does not imply that
the total time to defragment and recreate statistics for the entire Siebel database will
conclude in less than 15 minutes. The best method to estimate the total elapsed time
is to run the process against a backup copy of the Production database. Factors
influencing the total elapsed time include:
Amount of Columns populated for any Table, and size of the data populated in
these Columns. For example, one Siebel implementation may capture minimal
data for each Contact whereas a separate Siebel implementation may be
capturing extensive data for each Contact.
Total records for any Table. A Table with 10 million rows will naturally take
longer to process than the same Table (and Indexes) with one (1) million rows.
Total Indexes for any Table. A Table with a large number of Indexes will take
longer to process than a similar Table with few Indexes.
Please see the REINDEX script in Appendix 1 of the document, and the discussion of
Maintenance Plans in Appendix 2 of the document.
Performance Monitor
Performance Monitor (PerfMon) allows the Database Administrator to monitor multiple
performance counters for the operating system, SQL Server, and so on. PerfMon may
be run from the server or from most Windows-based computers.
1. Select Start -> Run, type perfmon, and click OK.
2. Multiple Counters for the local machine are selected by default. You may
monitor or remove these Counters.
3. Click on the Properties icon, change the sampling rate from one (1) second to
perhaps 15 or 30 seconds, and click OK.
4. Press CTRL+H to enable/toggle the highlight feature. This will highlight the
Counter observations in the graph as you highlight each monitored Counter.
Press CTRL+H again if you wish to toggle off the highlight feature.
5. Click on the Add Counters icon and add these recommended Counters.
Processor - % Processor Time (_Total)
SQLServer:Buffer Manager – Buffer Cache hit ratio
SQLServer:Buffer Manager – Page life expectancy
SQLServer:Databases – Active Transactions (siebeldb)
SQLServer:Locks – Lock Waits/sec (_Total)
SQLServer:SQL Statistics – Batch Requests/sec
SQLServer:SQL Statistics – Re-Compilations/sec. A high recompilation rate
may be indicative of non-representative statistics on one or more Tables.
SQLServer:Wait Statistics – Log write waits (Average wait time)
System – Processor Queue Length
6. Select File -> Save As and save the monitoring template for future use. For
example, save to your Desktop or save to the default folder of Performance
Monitor.
Note that each saved template is specific to the server since the specified Counters
include the name of the server.
Performance Tuning
Capture/Identification
Start with broad-brush tools such as Performance Data Collection or the DMVs.
These tools are minimally invasive, and Performance Data Collection is capturing
data 24x7.
Look at resource consumption on the server using tools such as Performance
Monitor.
Look for recurring, resource-intensive SQL statements.
Prioritize the recurring, resource-intensive SQL statements by the estimated
impact on the SQL Server database. A severe SQL statement that is only
executed once per day may be a lower priority than a moderate SQL statement
that is executed thousands of times per day.
If possible, identify the source of the SQL statement. The source may be from
the Siebel UI (user-induced), a customization (configuration or scripting),
integration (EAI), and so on.
If possible, reproduce the SQL statement and capture it using SQL Server
Profiler. The RPC:Starting event will include the actual SQL statement and is
invaluable when evaluating Execution Plans. See the example in Appendix 3 of
the document.
Evaluation
If possible, do all evaluation work against a Production-like database that
includes these considerations:
o Configuration parameters of SQL Server
o Identical schema (Tables, Columns, and Indexes)
o Same or similar volumes and distributions of data in the Tables and
Indexes
o Same or similar defragmentation levels and statistics on the Tables and
Indexes
Copy the SQL stream from the RPC:Starting event into SQL Server
Management Studio. Enable the Actual Execution Plan since it may be different
from the Estimated Execution Plan. Execute the SQL stream.
Review the Actual Execution Plan. Here it is useful to have the assistance of an
experienced Database Administrator since SQL tuning is a learned skill.
o Are the joins, constant values, and passed parameters allowing the
Optimizer to obtain a good, selective first hit?
o Could Index changes support a better first hit? Use caution with Index
changes since it could have an adverse affect on other SQL statements.
o Do Indexes support optimal joins after the first hit? This is generally not
a factor for Siebel-provided Tables and Indexes, but it may occur if
joining on an extension (X_) Column or a new (CX) Table.
The Database Engine Tuning Advisor (DTA) may be used to recommend Index or
Partition changes to the database.
Implementation
In addition to any configuration or script changes, remember that any Index
changes should be done using Siebel Tools in the Development environment.
This will ensure that schema changes are consistently propagated to all Siebel
environments.
Please see Appendix 4 in the document, which provides a sample of one approach to
identify and resolve a suboptimal Execution Plan.
4. In the Trace Properties dialog, click on the Events Selection tab at the top.
7. In the Performance events, enable the Auto Stats event if you want to be
aware of when an auto-update statistics event occurs in SQL Server.
8. In the TSQL events, enable all of the events. This will include the
SQL:StmtRecompile event, and this event shows when a cached Execution Plan
must be recompiled by SQL Server. Note that it is import to include the Column
EventSubClass in the trace if you want to see the reason for the recompile
event.
10. Click on Run to start a trace. It is then important that you validate that the
trace is capturing the needed events and columns/data.
11. If necessary, stop the trace, select File -> Properties, click on the Events
Selection Tab, and then adjust what events and columns are captured by the
trace. Start the trace again by clicking on Run.
12. Once you are satisfied with the trace properties, stop the trace and select File ->
Save As -> Trace Template. Save the trace template in the default folder with
an appropriate name (e.g. Siebel). When you start SQL Server Profiler at a later
date, you can select the trace template from the list of available templates.
Use caution when running SQL Server Profiler in a production environment. If the
Database Administrator needs to run a trace for an extended period of time then
consider creating a server-side trace (using sp_trace_create). This will tend to have
less impact on SQL Server.
Data Management Views (DMVs)
SQL Server 2005 introduced Dynamic Management Views (DMVs) for the Database
Administrator. DMVs continue in SQL Server 2008, and are further enhanced by the
performance-collection capabilities of the new Management Data Warehouse. DMVs
provide a simple and familiar interface (in the form of relational Tables) for gathering
critical system information from SQL Server.
DMVs are documented in SQL Server Books Online, and may be browsed in SQL Server
Management Studio by looking for all Views prefixed with the naming convention
sys.dm_.
Be aware that several DMVs only provide data since the last time the
procedure cache was cleared, or the last restart time of SQL Server (e.g. Index-
usage statistics in the DMV sys.dm_db_index_usage_stats). It is recommend that you
combine the data from the DMVs with the data in the Management Data Warehouse
when evaluating performance of the Siebel database.
To use:
1. Open SQL Server Management Studio.
2. Navigate to Tools -> Database Engine Tuning Advisor.
3. Select options in both the General and Tuning Options tabs.
Common Questions
Case-insensitive Search
A case-insensitive search allows the user or application to not worry about
inconsistencies in the data, and be guaranteed that the user or application will be
presented with all matching rows regardless of lower-case or upper-case data in the
database and predicates/filters in the SQL statement.
Use a case-insensitive collation (code page) for the Siebel database in SQL Server.
o Concerns: Must remember to use the tilda (~) character to invoke the case-
insensitive search. Resulting SQL statement involves multiple OR predicates
and LIKE pattern matching, and may result in poor performance.
Convert critical, existing search Columns to upper case (e.g. Account Name, Contact
Last Name).
o Benefits: Supported.
o Benefits: Supported.
o Concerns: New in Siebel 8.0, and not available in earlier versions of Siebel.
May be limited to particular Columns.
Dropping Indexes
Database Administrators are sometimes tempted to drop some of the numerous
Indexes provided by Siebel, since the complete physical schema (Tables and Indexes)
are created regardless of the functionality being used in Siebel. For example, in Siebel
7.8 the Activity (S_EVT_ACT) Table has over 15 Indexes defined in the default
Repository.
Use caution before dropping Siebel-provided Indexes. The Index might appear to not
be used based on data provided by a Data Management View (DMV), or the Index
might appear to have no value in the schema (e.g. all values for the Column(s) of the
Index are NULL). However, the Index might be used to optimize infrequent events
such as a Merge operation from a Siebel user.
Use of tools such as the Management Data Warehouse (combined with DMV’s) may be
able to provide this level of detail.
use siebeldb
go
select object_name(i.object_id) as 'Object'
, i.name as 'Index'
from sys.indexes as i with (nolock)
inner join sys.objects as o with (nolock)
on o.object_id = i.object_id
where i.index_id NOT IN
( select s.index_id
from sys.dm_db_index_usage_stats as s with (nolock)
where s.object_id = i.object_id
and s.index_id = i.index_id
and s.database_id = db_id('siebeldb')
)
and o.type = 'U'
order by object_name(i.object_id) asc
go
It is recommended that any Indexes be first inactivated in the Repository using Siebel
Tools, and then use the Siebel Database Utility to synchronize the Repository and the
physical schema. This will ultimately ensure a consistent schema across the Siebel
environments.
In SQL Server 2005 and SQL Server 2008, Database mirroring is primarily used for
increasing database availability, but it may also be used as a solution for near-real-time
reporting when it is desired to not have the reporting workload running against the
Siebel database. The intent is to have two database partners, have Siebel function
against the principal role, and have reporting function against the mirror role.
Partitioned Tables
Partitioned Tables were introduced in SQL Server 2005 and continue to be a supported
feature in SQL Server 2008. Partitioned Tables are typically used for Tables with a
large volume of data, such that the Table is easier to manage and maintain for the
Database Administrator. For example, an Activity Table (S_EVT_ACT) with 100 million
records takes more time to defragment and update statistics.
The criteria for identifying a Table as a candidate for partitioning are arbitrary.
Considerations:
How large is the Table? Large may be defined by both the average record width
and the total number of records.
Is much of the data in the Table static or historical? For example, a large
volume of data in the Activity (S_EVT_ACT) Table may not change after the
Activity is marked as Done.
Are the benefits worth the additional effort?
Are the business processes and transactions well understood such that the Table
can be partitioned to align with these business considerations?
The biggest impediment to the use of Partitioned Tables with Siebel is that
Siebel is not Partition-aware in Siebel Tools and Siebel Database Utility
(DDLSYNC). This means that schema changes cannot be applied, synchronized, or
confirmed using Siebel Tools or the Siebel Database Utility.
It is feasible to partition a Siebel Table so long as the Database Administrator and
Siebel Administrator understand that:
Partitioned Tables may or may not be implemented in the Siebel Development
environment. If not implemented in Development, Developers or the Siebel
Administrator will still be able to extend the schema or create/adjust custom
Indexes on demand for all Tables. If implemented in Development, only the
Database Administrator may implement any DDL changes for the partitioned
Table. However, the advantage to the latter approach is consistency across the
Siebel environments.
Manual coordination and workload will increase. The Siebel Database Utility
(DDLSYNC) will fail when attempting to apply a schema change against a
Partitioned Table. Consequently, schema changes will need to be manually
tracked and applied to Siebel environments (excluding Development).
The clustered Index on the Table is likely not aligned with how the Database
Administrator would like to partition the Table. This will require a redefinition of
the clustered Index for the Table that is not in sync with the Siebel Repository.
If planning to upgrade the Siebel product (e.g. 7.8 to 8.1) in the future and the
approach is to use Siebel’s upgrade processes/scripts, the Database
Administrator will likely need to remove the partitioning from the Table and
recreate Indexes such that the schema is completely in sync with the Siebel
Repository.
The choice of which Column to use to partition the Table is arbitrary - the Database
Administrator could use a Siebel-provided Column, or could add an extension Column
that represents a hash value. The Database Administrator must consider the following:
Cardinality. Does the selected Column provide the needed values to support the
envisioned and reasonably-balanced partitions?
Change. Does the value in the selected partitioning Column ever change?
Ideally the value should not change after the initial INSERT, since a change to
the value could cause SQL Server to move the record from one partition to
another partition.
Growth. How quickly will the Table grow? How does this align with the selected
Column?
Access. How do the online users and asynchronous processes typically access or
update the data?
Maintenance. How does the Database Administrator want to add or prune
partitions over time?
For DDL changes, note that the Siebel Repository has a last-updated timestamp on
every Table. The data in the Siebel Repository Tables may be of benefit for tracking
and confirming schema changes.
Tables. S_TABLE
Columns. S_COLUMN, joined to S_TABLE
Indexes. S_INDEX, joined to S_INDEX_COLUMN and S_TABLE
EIM Performance
Enterprise Integration Manager (EIM) is a Siebel-provided tool to perform bulk-data
operations.
EIM commits its changes to SQL Server per batch. Thus, rows in the EIM Table with the
same value for IF_ROW_BATCH_NUM will be processed and committed at the same
time to the base Tables. This is an important consideration when planning for
concurrent EIM tasks, or planning for EIM tasks concurrent with other workload (e.g.
online users).
the logical unit of work (LUW) contains more than 5,000 records
the LUW processes (INSERT, UPDATE, or DELETE) more than 20% of the
records in the Table.
These are two important rules of thumb relative to EIM, and both should influence how
the Database Administrator and Siebel Administrator plan and implement EIM in one of
four generic scenarios.
The Database Administrator may choose to temporarily disable Lock Escalation for one
or more base Tables before significant EIM activity. For example:
use siebel_db
go
alter table dbo.S_ORG_EXT set (LOCK_ESCALATION = disable)
alter table dbo.S_PARTY set (LOCK_ESCALATION = disable)
alter table dbo.S_ORG_BU set (LOCK_ESCALATION = disable)
alter table dbo.S_ACCNT_POSTN set (LOCK_ESCALATION = disable)
go
use siebel_db
go
alter table dbo.S_ORG_EXT set (LOCK_ESCALATION = auto)
alter table dbo.S_PARTY set (LOCK_ESCALATION = auto)
alter table dbo.S_ORG_BU set (LOCK_ESCALATION = auto)
alter table dbo.S_ACCNT_POSTN set (LOCK_ESCALATION = auto)
go
Plan for a moderate EIM batch size of perhaps 10,000 to 20,000 rows per batch
(directly controls the size of the LUW, or the COMMIT frequency to the base Tables).
Prepare a focused version of the script in Appendix 1. When invoked, the focused
script should defragment and recreate statistics for the EIM Table, and all of the
affected base Tables (e.g. EIM_ACCOUNT, S_ORG_EXT, S_ORG_BU, S_PARTY, etc.).
Don’t forget the intersection Tables!
Plan to NOT run concurrent EIM tasks if the data volumes are low(er), or until there
are at least 50,000 records in each base Table.
As the data in the base Tables quickly increase from no or minimal records, SQL
Server will automatically generate auto-updated statistics for the base Tables.
Expect to conclude all EIM tasks, and then run the focused script to defragment and
recreate statistics for the EIM Table and the base Tables.
Once complete, run the focused script to again defragment and recreate statistics
for the EIM Table and the base Tables.
Plan for a moderate EIM batch size of perhaps 10,000 rows per batch (directly
controls the size of the logical unit of work, or the COMMIT frequency to the base
Tables).
Prepare a focused version of the script in Appendix 1. When invoked, the focused
script should defragment and recreate statistics for the EIM Table, and all of the
affected base Tables (e.g. EIM_ACCOUNT, S_ORG_EXT, S_ORG_BU, S_PARTY, etc.).
Don’t forget the intersection Tables! For all of these Tables, consider increasing the
free space in the Table by reducing the FILLFACTOR parameter in the focused script
(e.g. set FILLFACTOR = 75, or 25% free for heavy INSERT operations).
Plan to initially NOT run concurrent EIM tasks that involve operations against the
same Siebel base Tables, until there are more than 50,000 rows in the base Tables).
For situations involving the need to load significant volumes of data (e.g. 10 million
Accounts), consider temporarily dropping some of the unneeded, non-clustered
Indexes on the Siebel base Tables being loaded by EIM. Use caution though, since
dropping a needed non-clustered Index may induce a separate performance
problem.
As the data in the base Tables quickly increase from no or minimal records, SQL
Server will automatically generate auto-updated statistics for the base Tables.
Expect to conclude all EIM tasks, and then run the focused script to defragment and
recreate statistics for the EIM Table and the base Tables.
Once complete, decrease the free space in the Table by increasing the FILLFACTOR
parameter in the focused script (e.g. set FILLFACTOR = 85, or a nominal 15% free),
and then running the focused script to again defragment and recreate statistics for
the EIM Table and the base Tables. Then use the Siebel Database Utility to
synchronize the Repository and the physical schema, and hence recreate any
dropped, non-clustered Indexes.
Consider a small EIM batch size of perhaps 1,000 to 3,000 rows per batch (directly
controls the size of the logical unit of work, or the COMMIT frequency to the base
Tables). The smaller batch size is technically less efficient, but it is assumed there
is an additional goal to avoid contention with online users.
Once complete and when able to take Siebel offline (or when workload is very low),
defragment and recreate statistics for the base Tables.
Consider a smaller EIM batch size of perhaps 3,000 to 5,000 rows per batch
(directly controls the size of the logical unit of work, or the COMMIT frequency to
the base Tables). The smaller batch size is technically less efficient, but it is
assumed there is an additional goal to avoid contention with online users.
Once complete and when able to take Siebel offline (or when workload is very low),
defragment and recreate statistics for the base Tables.
Appendix 1 – REINDEX Script
This generic script may be used for multiple scenarios by the database administrator.
Copy and paste the script into a query window in SQL Server Management Studio, and
then save for later use.
Notes:
By default, the script will defragment and update statistics for all Tables in the
database.
FILLFACTOR = 85. This equates to leaving 15% (100 – 85 = 15) free space
after defragmenting the Tables and Indexes. 15% is a very reasonable amount
of free space. It is not recommended to use a value of zero (0) or 100 for
FILLFACTOR since both values leave no free space. Similarly, it is not
recommended to use a value less than 75 (25% or more free space) for normal
operations. Consider using this sequence of commands to change the default
FILLFACTOR to 85 (15% free) for all future-created Tables in the database:
For very large Tables (e.g. 50+ million rows), it may be faster to exclude those
Tables from this script and take an alternate approach:
o Perform the ALTER operation on the Table and its clustered Index.
Remember to set an appropriate value for FILLFACTOR.
The script is not suitable for Partitioned Tables. Partitioned Tables should be
excluded by adding a simple predicate to the script.
SET ARITHABORT ON
SET QUOTED_IDENTIFIER ON
set nocount on
OPEN alter_table
WHILE @@FETCH_STATUS = 0
BEGIN
print convert(varchar(24), getdate(), 121) + ' ' + @exec_cmd
EXECUTE (@exec_cmd)
END
CLOSE alter_table
DEALLOCATE alter_table
go
Appendix 2 – Maintenance Plans
Simple maintenance will optimize the health of your SQL Server environments. The
Maintenance Plan Wizard may be used to define maintenance plans for the Siebel
database in each environment. Moreover, SQL Server Management Studio provides an
extensive design surface such that you can design an enhanced workflow for
maintenance-plan tasks.
Every day, perform a full backup of the Siebel database and transaction
log. Do this in all Siebel environments. Remember that Development likely
contains your master Siebel Repository.
Every 10-30 minutes, perform a transaction log backup for the Siebel
database. The combination of a full backup and the transaction logs will likely
allow the Database Administrator to perform point-in-time recovery if required.
You will likely have three to four maintenance plans for your Siebel database, and each
maintenance plan will have a different set of tasks:
The entire set of captured data in the RPC:Starting event should be used when
attempting to recreate the Execution Plan for the SQL statement. The initial
values for the internal parameters @p1 through @p7 are just as critical as the passed
parameters (Last Name like Smith*, First Name like John*, etc.). Note that the values
for @p1 through @p7 will be different in the RPC:Completed event.
LEFT OUTER JOIN dbo.S_POSTN_CON T10 ON T1.ROW_ID = T10.CON_ID AND T10.POSTN_ID = @P2
LEFT OUTER JOIN dbo.S_USER T11 ON T8.PR_EMP_ID = T11.PAR_ROW_ID
LEFT OUTER JOIN dbo.S_USER T12 ON T9.PR_EMP_ID = T12.PAR_ROW_ID
First, isolate the problem query in Management Studio (using the Performance Data
Collection):
In SQL Server Management Studio, open Management \ Data Collection \ Server
Activity
After the report opens, find the CPU spike under “% CPU Utilization” then click
on it
Management Studio will now generate a second report displaying your top 10
worst queries ordered by CPU time
Click on an individual query to drill down on the specific query. For example,
how many times it has been run, total CPU used, etc.
select top 10
e.plan_handle
, e.sql_handle
, (total_worker_time / execution_count) as
avg_worker_time
, s.text as query_text
, q.query_plan
, e.*
from sys.dm_exec_query_stats e
Once you have found a query of interest, confirm a suboptimal Execution Plan by
clicking on the “query_plan” hyperlink to automatically bring up the graphical
execution plan. When you are sure you have found the right query, keep your
results accessible. You will need it later, including the SQL Handle.
Next, to solve your short-term issues, remove the problem query plan from the
procedure cache using this command.
If all goes well, your CPU issues should be resolved. If yes, run this query. Compare
your results with the old version (such as comparing avg_elapsed_seconds,
avg_worker_time, etc.). You can also confirm the new Execution Plan is fixed by once
again clicking on the query_plan hyperlink and viewing the graphical Execution Plan.
select
e.plan_handle
, e.sql_handle
, (total_worker_time / execution_count) as
avg_worker_time
, s.text as query_text
, q.query_plan
, e.*
from sys.dm_exec_query_stats e