How to Performance optimization during import

Performance during transport: Transports should be performed as quickly as possible to minimize system downtimes or to be able to make maintenance intervals as short as possible.

This describes the issues that generally are to be taken into account. The first section involves issues that have to be taken into account, while other sections refer to options that lead to further improvements under certain circumstances.

    1. Homework:

        a) On UNIX: If the transport directory is mounted using NFS, use at least NFS 4 and leave the transport profile parameter "lock_check_wait_time=0" (this is the default value). For more information, see 132536.
        If "lock_check_wait_time=n" is set, you can expect that the import of m transport requests spends approximately 3*n*m seconds with "sleep" alone. Therefore, you must have  n=0 as of approximately 100 transport requests and higher.

        b) On Windows: Deactivate opportunistic locks ( 690449).

        c) Use the "import all" strategy wherever possible.
        If you can use organizational measures to ensure that the sequence of transport requests in the queue is correct, you should ideally process it with the "import all" strategy. Even if you are still working with individual imports in the Q system, it may be an option for subsequent systems.

        d) If you work with the individual import strategy or if you use Transportation Management tools of SAP partners, you should consider 1008058.

        e) Let transport background jobs run on high-performance hosts without competion.
        The steps that are performed during an import are partially implemented in ABAP and are executed by SAP background processing. that the transport jobs (job name = RDD*, normally user = DDIC) without much competition run by other background jobs.
        For more information about control and about the server on which the transport jobs are running, see 1147300.

        f) Regular cleanup in the transport directory.
        Directories with too many files have a negative effect on performance on all platforms. Therefore, run "tp clearold all" regularly. This prevents the number of files in the subdirectories of <TRANSDIR> from becoming higher and higher and a performance bottleneck occurring at file system level.
        For more information about "clearold", see 312843.
        Also see the "System-specific log directories" paragraph in chapter 2 of this .

        g) On DB2/MVS: Use a current R3trans version for the import: Kernel release 700 or higher, R3trans version from August 05, 2008 or later.

        h) In MSSQL: Use a current R3trans version for the import: Kernel release 700 or higher, R3trans version from March 22, 2010 or later.

    2. Further options for accelerating imports:

        a) "Accelerated Import" for a large number of small transports
        If you usually have many transport requests to import that are relatively small, you should then set the parameter "acc_import=true" in the transport profile. This activates the "accelerated import" with which the import steps DataDictionary import and main import (and possibly also Commandfile import, for example, if vers_at_imp is set) are each processed by a single R3trans process, so that the overhead, which normally occurs if a separate R3trans process is started for each transport request, no longer occurs.

        b) Using "activatemerged=true" to activate the ABAP Dictionary for multiple small transports
        If you typically have to import many transport requests that contain ABAP Dictionary objects (for example, domains, data elements, tables, indexes, views, and so on), you must set the parameter "activatemerged=true" in the transport profile. This ensures that the system does not activate the ABAP dictionary for each request; instead, it performs a joint activation run for all ABAP Dictionary objects that were imported in an import queue. This omits the overhead that occurs due to multiple activations of several transported objects and their dependent objects. In addition, the internal parallel processing potential of the ABAP Dictionary activation program can be better used.
        One disadvantage of this option is that a collective activation log exists rather that an individual activation log for each transport request; the activation logs then contain only a reference to the collective log. If it is important that the developer can see "their" activation errors directly, we recommend that you do not use this option yet for the consolidation system and that you wait until additional systems have been delivered.

        c) Import with parallel processes
        If you usually have large transport requests to import (with 100 or more objects, for example, client transports), you can then set the parameter "parallel=n" in the transport profile, whereby n is the maximum number of parallel processes. Since the ideal values for n depend to a large extent on the hardware and the database, we recommend that you start with small values and increase them gradually.
        For more information, see 1127194.

        d) System-specific log directories
        By default, all of the logs that are generated during the transport are stored in the directory <TRANSDIR>/log. If you set the transport profile parameter SID_LOG_FILES = TRUE, all of the logs of the transport activities and in particular, all of the transport request-specific logs, are stored in system-specific subdirectories <TRANSDIR>/log/<SID>. As a result, the number of files in the log directory is drastically reduced, leading to a considerable acceleration at file system level.

        e) Selective language import
        Importing deletions into language-dependent tables is faster with the profile parameter "sli=true" and the R3trans version from March 04, 2010 or later, particularly in the database DB2/6000.

    3. Options for shortening the system downtime:

        a) Delaying ABAP generation (see 1069417 for more information)

        b) When you transport large datasets that are mostly in the target system (for example, client transports in existing clients)
        It is worth using the R3trans version of July 4, 2008 or later for the import, since a performance improvement is effective for the internal comparison of table entries as of this version.

        c) Limiting table cache size
        R3trans tries to save time during the import by merging the existing table entries with the table entries that are to be imported, and it writes only the modified part to the database, thereby reducing the write database accesses. To so so, the system creates a main memory area dynamically that is up to 2GB in size (the table cache). If the main memory that is required for this purpose is available virtually but not physically, the operating system starts with paging, which undoes the expected performance improvement. In this case, it is better to limit the main memory that is occupied by the table cache. R3trans then automatically switches to DELETE/INSERT so no functional disadvantage arises.
        You limit the table cache with the R3trans option "tcs=nnn", whereby nnn is the number of bytes (for example, "tcs=100000000").
        To set this R3trans option, see 103582.