Skip to Content
Author's profile photo Boris Zarske
Boris Zarske
February 16, 2016 1 minute read

Optimized behavior in latest version of heterogeneous system copy with table splitting

If you plan to perform a heterogeneous system copy with table splitting in the next time, make sure to use the latest version of the Software Provisioning Manager, as offered by Software Logistics Toolset 1.0 SPS16 or higher (available in SAP Help Portal at help.sap.com/sltoolset).

 

With former versions, the thread dispatcher of the Migration Monitor might get blocked due to waiting for the successful processing of pre-packages (which might be very long-lasting under certain circumstances), which holds the dispatcher off starting further R3load processes. As a result, this might lead to an undesired inhomogeneous distribution of R3load processes, where in certain migration phases, only a low number of R3load processes gets active. This is visible in the graph below, showing a low number of R3laod processes in the beginning phase of the migration, taken from an example migration case:

R3load_distribution.png

 

With the latest version of Software Provisioning Manager, this behavior got optimized, so that the thread dispatcher can postpone the processing of corresponding packages to avoid waiting times in the handling of splitting packages, leading to a more harmonized distribution of a higher number of R3load processes and with this, a significant shorter runtime of the migration.

 

This optimization applies to all heterogeneous system copies (including sequential export/import and parallel export/import using FTP or file share) – only exception: behavior for parallel export/import with Socket mode is not changed, as the Socket mode requires a certain in-line processing of split table packages, so that the processing of pre-packages cannot be postponed. For all other use cases using table splitting, use the latest version of Software Provisioning Manager to automatically benefit from this optimization.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Nicholas Chang
      Nicholas Chang

      Thanks for continuous features/performance improvement on SL area always! Awesome!

      May i know where you generate the R3load graph, is it from the result of migration, eg: r3load.csv file?

      Also, it would be nice if you can add in the result of R3load when running with SLT SPS16.

      Thanks again,

      Nicholas Chang

      Author's profile photo Boris Zarske
      Boris Zarske
      Blog Post Author

      Hello Nicholas,

      Thanks a lot for your kind feedback, really appreciated! I will forward it to the developer in charge!

      The R3load graph was generated - as you already guessed - simply by importing the r3load.csv file into a spreadsheet program, like Microsoft Excel (and slightly adapting the outcome). I guess this is okay from handling perspective (even better than directly generating and including a corresponding graph into the procedure itself, as this way, you can adapt it to your needs and the efforts should be not very high to generate it)?

      Thanks again,

      Boris