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

How to Handle a Large Transaction Backlog

This section discusses how to handle a large transaction backlog in the transaction log table.

With the System Preference Docking:Transaction Logging set to TRUE, your Siebel application will record transactions to the transaction log table (S_DOCK_TXN_LOG). The Transaction Processor (txnproc) is responsible for deleting entries from this table—after all txnprocs in the system have copied them to the Application server TXNPROC directory. Enterprise visible data will be routed to the active Mobile Web Clients.

The backlog is the number of transactions in S_DOCK_TXN_LOG, or large number of DX files in TXNPROC directory. For example, to see the backlog in the S_DOCK_TXN_LOG select count (TXN_ID) from S_DOCK_TXN_LOG. Alternatively you may wish to know the oldest transaction, for example select min(CREATED) from S_DOCK_TXN_LOG. However, a backlog of 1000 transactions is not usually considered a problem.

If you are experiencing a large number of rows in S_DOCK_TXN_LOG, or large number of DX files under TXNPROC directory, follow these steps:

1. Check that Transaction Processor and Transaction Router or Routers are running.

   In the Server Tasks view (Administration - Server Management > Tasks), use standard query techniques to find tasks for the Transaction Processor and Transaction Router components, and then check the Task State and Status for each such record. The Task State should be Running for both the Transaction Processor and the Transaction Router.

   At least one Transaction Processor, Router, and Merger are required per Remote server. Multiple Routers and Mergers can be run on one Remote server. Multiple Routers are often recommended.

2. Check that Transaction Processor is processing Transactions.

   Check by looking at the Administration - Siebel Remote > Processor Status view. Here you will find information about the last transaction and last file, created by Transaction Processor in the TXNPROC directory on your Siebel Server. Under normal circumstances and if there are not any problems, these keep increasing.

3. Check for old TP entries.

   There may be old transaction processor entries in the S_NODE table that are no longer in use; either they have been left active after an upgrade or perhaps they are associated to a Siebel server that is no longer in use. It is a best practice to make sure transaction processor entries that are not required are end dated.

4. Check for Transaction Processors without end dates.

   It is very important to make sure old transaction processors have end dates. For example, this may happen when a transaction processor is started and then not used on a server, postupgrade, or a transaction processor is started and then the server is uninstalled.

   To end date an old transaction processor, see Managing Backlog in the Transaction Log Table.

5. Changes in positional Hierarchy, Territory realignments, or large EIM loads can also create a large number of Transactions.

   The higher in the hierarchy you change, add, or delete one or more positions, the more transactions will be created.

   When using EIM, the parameter LOG TRANSACTIONS TO FILE defaults to TRUE. This means EIM will log transactions under the File_System\eim folder with only one marker logged into the S_DOCK_TXN_LOG table. If the parameter is set to FALSE, EIM will use set-based transaction logging to reduce database contention for S_DOCK_TXN log by only recording one txn per EIM set in S_DOCK_TXN_LOG.

   It can take some time for the Transaction Processor and the Router to work through the created backlog and route the changes to your mobile users. Multiple routers or reextracting the mobile users will speed up processing.

6. If you are still having a problem, contact Technical Support and provide Transaction Processor and Router log files with the following trace flags set:
   • Change the following log events (in srvrmgr):
     • evtloglvl sql=4
     • sqlParseandExecute=4
     • genericlog=4
   • Run the Siebel Remote component with SQL Flag=2, Trace Flag=1

In addition to the steps above, you should examine the indexes on S_DOCK_TXN_LOG and S_DOCK_TXN_SET.

The P1 index is on an ID column that counts upwards. Lower IDs are deleted. This can lead to many index leaf rows pointing to rows that are no longer there.

For this reason, you should rebuild the indexes in the S_DOCK_TXN_LOG and S_DOCK_TXN_SET tables regularly.