Skip to Content

How to reduce latency of table being replicated

This document describes ways to reduce latency of table which is being replicated by SLT.

According to SLT operation guide, Latency is defined as the length of time it takes until a data change to a source table has been committed to the target system database. 

Even if, real time replication is enabled in SLT, in some cases, there may be significant time lag to reciprocate the data from source to target system.

Ways to check and reduce the latency are listed below –

1. Ensure sufficient resources: Ensure enough resources are available in all the three participating systems (Source, SLT and target). Resources include

         a) System resource like RAM, CPU, Disk Space

         b) Work process/Jobs – In the source system, the number of available dialog work processes that are reserved for the replication should be equal to the no. of data transfer jobs running in SLT. If a lot of tables are selected for load / replication at the same time, it may happen that there are not enough background jobs available to start the load procedure for all tables immediately. In this case, one may increase the number of load job – assuming sufficient system resources are available.

2. Application log analysis: Check for the warnings and errors in the SLT application log(LTRC) ,SM21 ,ST22 etc. and resolve the same.

Some of the common errors:

        a) Time_out dump  – In application log ,if one finds that replication of any table is failing due to the timeout dump in the source system, increase the dialog runtime in the source system.

        b) Duplicate key – replication may get aborted due to duplicate key. To solve this, change the writing behaviour from Array insert to Array modify as mentioned in SAP note 1919356.

        c) Any DB/Space error in source or SLT – (Error like unable to extend Tablespace, unable to connect to DB, etc.) should be resolved.

3. Index creation – In case of big tables (>1 GB in size),it is good to create secondary index on the column which have largest number of distinct values. This improves the reading performance significantly. Also, look for the index being used by the logging table. It may sometimes help if reorganization of index is done.

4. Order of logging table index and Read function module – For maximum efficiency in replication, the IUC index of the logging table must have the same field order as the select statement which is reading the data from the logging table of source table. If there is any order mismatch , either drop the IUC index and recreate it or stop replication on table and again add it for replication.

5. Upgrade DMIS component – It is always recommended to upgrade the DMIS to the latest version. One possible cause for latency could be a temporary inconsistency in the logging table.  When an inconsistency occurs in the logging table, records will not get processed until the inconsistent record is once again updated in the source system. The system may be missing many notes actually.Therefore, it is good practice to stay current with correction notes.

6. Advance replication settings

          a)      Increase jobs for replication – For tables with a large volume of data (especially if they are cluster tables – where the read performance is about 70% compared to transparent tables), one can use the transaction Advanced Replication Settings (transaction IUUC_REPL_CONTENT or LTRS) to further optimize the load and replication procedure for dedicated tables.In the tab page IUUC PERF OPTION/performance options in LTRS, one can assign more jobs to run in parallel for a table or define a       sequence that should be considered if load and replication of tables should run subsequently.

         b)      Change reading type – switch the default reading type 3 to another more appropriate reading procedure. The following table compares the advantages and disadvantages of the three most important reading types:

Reading type.png

        c)    Parallel replication – Use parallel replication to speed up the replication of bigger tables and thereby reducing latency. Steps on how to enable parallel replication is described in detail by Tobias Koebler in his blogs  –

http://scn.sap.com/community/replication-server/blog/2013/10/04/how-to-enable-parallel-replication

http://scn.sap.com/community/replication-server/blog/2014/02/25/how-to-filter-on-the-initial-load-parallelize-replication

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Alexey Ukrainsky

    the most often reason for the latency time is that SLT makes committed read in the source system, i.e. only the records where DB commit already took place are replicated. Accordingly, if there’s a mass data operation on a table and many records are modified/inserted/deleted but DB commit is done at the very end, the whole time between the record creation and DB commit will be count as latency.   

    (0) 
  2. Pragyesh Parekh

    Thanks Kartik for useful information!

    There is one more thing that can be followed incase of ABAP Timeout dumps in source system

    (point 2.a of your discussion)

    Run stats optimizer report – IUUC_SET_LOGTAB_OPTIMIZER_STAT for logging table in source SAP system as per SAP note : 2212229

    This helped us resolve problem without increasing dialog workprocess runtime in source system.

    Regards,

    Pragyesh Parekh

     

    (0) 

Leave a Reply