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

Last updated on JULY 11, 2017

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)
- this is why currently we have only 2 options: perform some other manual interventions on TXNPROC status values or 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 back...

For instance in one customer 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 128,394,229 records into S_DOCK_TXN_SKIP would take huge amount of time and potentially block all other DB operations / heavily impact performance plus would no longer process any txn / generate any DX, causing additional delays and txns backlogs.

Solution

Sign In with your My Oracle Support account

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

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms