My Oracle Support Banner

Siebl Remote: Enhancement Requeste to prevent TxnProc inserts into S_DOCK_TXN_SKIP table (Doc ID 2083098.1)

Last updated on FEBRUARY 07, 2019

Applies to:

Siebel CRM - Version 8.1.1.14.3 [IP2014] and later
Information in this document applies to any platform.

Goal

In certain cases for 8.x versions, when there are remote transactions backlogs, this behaviour could be observed:

- when LSM and LAST_TXN_NUM are for some reason a lot behind the current TXN_ID range from S_DOCK_TXN_LOG table and most likely behind the MIN(TXN_ID) from table
- then TxnProc gets into this "skipping" mode - starts to insert records in S_DOCK_TXN_SKIP table - for a not too clear purpose - that an administrator could review those and take note about that (records in this S_DOCK_TXN_SKIP table are not helping much aside for this informational purpose)
- currently there are only 2 options: to perform some other interventions on TXNPROC status values (only if indicated by Tech Support team following a detailed review of the issue) or to wait until TxnProc comp would complete these useless series of inserts in that skipping table - for the only purpose that by txnskip tool or table truncate, those would be removed.
- in the time TxnProc would be doing these 'skip' inserts, no other txns would be processed, so backlog could grow.

For instance in one case - TxnProc log shows it would do a lot of such inserts:

---------------------------------------
GenericLog GenericDetail 4 00001629564a2eec:0 2015-11-17 17:47:25 Copying txns to app server
Trace TracingInfo 3 00001629564a2eec:0 2015-11-17 17:47:25 SkipReader: use TxnID '0' to skip pre-processed transactions...
Trace TracingInfo 3 00001629564a2eec:0 2015-11-17 17:47:25 SkipReader: LowScanMark is '0'.
Trace TracingInfo 3 00001629564a2eec:0 2015-11-17 17:47:25
*********************
Iteration: 0
GenericLog GenericDetail 4 00001629564a2eec:0 2015-11-17 17:47:25 2015-11-17 17:47:25 Iteration: 0
GenericLog GenericDetail 4 00001629564a2eec:0 2015-11-17 17:47:25 Copying txns from 0...
GenericLog GenericError 1 00001629564a2eec:0 2015-11-17 17:47:25
WARNING: A transaction gap of 128394229 has been detected after transaction 0.
Probable Cause: There maybe long running transactions in your system which are not committing transactions within the specified duration (600 sec).
Recommendation: Reduce the batch size of your transactions. This will allow the transactions to be committed to the database within the wait time window.
GenericLog GenericError 1 00001629564a2eec:0 2015-11-17 17:47:25 128394229 transactions have been skipped after transaction 0, because the gap occurred 362760 seconds ago and is older than the Processor's gap wait time ( 600 seconds).
GenericLog GenericDetail 4 00001629564a2eec:0 2015-11-17 17:47:25 128394229 transactions have been skipped and inserted into S_DOCK_TXN_SKIP after transaction 0, because the gap occurred 362760 seconds ago and is older than the Processor's gap wait time ( 600 seconds).
SQLParseAndExecute Statement 4 00001629564a2eec:0 2015-11-17 17:47:25
insert into SIEBEL.S_DOCK_TXN_SKIP (
ROW_ID, CREATED, CREATED_BY, LAST_UPD, LAST_UPD_BY, MODIFICATION_NUM, CONFLICT_ID,
NODE_ID, TXN_ID)
values (?, current_date, '0-1', current_date, '0-1', 0, '0',
?, ?)
SQLParseAndExecute Bind Vars 4 00001629564a2eec:0 2015-11-17 17:47:25 01:1-327U-1
02:1-31ZD-1
03:1
...

-- then it contains a total of 362959 occurrences of "insert into SIEBEL.S_DOCK_TXN_SKIP ("
---------------------------------------

 

Inserting a large number of records into S_DOCK_TXN_SKIP could take a lot of time and potentially block all other DB operations / impact performance; TxnProc would no longer process any txn / generate any DX, causing additional delays and txns backlogs.

Solution

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Goal
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.