Siebel Remote and Replication Manager Administration Guide > Troubleshooting Siebel Remote >

Troubleshooting a Large Transaction Backlog Problem

This topic describes how to troubleshoot the following situations:

• The S_DOCK_TXN_LOG table contains a large number of rows
• There are a large number of dx files in the txnproc folder

If the Enable Transaction Logging system preference is TRUE, then the Siebel application records transactions to the S_DOCK_TXN_LOG transaction log table. The Transaction Processor server component deletes entries from this table after the Transaction Processor server components copy the transactions to the txnproc folder on the Siebel Server. Siebel Remote routes visible data across the Siebel Enterprise to the active remote clients.

A transaction backlog is a situation that occurs if any of the following situations is true:

• A large number of transactions exist in the S_DOCK_TXN_LOG table.
• A large number of dx files reside in the txnproc folder.

To view the backlog in the S_DOCK_TXN_LOG table, you can run the following SQL query:

select count (TXN_ID) from S_DOCK_TXN_LOG

To determine the oldest transaction, you can run the following SQL query:

select min(CREATED) from S_DOCK_TXN_LOG

A backlog of 1000 transactions is not typically considered a problem.

For more information about:

• Avoiding a backlog when deactivating remote clients, see Deactivating a Large Number of Remote Clients.
• Troubleshooting performance problems that might be associated with the Transaction Router server component, see 476759.1 (Article ID) on My Oracle Support. This document was previously published as Troubleshooting Steps 8.
• The S_DOCK_TXN_LOG table, see Modifying the S_DOCK_TXN_LOG Table.

To troubleshoot a large transaction backlog problem

1. Log in to the Siebel Server with administrator privileges.

   For more information, see Logging In to the Siebel Server as an Administrator.

2. Make sure the Transaction Processor server component and all Transaction Router server components are running.
3. Navigate to the Administration - Server Management screen, and then the Server Tasks view.
4. Locate tasks for the Transaction Processor and Transaction Router server components.
5. Examine the Task State and Status for each record you locate in Step 4.

   The following value is the correct value for Task State for the Transaction Processor and the Transaction Router:

   Running

   Each Siebel Server requires at least one Transaction Processor, Transaction Router, and Transaction Merger. Multiple Transaction Routers and Transaction Mergers can run on one Siebel Server. It is recommended that you run multiple Transaction Routers, when necessary.

6. Make sure the Transaction Processor is processing transactions:
   1. Navigate to the Administration - Siebel Remote screen, and then the Processor Status view.
   2. Examine the information that describes the last transaction and the last file.

      The Transaction Processor creates this information in the txnproc folder on the Siebel Server. These values increase continuously in typical situations and when no problems exist.

7. Expire the Transaction Processor entries that are obsolete.

   Transaction Processor entries that are obsolete might exist in the S_NODE table. The transactions remain active after an upgrade or they are possibly associated with a Siebel Server that is no longer in use. To expire Transaction Processor entries that are not required, it is recommended that you enter an end date that has already occurred.

8. Expire each Transaction Processor that is obsolete.

   For more information, see Reducing the Transaction Log Table by Expiring Obsolete Transaction Processors.

9. If you have recently modified the positional hierarchy or to territories, then reextract the remote clients.

   For more information, see How Positions, Organizations, and Responsibilities Affect Access.

10. If you are using EIM, then set the LOG TRANSACTIONS TO FILE parameter to FALSE.

    For more information, see Using EIM to Create Multiple Siebel Remote Clients.

11. Examine the indexes on the S_DOCK_TXN_LOG table and the S_DOCK_TXN_SET table.

    The P1 index is on an ID column that increments. Siebel Remote deletes lower IDs. Index leaf rows might reference rows that no longer exist. It is recommended that you regularly rebuild the indexes in the following tables:

    • S_DOCK_TXN_LOG
    • S_DOCK_TXN_SET
12. If Siebel CRM is still experiencing a backlog, get help.

    For help with handling a large transaction backlog, see Getting Help from Oracle. Be prepared to send the log files of the Transaction Processor and Transaction Router server components with the following flags set:

    • Use Server Manager to modify the following log events:
      • evtloglvl sql=4
      • sqlParseandExecute=4
      • genericlog=4

        For more information, see Naming Conventions for Log Files and Configuring Traces for a Server Component.

    • Run the Siebel Remote component with the following values:
      • SQL Flag=2
      • Trace Flag=1