Advanced Options

The advanced options available for System Copy GT are:

Multiple commit sizes – This functionality allows to specify multiple numbers of entries per commit for selected tables. In some cases creating smaller intervals only for selected tables can help improve overall performance without massively increasing the total number of intervals to be processed in a program run. See example below:

Multiple name conversion – This option allows to include additional logical system name conversion in one single run. In addition to time performance improvement it is very convenient from a usability perspective. Furthermore, specific table list can be assigned to each individual additional conversion to improve performance. By doing this unnecessary update requests to the database can be avoided. See example below:

A number of additional options are also available as checkboxes, the details of each of these are described in more detail below the screenshot.

• Ignore check on old LS value – The standard operation of both BDLS and System Copy GT is to only update logical system fields with the specified input parameter “Old Logical System Name”. By selecting this checkbox, it overrides the restriction on the old logical system value and updates ALL records, regardless of their current value. Please ensure that this parameter is used appropriately. The default value is to turn this off. It is useful when previous BDLS executions have not been fully executed in the past.

• Process special objects – Prior to updating the logical system names of all relevant tables, some special tables must be updated. These include tables such as SOOD (SAP Office Documents). Equally, after all tables have been updated, some additional tables are updated. This parameter ensures that the standard BDLS process for updating these special objects is also performed. The default for this parameter is turned on.

• Randomize intervals – When updating tables through the use of parallel processing, locking of database rows is required during the commit scope. This is a function of the database and not the application. When the same table is updated concurrently, it can lead to instability if too many processes are updating the same table. To mitigate this restriction, the intervals (tables to be updated) is randomized so that the same table is not constantly updated “together” and instead are randomly spread out amongst the total interval set. This parameter is by default set to true and we recommend this is not changed.

• Dynamic Interval Key– System Copy GT offers two ways of interval generation. The first one is a simple and efficient algorithm which determines a number of up to three keys to break up tables by once at the beginning of interval generation for every table. This algorithm is set by default and applies when option Dynamic Interval Key is unchecked.
  If Dynamic Interval Key option is checked a second algorithm is applied for the interval generation instead. Dynamic Interval Key Generation works by determining the best number of keys by which to break up a table for every interval. This provides a more precise interval key and therefore quicker database access during the actual table update process of System Copy GT. The drawback is that the interval generation can take longer than the default algorithm.
  In general, it is recommended to use the default algorithm for most tables and only use Dynamic Interval Key Generation for disproportionately big tables or tables with long keys (e.g. 4 or more key fields). This can be specified in the Multiple Commit Sizes option as shown below:

• Ignore contents in bdlsexz – In certain situations table bdlsexz may be used concurrently by the standard tool. To avoid conflict you can ignore the contents of this config table when you run System Copy GT

• Postpone position log update – This option allows

The final section deals with Interval Generation, which is the process of breaking up all the tables involved with the BDLS run into the commit sizes.

• Parallel interval generation – Prior to the actual conversion step System Copy GT breaks up the tables to be converted into ranges of rows (intervals) that can be updated independently. Any one table can only be broken up sequentially but the same process can be conducted on multiple tables in parallel. Selecting this option can significantly improve overall performance.

• Number of jobs for interval – This determines how many parallel processes are allocated for this purpose

*Advanced option values are defaulted when you execute the program and the defaults are generally what you should execute with.