| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
Previous |
Next |
View PDF |
This chapter discusses tuning for Siebel Remote that can enhance performance. It contains the following topics:
For more information about Siebel Remote, see Siebel Remote and Replication Manager Administration Guide on the Siebel Bookshelf. My Oracle Support also contains support documents that address performance issues for Siebel Remote.
Siebel Remote allows Mobile Web Clients (typically operating remotely, in disconnected mode on a laptop) to connect to a Siebel Server and exchange updated data and files, a process known as synchronization. Siebel Remote supports mobile computing by allowing field personnel to share current information with members of virtual teams of other mobile and connected users across the organization.
Siebel Remote uses server components in two component groups to manage the exchange of data and files. You must enable both of these component groups in order to use Siebel Remote. Additional component groups might also be required for your deployment.
The Siebel Remote component group (alias Remote) includes the following components:
Generate New Database (alias GenNewDb)
Replication Agent (alias RepAgent). This component is used by Siebel Replication Manager, and has no role in supporting Mobile Web Clients
Synchronization Manager (alias SynchMgr)
Transaction Merger (alias TxnMerge)
The Disconnected Mobile Synchronization component group (alias MobileSync) includes the following components that are used by Siebel Remote or Siebel Replication Manager:
Database Extract (alias DbXtract)
Parallel Database Extract (alias PDbXtract)
Transaction Processor (alias TxnProc)
Transaction Router (alias TxnRoute)
|
Caution: The MobileSync component group also includes some components that are used only by Siebel Mobile disconnected applications or Siebel Handheld applications. This component group is new as of Siebel Innovation Pack 2014. Several existing components were moved into this component group, mostly from the Siebel Remote component group. |
For information about how you can configure some of these components to optimize the performance of your Siebel Remote deployment, see "Tuning Siebel Remote Server Components".
Related Books Siebel Remote and Replication Manager Administration GuideSiebel System Administration GuideSiebel Mobile Guide: Disconnected
This topic describes how you can improve the performance of certain components on the Siebel Remote Server. It contains the following information:
This topic is part of "Tuning Siebel Remote Server Components". It provides tips to help you improve the throughput for the Database Extract (alias DbXtract) and Parallel Database Extract (alias PDbXtract) components.
For more information about component groups that you must enable to use Siebel Remote, see "About Siebel Remote".
Use Parallel Database Extract for extracting a regional database or extracting remote users who have very large visibility footprints. Some of the characteristics of Database Extract and Parallel Database Extract follow:
Parallel Database Extract can support only one task at a time. You cannot run multiple instances of Parallel Database Extract simultaneously, as you can do with Database Extract.
Parallel Database Extract takes advantage of servers that have multiple CPUs and RAID disc array by using multiple threads.
Database Extract by default uses a data file type of Bulk Copy format (BCP) to export data. This can lead to a faster time in extracting and initializing than if you use the data file type DAT.
The following list describes tips to improve the throughput for the Database Extract and Parallel Database Extract components:
Run multiple concurrent instances of Database Extract
You can increase throughput by running multiple concurrent instances of the Database Extract component. Each instance of the Database Extract component requires a temporary table. This table is called S_DOCK_INITM_N where N equals the value of the parameter TS Table Number (alias TSTableNum). TS Table Number specifies the number of the temporary table that serves the Database Extract component.
For example, if TS Table Number equals 1, then temporary table 1 (S_DOCK_INITM_1) serves the instance of the Database Extract component that is currently executing.
By default, 48 temporary tables are available for use. If you require additional tables, then you create them using Siebel Tools.
The recommended number of temporary tables to use depends on the database platform in use. For example:
Oracle Database
The number of temporary tables that you use depends on the size of the shared pool that this database server can access. If the size of the shared pool is less than 300 MB, then it is recommended that you use one temporary table and execute one instance of the Database Extract component. If the size of the shared pool is greater than 600 MB, then using one temporary table for each instance of the Database Extract component can increase throughput.
Microsoft SQL Server and IBM DB2
Use one temporary table for each instance of the Database Extract component that you execute. For example, if you execute eleven instances of the Database Extract component, then use eleven temporary tables.
Stop Transaction Router component
Stop the Transaction Router component if you are running multiple instances of the Database Extract or Parallel Database Extract component in order to avoid table locking.
Extract lists of users simultaneously
Separate users to be extracted into groups of 50 to 100 users per list and extract these lists of users simultaneously using the Database Extract and Parallel Database Extract components. These components extract the Enterprise visibility data for all users in the list once.
Set the Truncate TS table parameter to TRUE
Setting this parameter (alias TruncateTSTable) to TRUE can improve performance, because deletions from S_DOCK_INITM_N tables are usually logged and can take a long time.
Defragment tables
Defragment tables to which you intend to extract data and defragment S_DOCK_INITM_N tables.
For more information about the components and parameters described here, see Siebel Remote and Replication Manager Administration Guide. For more information about performance issues for the Database Extract component, see 477174.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Troubleshooting Steps 15.
This topic is part of "Tuning Siebel Remote Server Components". It describes how to resolve or avoid performance issues for the Transaction Router component (alias TxnRoute).
For more information about component groups that you must enable to use Siebel Remote, see "About Siebel Remote".
Performance issues for Transaction Router can arise from the following sources:
Visibility-related transactions
Docking rules and data distribution
Slow-running queries
Increasing Transaction Router throughput
Setting the Id Db Size parameter
For more information about Transaction Router performance issues, consult the following documents:
476759.1 (Article ID) on My Oracle Support. This document, previously published as Siebel Troubleshooting Steps 8, describes how to diagnose and resolve Transaction Router performance issues.
477816.1 (Article ID) on My Oracle Support. This document, previously published as Siebel Troubleshooting Steps 38, describes how to monitor and manage the transaction backlog for a Siebel Remote implementation.
If you diagnose the root cause of the Transaction Router performance issue to be visibility-related transactions, then consider the following two possible solutions:
Reextract all mobile users and regional nodes. For more information, see Siebel Remote and Replication Manager Administration Guide.
Allow the Transaction Router component tasks to continue processing until they clear the backlog.
Once the Transaction Router has processed all visibility-related transactions, the backlog will be processed more quickly. Starting additional Transaction Router tasks can also improve performance, but do not start more tasks than the Siebel Server or database engine can support.
If you diagnose the root cause of the Transaction Router performance issue to be docking rule related transactions, then it is advisable to request assistance from Global Customer Support. Create a service request (SR) on My Oracle Support. Alternatively, you can phone Global Customer Support directly to create a service request or get a status update on your current SR. Support phone numbers are listed on My Oracle Support.
When you log the SR, provide the following pieces of information:
RDBMS trace of the Transaction Router task
Transaction Router log files
.dx files that the Transaction Router is processing from the SIEBEL_ROOT\siebsrvr\Docking\txnproc directory
The results from executing the visrule script
For more information about the visrule script, see 476759.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Troubleshooting Steps 8.
If you diagnose the root cause of the Transaction Router performance issue to be slow-running queries, then consult your database administrator to determine the following:
All indexes are present and valid on the tables involved in the poor-performing queries. To determine if all indexes are valid and present, see Siebel Data Model Reference on My Oracle Support (Article ID 1572379.1).
Check whether the tables and indexes involved in the poor-performing queries require defragmentation.
The following factors can impact throughput for the Transaction Router component:
Large batch sizes for Siebel Enterprise Integration Manager (Siebel EIM)
It is recommended that, where possible, you reduce the size of the batch that Siebel EIM processes when it imports data. In addition, it is recommended that you log transactions to the Siebel File System rather than the Master Transaction Log (S_DOCK_TXN_LOG). For more information, see Siebel Enterprise Integration Manager Administration Guide.
Large batch size for Siebel Assignment Manager
Where possible, reduce the batch file size for Siebel Assignment Manager, because large batch files can impact the performance of the Transaction Router component. For information, see Siebel Assignment Manager Administration Guide.
In both instances, you need to decide if an increase in throughput for the Transaction Router component is more important than a decrease in throughput for the Siebel EIM and Siebel Assignment Manager components, before you make changes.
Increasing the size of the visdata.dbf file has been shown to help performance in certain situations. This file is a cached file used by the Transaction Router and Transaction Processor components. The size of the visdata.dbf file is determined by the value of the parameter Id Db Size, which is available for both of these components.
The value for this parameter must be the same in both components. If the value of the Id Db Size parameter is increased in one component, such as to 204800 (200 MB), then it must be changed in the other component.
This topic discusses how you can optimize the performance of a Mobile Web Client in a Siebel Remote deployment. It contains the following information:
For more information about performance tuning for Mobile Web Clients, see Chapter 5, "Tuning Siebel Web Client for Performance."
This topic is part of "Tuning the Mobile Web Client in a Siebel Remote Deployment". It discusses how you can modify values for the parameters specified in your Siebel application configuration file to optimize the performance of a Mobile Web Client.
The value of this parameter specifies the number of transactions that Siebel Remote applies to the local database before performing a commit. If you have an environment where a large number of transactions are constantly being created, then adjusting the value of DockTxnsPerCommit upwards might decrease the amount of time taken for initialization and synchronization tasks for large quantities of data. In such a scenario, test a variety of values (for example, 1000, 2000, 3000) and determine which value is best for your environment.
The DockTxnsPerCommit parameter appears in the [Local] section of your application configuration file. The default value is 500.
Set the parameter AutoStopDB to FALSE so that the SQL Anywhere database engine continues to execute after the user exits the Siebel application. This reduces the time required to restart the Siebel application at a later time. If AutoStopDB is set to TRUE, the SQL Anywhere database engine automatically closes down when you exit a Siebel application.
|
Note: For Siebel Innovation Pack 2015, the local database for the Siebel Mobile Web Client uses SAP SQL Anywhere. SAP SQL Anywhere is not available for new deployments after September 2015. For more detailed information on how this change affects Siebel Tools and Siebel Remote, see Siebel Release Notes on My Oracle Support for Innovation Pack 2015 (Doc ID 1996273.1). |
You set the AutoStopDB parameter in the [Local] section of your application configuration file. The default value is FALSE.
The amount of memory (especially cache) made available to the SQL Anywhere database engine is one of the major factors that can influence performance. The SQL Anywhere database engine uses memory for many purposes, but one of the major uses is to hold data that is accessed repeatedly, so that it does not have to retrieve data from the database each time it is needed.
You can configure how much memory is available to the cache by setting a value for the -c command line option in the ConnectString parameter of the siebel.cfg file. For example, the following entry:
-c15m -ch25m
allocates a minimum of 15 MB of memory to the cache. The value for the parameter (ch) indicates that the amount of memory allocated to the cache can be increased upwards to a maximum of 25 MB.
By default, the values for these parameters are expressed as a percentage of the total memory available. For example, the following entry:
-c5p -ch7p
specifies that a minimum of 5% of available memory be allocated to the cache memory and a maximum of 7%.
Allocating more memory to the memory cache of the SQL Anywhere database engine reduces the amount of memory that is available to other applications on the local computer.
As a guideline, use the difference between 80% of total computer memory and the amount of memory used by all applications on the computer during regular use. For example, if a local computer that has 512 MB of memory available uses 328 MB during regular use (after all applications including Siebel Business Applications are loaded), then you can allocate 82 MB of memory to the cache of the SQL Anywhere database engine.
Also conduct tests to determine an upper limit for the amount of memory that you can allocate to the SQL Anywhere database engine cache.
|
Caution: Do not increase the amount of memory allocated to the cache to a level that it results in paging. Paging is where memory utilization exceeds the total available memory and can cause reduced performance. |
Set the parameter SortCollation to binary to optimize the retrieval of data from the local database. The SortCollation parameter is not a default part of the application configuration file. You have to manually add it to the configuration file of your Siebel application. You set the value of SortCollation in the [Local] section of your application configuration file.
For more information about this parameter, see Siebel System Administration Guide. To determine the current status of SortCollation, see 477096.1 (Doc ID) on My Oracle Support. This document was previously published as Siebel Alert 801.
This topic is part of "Tuning the Mobile Web Client in a Siebel Remote Deployment". It lists some points that can help you to optimize data synchronization between your Siebel Mobile Web Client and Siebel Remote Server. Note the following:
Synchronize frequently
Synchronizing frequently reduces the number of transactions to transmit and commit for each synchronization session. The longer that a user waits between synchronization sessions, the more data there is to send.
Enable TrickleSync on the Siebel Mobile Web Client
Each time that a Siebel Mobile Web Client connects to your Siebel Enterprise network, TrickleSync performs database synchronization. For more information, see Siebel Remote and Replication Manager Administration Guide.
Use time-based filters to prevent sending data from server to client that is older than a specific date.
This topic is part of "Tuning the Mobile Web Client in a Siebel Remote Deployment".
One way to increase performance is to reduce the volume of data transmitted to the remote users. This can be best achieved by choosing the appropriate routing model.
Routing model choices provide a useful level of granularity in setting the size of a local database. In general, using appropriate routing models improves overall performance of a remote environment and helps decrease Database Extract times and increase Transaction Router throughput.
If none of the supplied routing models are appropriate, then contact Oracle Advanced Customer Services, who can help you to develop a routing model that is appropriate to your environment. Contact your Oracle sales representative to request assistance from Oracles Application Expert Services.
