Tuning Siebel Remote Server Components

This topic describes how you can improve the performance of certain components on the Siebel Remote Server. It contains the following information:

• "Increasing Throughput for the Database Extract and Parallel Database Extract Components"

• "Tuning the Transaction Router Component"

Increasing Throughput for the Database Extract and Parallel Database Extract Components

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.

Tuning the Transaction Router Component

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.

Visibility-Related Transactions

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.

Docking Rules and Data Distribution

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.

Slow-Running Queries

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 2285310.1).

• Check whether the tables and indexes involved in the poor-performing queries require defragmentation.

Increasing Transaction Router Throughput

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.

Setting the Id Db Size Parameter

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.